DPDP Act, SOC 2, ISO 27001: What Your India EOR Must Prove

Your India EOR just sent you a SOC 2 report, an ISO 27001 certificate and a line about the DPDP Act. What do you actually do with them?

This guide is for the security reviewer, GRC analyst or in-house counsel who owns employee data protection and has to clear an India EOR through vendor review.

We run India employment for global companies, so we see these questionnaires from the other side every week.

It covers what each document proves, what India's data protection law adds that neither of them covers, and the contract clauses that carry the real risk.

The frameworks tell you how a vendor works. Indian law tells you who answers for it, and only one of those lands on your balance sheet.

What is India's DPDP Act, and who does it apply to?

The Digital Personal Data Protection Act, 2023 is India's general data protection statute, and it was published in the Gazette of India on 11 August 2023. It applies to the organizations that decide why and how personal data is processed, called Data Fiduciaries, and to the vendors that process data for them. There is no separate DPDP 2025.

India's DPDP Act is the first Indian statute to give personal data a general framework rather than an IT-law appendix.

Who are the Data Fiduciary, the Data Processor and the Data Principal?

The Act names three roles, and every argument about EOR data protection turns on which one you occupy:

• Data Fiduciary: any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data, under section 2(i).
• Data Processor: any person who processes personal data on behalf of a Data Fiduciary, under section 2(k).
• Data Principal: the individual the data is about, which here is your employee or your candidate.

On an India team the Data Fiduciary decides why the data exists, and two companies can both qualify over the same person.

DPDP 2025 does not exist. The statute is the DPDP Act 2023, and what arrived in 2025 were the Rules made under it, which is a different instrument.

Most reviews open by asking for a data protection policy, and that is where a Fiduciary records how it applies these roles.

When do DPDP Act obligations actually bite?

India's data protection regime became operational in November 2025, when the Digital Personal Data Protection Rules 2025 were notified as G.S.R. 846(E). Commencement is staged: definitions and the Data Protection Board took effect on publication, Consent Manager registration one year later, and the substantive compliance duties eighteen months later, in May 2027.

The phasing is written into both instruments. Section 1(2) of the Act says it comes into force on such date as the Central Government may appoint by notification, and that different dates may be appointed for different provisions.

Rule 1 of the Rules then sets the stages as durations rather than calendar dates, which is why published summaries disagree about the exact day. Read the rule numbers instead, because those are unambiguous.

Until those duties commence your EOR's data obligations run through the older regime, while its filing duties run to the monthly India compliance calendar as usual.

Who is the Data Fiduciary when an EOR employs your India team?

The DPDP Act does not name EORs, so this is reasoned from its definitions. The answer is both, split by data set. For statutory payroll, provident fund and tax filing data the EOR is a Data Fiduciary in its own right, because it is the legal employer. For data it handles only on your instruction, you are the Fiduciary.

Here is the reasoning, because the Act does not do this work for you. India recognises one legal employer per worker, and under an EOR arrangement that employer is the EOR, which is the first premise behind is an EOR legal in India.

The second premise is section 2(i). A Data Fiduciary is whoever determines the purpose and means of processing.

For a provident fund filing, no company determines that purpose. Indian law does, and the EOR is the entity the law addresses.

So on statutory data the EOR is not acting on your instruction. It is acting on India's, which is the opposite of what a processor does.

Why a GDPR-shaped DPA maps badly onto India employment data

Most EOR data processing agreements cast the client as controller and the EOR as processor, copied across from a GDPR template.

For India employment data that mapping is wrong, and section 8(1) puts it beyond argument: a Data Fiduciary is responsible for compliance "irrespective of any agreement to the contrary", for any processing undertaken by it or on its behalf by a Data Processor.

A buyer who signs a GDPR-shaped DPA and assumes the EOR carries the DPDP exposure has assumed something the contract does not say.

This is a narrower question than co-employment vs joint employment in India, which asks who the employer is rather than who the Fiduciary is.

Whose balance sheet does the penalty land on?

Section 8(5) settles it in the statute's own words, and it is worth reading slowly.

A Data Fiduciary must protect personal data "in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach."

The Fiduciary's own duty expressly extends to what its Processor does. So wherever you are the Fiduciary, your EOR's failure is your failure as far as the Act is concerned.

