Short answer: Client first, within contract hours; CERT-In in six hours
Tell the client first, within the time your contract sets, because the client is the fiduciary and must tell its own customers and the Board. Report to CERT-In within six hours if the incident is reportable. Give the client logs and facts quickly; do not contact the client's customers yourself unless the client asks.
What the law says
Section 8(6) puts the duty to tell people on the fiduciary. As processor, your contract decides your duty to the client. Section 8(6) · Rule 7 · Section 8(1)–(2)
Steps
Keep a list of client notice times.
Name who calls each client.
Prepare a client incident template.
File CERT-In if reportable.
Share logs and a written account.
Evidence to keep
Client notice list
Incident timeline
CERT-In record
Common mistakes
Waiting to finish the investigation before telling the client
Short answer: Mostly exempt for offshore data; security still applies
Mostly not. Section 17(1)(d) exempts processing of personal data of people outside India when you do it under a contract with a party outside India. Security safeguards and responsibility for your processors still apply. The exemption does not cover your Indian staff, Indian customers, or Indian data mixed into the same work.
You are a Data Fiduciary when you decide why and how personal data is used, as you do for your own staff and customers. You are a Data Processor when you handle data only on another organisation's instructions. Many organisations are both, for different data sets.
In IT and ITeS
You are usually a processor for client data and a fiduciary for staff and candidates.
What the law says
Section 2(i) and 2(k) define the two roles. Section 8(1) puts the duties on the Data Fiduciary, which must use processors only under a valid contract. Section 8(1)–(2) · Section 17(1)(d)
Steps
List each data set you handle.
For each, ask: who decides the purpose?
Mark yourself as fiduciary or processor, and name the other party.
Check that contracts match the role.
Route requests about processor data to the fiduciary.
Evidence to keep
Role register by data set
Contracts matching the role
Common mistakes
Calling yourself a processor for data you use for your own purposes
Short answer: One line per duty, with owner and evidence
Turn each duty into a risk line with an owner, a control, evidence and a review date. Map controls you already run for your regulator, auditors or certifications, so the same evidence serves several purposes. Track vendor risk separately.
From your seat: Chief risk officer. Split DPDP into separate duties. One line called 'DPDP compliance' hides where the risk actually is.
Short answer: Six hours for CERT-In; without delay for people and the Board; 72 hours for the detailed report
Contain it, then tell people. A reportable cyber incident goes to CERT-In within six hours of being noticed. Under DPDP, each affected person and the Data Protection Board must be told without delay, and the Board needs a detailed report within 72 hours. Sector regulators may have their own clock too.
From your seat: Chief risk officer. Map every reporting clock that applies to you on one page: CERT-In, your regulator and the Data Protection Board.
In IT and ITeS
If client data is involved, the client contract sets your first deadline, often a few hours.
What the law says
Section 8(6) and Rule 7 set the DPDP steps. The CERT-In Directions of 28 April 2022 set the six-hour report. A breach includes accidental disclosure and loss of access, not only hacking. Section 8(6) · Rule 7 · Section 8(5) · Rule 6
Steps
Name one incident lead and a back-up, with phone numbers that work at night.
Write the first-hour steps: isolate, preserve logs, tell the DPO and the incident lead.
Keep ready-made drafts for CERT-In, the regulator, the Board and affected people.
Decide in advance who signs off each message.
Rehearse once a year with the people who would actually be called.
Evidence to keep
Incident plan with clocks
Rehearsal record
Incident log with times of each step
Common mistakes
Waiting to finish the investigation before telling anyone
Treating a wrong email or a lost laptop as 'not a breach'
Short answer: Yes, every vendor that touches personal data
You stay responsible for what your vendors do with personal data. The contract should say what data they get, for what purpose, the security they must keep, how fast they must tell you about an incident, that sub-contractors need your approval, and how data is returned or deleted at the end.
From your seat: Chief risk officer. Vendor risk is usually the largest single item. Track the top vendors as separate risk lines.
In IT and ITeS
Sub-contractors working on client data need the same terms you signed with the client.
Short answer: Only by notification; none notified yet
Only the government can notify an organisation or a class of organisations as a Significant Data Fiduciary, based on the volume and sensitivity of data and the risk to people or the State. None had been notified when this page was last reviewed. Large holders of sensitive data should plan as if it could happen.
From your seat: Chief risk officer. Keep notification as a scenario in the register, with a trigger and an owner.
In IT and ITeS
Notification is more likely for consumer platforms than for IT services, but large SaaS players should watch.
What the law says
Section 10 and Rule 13 set the extra duties: a DPO in India, an independent data auditor, a yearly Data Protection Impact Assessment and audit, and checks on algorithms. Rule 13(4) allows the government to restrict some data from leaving India. Section 10 · Rule 13 · Section 16 · Rule 15
Steps
Estimate how many people's data you hold and how sensitive it is.
Note any public or security role your data plays.
If you are a likely candidate, run a trial impact assessment this year.
Short answer: Yes, unless a sector rule says otherwise
Under DPDP, yes, unless the government restricts a country, and none had been restricted when this page was last reviewed. A sector rule can be stricter, for example RBI's rule that payment system data must be stored only in India. Remote support access from abroad also counts as data going outside India.
From your seat: Chief risk officer. Record every system or support team outside India, and check each against sector localisation rules.
In IT and ITeS
Global HR and collaboration tools are often hosted abroad. Clients may restrict where their data goes.
What the law says
Section 16 allows transfers unless restricted, and keeps stricter sector laws in force. Rule 15 adds conditions on making data available to foreign states. Section 16 · Rule 15 · Section 8(1)–(2)
Steps
List where each system is hosted and where support teams log in from.
Check sector rules for localisation.
Put location and access terms in cloud and vendor contracts.
Keep the list current; new SaaS tools change it quietly.
Short answer: They cover security, not the whole Act
They help a great deal with the security part. ISO/IEC 27001 and NIST CSF 2.0 are good evidence of reasonable security safeguards. They do not cover notice, consent, rights, complaints or children's data. ISO/IEC 27701 adds privacy controls, but no certificate replaces the Act.
From your seat: Chief risk officer. Use existing certifications as evidence, but record the DPDP duties they do not cover as their own risk lines.
In IT and ITeS
ISO/IEC 27001 is common in the sector; ISO/IEC 27701 adds privacy controls clients ask for.
What the law says
Section 8(5) and Rule 6 ask for reasonable security safeguards. A recognised standard is strong evidence of that duty, and only of that duty. Section 8(5) · Rule 6
Steps
Map your current controls to Rule 6.
Add the DPDP-only items: notice, consent, rights, complaints, children, retention.
Use the same evidence for audits and for DPDP.
Include privacy in the scope of your next internal audit.
Consider ISO/IEC 27701 if clients ask for it.
Evidence to keep
Control map
Audit reports
Gap list for DPDP-only items
Common mistakes
Treating a certificate as DPDP compliance
Scope that leaves out the systems with the most personal data
Short answer: Six to nine months of steady work for most
For most organisations it is a programme of six to nine months, not a single project. The heavy parts are the data inventory, vendor contracts, access control and the request process. Notices, the contact person and training are lighter. Starting now leaves time to fix what you find.
From your seat: Chief risk officer. Track the programme against dated milestones and report slippage early.
In IT and ITeS
Staff data work is quick; client contract alignment takes longer.
Section 8(1)–(2): Responsibility for vendors. You are usually the processor for client data and a fiduciary for your own staff. Your sub-contractors are your processors.
Section 8(6) · Rule 7: Telling people about a breach. Clients' contracts often require notice within hours, because their own clock starts when you tell them.
Section 8(5) · Rule 6: Security safeguards. Remote access to client systems, laptops and ticketing tools need control, monitoring and one-year logs.
Other rules that sit alongside DPDP
Rule
What it says
What it means alongside DPDP
Source
CERT-In Directions, 28 April 2022
Report specified cyber incidents within six hours. Keep ICT logs for 180 days within India. Sync clocks to NIC or NPL time servers. Data centres, VPS, cloud and VPN providers keep specified subscriber information for five years.
Breach handling must meet the six-hour CERT-In clock and the DPDP report to the Board. Subscriber records need DPDP-level protection.
