# DPDP security safeguards: the Rule 6 controls and how to evidence them

Source: https://dpdp.d2c.in/guides/dpdp-security-safeguards/ · Updated 2026-11-13 · DPDP Ready by Mirav Labs

**Short answer:** Section 8(5) of the DPDP Act requires every Data Fiduciary to take reasonable security safeguards to prevent a personal data breach. From 13 May 2027, Rule 6 sets the minimum: encryption or similar, access control, logging and monitoring, continuity measures, one-year retention of logs, safeguards in processor contracts, and measures to make all of it work. Failing to take them can draw a penalty of up to ₹250 crore.

## Key takeaways

- Rule 6(1) lists seven minimum safeguards; the examples it gives (“such as”) are illustrative, not a complete checklist.
- Each safeguard needs evidence you can produce: configurations, logs, reviews, test results.
- Keep logs for one year under Rule 6(1)(e) and Rule 8(3), and keep them free of unmasked identifiers.
- You are responsible for your processors' security (s.8(1)), so write safeguards into every processor contract.
- ISO 27001 or SOC 2 help you evidence controls, but neither certificate on its own shows DPDP compliance.

Security is the obligation with the largest penalty in the DPDP Act and the one most engineering teams think they have already covered. Often they have covered a good part of it. What changes from 13 May 2027 is the standard of proof: Rule 6 names specific measures, and after an incident you will need to show the Board that each one was in place for the personal data involved, not just that your company has a security policy.

This guide takes each Rule 6 measure, turns it into a control, and lists the evidence that shows it works. It also covers the one-year log requirement, processor contracts, and how existing ISO 27001 or SOC 2 programmes fit.

## What does Rule 6 require?