The Schedule sets the price. Failure to take reasonable security safeguards may extend to INR 250 crore (INR 2,500,000,000), the highest single penalty in the Schedule. Breach of any other provision may extend to INR 50 crore.

Liability for a vendor's mistake is a familiar problem, and who is liable if your India payroll vendor makes an error follows the same logic: the duty sits with the party the law names.

Splitting the roles by data set is the most useful thing you can do in a vendor review, and it belongs in the same conversation as the rest of Employer of Record compliance.

What does a SOC 2 report actually prove, and what does it not?

A SOC 2 is an attestation report issued by a CPA firm, not a certification, so no organization is SOC 2 certified. It proves that an auditor examined the controls the vendor described, against the Trust Services Criteria the vendor elected. Only Security is mandatory, so a report can leave Confidentiality and Privacy untested.

Why nobody is "SOC 2 certified"

The AICPA's own language for a SOC 2 engagement is examination, attestation and report. There is no certificate, no certifying body and no pass mark.

The phrase is marketing shorthand. Correcting it in your own vendor register is worth the trouble, because it changes what you ask for next.

Which Trust Services Criteria were actually in scope?

There are five criteria, drawn from the 2017 Trust Services Criteria with points of focus revised in 2022, and the vendor elects how many to be examined against:

• Security: the only mandatory criterion, so every SOC 2 report covers it.
• Availability: whether the system is there when it is needed.
• Processing Integrity: whether processing is complete, valid, accurate and timely.
• Confidentiality: how information designated as confidential is protected.
• Privacy: how personal information is collected, used, retained and disclosed.

So "we have a SOC 2" can honestly mean Security alone, which is the criterion least likely to answer what a privacy reviewer is asking.

Type I, Type II, and why the period is the buyer's lever

A Type I report opines on the design of controls at a single point in time. A Type II opines on operating effectiveness across a period.

Type I proves they wrote the policy. Only Type II is evidence they followed it.

The observation period is where your leverage sits. A Type II period commonly runs twelve months, and shorter windows of three to six months are typical only for a first report.

The mechanics of how an EOR keeps employee data secure are a separate question from the evidence that those mechanics were examined.

Reading a report for what it excludes rather than what it claims is the same discipline as the rest of EOR risk management.

How do you read the SOC 2 report your EOR sent you?

Read it in five moves. Check the system description to see which entity and which services were in scope. Confirm it is a Type II and read the observation period. Then read the auditor's test results, the controls the report expects you to run, and the date the period closed.

Here are the five moves, in the order that saves you the most time:

1. Read the system description first: it names the legal entity and the services examined, and an India delivery operation is not always the entity on the cover.
2. Confirm the report type and the period: a Type II states an observation window, and a first report covering three to six months is normal rather than a red flag on its own.
3. Go straight to the test results: this is where the auditor records what did not work.
4. List the controls you are expected to operate: the report assumes you run some of them, and an unowned control is a gap nobody is watching.
5. Check the closing date: the window is historical, so a period that ended more than twelve months ago says little about today.

Each of those takes about ten minutes, and together they answer more than any questionnaire you could send.

Scope, period and the closing date

The system description defines the boundary of everything else in the report. If it names a parent entity while your service is delivered by a subsidiary, the report may not cover the operation running your payroll.

It also names the platforms examined, which matters when you are assessing EOR technology integration alongside the data question.

A stale report is a real finding, not a formality, because the report describes a closed historical window rather than the company you are about to sign with.

The test results and the controls you are expected to run

The auditor's testing sits in the report's trust services criteria and tests-of-controls section, conventionally Section 4, though firms number their reports differently. Read the results column rather than the opinion.

Each control comes back one of three ways: no deviations noted, deviations or exceptions noted, or no instances of occurrence. That last one means the control was never triggered during the period, so it was never tested, and it is the line buyers most often read as a pass.

Complementary user entity controls are the controls you must operate for the vendor's controls to work as described. Ignoring that list is how a buyer quietly inherits a control nobody on either side is running.

Treat it as your own to-do list and fold it into an EOR compliance audit rather than filing it with the report.

What a bridge letter is, and what it is not

A bridge letter sits on the service organization's letterhead and is signed by the service organization, not by the auditor, covering the gap between the report's period end and today.

