Client data must be deleted at project end as the contract says, while staff records must be kept for the period labour and tax laws require. Mixing the two leads to keeping client data too long or deleting staff records too soon.
The first four things to sort out
Keep one retention schedule covering staff, candidate and client records.
Log every destruction, with a certificate for paper.
Delete client project documents at closure as the contract says.
Lock record rooms and log file movement.
A worked example
Records and archives department
Project files kept after closure
Week 1Records finds documents from projects closed two years ago.
Week 2Each is checked against the client contract.
Week 3Client data is destroyed with a certificate.
AfterClosure triggers deletion.
Evidence kept
Contract check
Destruction certificate
Client records follow the client's deletion terms.
What others in the sector usually do. Many records teams add a project-closure step that confirms deletion to the client in writing.
Where it usually goes wrong, by organisation type
Organisation type
Hotspots
IT services and consulting
Production data copied to laptops or test environments; Shared client credentials in team chats; Sub-contractors working under your client access
BPO and contact centre
Card numbers spoken on recorded calls; Phones and paper on the floor; Outbound calls without consent checks for Indian customers
Global capability centre
Indian customer data mixed into global data sets; Global HR systems hosted abroad; Intra-group agreements that predate DPDP
SaaS and software products
Support staff browsing customer tenants; Analytics on customer data beyond the contract; Deletion that does not reach backups
Managed services, data centres and cloud
Privileged admin access across many clients; Subscriber records kept with no access limits; Backups of client systems held for years
6 questions the Records and archives department asks, answered in full
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: Records and archives department. Own the schedule and the destruction log.
Example 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: 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: Records and archives department. Explain clearly what is kept and why.
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: Yes, through a written backup-expiry rule
Deletion should reach every copy you control. For backups, the usual practice is to let deleted records expire with the normal backup cycle, never restore them into live use, and write this down. Test and training copies should use masked data.
From your seat: Records and archives department. Old backups are records too.
Example in IT and ITeS
Client backups held by managed service teams must follow client retention.
What the law says
Section 8(7) asks for erasure. Rule 6 asks for backups for continuity. The two meet in a backup retention rule that is short enough and written down. Section 8(7) · Rule 8 · Section 8(5) · Rule 6
Steps
List where copies live: backups, replicas, test, analytics, laptops, vendors.
Set backup retention to match the retention schedule.
Write a rule: deleted records are not restored into live systems.
Mask personal data in test and training copies.
Get deletion confirmations from vendors.
Evidence to keep
Backup retention settings
Written backup-expiry rule
Masking procedure for test data
Common mistakes
Ten-year backups for convenience
Live copies in test
Restoring old backups and bringing deleted records back
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: Records and archives department. Find records fast when someone asks.
Example 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: Yes, when the request is lawful and in writing
Check that the request is in writing, comes from the right authority and cites the legal power. Share only what is asked for, record what you sent and to whom, and keep the request on file. The Act allows processing to meet a legal duty, but it does not mean sharing everything on a phone call.
From your seat: Records and archives department. Log what was released.
What the law says
Section 7(d) and 7(e) allow processing to meet a legal duty to disclose to the State, or to comply with a judgment or order. Section 17(1)(c) exempts processing for preventing, detecting or investigating offences. Section 7 · Section 8(5) · Rule 6
Steps
Route every such request to Legal.
Check the authority, the legal power and the scope.
Share only what is asked, by a secure method.
Log the request, what was sent, by whom and when.
Tell the person, unless the law or the authority says you must not.
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: Records and archives department. A missing file is a breach.
Example 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'
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.
CERT-In
DPDP Act, Section 17(1)(d)
Processing of data of people outside India, under a contract with a party outside India, is exempt from most of the Act.
Tag each data set by where the people live. The exemption does not cover Indian staff or Indian customers.
MeitY
IT Act, Section 43A and SPDI Rules, 2011
Reasonable security practices for sensitive personal data, until Section 43A is omitted on 13 May 2027.
Your current ISO 27001 practices meet these today; DPDP Rule 6 takes over from May 2027.
Commercial calls and SMS to Indian numbers must follow registration and preference rules.
Outbound campaigns for Indian clients need both DPDP consent and TRAI compliance.
TRAI
Labour Codes (in force from 21 November 2025)
The four labour codes replaced older labour laws, including registers and records employers must keep.
Set retention for staff records against the new codes and state rules.
Ministry of Labour
Client contracts and foreign laws (for example GDPR for EU clients)
Clients often bind you to their own country's law through contracts and standard clauses.
These are contract duties, not Indian law, but you must meet them alongside DPDP.
Contract
Explore our research-built assessment platformsDPDP Insights helps you understand the law. DPDPiq is where an organisation's evidence is assessed. Each platform comes out of the same Foundation Layer research. No AI, API or outside service is used when you use this site. Everything runs from InfraVeritas360's own server.
