A breach response plan is not a document you open after the incident.
It is a set of decisions you make before the incident so the organisation can move quickly when facts are incomplete.
The plan should connect security, privacy, engineering, legal, communications, and leadership.
For India, a personal data breach can create DPDP obligations alongside separate cyber-incident reporting obligations. CERT-In's directions include a six-hour reporting requirement for covered incidents, while Rule 7 of the final DPDP Rules requires the Board to be notified without delay, with detailed and updated information within 72 hours unless a longer period is allowed. Affected Data Principals must also be informed without delay.
Build around the first 60 minutes
At 2:00 AM nobody wants a 40-page policy.
They need:
Detect
→ Open incident
→ Contain
→ Identify data
→ Assign owners
→ Assess reporting
→ Preserve evidence
→ Communicate
Step 1: Define what counts as a privacy incident
Include examples:
- Database compromise
- Lost device containing personal data
- Mis-sent customer export
- Public S3 bucket
- Exposed API
- Credential theft
- Vendor breach
- Accidental disclosure
Do not limit the plan to “hacking.”
Step 2: Log the first facts
Record immediately:
- Detection time
- Reporter
- System
- Initial description
- Current containment
- Suspected data
- Current uncertainty
Never rely on memory later.
Step 3: Contain without destroying evidence
Actions may include:
- Revoke credentials
- Isolate systems
- Disable exposed endpoints
- Rotate secrets
- Preserve logs
Coordinate containment with forensic preservation.
Step 4: Find the data
This is where the data map matters.
If the affected system is:
customer-db.orders
you need to know:
- Which fields
- How many records
- Which users
- Which copies
- Which processors
The faster you can map the blast radius, the faster you can make reporting decisions.
Step 5: Branch the regulatory workflow
Do not run one generic “notify regulators” checklist.
Build separate tracks:
Security incident
├── CERT-In assessment
├── DPDP assessment
├── Sector regulator assessment
├── Customer notification
└── Data Principal notification
Which branches activate depends on the incident and applicable rules.
Step 6: Prepare the DPDP notification fields in advance
Rule 7 establishes the required content and timing for breach notifications. Build a template that captures the key facts so the team is filling information rather than designing a document during the incident.
Step 7: Build vendor notification paths
If your processor discovers the incident first, you need a contact that actually answers.
For high-risk processors, document:
- Security contact
- Escalation contact
- Contractual notification expectation
- Data categories
- Your internal owner
Step 8: Run a tabletop
A quarterly tabletop is far more useful than another policy review.
Scenario:
“At 02:07 a.m. a database credential is found in a public repository. The database contains customer email, phone and KYC references.”
Ask each person what they do next.
Record delays.
Fix them.
Common failures
Nobody knows who owns the clock.
Data inventory is six months old.
Legal learns about the breach after engineering has already deleted logs.
Vendor contacts are outdated.
Notification templates are drafted from scratch.
The plan is never tested.
Where Privra fits
Privra connects discovery, processor mapping, evidence, and compliance workflows so the incident team can identify scope faster and preserve a structured record of what happened.
During a breach, the question is not whether you have a policy.
It is whether you can turn uncertainty into facts quickly enough to act.