Until November 2025, DPDPA was a paper law. The Digital Personal Data Protection Act passed Parliament in 2023, but operational rules didn’t arrive until the Ministry of Electronics and Information Technology notified the DPDP Rules in November 2025. Now it’s live. Companies processing personal data of Indian residents have specific, dated obligations — and enforcement has begun.
For US SaaS companies with India operations, this creates an immediate compliance pressure that didn’t exist 18 months ago. If you have Indian customers, Indian employees, or even just Indian users on a free tier, you’re a Data Fiduciary under DPDPA. If you process at meaningful scale, you may be designated a Significant Data Fiduciary with elevated obligations including a mandatory India-based DPO, independent annual data audits, and Data Protection Impact Assessments.
At the same time, you almost certainly need SOC 2. Your enterprise buyers expect it. Your retention depends on it. And SOC 2’s Privacy criteria — the P series of the Trust Services Criteria — covers conceptually similar ground to DPDPA.
The temptation is to treat these as separate compliance projects. Don’t. The right approach is to design a unified privacy control set that meets DPDPA’s stricter, India-specific requirements and lets SOC 2 Privacy testing leverage the same evidence. One control framework. Two attestation outputs. This article shows you how.
What DPDPA actually requires
The DPDP Act 2023 plus the DPDP Rules 2025 establish a framework that combines elements of GDPR (notice, consent, rights) with India-specific innovations (SARAL approach to notices, sector-specific data localization). The core obligations for any Data Fiduciary include:
Lawful basis for processing. Almost exclusively consent for most categories of personal data, with limited “legitimate use” exceptions for things like employment relationships, legal compliance, medical emergencies. The default presumption is consent.
Notice to data principals. Under the SARAL approach, notices must be Simple, Accessible, Rational, and Actionable. The legal jargon-dense privacy policy is non-compliant. Notices need to itemize each data category, each processing purpose, and each recipient in plain language. Notices must be available in English and the data principal’s preferred language (one of 22 scheduled languages).
Consent management. Consent must be free, specific, informed, unconditional, and unambiguous. It must be capable of being withdrawn as easily as it was given. The DPDP Rules contemplate the use of Consent Managers — a new category of regulated entity that operates between Data Fiduciaries and data principals to manage consent records.
Data principal rights. Right to access, correct, complete, update, erase. Right to nominate. Right to grievance redressal. Companies must provide a clear mechanism for data principals to exercise these rights and must respond within prescribed timelines.
Data minimization and purpose limitation. Collect only what’s necessary for the stated purpose. Retain only as long as needed for that purpose. Delete or anonymize when no longer needed.
Security safeguards. Reasonable security to prevent unauthorized access, alteration, disclosure, or destruction. The DPDP Rules 2025 specify minimum technical and organizational measures.
Breach notification. Personal data breaches must be notified to the Data Protection Board of India within 72 hours of becoming aware. Affected data principals must be notified as soon as practicable.
Special obligations for children. Verifiable parental consent required for processing personal data of children (under 18). Tracking, behavioral monitoring, and targeted advertising directed at children is prohibited.
Cross-border transfer. Generally permitted, with the Central Government holding authority to restrict transfer to specific countries via notified rules. As of mid-2026, no restrictions on US transfers have been announced.
Significant Data Fiduciary obligations. If designated as SDF (criteria covered below), additional obligations include:
- Appointment of an India-based Data Protection Officer (DPO) accountable to the board
- Annual independent data audit
- Data Protection Impact Assessments for processing involving large-scale or sensitive data
- Periodic disclosure of specific information to the Board
What SOC 2 Privacy actually requires
SOC 2 Privacy is governed by the Privacy criteria (P1–P9) within the AICPA Trust Services Criteria. Unlike Security (Common Criteria), which is mandatory in every SOC 2 report, Privacy is one of the four additional categories (along with Availability, Processing Integrity, and Confidentiality) that you choose whether to include in scope.
The Privacy categories cover:
- P1 Privacy notice. The organization provides notice about its privacy practices.
- P2 Choice and consent. The organization offers choice and obtains consent regarding collection, use, retention, disclosure, and disposal.
- P3 Collection. Collection is limited to what’s identified in notice.
- P4 Use, retention, and disposal. Use is limited to stated purposes; retention and disposal follow defined criteria.
- P5 Access. Data subjects can access their personal information and obtain it for review.
- P6 Disclosure to third parties. Disclosure is limited and tracked.
- P7 Quality. Personal information is maintained accurately and completely.
- P8 Monitoring and enforcement. The organization monitors compliance and addresses complaints.
- P9 (in the 2017 criteria, this was combined). Newer versions of TSC may renumber.
If you scope Privacy into your SOC 2, the auditor will test that your privacy controls operate effectively over the audit period.
The cross-mapping
Here’s where it gets interesting. SOC 2 Privacy and DPDPA require substantially similar things, with India-specific overlays. Below is a working cross-mapping you can use as a starting point. (The full mapping with sub-criteria is available as a downloadable spreadsheet — sign up for The GCC Compliance Brief to receive it.)
Notice — DPDPA Section 5 ↔ SOC 2 P1
- DPDPA requirement: SARAL-compliant notice in English and preferred Indian language, itemized data categories, processing purposes, retention, recipients.
- SOC 2 requirement: Privacy notice provided to data subjects covering collection, use, retention, disclosure, and disposal.
- Unified control: Single privacy notice published in plain language, structured to itemize categories/purposes/recipients/retention per SARAL, available in English (default) plus Hindi and 2–3 other major Indian languages, with geo-detection serving the right version. Same notice satisfies both frameworks.
Consent — DPDPA Sections 6–7 ↔ SOC 2 P2
- DPDPA requirement: Free, specific, informed, unambiguous consent; capable of withdrawal; granular per purpose where reasonably practical.
- SOC 2 requirement: Choice and consent regarding collection, use, retention, disclosure.
- Unified control: Granular consent capture (per data category, per purpose), stored with timestamp and notice version, withdrawable via the same mechanism that captured it. Consent records exportable on demand.
Collection limits — DPDPA Sections 6, 8 ↔ SOC 2 P3, P4
- DPDPA requirement: Process only for the purpose for which consent was obtained or for legitimate use cases.
- SOC 2 requirement: Collection limited to information identified in notice; use limited to identified purposes.
- Unified control: Documented data inventory mapping each data category collected to each processing purpose, with consent or legitimate basis cited. Data Protection Impact Assessment for new processing.
Data principal/subject rights — DPDPA Sections 11–14 ↔ SOC 2 P5
- DPDPA requirement: Access, correction, completion, updating, erasure, nomination, grievance.
- SOC 2 requirement: Data subjects can access their information.
- Unified control: Self-service portal or documented manual process for data principal/subject requests, with response SLA (10 days target, 30 days maximum recommended), audit trail of requests and responses.
Disclosure — DPDPA Section 5 (notice of recipients), Section 8 (sharing) ↔ SOC 2 P6
- DPDPA requirement: Disclose recipients in notice; lawful basis for any sharing.
- SOC 2 requirement: Disclosure limited to what’s stated in notice; tracked.
- Unified control: Vendor/processor inventory with DPAs (data processing agreements), disclosure tracking, vendor risk assessments.
Security — DPDPA Section 8 ↔ SOC 2 CC6, CC7 (Security criteria)
- DPDPA requirement: Reasonable security safeguards.
- SOC 2 requirement: Logical and physical access controls, vulnerability management, monitoring.
- Unified control: Your full SOC 2 Security control set (which is already mandatory) directly satisfies DPDPA’s “reasonable security.”
Breach notification — DPDPA Section 8 + DPDP Rules 2025 ↔ SOC 2 CC7.5
- DPDPA requirement: Notify DPB within 72 hours; affected principals as soon as practicable.
- SOC 2 requirement: Documented incident response, including breach assessment and communication.
- Unified control: Incident response procedure with 72-hour DPB notification path, principal notification template, post-incident review process, evidence retention.
Retention and disposal — DPDPA Section 8 ↔ SOC 2 P4
- DPDPA requirement: Retain only as long as needed; delete or anonymize when no longer needed.
- SOC 2 requirement: Retention and disposal per documented criteria.
- Unified control: Data retention schedule by data category, automated deletion workflows, audit logs of deletions, anonymization procedures for analytics.
Monitoring and oversight — DPDPA SDF audits ↔ SOC 2 P8, CC1
- DPDPA requirement: For SDFs — annual independent audit; ongoing DPIA; DPO with board access.
- SOC 2 requirement: Monitoring of compliance; complaint and incident management.
- Unified control: Privacy governance program with DPO (or designated privacy lead), regular internal reviews, complaint logging, annual external assessment (the SOC 2 audit itself satisfies the “annual independent audit” expectation for SDFs in many cases, depending on how DPB interprets it).
What DPDPA requires that SOC 2 doesn’t
The overlap is substantial, but several DPDPA requirements have no direct SOC 2 counterpart:
India-resident DPO for SDFs. If you’re designated a Significant Data Fiduciary, you need an India-based DPO who is responsible for ensuring compliance with the Act, serves as the contact for data principals, reports to the board, and is accountable for breach notifications. SOC 2 doesn’t require any particular role.
Consent Manager framework. DPDPA contemplates Consent Managers — registered entities that handle consent collection and management on behalf of data principals. This is an emerging ecosystem in India. US SaaS may eventually need to integrate with Consent Managers for Indian users. SOC 2 has no parallel concept.
SARAL notice requirements. The specific plain-language, itemized format isn’t directly required by SOC 2, though SOC 2 implicitly expects clear notices.
Multi-language notices. SOC 2 doesn’t require notices in any specific language. DPDPA requires English plus the data principal’s preferred Indian language.
Children’s data protections. DPDPA has specific verifiable parental consent requirements and prohibits behavioral tracking/targeted advertising to children. SOC 2 Privacy mentions children’s data only in passing.
Cross-border restrictions. DPDPA gives government authority to restrict transfers; SOC 2 has no equivalent.
₹250 crore penalty regime. Driving board-level engagement that SOC 2 doesn’t typically trigger.
What SOC 2 requires that DPDPA doesn’t
A few items go the other way:
Trust services categories beyond Privacy. SOC 2 Security, Availability, Processing Integrity, Confidentiality cover terrain DPDPA doesn’t address — DPDPA is purely a privacy framework, not a broader security/operations framework.
Service organization perspective. SOC 2 is fundamentally about giving customer organizations assurance over your controls. DPDPA is about regulator-data-principal-fiduciary relationships. These structures interact but aren’t identical.
Auditor attestation language. SOC 2 produces a specific report format that customers consume. DPDPA contemplates audit but doesn’t dictate the format.
How to design a unified control set
Here’s a practical sequence:
Step 1: Data inventory. Build (or rebuild) your data inventory mapping every data category to: source, processing purpose, lawful basis (consent or legitimate use), retention period, recipients (internal and external), and storage location (US, India, EU, or other). Without this, neither framework’s controls work. With it, both become tractable.
Step 2: Notice unification. Rewrite your privacy notice to be SARAL-compliant: plain language, itemized data categories with corresponding purposes and recipients, retention statements, data principal rights, contact details. Publish English by default and Hindi at minimum. Use geo-detection to serve the right version.
Step 3: Consent capture. Implement granular consent capture per purpose. Store consent records with timestamp, notice version, IP address, user identifier. Build the withdrawal mechanism with the same UX prominence as the capture mechanism.
Step 4: Data subject/principal rights workflow. Build a request intake (form on your website plus email channel), an internal routing process to the team that can fulfill the request (engineering, support, legal), an SLA tracker (10 days target), a response template, and an audit trail.
Step 5: Vendor/processor management. Build a vendor inventory. Sign DPAs with all processors that touch personal data. Track sub-processors. Review annually.
Step 6: Retention and deletion. Set retention periods per data category. Build automated deletion or anonymization workflows. Generate deletion audit logs.
Step 7: Incident response with 72-hour DPB notification. Update your incident response procedure to include DPB notification within 72 hours of becoming aware of a personal data breach affecting Indian data principals. Create the notification template. Test the procedure annually via tabletop exercise.
Step 8: Privacy governance. Designate a privacy lead (DPO if you’re SDF or anticipating designation, otherwise a senior privacy contact). Establish a privacy committee meeting quarterly. Report to the board annually.
Step 9: SDF readiness. If you have meaningful Indian user volume, prepare for SDF designation: identify candidates for the India-based DPO role, scope the independent annual audit, build DPIA templates.
Step 10: Audit-ready evidence. Every control above should produce evidence: documents, logs, screenshots, signed agreements, training records. Centralize evidence collection so SOC 2 auditors can sample and DPDPA audits can verify.
The Significant Data Fiduciary question
If you have any meaningful Indian user base — say, more than 10,000 active Indian users, or you process data of Indian residents in sensitive categories like health or finance, or you’re an AI company training on data that includes Indian personal data — you should assume you’ll eventually be designated SDF.
The Central Government has not published quantitative thresholds as of mid-2026, and designations are happening case-by-case. But the trajectory is clear: SDF status will become common for any meaningfully-scaled US SaaS with Indian operations or users.
The practical implications:
- Recruit an India-based DPO. Roles are emerging in the ₹40–80 lakh range ($48K–$96K) for experienced candidates.
- Plan for the annual independent data audit. Auditors with SDF experience are scarce; book early.
- Build DPIA templates and a workflow. Major new processing initiatives will require formal DPIAs going forward.
- Brief your board. SDF status means board-level accountability.
Common implementation mistakes
Mistake 1: Treating DPDPA as a localization-only problem. Some teams update their India users’ privacy notice and call it done. DPDPA is far broader — consent capture, rights, retention, breach response all need rebuilding.
Mistake 2: Treating SOC 2 Privacy as optional. If you have any data subjects you communicate privacy promises to (you do — every SaaS does), SOC 2 Privacy should be in scope. Skipping it leaves a meaningful assurance gap.
Mistake 3: Building separate DPDPA and SOC 2 control sets. Wasteful and inconsistent. Build one set, test against both.
Mistake 4: Ignoring sectoral overlays. RBI rules for payment data, IRDAI for insurance, CERT-In directives. These can override DPDPA’s general permissibility and create localization or notification requirements you might miss.
Mistake 5: Underestimating the DPO role. Especially for SDFs, the DPO is a senior role with real authority and board reporting. Not a checkbox.
What this looks like inside an Attri Edge engagement
This kind of unified compliance build is exactly what the Active Retainer covers in months 2–4 of a typical engagement. We build the data inventory, design the unified control set, implement consent capture and rights workflows, prepare the privacy governance documentation, and run an internal DPIA. By the time SOC 2 audit kicks off in month 5–6, the Privacy criteria evidence is in place. By the time DPDPA compliance is reviewed by regulators or buyers, the controls are operating.
If you want to assess where you are on this and what the unified roadmap looks like for your specific situation, the $999 Diagnostic produces an Evidence Index Blueprint that explicitly maps your gaps to both frameworks and identifies your top 10 priorities. Book the diagnostic →
Related reading:
- The Complete Guide to SOC 2 for US SaaS Companies With India Teams — entity scoping, audit structure, control selection
- The GCC Compliance Encyclopedia — the full operational compliance reference for India GCCs
- The Compliance Automation Gap — why platform privacy modules don’t finish the DPDPA job