How to Map Data Flows to Third-Party Processors Under DPDP

Every Indian company processing personal data has a compliance blind spot in the same place: the third-party layer.

You know what data you collect. You have some sense of where it lives in your own infrastructure. You probably know the names of your major vendors. What you almost certainly don't have is a complete map of what data flows to which processor, under what contract, for what purpose, with what sub-processors downstream, and what happens to the data if the user withdraws consent.

Under Section 8(2) of the DPDP Act, you (the Data Fiduciary) remain liable for any processing of personal data by your processors. The Data Protection Board penalizes you, not your vendor. When a breach happens at your CRM provider's sub-processor's cloud infrastructure, you are the one on the hook.

This guide is a practical, step-by-step method for mapping the entire processor chain. It is written for CTOs, security leads, and compliance owners who need to build a real vendor inventory that survives audit and holds up under Section 8 scrutiny.

Why processor mapping is where most compliance programs fail

Across 300+ DPDP audits, the processor layer is the single largest gap. A typical pattern:

• The company lists 8 to 12 "major vendors" they can name from memory
• Discovery reveals 25 to 60 actual processors touching personal data
• Only 40% to 60% have executed Data Processing Agreements
• Almost none have sub-processor visibility
• Nobody has tested consent withdrawal propagation to any of them

The gap is not because compliance teams are careless. It is because processors accumulate silently. A marketing intern connects a new tool via Zapier. A product manager signs up for a session recording service. An engineer adds an error monitoring SDK. Six months later there are 15 new processors that never touched the compliance inventory.

Under DPDP Section 8(2) and Rule 6 of the DPDP Rules 2025, every one of these processors must be under a contract that binds them to DPDP-compliant processing. Every one is a potential breach source. Every one needs to be reachable when a user withdraws consent or requests erasure.

If you get the processor layer wrong, everything downstream is broken. A complete data map without processor visibility is incomplete.

The three roles you need to understand

Before mapping anything, understand the role classification. DPDP distinguishes three roles:

Data Fiduciary (Section 2(i)): The entity that determines the purpose and means of processing personal data. This is usually you. You decide what data to collect and why.

Data Processor (Section 2(k)): Any entity that processes personal data on behalf of a Data Fiduciary. They process according to your instructions, for your defined purposes. Examples: your email delivery vendor, your cloud storage provider, your analytics tool.

Independent Data Fiduciary: A third party that processes data for their own defined purposes, not on your behalf. Examples: credit bureaus (CIBIL, Experian, Equifax), payment aggregators when acting on their own regulatory obligations, marketing platforms that use your data for their own model training.

The distinction matters because obligations differ:

• Your relationship with a Processor is governed by a Data Processing Agreement (DPA). You control the processing.
• Your relationship with an Independent Fiduciary is a data-sharing arrangement. Both parties have independent DPDP obligations. The Data Principal has independent rights against each.

Getting the classification wrong creates compliance gaps in both directions. Treating an Independent Fiduciary as a Processor understates your compliance exposure. Treating a Processor as an Independent Fiduciary lets them off the hook contractually.

The step-by-step mapping process

Step 1: Discover every processor (not just the ones you remember)

Start with what you can enumerate:

• Your team's SaaS subscriptions (get this from Finance or from an SSO admin view)
• Your production infrastructure vendors (AWS, GCP, Cloudflare, etc.)
• Your marketing stack
• Your customer support stack
• Your analytics stack
• Your payment processors

Then find the ones you don't remember:

Network egress analysis. Check outbound traffic from production. Any destination domain you don't recognize is a candidate processor. Common findings: legacy A/B testing tools, dormant analytics pixels, retargeting SDKs, unused monitoring services.

Codebase scan. Search your codebase for common patterns:

• HTTP client calls to external APIs (grep for axios, requests, fetch, curl calls)
• SDK imports (search for import or require of common vendor packages)
• API keys and endpoints in environment variables (grep for common vendor URL patterns)

Zapier / Make / n8n audit. Any automation platform your team uses connects your systems to third parties. Enumerate every active workflow.

Browser DevTools on your own site. Load your production site with Network tab open. Every third-party domain making requests is a processor.

Mobile app analysis. Decompile or use tools like Exodus Privacy to enumerate SDKs bundled in your Android or iOS builds.

Finance and expense records. Any vendor showing up in expense reports for the last 12 months is a candidate. Legal already-approved list often lags actual usage by months.

The full discovery typically surfaces 2x to 5x the number of processors the team estimated.

