Mapping Your Security Controls to DPDP: What CISOs at BFSI Organisations Must Document Now

Security teams spend years building controls — firewalls, SIEM, endpoint protection, access management, encryption at rest and in transit. The DPDP Act now requires you to prove those controls exist as documented safeguards linked to specific processing activities. Having the control is not enough. You need to show the control, map it to a processing activity, and attach evidence that it works.

The documentation problem most CISOs discover late

DPDP §8(4) requires data fiduciaries to implement "reasonable security safeguards" to protect personal data. The word "reasonable" is doing heavy lifting — it means proportionate to the sensitivity of data, the volume processed, and the risk of harm. ISO 27001 certifies your ISMS exists, but the DPDP Act requires those controls mapped to each ROPA entry, with evidence attached.

The gap most CISOs discover during their first audit is not that controls are missing. It is that the link between a control and a processing activity does not exist in any documented, retrievable form. The firewall rule exists. The ROPA entry exists. But nothing connects the two in a way a regulator can follow.

Five control categories DPDP expects evidenced

The Act does not prescribe specific controls, but regulatory guidance and audit practice have converged on five categories that every data fiduciary should document:

• Encryption: Data at rest (AES-256 or equivalent) and in transit (TLS 1.2+). Evidence: configuration exports, certificate details, key management policy
• Access controls: Role-based access, least privilege, periodic access reviews. Evidence: IAM policy exports, access review logs, privileged account inventory
• Audit logging: Immutable logs of access to personal data, retention of logs for minimum 180 days. Evidence: SIEM dashboard exports, log retention configuration
• Retention and deletion: Automated deletion at retention expiry, deletion confirmation logs. Evidence: retention schedule, deletion job logs, data lifecycle policy
• Breach detection: Incident detection within 72 hours, notification workflow documented. Evidence: incident response plan, SIEM alert rules, breach simulation results

RBI CSF and SEBI CSCRF overlap

BFSI organisations already maintain controls under the RBI Cyber Security Framework and SEBI Cyber Security and Cyber Resilience Framework. The good news: significant overlap exists. The bad news: existing controls need explicit linking to privacy processing activities, not just security domains.

A single evidence artefact — say, an encryption configuration export — can satisfy both the RBI CSF encryption requirement and the DPDP §8(4) safeguard obligation for a specific processing activity. But it must be linked to both. Storing the evidence in one framework's folder and referencing it by memory in the other is not sufficient for audit purposes.

What counts as evidence for each control

Regulators do not accept descriptions. They accept artefacts. Configuration screenshots with timestamps. Audit log exports covering specific date ranges. Deletion job logs showing records purged at retention expiry. DPA agreements with processor signatures and dates. Access review reports showing who reviewed, when, and what action was taken.

The standard of evidence is: could a regulator, reading this document alone, confirm the control exists and operates as described? If the answer is no, the evidence is insufficient regardless of whether the control itself works perfectly.