DPDP readiness checklist for employee identity data

Identity systems hold more personal data about your workforce than most teams realise: names, work and personal contact details, phone numbers used for codes, device and location traces in sign-in logs, and records of what each person can reach. This checklist helps you map that data and prepare the routines a Data Fiduciary is expected to have. It is general information, not legal advice. The Act, its rules and how they apply to your organisation are for your compliance counsel to confirm.

1. Know what you hold

Start with an inventory. You cannot protect, correct or erase data you have not listed. Write down each system that stores identity data and what it keeps.

List every system that holds employee identity data: directory, HR system, identity provider, ticketing, email, applications with their own user tables.
For each, record the fields held (name, email, phone, employee ID, photograph, department, manager).
Note sign-in and audit logs separately: they contain IP addresses, device details and timestamps tied to a person.
Record who is the owner of each system, in a person's name, not a team alias.
Mark which fields are required to do the job and which are convenience.

2. State the purpose and tell people

Purpose limitation is central to the Act: data collected for one purpose should not quietly be used for another. People should receive a clear notice about what you collect and why.

Write one plain-language sentence of purpose for each category of identity data.
Publish or share an employee notice that matches that list, in language people actually read.
Check that phone numbers collected for sign-in codes are not reused for marketing or HR messages without a separate basis.
Ask counsel how the Act's provisions on employment-related processing apply to your situation, and record the answer.

3. Consent records where you rely on consent

Where consent is the basis for a particular use, keep a record of what was agreed, when, and how it can be withdrawn. AuthMantra includes consent records, which can support this; the policy about when to rely on consent is still yours to decide.

Identify uses that depend on consent (for example optional profile photographs or optional notifications).
Store the wording shown, the timestamp and the version of the notice.
Make withdrawal as easy as giving consent, and make sure it takes effect in downstream systems.

4. Reasonable security safeguards

The Act expects reasonable security safeguards to protect personal data. For identity data, that usually means strong sign-in, tight admin access, encryption, and logs you can examine.

Require MFA, and prefer passkeys, for every administrator and for everyone who can see other people's data.
Use step-up re-authentication before sensitive admin actions such as exporting users or changing roles.
Limit admin roles: separate those who manage systems from those who only read audit records.
Confirm encryption at rest and in transit, and who controls the keys.
Review active sessions regularly and revoke those you do not recognise.

5. Access, correction and erasure requests

People whose data you hold can ask about it, ask for correction, and in many cases ask for erasure, subject to the law's conditions and to other laws that require you to keep records. Decide in advance who handles these and how fast.

Name an owner for data requests and a backup.
Define how you verify that the requester is the person concerned.
Know where to find a person's data across the systems in your inventory (a data export helps).
Write down which records you must keep despite a request, and why, so the answer is ready.
Keep a log of requests and outcomes.

6. Grievance redressal

There must be an accessible route for people to raise concerns about their data and a process that responds. A workflow with an owner, a status and a due date is better than a shared mailbox.

Publish how to raise a grievance and whom it reaches.
Track each grievance with an owner and a status.
Set an internal target response time and report on it.
Review recurring themes quarterly.

7. Retention and deletion

Keep data no longer than the purpose or a legal requirement demands. Sign-in logs may have their own retention duties; CERT-In directions of 28 April 2022 mention keeping certain logs for 180 days. Whether and how that applies to you is a question for counsel.

Set a retention period for each category in your inventory.
Agree what happens to a leaver's account, mailbox and logs, and when each is deleted.
Automate deletion where possible and test it.
Document legal-hold exceptions.

8. Vendors and where data lives

If a supplier processes employee data for you, your contract and due diligence should reflect your obligations. Ask where data is stored and who can reach it.

Ask each identity-related supplier where data is hosted and which sub-processors are involved.
Prefer India hosting where your policy requires it. AuthMantra hosts in the Mumbai region (asia-south1).
Have counsel review data-processing terms.
Record the supplier's route for reporting a data breach to you.

9. Be ready for an incident

If personal data is breached, there are duties to inform the regulator and the people affected, and CERT-In has separate reporting directions. Practise before it happens.

Write a one-page incident plan: who decides, who tells whom, in what order.
Stream identity logs to your SIEM so unusual sign-ins are noticed.
Keep contact details for counsel and your regulator handy.
Run a tabletop exercise once a year.

About this runbook

AuthMantra provides tools that support these routines: a grievance workflow, data export, consent records, India data residency, audit log export and SIEM streaming. They help you operate your process; they do not by themselves make an organisation compliant.

General information, not legal advice. Published by AuthMantra, Titanium Tech Park, Bidarahalli, Bengaluru 560066.

authmantra.com/praxis/run/dpdp-readiness-checklist/ · info@authmantra.com