Section 8(5) of the Act requires a fiduciary to take reasonable security safeguards to prevent a personal data breach, and section 8(1) keeps it responsible for processing done by its processors. Rule 6(1) of the [DPDP Rules, 2025](https://dpdp.d2c.in/guides/dpdp-rules-2025/) says these safeguards shall include, at the minimum, seven measures. Several are written with “such as”, so the named techniques are examples. You choose what is appropriate for your data and must be able to defend the choice.

The seven are not a menu. You need all of them, scaled to your risk. A clinic chain holding health records and a SaaS company holding business contact details will implement them differently, but both will implement each one.

## How do you implement and evidence each Rule 6 control?

The table below is the control set we use in readiness assessments. The third column is what the Board is likely to ask for after an incident.

| Rule 6(1) measure | How to implement | How to evidence it |
|---|---|---|
| (a) Encryption, obfuscation, masking or virtual tokens | Encrypt data at rest and in transit; field-level encryption or tokenisation for high-risk fields (identity numbers, health, financial data); masking in non-production environments and support screens | Encryption configuration exports, key management policy and rotation records, a list of tokenised fields, test data sets showing masking |
| (b) Access control over computer resources | Single sign-on with multi-factor authentication; role-based access; least privilege; joiner, mover and leaver process; privileged access through a controlled path | Access matrix per system, quarterly access reviews with sign-off, MFA enforcement reports, leaver tickets closed against HR dates |
| (c) Visibility through logs, monitoring and review | Log access to personal data at the application layer, not only infrastructure; central log store; alerts for unusual access; scheduled review | Log samples showing who accessed what and when, alert rules, review records, tickets raised from alerts |
| (d) Continuity, such as backups | Encrypted backups, separated from production; tested restores; a recovery plan for loss of access, including ransomware | Backup job reports, restore test results with dates and timings, recovery plan with owners |
| (e) Retain logs and personal data for one year | Retention policy on log stores set to at least one year; immutable or write-once storage for security logs; erase after the period unless another law requires more | Retention settings, storage policy screenshots, a sample query retrieving an eleven-month-old event |
| (f) Safeguards in processor contracts | Security schedule in every processor contract: Rule 6 measures, breach notice to you, log retention, sub-processor approval, audit rights, erasure on exit | Contract register with clause status per processor, vendor assessments, sub-processor lists |
| (g) Technical and organisational measures to make sure safeguards are observed | Named owner per control; training; secure development practice; periodic internal review; vulnerability management | Control owner list, training completion, internal audit or review reports, vulnerability scan and fix records |

Rule 6(1)(b) covers the computer resources used to process personal data, by you and by your processors. In practice that means laptops, servers, cloud accounts, databases and the SaaS tools your staff use to touch personal data.

## Which encryption does DPDP expect?

The Rules do not name an algorithm or a key length. Rule 6(1)(a) asks for appropriate data security measures, and lists encryption, obfuscation, masking and virtual tokens mapped to the personal data as examples. A sensible baseline for most organisations:

- **In transit:** current TLS for every external and internal service that carries personal data, including service-to-service traffic.

- **At rest:** storage and database encryption, with keys held in a managed key service and access to keys logged.

- **Field level:** tokenise or encrypt the fields that would cause the most harm if exposed, so a database dump alone is not readable.

- **Outside production:** masked or synthetic data in development, testing and analytics wherever the real values are not needed.

Write down why you chose each measure. “Appropriate” is judged against your data and your risk, and a short design record is better evidence than a policy statement.

## How long must you keep logs, and how do you square it with minimisation?

- **1 year** log and data retention under Rule 6(1)(e)
- **1 year** minimum retention of data, traffic data and processing logs under Rule 8(3)
- **7** minimum safeguards in Rule 6(1)
Two rules point the same way. Rule 6(1)(e) asks you to keep logs and personal data for one year so that unauthorised access can be detected, investigated and remediated, and processing can continue after a compromise, unless another law requires otherwise. Rule 8(3), new in the final Rules, requires every fiduciary to retain personal data, associated traffic data and processing logs for at least one year from the date of processing, including those of its processors, and then erase them unless another law requires longer retention.

The tension is obvious: the Act asks you to erase data when consent is withdrawn or the purpose is served, and your logs are full of personal data. The answer is to make logs carry as little as possible.

Keep logs useful, not identifyingLog internal user IDs or tokens, not raw phone numbers, email addresses, identity numbers or health details. Never log full request bodies with personal data. Keep the mapping from token to person in a separate, tightly controlled store. A log that reads “user 48213 viewed record 99102” serves investigation; a log that repeats the record does not.

Set the retention clock on every log store, including those run by processors, to at least one year and then automatic deletion, unless a sector rule or other law requires longer. Lock down access to logs the same way you lock down production data, because a log store is a high-value target. Our [data retention guide](https://dpdp.d2c.in/guides/dpdp-data-retention/) covers how this fits with erasure on withdrawal.

## What should processor contracts say about security?

Section 8(1) keeps you responsible for processing done on your behalf, despite anything your contract says. Section 8(2) allows you to engage a processor only under a valid contract. Rule 6(1)(f) then requires appropriate provision in that contract for reasonable security safeguards. Your cloud provider, payment gateway, CRM, support desk tool and payroll vendor are all in scope.

A DPDP security schedule for processors should cover:

- The Rule 6(1) measures the processor will maintain, mapped to its own controls.

- Notice to you of any personal data breach within a fixed number of hours, so you can meet your own [breach notification](https://dpdp.d2c.in/guides/dpdp-breach-notification/) duties.

- Log retention for at least one year, matching Rule 8(3), and access to logs during an investigation.

- Prior approval of sub-processors, with the same terms flowing down.

- Your right to assess or audit, or to receive independent audit reports.

- Stopping processing and erasing data on your instruction, including after consent is withdrawn.

The roles guide on [fiduciaries and processors](https://dpdp.d2c.in/guides/data-fiduciary-vs-data-processor/) covers how to tell which side of the contract you sit on.

## What is the penalty for weak security?

Failing to take reasonable security safeguards to prevent a personal data breach can attract a penalty of up to ₹250 crore under the Schedule to the Act. It is the highest amount in the Schedule. Failing to notify a breach is a separate item, up to ₹200 crore. Under section 33, the Board decides after an inquiry and a hearing, and weighs factors including the nature, gravity and duration of the breach, the type of data, whether it was repeated, and whether you took timely steps to mitigate it. The [penalties guide](https://dpdp.d2c.in/guides/dpdp-act-penalties/) sets out the full Schedule.

Also note that section 43A of the Information Technology Act, under which many companies built their current “reasonable security practices”, is omitted from 13 May 2027. Rule 6 becomes the reference point for personal data.

## Do ISO 27001 or SOC 2 satisfy DPDP?

They help, but they do not settle it. An ISO 27001 information security management system or a SOC 2 report gives you documented controls, owners, reviews and independent testing. Much of that evidence maps directly onto Rule 6(1)(b), (c), (d) and (g). No certification is recognised under the Act as proof of compliance, and the Board will look at what happened to the personal data, not at your certificate.

Where your ISO 27001 or SOC 2 work helps

- Access control and reviews

- Logging and monitoring processes

- Backup and recovery testing

- Vendor management and risk assessment

- Control ownership and internal audit
What you still need to check for DPDP

- Scope covers every system holding personal data

- One-year retention of logs and processing data (Rules 6(1)(e), 8(3))

- Logs minimised so they do not repeat personal data

- Processor contracts carry DPDP security and breach terms

- Breach intimation to the Board and to people (Rule 7)

## How to implement this

- **Scope the data.** Use your data inventory to list every system and processor holding personal data. Rule 6 applies to all of them.

- **Assess against the table.** For each of the seven measures, record the current control, the gap and the evidence you could produce today.

- **Fix logging first.** Add application-level access logs, strip identifiers from logs, and set one-year retention with automatic deletion.

- **Re-paper processors.** Add a DPDP security schedule to every processor contract, starting with those holding the most sensitive data.

- **Build an evidence pack.** One folder per control, refreshed quarterly, so you are not assembling proof in the middle of an incident.

- **Test.** Run a restore test and a breach tabletop before 13 May 2027.

Security safeguards are a core part of the [DPDP compliance checklist](https://dpdp.d2c.in/guides/dpdp-compliance-checklist/). If you want security engineers to run the gap assessment and build the evidence pack with your team, see [our services](https://dpdp.d2c.in/#services).

## Frequently asked questions

### What are reasonable security safeguards under DPDP?

Section 8(5) requires them and Rule 6(1) sets the minimum: encryption, obfuscation, masking or virtual tokens; access control; logging and monitoring; continuity measures such as backups; one-year log retention; safeguards in processor contracts; and technical and organisational measures to make sure they are observed.

### Does the DPDP Act require encryption?

Rule 6(1)(a) requires appropriate data security measures, and gives encryption, obfuscation, masking and virtual tokens as examples. Encryption is not the only option, but you need at least one appropriate measure that protects the data itself, and a reason for the choice.

### How long must logs be kept under the DPDP Rules?

Rule 6(1)(e) requires logs and personal data to be kept for one year for detecting and investigating unauthorised access, unless another law requires otherwise. Rule 8(3) separately requires every fiduciary to keep personal data, associated traffic data and processing logs, including its processors', for at least one year from processing.

### Is ISO 27001 certification enough for DPDP compliance?

No certificate is recognised as proof of DPDP compliance. An ISO 27001 or SOC 2 programme gives you policies, controls and audit evidence that cover much of Rule 6, which helps. You still need to check each Rule 6 measure against your personal data specifically, and cover the DPDP items those frameworks do not address.

### What is the penalty for a security failure under DPDP?

Failing to take reasonable security safeguards to prevent a personal data breach can attract a penalty of up to ₹250 crore under the Schedule to the Act, the highest amount in the Schedule. The Board decides the amount after an inquiry, considering factors in section 33(2) such as gravity, duration and mitigation.

### Is the fiduciary liable for a processor's security breach?

Yes. Section 8(1) keeps the fiduciary responsible for processing done on its behalf by a processor, despite any agreement to the contrary. That is why Rule 6(1)(f) asks for security safeguards to be written into fiduciary and processor contracts.