SOC 2 and DPDPA Compliance: One Control Set for Both

SOC 2 and the DPDP Act overlap where it is most expensive to build twice: security safeguards, access control, logging, incident response and vendor contracts. A SOC 2 control set covers most of what the Act asks a Data Fiduciary to do to protect personal data. A typical SOC 2 report does not cover notice and consent, the rights of Data Principals, children's data or grievance redressal, and holding a SOC 2 report is not compliance with the Act. An Indian company that needs both should build one control set and map it twice.

At a Glance

• What each one is: SOC 2 is a voluntary attestation report issued by a licensed CPA firm against the AICPA's Trust Services Criteria. The Digital Personal Data Protection Act, 2023 is Indian law, enforced by the Data Protection Board.
• Who asks for it: customers ask for SOC 2. The DPDP Act applies whether or not anyone asks.
• The date that matters: most Data Fiduciary duties under the DPDP Rules, 2025 come into force eighteen months after the Rules were published on 13 November 2025, which is 13 May 2027 unless the Rules are amended.
• Where they overlap: security safeguards, breach response, processor contracts, retention and disposal.
• Where they do not: notice, consent, Data Principal rights, children's data, grievance redressal and the extra duties of a Significant Data Fiduciary.
• The penalty SOC 2 work helps you avoid: up to Rs 250 crore for failing to take reasonable security safeguards to prevent a personal data breach.

Two Different Instruments

It helps to be precise about what each one is before mapping them.

SOC 2 is assurance you buy because a customer wants it. A CPA firm examines your controls against criteria and gives an opinion, and the report goes to customers under NDA. Nothing in Indian law requires it. Its scope is whatever system you define, and it treats all customer data alike, personal or not.

The DPDP Act is a statute. It applies to the processing of digital personal data in India, and to processing outside India connected with offering goods or services to people in India. It puts duties on the Data Fiduciary, the party that decides why and how personal data is processed, and it is enforced with financial penalties. There is no certificate and no report. You are either meeting the duties or you are not.

So the two answer different questions. SOC 2 tells a customer your system is run with discipline. The Act tells you what you owe the people whose data you hold.

Fiduciary or Processor: Work Out Your Role First

How much of the Act lands on you directly depends on your role, and most Indian SaaS and IT services companies hold two roles at once.

For the personal data inside your customers' accounts, you are usually a Data Processor. You process on the customer's behalf, and the customer is the Data Fiduciary. The Act places its duties on the fiduciary, including responsibility for what its processors do, and requires the fiduciary to engage a processor only under a valid contract. In practice that means your Indian customers will write security, breach reporting and deletion terms into your contract, and will ask for evidence that you meet them. A SOC 2 report is one of the most widely recognised forms of that evidence.

For your own employees, job applicants, website visitors and marketing contacts, you are a Data Fiduciary yourself, and the Act's duties apply to you directly.

This is why the two programmes belong together. As a processor, SOC 2 is how you answer your customers' DPDP-driven questions. As a fiduciary, the same controls protect the personal data you are directly accountable for.

Where SOC 2 Controls Meet DPDP Duties

The matrix below maps the Act's operational duties to the SOC 2 criteria that address them. "Covered" means a well-run SOC 2 control satisfies the duty with little change. "Partly" means the control exists but needs DPDP-specific content. "Not covered" means SOC 2 has nothing to say.

Two patterns are worth drawing out. Most duties in the top half are about protecting data, and SOC 2's Security category already demands the core of them; erasure and accuracy additionally need Confidentiality, Privacy or Processing Integrity in scope. Every duty in the bottom half is about a person's relationship with their own data, and Security does not reach it. The Privacy category does reach some of it, but most B2B companies leave Privacy out of scope, which is why the table says "a typical report". Our guide to the SOC 2 Trust Services Criteria explains when Privacy belongs in scope.

What SOC 2 Does Not Give You

The gaps are worth stating plainly, because a SOC 2 report in hand creates false confidence about them.

Notice and consent. The Act requires a notice describing the personal data and the purpose of processing, and consent that is free, specific, informed, unconditional and unambiguous, and that can be withdrawn with comparable ease. SOC 2 without the Privacy category does not look at any of this.

Data Principal rights. Individuals can ask what data you hold, ask for correction and erasure, and nominate someone to exercise their rights. You need a way to receive those requests, verify them and respond.

Grievance redressal. You must publish how a person can raise a grievance and deal with it within the period the Rules prescribe.

Children's data. Processing a child's personal data needs verifiable consent from a parent or lawful guardian, and tracking, behavioural monitoring and targeted advertising directed at children are prohibited, subject to prescribed exemptions.

Breach reporting to a regulator. SOC 2 tests that you have an incident response process. It does not test that the process ends in a report to the Data Protection Board. Our guide to DPDP Act breach notification sets out who must be told and when.

Significant Data Fiduciary duties. If the Central Government notifies you as one, you must appoint a Data Protection Officer based in India, engage an independent data auditor and carry out periodic Data Protection Impact Assessments.

Running Both From One Control Set

The mistake is to run two projects: a SOC 2 project owned by engineering and a DPDP project owned by legal, each with its own policies, its own vendor review and its own incident procedure. The controls collide, and the team maintains two versions of the same thing.

The better structure is one control set with two mappings.

1. Inventory personal data first. List what personal data you hold, where, why, and in which role. SOC 2 scoping needs a system boundary and DPDP needs a data map, and they are the same exercise done once.
2. Build the shared security controls. Access control, encryption, logging, change management, backup and incident response. Write each control once and tag it to the SOC 2 criterion and the DPDP duty it serves.
3. Extend the controls that are partly covered. Log retention of at least a year. Breach procedure with the Board and affected individuals as recipients. Vendor contracts with DPDP terms.
4. Add the DPDP-only layer. Notices, consent records, the rights request workflow, grievance contact, and children's data handling if it applies.
5. Collect evidence once. The access review that satisfies CC6 is the same access review that demonstrates a security safeguard. One evidence trail, read by the CPA firm and available if the Board ever asks.