Because the auditor does not sign it, nobody is attesting to the control environment during that gap. Practice caps it at about three months, and it never replaces a report.

A report read this way tells you a great deal. The certificate that arrived beside it works on entirely different principles.

How do you read the ISO 27001 certificate your EOR sent you?

Start with the scope statement, not the logo. ISO/IEC 27001:2022 certifies an information security management system of a declared scope, not a company, so a certificate can cover one office or one product line and say nothing about the operation running your payroll. Then read the Statement of Applicability and confirm the certificate.

Why the scope statement matters more than the logo

Read the scope line, not the logo. That is the practical consequence of how ISO/IEC 27001:2022 defines certification: the organization sets the boundaries of its own information security management system, and the certificate reaches exactly that far and no further.

So the first thing to read is the scope statement, usually one sentence naming sites, services and sometimes a specific platform.

We have read certificates whose scope covers a head office and a development center while the payroll operation sits in a third location that is never named.

What the Statement of Applicability tells you that the certificate does not

The Statement of Applicability records which Annex A controls apply, which are excluded, and the justification for each exclusion, under clause 6.1.3.

Annex A of the 2022 revision carries 93 controls in four themes: Organizational, People, Physical and Technological.

The certificate tells you a management system exists. The Statement of Applicability tells you what it decided to leave out, which is the cheapest upgrade available to EOR vendor selection.

Accredited, not accredited, and how to check

Anyone can print a certificate. Accreditation is what independently confirms the certification body's competence, so check that the body is accredited and that its accreditation body is a signatory to the Global Accreditation Cooperation Incorporated arrangement, which replaced the International Accreditation Forum and ILAC arrangements on 1 January 2026.

In the United States that accreditation body is ANAB, and in the United Kingdom it is UKAS. Certification bodies are themselves assessed against ISO/IEC 27006-1:2024, whose transition period closed on 31 March 2026, so a body still working to the withdrawn 2015 edition is behind.

The CertSearch database confirms a certificate and the accreditation standing behind it, which turns a five-email exchange into a lookup (as of August 2026).

Evidence you can verify yourself beats evidence you have to trust, and that principle carries through how to choose an Employer of Record.

Why are two Indian privacy regimes running at once?

Because the DPDP Act's repeal provision has not commenced. The SPDI Rules 2011 and sections 43A and 72A of the IT Act 2000 are still in force as of August 2026, and they fall away only when that provision takes effect, eighteen months after publication of the Rules, in May 2027. Until then your EOR owes obligations under both.

The provision has a number, and it is worth quoting in a vendor conversation. Section 44(2)(a) of the DPDP Act omits section 43A of the IT Act 2000.

Section 44(2)(c) omits section 87(2)(ob), the rule-making power under which the SPDI Rules were made.

So the SPDI Rules do not die by repeal. They die because the power that created them is removed, and that removal sits on the same commencement clock as everything else.

Two Indian privacy regimes are in force at the same time. The Digital Personal Data Protection Act, 2023 is enacted, and its own section 44(2) is the clause that will retire the SPDI Rules 2011, so until that subsection commences an India vendor answers to both.

Overlapping commencement is a familiar pattern in Indian law, and India's four Labour Codes went through the same staged process.

Ask your EOR which regime each of its controls was designed for, and treat the answer as part of statutory compliance in HR in India.

How should an India EOR handle Aadhaar, PAN and data leaving India?

Aadhaar authentication stays voluntary, because the 2019 amendment confines mandatory use to an Act of Parliament and routes private access through a UIDAI-approved agency. So an EOR should collect it only where a lawful route applies and delete the raw number once authentication is confirmed. Cross-border transfer is permitted by default under section 16.

What can an employer lawfully do with Aadhaar?

Aadhaar is India's 12-digit national identity number, and it is the identifier vendors ask for most often. Aadhaar authentication is voluntary, and it cannot be forced on a hire.

Section 57 of the Aadhaar Act 2016, which had let any body corporate use Aadhaar under a law or a contract, was struck down by the Supreme Court in 2018 and then formally omitted by section 25 of the Aadhaar and Other Laws (Amendment) Act 2019. Both things happened, and most summaries mention only the first.

