Breach response plan¶

A documented breach response plan ensures your organization can respond quickly and consistently when a data breach occurs. Dxtra's breach reporting workflow provides the structure — this guide helps you build the surrounding processes, roles, and procedures that make it effective.

Why you need a response plan¶

Without a plan, breaches are handled reactively and inconsistently. A documented plan ensures:

• You meet the GDPR 72-hour notification deadline (starting from when the breach is discovered, not when it occurred)
• The right people are involved from the start (DPO, IT, legal, communications)
• Evidence is preserved for regulatory investigations
• Individual notifications include the right recommended actions
• Post-incident reviews lead to measurable improvements

Building your plan¶

1. Define roles and responsibilities¶

Identify who does what when a breach occurs:

Data Protection Officer — Leads the breach response, decides whether regulatory notification is required, and signs off on the breach report. In Dxtra, the DPO is selected in Step 1 of the breach report.

IT / Security team — Performs technical investigation, contains the breach, preserves evidence, and assesses whether encryption keys were compromised. Their findings feed into Steps 2 and 3 of the breach report.

Legal counsel — Advises on regulatory notification requirements, reviews the breach report before submission, and manages any legal proceedings. Their input is critical for the Notifications step.

Communications / Customer support — Drafts individual notifications and manages data subject communications. The notification checklist in Step 4 guides what to recommend to affected individuals.

Senior management — Approves the breach report, authorises remediation spend, and makes decisions about public disclosure.

2. Establish detection procedures¶

Define how your organization detects breaches:

• Security monitoring and alerting (SIEM, intrusion detection)
• Employee reporting procedures (who to contact, how to escalate)
• Processor notifications (contractual obligation for processors to report breaches to you)
• Data subject reports (individuals reporting suspicious activity)
• PII scan anomalies (Dxtra's PII scanning may reveal unexpected data exposure)

Document these detection channels so the breach timeline in Step 1 accurately captures when the breach occurred versus when it was discovered.

3. Create containment procedures¶

For each type of breach your organization might face, document the containment steps:

Unauthorised access — Revoke access, reset credentials, review access logs, isolate affected systems.

Data exfiltration — Block the exfiltration channel, identify what was taken, preserve network logs.

Ransomware / malware — Isolate affected systems, activate backups, engage incident response specialists.

Accidental disclosure — Contact the recipient, request deletion, document the exchange.

Physical breach — Secure the premises, inventory missing devices or documents, report to authorities if relevant.

These procedures map directly to the Measures Taken and Immediate Containment Actions fields in Step 3 of the breach report.

4. Define notification criteria¶

Not every breach requires regulatory notification. Document your criteria for determining when notification is required:

GDPR — Notify the supervisory authority unless the breach is unlikely to result in a risk to individuals' rights and freedoms. Notify affected individuals if the breach is likely to result in a high risk. In Dxtra's Step 4, you select Yes, No, or Under Assessment for regulatory notification.

CCPA/CPRA — Notify the California Attorney General if the breach affects more than 500 California residents. Notify affected individuals without unreasonable delay.

Other regulations — Document the notification thresholds for each jurisdiction where you operate. The Geographic Scope field in Step 2 helps identify which regulations apply based on where affected individuals are located.

5. Prepare notification templates¶

Draft notification templates in advance so you are not writing them under time pressure:

• Regulatory notification — Template letter to the supervisory authority covering what happened, what data was affected, what you are doing about it, and who to contact
• Individual notification — Template email/letter to affected individuals explaining what happened, what data was involved, what actions they should take, and how to contact you

Dxtra's Step 4 checklist (Change Passwords, Enable MFA, Monitor Financial Accounts, etc.) provides the recommended actions to include in individual notifications. Prepare these templates as attachments you can upload in Step 5.

6. Plan post-incident review¶

After every breach, conduct a post-incident review:

• What happened and why
• How quickly was the breach detected and contained
• Were notification deadlines met
• What worked well in the response
• What needs to improve

Document findings in the Long-term Improvements field in Step 3 of the breach report. Use the findings to update this response plan.

Testing your plan¶

Run tabletop exercises at least annually:

1. Choose a realistic breach scenario
2. Walk through the Dxtra breach reporting wizard as if the breach were real
3. Time how long each step takes
4. Identify gaps in your procedures or information
5. Update the response plan based on what you learn

Save the test report as a draft in Dxtra — this creates a record of your preparedness exercise without submitting it as a real incident.

Maintaining the plan¶

Review and update your response plan when:

• Your organization adds new processors or data categories
• Regulations change (new notification deadlines, new jurisdictions)
• Post-incident reviews identify improvements
• Key personnel change (new DPO, new IT security lead)
• Annual review cycle (at minimum)

Related¶

• Breach & incident management overview — The 5-step workflow and notification deadlines
• Report a data breach — Step-by-step guide to filing a breach report
• Assessments — Impact assessments that may be triggered by a breach
• Processor management — Processor breach notification obligations