You are a Data Fiduciary for your own staff and candidates, and usually a Data Processor for the client data your teams work on. Data of people outside India, handled under a contract with a foreign client, is mostly outside the Act, but security and responsibility for sub-contractors still apply.
The first four things to sort out
Route client requests to the client.
Mask data in tickets.
Recording notices.
Close tickets with deletion.
A worked example: An end user asks the helpdesk to delete his data
Day 1The helpdesk logs it and checks: the data belongs to the client.
Day 1The request goes to the client as the contract says.
Day 5The client instructs deletion.
AfterDone and confirmed.
Evidence kept: Log; Client instruction.
Client data requests go to the client.
What others in the sector usually do. Ticket attachments are cleaned after closure.
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: 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: Customer service department. Log every request on the day it comes in and route it to the DPO's register.
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: Customer service department. Tag privacy complaints and count the days.
In IT and ITeS
Most complaints come from staff, ex-staff and candidates. Tag them.
Short answer: Yes, with notice, a retention period and masking
Call recordings, chat transcripts and agent screens hold a lot of personal data. Tell callers that calls are recorded and why, keep recordings for a set period, limit who can listen, and mask card numbers and passwords on screen and in recordings.
From your seat: Customer service department. Play the recording notice and pause recording for card details.
In IT and ITeS
BPO call recordings must pause for card details and follow client retention rules.
Short answer: Yes, unless a law requires you to keep it
You must erase data that you no longer need for the purpose it was collected for, unless a law requires you to keep it. Where a law does require it, keep the data, stop using it for anything else, and tell the person why it is being kept and until when.
From your seat: Customer service department. Explain clearly what can be deleted and what the law requires to be kept.
What the law says
Section 12 gives the right to correction and erasure. Section 8(7) allows retention only where a law requires it. Rule 8(3) asks every organisation to keep personal data and logs for at least one year first. Sections 11–14 · Rule 14 · Section 8(7) · Rule 8
Steps
Log the request and verify identity.
Check the retention schedule for each record type involved.
Delete what has no legal reason to stay, including copies with vendors and in test systems.
Mark what must stay, with the law and the end date.
Reply in plain words: what was deleted, what is kept, why and until when.
Evidence to keep
Erasure log
Vendor deletion confirmations
Reply to the person
Common mistakes
Refusing every erasure request 'because of backups'
Short answer: Stop that use quickly, across every system and vendor
Withdrawal must be as easy as giving consent. Once someone withdraws, you and every vendor working for you must stop that use within a reasonable time. What was done before withdrawal stays lawful, and data that a law requires you to keep is kept.
From your seat: Customer service department. Process stop requests the same day and confirm in writing.
What the law says
Section 6(4) to 6(6) give the right to withdraw at any time, with the same ease, and require processors to stop as well. Section 8(7) then asks for erasure unless a law requires retention. Section 6 · Section 8(7) · Rule 8 · Section 8(1)–(2)
Steps
Give one simple way to withdraw on every channel where consent is taken.
Record the withdrawal against the person and the purpose.
Push the change to every system and vendor that uses that purpose.
Confirm to the person, in writing, what has stopped and what is kept by law.
Check a sample every month to see that the change actually reached every list.
Evidence to keep
Withdrawal log with time stamps
Proof that downstream systems and vendors updated
Confirmation sent to the person
Common mistakes
Withdrawal by email only, while consent was one tap in an app
Stopping in the main system but not in vendor lists
Short answer: Yes, this is a common breach; give staff a safer option
Sending personal data to the wrong chat or a personal account is one of the most common breaches. Banning messaging rarely works. Give staff an approved tool that is easy to use, set simple rules, and make it safe to report a wrong send at once.
From your seat: Customer service department. Never send customer data from personal phones or accounts.
In IT and ITeS
Client credentials and customer screenshots in team chats are a common issue.
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.
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.