Section 4(7) now allows mandatory authentication only where an Act of Parliament requires it, and section 4(6) obliges a requesting entity to offer alternate and viable identification and forbids denying service to anyone who refuses or cannot authenticate. A voluntary route does exist, but it is gated: under section 4(4), UIDAI must be satisfied that the entity meets the privacy and security standards set by regulations and is either statutorily permitted to offer authentication services or is seeking it for a purpose the Central Government has prescribed.

In practice an employer reaches Aadhaar through a UIDAI-approved requesting entity, an Authentication User Agency or an e-KYC User Agency under the Aadhaar (Authentication and Offline Verification) Regulations 2021. Section 29(1) bars core biometric information from being shared with anyone for any reason whatsoever, and section 29(3) confines identity information held by a requesting entity to the purposes disclosed to the individual in writing at the time of collection, in clear and precise language (as of August 2026).

Identity checks usually sit inside background checks in India, where identity verification returns in one to two days, the average turnaround is seven to ten business days, and a standard package runs seven to fifteen business days.

Can your India employee data leave India?

Section 16(1) works as a negative list. Transfer of personal data outside India is permitted by default, and the Central Government may restrict a named country or territory by notification.

Section 16(2) is the part buyers miss. Nothing in section 16 displaces any Indian law in force that provides a higher degree of protection or a stricter transfer restriction, so sectoral rules still apply on top.

The Rules then add a localisation trigger the Act itself does not contain. Under Rule 13(4) of the DPDP Rules 2025, where the Central Government specifies a category of personal data on the recommendation of a committee it constitutes, a Significant Data Fiduciary must ensure that data, and the traffic data about its flow, are not transferred outside India. Rule 15 separately lets the Government set conditions on making personal data available to a foreign State or its agencies.

So the honest answer to your reviewer is that there is no general bar today, and there is a mechanism by which specified categories can be pinned to India tomorrow. Ask your EOR whether it could comply if that mechanism were used.

Data leaving India and intellectual property leaving India are governed differently, which is why protecting IP when hiring in India belongs in its own clause.

What about PAN and payroll identifiers?

PAN is India's permanent account number, the tax identifier collected so withholding can be reported against the right person. That makes it statutory employment data, and it lands on the EOR side of the split from earlier in this article.

The same split governs verification data, so agree in writing who is Fiduciary for criminal record checks in India before the first candidate is screened.

What should the contract say about data, from breach clock to exit?

Six things, and none of them are in the framework reports. Allocate the Fiduciary and Processor roles by data set. Set a breach notice SLA that starts at your vendor's awareness. Require a named subprocessor list with notice of change, cross-border terms, evidence refreshed on a schedule, and a data return and deletion deadline on exit.

These clauses belong in a master services agreement rather than in a schedule nobody opens at renewal.

Employee-facing notice and consent language is a different document, and it sits with employment agreements in India.

Why the breach clock is a vendor SLA, not just a statute

Section 8(6) of the Act requires a Data Fiduciary to intimate the Board and each affected Data Principal "in such form and manner as may be prescribed". The Act itself sets no breach notification timeline, which is why the timing lives in the Rules.

Rule 7 of the DPDP Rules 2025 splits the clock three ways, and the first two are stricter than the seventy-two hours most vendors quote. On becoming aware of a breach, the Data Fiduciary must tell each affected Data Principal without delay, in concise and plain language, covering the nature, extent and timing of the breach, the consequences likely to affect that person, the mitigation measures implemented and being implemented, the safety steps that person can take, and a business contact who can answer their questions.

The Board gets a description without delay as well, including the location of occurrence and the likely impact. Only the detailed follow-up report to the Board sits at seventy-two hours of becoming aware, and the Board may allow longer on a request made in writing.

So the clock starts on awareness, not on notification. If your EOR becomes aware first and you are the Fiduciary, your own duty is already running while you know nothing, which is why the contract must oblige your EOR to tell you the moment it becomes aware rather than within a fixed window.

Rule 7(1) also requires the affected employee to be told directly, with those five items. Your EOR holds the communication channel to your India team, so the agreement has to say who drafts that notice and who sends it.

Failure to give notice of a breach may extend to INR 200 crore (INR 2,000,000,000), which is what makes the clock worth negotiating rather than accepting.