A first SOC 2 Type 2 typically takes six to nine months including the observation period. With the main DPDP duties commencing on 13 May 2027, a company starting now can have the shared controls and the DPDP-specific layer operating by that date; the Type 2 report itself will usually follow it. How SOC 2 works in India walks through the SOC 2 side of that timeline.

The DPDP Dates

The Rules state intervals from their date of publication rather than calendar dates. The dates below are that arithmetic.

• 11 August 2023: the Act received assent.
• 13 November 2025: the Rules were published, and the provisions setting up the Data Protection Board came into force.
• 13 November 2026: one year after publication, Rule 4 on the registration of Consent Managers came into force. It does not oblige a Data Fiduciary to integrate a Consent Manager.
• 13 May 2027: eighteen months after publication, the remaining Rules come into force, including those on notice, security safeguards and breach intimation.

What SecureRoot Does, and Does Not Do

SecureRoot runs both programmes. For SOC 2 we do scoping, gap assessment, control design, evidence setup and audit support, at a published range of Rs 1.5 lakh to Rs 4.5 lakh, set out on our SOC 2 service page. For the DPDP Act we do data mapping, gap assessment, notices and consent design, rights workflows and breach procedures, described on our DPDPA compliance service page. When a client needs both, we build one control set.

Three limits. We are not a CPA firm and do not issue SOC 2 reports; a licensed CPA firm does, and its fee is separate. We are not a law firm, and questions of legal interpretation under the Act belong with your counsel. And there is no DPDP certificate for anyone to issue: no body is authorised to certify compliance with the Act.

Frequently Asked Questions

Does a SOC 2 report make a company DPDP compliant?

No. A SOC 2 report is an auditor's opinion on whether your controls met the Trust Services Criteria you scoped, and the DPDP Act is a law with its own duties, many of which SOC 2 does not examine at all. A typical report covers Security, which lines up well with the Act's requirement for reasonable security safeguards, incident handling and vendor oversight. It says nothing about whether you give a proper notice, hold valid consent, respond to requests from individuals, handle grievances or treat children's data lawfully. Those are, in our view, the duties most likely to draw complaints to the Data Protection Board, because they are the ones individuals experience directly. What a SOC 2 programme does give you is the security half of DPDP compliance already built and evidenced, which is often the more expensive half. The remainder has to be added deliberately and maintained alongside it.

Does the DPDP Act require Indian companies to get SOC 2?

No. Nothing in the Act or the Rules mentions SOC 2 or any other named standard. The Act requires a Data Fiduciary to protect personal data with reasonable security safeguards, and the Rules describe the kinds of measure expected, such as encryption, access control, logging and backups, without prescribing a framework. A company is free to meet that duty however it can demonstrate. In practice a recognised framework is the easiest way to show the safeguards were reasonable, because it gives you a structured control set and independent evidence that the controls operated. That is why companies building for the Act often choose SOC 2 or ISO 27001 as the backbone, particularly when overseas customers are asking for one anyway. The choice between the two is commercial: SOC 2 is asked for mainly by US buyers and ISO 27001 more widely elsewhere.

We are a B2B SaaS company. Are we a Data Fiduciary or a Data Processor?

Usually both, for different data. For the personal data your customers load into your product, you are generally a Data Processor: the customer decides the purpose and you process on its instructions, so the customer is the Data Fiduciary and carries the Act's duties, including responsibility for you. Your exposure there is contractual. The customer must engage you under a valid contract and will pass security, breach reporting and deletion obligations down to you. For personal data you collect for your own purposes, you are a Data Fiduciary and the duties apply to you directly. That covers employee and applicant records, sales and marketing contacts, website analytics tied to individuals, and often the account details of your customers' administrators. Map each category of personal data to a role before designing anything, because the answer decides which duties are yours by law and which arrive through a contract.

Should we add the SOC 2 Privacy category to cover the DPDP Act?

Only if you are a Data Fiduciary for the data in scope, and even then it is a partial answer. The Privacy criteria cover notice, consent, collection, retention, access and disclosure, which is the same territory as much of the Act, so a company that collects personal data directly from individuals can use them to have its privacy practices independently examined. Two cautions apply. The criteria are generic and were not written for Indian law, so meeting them does not establish that your notice or consent mechanism satisfies the Act's specific requirements. And for a processor, many of the criteria do not fit and end up marked not applicable. For most B2B companies the practical route is Security and Confidentiality in the SOC 2 report, with DPDP duties handled through a separate mapped layer in the same control set rather than through the audit.

Which should we do first, SOC 2 or DPDP compliance?

Start them together and let the deadlines set the emphasis. A SOC 2 project begins with scoping and a gap assessment, and a DPDP project begins with a personal data inventory, and both are the same discovery work looked at from two angles. Doing that once avoids the most common waste, which is two inventories that disagree. After that, the shared security controls serve both, so build them first. If a customer contract is waiting on a SOC 2 report, that sets the pace for the audit. The DPDP-specific layer, covering notices, consent, rights requests and grievance handling, can be built in parallel and does not depend on an auditor's calendar. With most Data Fiduciary duties commencing on 13 May 2027, a company that leaves the Act until after its SOC 2 report risks running short of time for the parts a typical SOC 2 report does not cover.

Where to Start

Begin with one list: every category of personal data you hold, where it sits, and whether you are fiduciary or processor for it. That list scopes the SOC 2 boundary and the DPDP gap assessment at once. If you want it done against your own systems, request an assessment and we will map both from the same inventory.