The hard part is keeping the line clear. Requests about client data go to the client. Requests from your own people come to you. Offshore data under a foreign contract is mostly exempt, but Indian data is not, and many projects have both.
The first four things to sort out
Keep a register of client data sets, tagged by where the people live.
Check that each client contract covers instructions, security, incidents and deletion.
Route client-data requests to the client, and log them.
Apply full DPDP duties to employee and candidate data.
A worked example: A client asks you to delete one of its customers
Hour 1The request reaches the delivery lead and is logged against the client contract.
Day 1The team finds the record in the production database, two test copies and last month's backup.
Day 3Production and test copies are deleted; the backup copy expires on its normal cycle, as the contract allows.
Day 3The client receives written confirmation listing every copy and what was done.
Evidence kept: Request log; Deletion record by copy; Confirmation to the client.
Clients remember a clear, complete answer that lets them meet their own duty.
What others in the sector usually do. Larger firms keep one privacy register that says, for every project, whether they act for themselves or for 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.
From your seat: DPO / Privacy lead. Own the project tagging.
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: Yes, at every point where you collect data
A notice must tell people, in plain words, what data you collect, why, how they can withdraw consent, how they can use their rights and how they can complain to the Data Protection Board. It has to stand on its own, separate from long terms and conditions, and be shown at the point where data is collected.
From your seat: DPO / Privacy lead. You own the wording and the version history. Keep a folder with every live notice, its date and who approved it; that folder is usually the first thing an auditor asks for.
In IT and ITeS
Your careers page, candidate portal, employee onboarding and website forms need notices. For client data, the client gives the notice.
What the law says
Section 5 and Rule 3 ask for a notice that can be understood on its own, with an itemised list of the data and the purpose for each item. Data you already hold from before the Act also needs a notice, as soon as reasonably practicable. Section 5 · Rule 3 · Section 6 · Sections 11–14 · Rule 14
Steps
List every point where personal data comes in: forms, apps, counters, calls, emails, partner feeds.
Write one short notice per collection point, with the data items and purpose side by side.
Add how to withdraw consent, how to make a request and the DPO or contact person's details.
Offer the notice in English and in the languages your client customers actually use.
Keep each version with the date it went live.
Evidence to keep
Screenshots or copies of the notice at each collection point, with dates
Notice version history
Translations, where used
Common mistakes
Hiding the notice inside terms and conditions
One notice for everything, with no link between data items and purposes
Short answer: It depends on the use; most organisations need both
For every use of personal data you need one basis: consent, or one of the legitimate uses in Section 7, such as a legal duty, employment, a medical emergency, or data a person gave voluntarily for a specific purpose. Anything beyond what the person expects, such as marketing, profiling or sharing with partners, usually needs consent.
From your seat: DPO / Privacy lead. Build the purpose-and-basis register yourself, even if each team fills its own rows. When someone asks why their data was used, this register is your answer.
In IT and ITeS
Payroll and background checks are employment purposes. Newsletters to prospects need consent.
What the law says
Section 4 allows processing only with consent or for a legitimate use. Section 6 sets what valid consent looks like. Section 7 lists the uses that need no consent. Section 4 · Section 6 · Section 7
Steps
List each purpose for which you use personal data.
Against each purpose, write the basis: consent or the exact clause of Section 7.
Where the basis is consent, check that it was asked separately, with a clear action and no pre-ticked box.
Stop or re-paper any purpose with no basis.
Review the list whenever a new product, campaign or system starts.
Evidence to keep
Purpose and basis register
Consent records with date, version and channel
Legal sign-off on each legitimate use relied on
Common mistakes
Treating account terms as consent for marketing
Bundling several purposes in one tick-box
Relying on 'legitimate interest', which the Indian Act does not have
Short answer: Yes, a clear summary, inside the published timeline
Send a summary of the personal data you hold about them and what you do with it, and the names of the other organisations you shared it with and what was shared. Check the person's identity first, log the request and keep a copy of your reply.
From your seat: DPO / Privacy lead. Requests land with you even when the data sits with other teams. Agree a turnaround with each system owner in advance, so you are not chasing people on day 25.
In IT and ITeS
Requests about client data go to the client. Requests from staff and candidates come to you.
What the law says
Section 11 gives the right to a summary and the list of organisations it was shared with. Rule 14 asks you to publish how requests are made and to answer within the period you publish. Sections 11–14 · Rule 14 · Section 8(9)–(10) · Rules 9, 14
Steps
Log the request in one register the day it arrives.
Verify identity using details you already hold.
Search every system, including vendors' copies.
Write a plain summary: what data, why it is used, who received it.
Send it, and file the request, search notes and reply.
Short answer: Reply within your published period, never beyond 90 days
Publish one clear way to complain, log every complaint, give it an owner and reply within the period you publish, never more than 90 days. People can go to the Data Protection Board only after using your process, so a good process keeps most matters with you.
From your seat: DPO / Privacy lead. Count the days yourself. A short monthly note to management with open complaints and their age keeps the 90-day limit visible.
In IT and ITeS
Most complaints come from staff, ex-staff and candidates. Tag them.
Short answer: For the legal or business period, then erase
Keep data for as long as its purpose needs, or as long as a law requires, and then erase it. Every organisation must keep personal data and logs for at least one year under Rule 8(3). Write a retention schedule by record type, with the law or reason against each period.
From your seat: DPO / Privacy lead. Draft the schedule, but get Legal and each department head to sign their rows. Your role is to make sure deletion actually happens.
In IT and ITeS
Candidates, employees, alumni, and client data at project end.
What the law says
Section 8(7) asks for erasure when the purpose is over, unless a law requires retention. Rule 8(3) sets a one-year minimum for personal data, traffic data and logs. Section 8(7) · Rule 8 · Section 8(5) · Rule 6
Steps
List the record types you hold.
Write the period for each, with the law, regulator rule or business reason.
Set a trigger for the period to start: end of relationship, date of transaction, exit date.
Automate deletion where you can; for paper, schedule shredding.
Keep a deletion log.
Evidence to keep
Retention schedule approved by Legal
Deletion log
Shredding or disposal certificates
Common mistakes
'Keep everything forever' because storage is cheap
Short answer: Check every channel; children often appear where you least expect
Anyone under 18 is a child under the Act. For a child's data you need verifiable consent from a parent or lawful guardian, and you must not track, behaviourally monitor or show targeted ads to children. Some classes and purposes are exempt under Rule 12 and the Fourth Schedule, for example healthcare to the extent needed to protect the child's health, and educational institutions for their educational work.
From your seat: DPO / Privacy lead. Ask every team, not only marketing. Dependants, interns, scholarship applicants and visitors are where children's data usually hides.
In IT and ITeS
Usually only if a client's service involves children, or in staff dependants' records.
What the law says
Section 9 sets the duties. Rule 10 explains how to verify the parent. Rule 12 and the Fourth Schedule list the exemptions. Section 9 · Rules 10, 12 · Section 6
Steps
Find where children's data enters: customers, dependants, interns, visitors, scholarships, app sign-ups.
Decide whether an exemption in the Fourth Schedule applies to that purpose.
Where none applies, add an age question and a parent-consent step.
Switch off tracking and targeted ads for under-18 users.
Record the decision for each channel.
Evidence to keep
Channel-by-channel note on children's data
Parent-consent records
Ad and tracking settings
Common mistakes
Assuming 'we are B2B, so no children'
Using the age 13 or 16 from foreign laws
Treating a tick-box from the child as parental consent
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: DPO / Privacy lead. You decide whether people and the Data Protection Board must be told, so you must be on the first call, not informed the next morning.
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: DPO / Privacy lead. Keep the vendor register with IT and Procurement. You decide which vendors carry the most personal-data risk and need review first.
In IT and ITeS
Sub-contractors working on client data need the same terms you signed with the client.
Section 5 · Rule 3: Notice. Candidate portals, employee onboarding and your own website forms need notices. For client data, the client normally gives the notice.
Section 6: Consent. Marketing to prospects and optional employee programmes need proper consent.
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.
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.