Which subprocessors should your EOR name?

Ask for the list by function, because the names change more often than the functions do:

• Payroll bureau: the processor that produces the payslips and the bank file.
• Background verification vendor: identity, education, employment and criminal record checks.
• Benefits broker: insurance and benefits administration, which carries health data.
• Equipment vendor: device provisioning and asset recovery, which carries home addresses.
• Authentication or e-KYC User Agency: the UIDAI-approved route for any identity authentication.

Then require notice of change in writing, because a subprocessor you have never heard of is a transfer you never approved.

What should the exit and data-return terms say?

Start from section 8(7)(b), which requires a Data Fiduciary to cause its Data Processor to erase any personal data the Fiduciary made available for processing.

Deletion on exit is therefore a statutory duty rather than a concession you win at the table. The contract's job is to make it verifiable and time-bound.

So specify the return format, a signed deletion confirmation, a deadline in days, and who bears the cost of both.

Exit terms get tested when you move, so read how to switch your Employer of Record while you are still negotiating rather than when you need it.

The same clauses matter in the other direction when a team moves between structures, which is the practical half of how to close an Indian subsidiary without losing your team.

Which questions should you send your India EOR?

Eleven, and they should go in one email rather than a 200-row spreadsheet. Six ask for evidence you can verify yourself: the report, the certificate, the scope statements, the Statement of Applicability, the accreditation record and the test results. Five ask for commitments that belong in the contract rather than in a questionnaire answer.

Vendor review is one part of a wider set of legal considerations for India outsourcing, and the data questions are the ones most often skipped.

Which six questions ask for evidence you can verify yourself?

Send these six together, and expect documents rather than prose:

1. The full report: not the summary and not the badge, including every section.
2. The system description scope: which legal entity and which services were examined.
3. The report type and observation period: Type II, with start, end and closing dates.
4. The tests-of-controls results: the auditor's findings in full, including anything recorded as no instances of occurrence.
5. The ISO 27001 scope statement: the exact wording on the certificate, plus its validity dates.
6. The Statement of Applicability and the accreditation record: which controls were excluded and why, plus the CertSearch entry for the certificate.

Every one of those already exists, so a delay in producing them is itself an answer.

Which five questions ask for a commitment rather than a document?

The other five belong in the contract, so put them to the commercial owner rather than the security team:

1. Which party is Data Fiduciary for each data set: payroll, tax, benefits, verification and performance data, named individually.
2. How long from your awareness of a breach to our notification: a trigger and a number, not "promptly".
3. Which subprocessors touch our employee data, by name: with written notice before any change.
4. Where our data is stored and processed: and whether you could keep a specified category inside India if the Government required it.
5. What the deletion timetable is on exit: return format, signed confirmation, deadline and cost.

Answers to those five belong in the agreement, not in an email thread nobody can find in eighteen months.

Send the eleven together, then review what comes back on a schedule you set yourself, alongside the rest of HR compliance in India.

How can Wisemonk help you protect employee data in India?

Wisemonk is an India-native Employer of Record (EOR) that helps global companies hire, pay, and manage talent in India without setting up a local entity. Because we are the legal employer of your India team, the data roles are settled before your first payroll runs, and they are written into the agreement rather than assumed.

We manage 2,000+ employees for 300+ global companies, which means we handle Indian payroll, tax and identity data at volume every month.

Our own India team runs the filings, so the statutory data stays with the entity Indian law addresses and your side of the split stays small and clearly described.

Onboarding runs in under 48 hours, and the data questions are answered in the agreement rather than after signature.

Here is how we help:

• Employer of Record in India: we become the legal employer, so one entity holds the employment relationship and the statutory data that comes with it.
• Managed India payroll: monthly payroll, payslips and bank files run by our own team rather than passed down a chain of vendors.
• Statutory compliance calculation and filing: contributions and withholding calculated and filed against India's monthly deadlines.
• Background checks: identity, education and employment verification run through approved routes, with retention limited to what the check needs.
• Entity setup in India: when you outgrow the EOR model, we set up your own India entity and move the team across.

Whichever of those you use, the same principle holds: the party carrying a duty under Indian law should be the party doing the work.

We provide EOR services in India, and we are expanding rapidly into the US and UK markets.