Step 2: Classify each processor

For every processor discovered, capture:

Role classification:

• Data Processor (acts on your instructions)
• Independent Data Fiduciary (acts on their own purposes)
• Joint Fiduciary (rare, both parties determine purpose together)

The test: whose purpose is being served by the processing? If theirs, they are Independent Fiduciary or Joint. If yours, they are Processor.

Data flow characteristics:

• What data categories flow to them? (Name, email, phone, Aadhaar, PAN, financial data, device data, behavioral data)
• What is the purpose of the flow? (Authentication, marketing, analytics, support, payment)
• What lawful basis authorizes the flow? (Consent, Section 7 legitimate use, contract necessity)
• Volume: how many Data Principals' data flows to them?
• Frequency: is this a one-time transfer, batch, or continuous?

Cross-border transfer status:

• Is the processor Indian-incorporated or foreign?
• Where is data physically stored? (India, US, EU, other)
• If foreign, is the country on the DPDP restricted list? (List not yet published as of writing; watch for CG notifications.)

Sub-processor chain:

• Does the processor use sub-processors?
• Who are they?
• Where are they located?
• What data reaches them?

Getting sub-processor visibility requires actively asking your processors. Most SaaS vendors publish sub-processor lists (Segment, Sendgrid, Intercom, Mixpanel all do). For those that don't, put it in your DPA renewal negotiation as a mandatory clause.

Step 3: Verify DPA coverage

For every processor, verify a Data Processing Agreement is in place. The DPA must include (per Section 8(2) and Rule 6):

• Defined scope of processing (data categories, purposes, duration)
• Processor's obligation to process only on the Fiduciary's instructions
• Security safeguards (Rule 6 alignment)
• Confidentiality obligations
• Breach notification SLA (aim for 24 to 48 hours to you, to feed your 72-hour DPB obligation)
• Sub-processor consent or prior notification requirements
• Audit rights
• Data return or destruction on termination
• Indemnification for processor-caused breaches
• Governing law (Indian law preferred for enforceability)

Common gaps:

• SaaS vendors' standard terms don't include Indian-law governing clauses
• Breach notification SLAs longer than 72 hours (which makes your DPB obligation unmeetable)
• Sub-processor language that permits general consent (which loses your control over the sub-processor chain)
• Missing indemnification for processor-caused violations

If your vendor won't negotiate these clauses, you have three choices: escalate the risk internally, accept the residual liability documented in your risk register, or replace the vendor. There is no fourth option that keeps you compliant.

Step 4: Map the deletion propagation path

For every processor, document how consent withdrawal or erasure requests reach them.

API-based deletion (preferred):

• Sendgrid Suppression API
• Segment Deletion API (works for DPDP-style deletes)
• Mixpanel /api/2.0/engage/delete
• Klaviyo Data Deletion API
• Freshdesk / Intercom contact deletion endpoints
• Razorpay customer data deletion request
• HubSpot GDPR deletion (also works for DPDP)

For each, wrap the vendor's API in a consistent internal interface. Your DSR orchestration engine calls the internal interface; the interface handles vendor-specific quirks. This is the same propagation layer covered in DPDP compliance for engineering teams and the consent management implementation guide.

Manual deletion (fallback):

• Vendor support ticket process
• Contractual deletion request procedure
• SLA and evidence requirements

Manual processes will fail at scale. If more than 20% of your processors require manual deletion, that is a critical remediation priority. Either automate through API where available, or migrate off the vendor.

Sub-processor propagation:

• Confirm that when you send a deletion request to your Processor, they propagate it to their sub-processors
• Get this in writing in the DPA
• Verify through evidence at least annually

Step 5: Tier processors by risk

Not all processors carry equal risk. Tier them for prioritization:

Tier 1: Critical. Processors handling:

• Sensitive personal data (financial, health, biometric)
• Children's data (Section 9 exposure)
• Aadhaar or PAN
• Bulk data (>100K records)

Requires: full DPA, quarterly review, sub-processor visibility, tested deletion propagation.

Tier 2: Important. Processors handling:

• Standard personal data at material volume
• Data used for regulated processing (financial services, medical)
• Data whose loss would materially affect Data Principals

Requires: full DPA, annual review, sub-processor list at minimum, documented deletion path.

Tier 3: Standard. Processors handling:

• Limited personal data
• Non-sensitive processing
• Data with limited breach impact

Requires: DPA in place, biennial review, deletion capability confirmed.

