India's DPDP Act 2023: What Security Teams Need to Actually Do
India's Digital Personal Data Protection Act (DPDP) 2023 is not just a privacy compliance exercise that lives in the legal team's domain. It has direct and practical implications for how security teams classify data, respond to incidents, manage access to systems holding personal data, and handle relationships with vendors and clients. This post is written for security practitioners — not lawyers — who need to understand what actually changes in day-to-day security operations.
Key terms to understand
Term | What it means for security teams |
Data Principal | The individual whose personal data is being processed — your customer, employee, or user |
Data Fiduciary | The organization that determines the purpose and means of processing personal data — typically your company |
Data Processor | A third party processing data on behalf of the Data Fiduciary — your vendors, SaaS providers, outsourcing partners |
Personal Data | Any data that can identify an individual — names, email addresses, device IDs, location data, biometrics |
Data Protection Board | The regulatory body that receives breach notifications and investigates violations under the Act |
Breach notification — where security teams own the process
The DPDP Act requires notification to the Data Protection Board and affected Data Principals in the event of a personal data breach. The implementing rules will specify the exact timeframe, but the direction is toward prompt notification — similar to GDPR's 72-hour window. Security teams need a breach classification process that can determine within hours whether an incident involves personal data, the scope of affected individuals, and whether it crosses the reporting threshold. This means your incident response runbook needs a specific branch for personal data breaches, with defined roles, escalation paths, and notification templates ready before an incident occurs.
Access control — reviewing who can reach personal data
The Act's purpose limitation principle — that personal data should only be used for the purpose it was collected for — has direct access control implications. Broad access grants justified as "operational necessity" need to be revisited. Systems holding customer data, HR records, or financial information should have role-based access controls with access limited to individuals who need it for their specific function. Security teams should work with data owners to map which systems hold personal data and then review whether current access levels are appropriate.
Data minimization in security tooling
Security tools are among the biggest collectors of personal data in any organization. SIEMs ingest authentication logs containing usernames and endpoint data. EDR agents collect process execution data tied to user identities. DLP tools inspect email content. Network monitoring tools capture DNS queries tied to user devices. Under DPDP's data minimization principle, collecting and retaining more than necessary is a compliance risk, not just a storage cost. Review your SIEM log retention policies, your EDR data retention settings, and your DLP configuration with the question: are we retaining this personal data longer than we need it for a legitimate security purpose?
A practical starting point: identify the top 5 security tools in your environment that handle personal data. For each, document what data is collected, how long it is retained, who has access, and whether that retention period is justified by a security or legal requirement.
Processor obligations for outsourcing and BPO contexts
If your organization processes personal data on behalf of a client — common in IT outsourcing, BPO, and managed security service contexts — you are a Data Processor under the Act. Your obligations include implementing appropriate technical and organizational security measures, notifying the Data Fiduciary (your client) promptly in the event of a breach, and ensuring your subprocessors (your own vendors) meet equivalent standards. Review your client contracts to understand whether your existing data processing agreements cover DPDP obligations or require updates.
DPDP obligation | Security team action | Priority |
Breach notification | Update IR runbooks with personal data breach classification and notification workflow | High — before an incident occurs |
Access control | Map personal data systems, review and restrict access | High — audit finding risk |
Data minimization | Review retention policies in SIEM, EDR, DLP tools | Medium — phased review approach |
Processor obligations | Review client contracts, update DPAs, assess subprocessors | High — contract obligation |
Technical safeguards | Encryption at rest and in transit for personal data systems | High — foundational requirement |
What is still being defined
The DPDP Act received Presidential assent in August 2023, but the implementing rules — which will specify notification timelines, consent mechanisms, and exemption categories — are still being finalized as of late 2025. This does not mean security teams should wait. The direction of the regulation is clear, and the foundational actions — breach classification capability, access control review, data minimization, and contract updates — are valuable regardless of the final rule text.
Closing
DPDP represents a significant shift in India's regulatory landscape for personal data. For security teams, it means incident response processes, access control models, and tool configurations all need to be evaluated through a personal data lens. The teams that build this capability before the rules are finalized will be in a far stronger position than those who wait for the final text before starting.
