Security safeguards and personal data breaches

DPDP — not yet effective

Act section 8(5)–(6) and Rules 6–7 are scheduled for 13 May 2027.

CERT-In directions in force

Minimum Rule 6 map

Rule 6 describes safeguards including:

• encryption, obfuscation, masking or virtual tokens as appropriate;
• access-control measures for relevant computer resources;
• visibility through logs, monitoring and review to detect, investigate and remediate unauthorised access;
• continuity measures such as backup;
• retention of relevant logs and personal data for one year for detection, investigation, remediation and continuity, unless another law requires otherwise;
• processor contract provisions;
• technical and organisational measures that make the safeguards effective.

These are a minimum-shaped list, not a universal implementation recipe. Reasonableness remains fact-dependent. Evidence must connect a system, risk, control implementation, test, owner, exception and review date.

DPDP notification sequence

On becoming aware of a personal data breach, Rule 7 requires:

1. notice to each affected Data Principal without delay, in concise, clear and plain terms, with nature/extent/time, likely consequences, mitigation, protective steps and contact;
2. notice to the Board without delay with nature, extent, timing/location and likely impact;
3. detailed information to the Board within 72 hours, or a longer period granted in writing, covering updates, causes/circumstances, mitigation, findings about the responsible person, recurrence prevention and Principal notifications.

The product preserves the original awareness time and every update; changing severity cannot reset the clock.

CERT-In is a separate test

The 28 April 2022 Directions require covered entities to report listed cyber incidents within six hours of noticing or being brought to notice. They also address time synchronisation and 180-day secure ICT log retention in India. The official FAQ and MSME/data-centre/VPS/cloud/VPN extension must be applied.

flowchart LR
  A[Incident signal] --> B[Preserve facts and awareness time]
  B --> C{Personal data breach?}
  B --> D{CERT-In listed cyber incident?}
  B --> E{Sector / contract trigger?}
  C -->|yes| F[DPDP Principal + Board clocks]
  D -->|yes| G[CERT-In six-hour clock]
  E -->|yes| H[Separate sector clocks]
  F --> I[Coordinated content, separate decisions]
  G --> I
  H --> I

Required incident fields

tenant, accountable entity, signal source, awareness time/time zone, data/system scope, affected population estimate, confidentiality/integrity/availability impacts, each regime decision and source, deadline, approver, communication version, delivery/submission receipt, remediation and post-incident actions.

Failure behavior

• Missing facts do not pause a statutory clock; send the allowed initial report and update it.
• A regulator portal outage records attempts, screenshots/checksums and uses an approved fallback.
• Notification delivery failure is retried by channel and reported as a population, not hidden.
• Processor notice begins the Fiduciary assessment; the processor cannot close the Fiduciary’s decision.
• Evidence export is read-only and hash-verified.

Acceptance tests

• Given awareness at 10:00 IST, when a user changes incident severity at 15:00, then all clocks retain 10:00.
• Given an event is CERT-In-reportable but not a personal data breach, then only the applicable clocks activate and the decision is evidenced.
• Given Board detail is incomplete at hour 70, then escalation occurs and the initial/update pack is available; the system does not wait for perfect forensics.