Tier your inventory. Focus your compliance investment on Tier 1 first.

Step 6: Build the vendor evidence trail

For audit purposes, maintain per-processor evidence:

• Executed DPA (with countersignature and date)
• Vendor security posture (SOC 2 Type II report, ISO 27001 certificate, DPDP-specific attestation if available)
• Vendor privacy policy (their own compliance posture)
• Sub-processor list (if provided)
• Any breach or incident history involving the processor
• Periodic re-assessment records

Store this in a vendor management system, not a folder of PDFs. When an audit hits, you need query-able access to this evidence for any specific processor.

The mapping template

For every processor, capture:

For a mid-size company with 30 processors, this is a 30-row inventory. It becomes the operational core of your Section 8 compliance.

The seven mistakes to avoid

Mistake 1: Trusting the vendor's standard DPA without negotiation.

Most SaaS DPAs are GDPR-oriented. They lack DPDP-specific clauses (Grievance Officer references, Indian-law governing clauses, DPDP-aligned breach templates). Negotiate additions. Vendors negotiate more than you think for enterprise customers.

Mistake 2: Missing the sub-processor layer entirely.

You have DPAs with 30 direct processors. Each has an average of 4 sub-processors. Your actual data-touching entity list is 150+. When a breach happens at a sub-processor, you are still liable. Sub-processor visibility is your ceiling on liability control.

Mistake 3: Treating role classification casually.

Calling a payment aggregator a "processor" when they are actually an Independent Fiduciary understates your compliance exposure. Getting this right requires reading the actual contract and how each party defines its purposes.

Mistake 4: Assuming SOC 2 or ISO covers DPDP.

SOC 2 and ISO 27001 attest to security control frameworks. They do not attest to DPDP-specific obligations (consent architecture, Data Principal rights fulfilment, DPDP breach notification). A processor can be SOC 2 compliant and DPDP non-compliant simultaneously.

Mistake 5: Not testing deletion propagation.

Your process document says consent withdrawal propagates to Sendgrid. Nobody has ever verified that this actually happens end-to-end. Test data with real requests. Log the outcomes. When the auditor asks for evidence of Section 6(4) compliance, this test is the evidence.

Mistake 6: Static inventory in a dynamic environment.

Your vendor inventory reflects the state 8 months ago. Since then, three new processors were added and one was deprecated. Static inventory in a dynamic environment is dangerous because it looks like coverage when it isn't. Automate discovery cadence.

Mistake 7: No breach notification SLA in DPA.

Your DPB obligation is 72 hours. If your Processor's DPA gives them 72 hours to notify you, you cannot possibly meet your own obligation. Push for 24 to 48 hours from Tier 1 processors. Anything longer than 48 hours is a critical gap.

What to do if you're starting from scratch

If you have no processor inventory today:

Week 1: Discovery. Enumerate every processor through the methods in Step 1.

Week 2: Classification. Tier processors. Identify DPA gaps.

Week 3: Contract remediation. Start DPA negotiations for the top 5 Tier 1 processors without executed DPAs.

Week 4: Deletion path documentation. Map deletion mechanism for every Tier 1 processor.

Month 2: Extend Weeks 3 and 4 to Tier 2 processors.

Month 3: Continuous discovery instrumentation. Establish drift detection so new processors surface within 7 days of onboarding.

Ongoing: annual re-assessment cadence, quarterly reviews for Tier 1.

The self-audit

Answer these:

1. How many processors touch personal data in your infrastructure? (Not what you can name from memory; what would a network egress scan reveal?)
2. What percentage have executed DPAs with DPDP-compliant clauses?
3. For your top 10 Tier 1 processors, do you have a documented sub-processor list?
4. If a user withdraws consent right now, which of your Tier 1 processors will actually stop processing their data within 24 hours?
5. When was your vendor inventory last updated?

If you cannot answer 1 through 5 with confidence and current data, processor mapping is your compliance priority.

Where Privra fits

Privra runs continuous processor discovery across your infrastructure, from network egress analysis to codebase scanning to SaaS SSO audit. Our vendor management module tracks DPA status, sub-processor chains, deletion propagation testing, and risk tiering for every processor in your environment. When the environment changes (new vendor connected, existing vendor discontinued, sub-processor added), we surface it before it becomes a compliance gap.

Your compliance team gets the visibility to actually manage Section 8 obligations. Not a spreadsheet that was last updated 8 months ago.

Talk to us about processor mapping.