Data Breach Response

A data breach occurs when personal data is accessed, disclosed, altered, or destroyed without authorisation. This playbook governs the response when breach is confirmed or reasonably suspected, covering data exfiltration by external attackers, cloud storage exposure, and breaches at third parties who process organisational data. Protection and safeguarding data incidents require the Protection Data Breach Response playbook due to additional safety considerations.

The response operates under regulatory time pressure. GDPR Article 33 requires notification to supervisory authorities within 72 hours of becoming aware of a breach likely to result in risk to individuals. This 72-hour window begins when the organisation has reasonable certainty that a breach has occurred, not when investigation completes. Other jurisdictions impose similar or shorter timelines.

Activation criteria

Invoke this playbook when any of the following conditions are met:

Confirmed breach indicators:

• Security tools detect data exfiltration (DLP alerts, unusual data transfers exceeding 100MB to external destinations)
• Personal data discovered on external systems, dark web monitoring services, or paste sites
• Attacker communication claims data theft with evidence (sample records, file listings)
• Cloud storage access logs show unauthorised downloads of personal data
• Third-party processor notifies of breach affecting organisational data

Suspected breach requiring investigation:

• Ransomware incident where attackers claim data exfiltration
• Compromised account with access to personal data repositories
• Anomalous database queries extracting large record sets
• Missing or corrupted audit logs covering personal data systems
• Whistleblower or staff report of data handling concerns

Do not invoke this playbook for security incidents without personal data involvement. Use Malware Containment or Account Compromise for incidents that do not involve personal data exposure.

Roles

For organisations without dedicated Data Protection Officer, the data protection lead role falls to whoever holds data protection responsibilities, whether that is IT leadership, a compliance officer, or legal counsel. Document who fills each role at incident start.

Phase 1: Initial assessment

Objective: Determine breach likelihood and establish response structure Timeframe: 0-4 hours from detection

1. Establish incident command

   Convene available response team members within 30 minutes of detection. For after-hours detection, the on-call IT staff member assumes initial incident commander role until leadership is available. Record the exact time the organisation became aware of the potential breach in the incident log using format YYYY-MM-DD HH:MM UTC.

   Create incident communication channel (dedicated messaging channel or conference bridge) and incident log document. All significant actions and decisions must be timestamped in the log.

2. Perform initial breach assessment

   Gather available information to assess breach likelihood:

   Initial Assessment Checklist:
   [ ] What triggered the alert or report?
   [ ] What system or data repository is involved?
   [ ] What type of data does the system contain?
   [ ] Is there evidence of actual data access or exfiltration?
   [ ] Is the incident ongoing or contained?
   [ ] What is the earliest known date of compromise?

Query relevant logs to establish timeline. For cloud services, check audit logs for the past 30 days. For on-premises systems, preserve logs before rotation occurs.

3. Classify breach likelihood

   Based on initial assessment, classify as:

   • Confirmed breach: Evidence proves personal data was accessed or exfiltrated
   • Probable breach: Circumstances strongly suggest data exposure but confirmation pending
   • Possible breach: Personal data at risk but exposure unconfirmed
   • No breach: Investigation confirms no personal data involvement

   For confirmed or probable breach, proceed immediately to Phase 2. For possible breach, continue investigation with 24-hour reassessment checkpoint. Document classification rationale.

4. Notify executive sponsor

   Brief executive sponsor within 2 hours of initial detection regardless of classification. Provide:

   • Nature of incident
   • Systems and data types potentially affected
   • Current classification (confirmed/probable/possible)
   • Immediate actions taken
   • Resource requirements

Decision point: If breach involves protection, safeguarding, or case management data, transfer to Protection Data Breach Response playbook immediately.

Checkpoint: Before proceeding to Phase 2, confirm: incident command established, initial assessment complete, executive sponsor notified, incident log active with timestamps.

Phase 2: Scope determination

Objective: Establish breach boundaries and data subject impact Timeframe: 4-24 hours from detection

1. Identify affected data categories

   Map compromised systems to data inventories. Determine which personal data categories are involved:

   +------------------------------------------------------------------+
   |                   DATA CATEGORY ASSESSMENT                       |
   +------------------------------------------------------------------+
   |                                                                  |
   |  Standard personal data:                                         |
   |  [ ] Names, addresses, contact details                           |
   |  [ ] Dates of birth                                              |
   |  [ ] Employment information                                      |
   |  [ ] Financial data (bank details, payment info)                 |
   |  [ ] Government identifiers (national ID, passport)              |
   |                                                                  |
   |  Special category data (GDPR Article 9):                         |
   |  [ ] Health data                                                 |
   |  [ ] Racial or ethnic origin                                     |
   |  [ ] Political opinions                                          |
   |  [ ] Religious or philosophical beliefs                          |
   |  [ ] Trade union membership                                      |
   |  [ ] Genetic or biometric data                                   |
   |  [ ] Sex life or sexual orientation                              |
   |                                                                  |
   |  Criminal data (GDPR Article 10):                                |
   |  [ ] Criminal convictions                                        |
   |  [ ] Alleged offences                                            |
   |                                                                  |
   +------------------------------------------------------------------+

Special category and criminal data breaches almost always require supervisory authority notification as they present inherent risk to individuals.

2. Quantify affected data subjects

   Determine the number of individuals whose data is affected. Query databases for distinct record counts:

   -- Example: Count affected individuals in compromised table
   SELECT COUNT(DISTINCT person_id) as affected_count,
          MIN(created_date) as earliest_record,
          MAX(modified_date) as latest_record
   FROM compromised_table
   WHERE [conditions matching breach scope];

Document count ranges if exact figures unavailable: “between 5,000 and 7,500 individuals based on table row counts and deduplication estimates.”

3. Establish breach timeline

   Determine:

   • First potential exposure: Earliest date attackers could have accessed data
   • Last potential exposure: When access was terminated or contained
   • Discovery date: When organisation became aware
   • Awareness date: When organisation achieved reasonable certainty of breach

   For cloud breaches, review access logs to establish precise windows. For exfiltration, network logs may show data transfer timing.

4. Assess data subject risk

   Evaluate likely consequences for affected individuals:

   Risk factor	Low risk	High risk
   Data sensitivity	Contact details only	Financial, health, or special category
   Data completeness	Partial records	Full profiles enabling identity theft
   Encryption status	Data encrypted at rest	Unencrypted or encryption keys compromised
   Recipient	Opportunistic attacker	Targeted or state actor
   Potential for harm	Inconvenience	Financial loss, discrimination, safety risk

   High risk in any factor typically requires data subject notification regardless of supervisory authority guidance.

5. Identify geographic scope

   Determine jurisdictions of affected data subjects for regulatory notification requirements:

   +------------------------------------------------------------------+
   |                  JURISDICTION DETERMINATION                      |
   +------------------------------------------------------------------+
   |                                                                  |
   |  Affected data subjects located in:                              |
   |                                                                  |
   |  [ ] UK --> ICO notification                                     |
   |  [ ] EU Member States --> Lead supervisory authority             |
   |  [ ] Switzerland --> FDPIC notification                          |
   |  [ ] USA --> State-specific requirements                         |
   |  [ ] Other jurisdictions --> Check local requirements            |
   |                                                                  |
   |  For multi-jurisdiction breach:                                  |
   |  - Identify lead supervisory authority (main establishment)      |
   |  - Notify lead authority who coordinates with others             |
   |  - Direct notification may still be required in some states      |
   |                                                                  |
   +------------------------------------------------------------------+

Decision point: Based on scope determination, decide notification requirement:

                              +------------------+
                              | Breach           |
                              | confirmed?       |
                              +--------+---------+
                                       |
                         +-------------+-------------+
                         |                           |
                         | Yes                       | No
                         v                           v
                +--------+---------+        +--------+---------+
                | Risk to          |        | Continue         |
                | individuals?     |        | investigation    |
                +--------+---------+        +------------------+
                         |
           +-------------+-------------+
           |                           |
           | Yes/Likely                | Unlikely
           v                           v
  +--------+---------+        +--------+---------+
  | Notify           |        | Document         |
  | supervisory      |        | decision not     |
  | authority        |        | to notify        |
  +--------+---------+        +------------------+
           |
           v
  +--------+---------+
  | High risk to     |
  | individuals?     |
  +--------+---------+
           |
     +-----+-----+
     |           |
     | Yes       | No
     v           v
+----+----+ +----+----+
| Notify  | | No data |
| data    | | subject |
| subjects| | notify  |
+---------+ +---------+

Figure 1: Notification requirement decision tree

Checkpoint: Before proceeding to Phase 3, confirm: data categories identified, affected count established, timeline documented, risk assessment complete, notification decision made.

Phase 3: Containment

Objective: Stop ongoing breach and prevent further exposure Timeframe: Immediate and ongoing from detection

Containment actions run in parallel with scope determination. Do not delay containment awaiting complete scope analysis.

1. Revoke compromised access

   If breach resulted from credential compromise:

   • Reset passwords for affected accounts
   • Revoke active sessions across all systems
   • Disable compromised service accounts or API keys
   • Review and revoke suspicious OAuth grants

   # Example: Azure AD - Revoke all sessions for user
   Revoke-AzureADUserAllRefreshToken -ObjectId user@example.org

   # Example: Google Workspace - Sign out user from all sessions
   gam user user@example.org signout

2. Isolate affected systems

   For active exfiltration or ongoing attacker access:

   • Block network egress from compromised systems
   • Isolate systems from network while preserving for forensics
   • Disable external access to affected cloud storage

   Do not shut down systems if forensic investigation is required. Memory contents are lost on shutdown.

3. Secure exposed data

   If data exposed publicly (misconfigured storage, paste site):

   • Remove public access immediately
   • Request takedown from hosting providers
   • Document URL and content before removal for evidence
   • Check web archives (Wayback Machine) for cached copies

4. Block attacker infrastructure

   If attacker command and control or exfiltration destinations identified:

   • Block IP addresses and domains at firewall
   • Add to email security blocklists
   • Share indicators with peer organisations if appropriate

5. Implement additional monitoring

   Increase logging and alerting on:

   • Authentication to affected systems
   • Data access patterns
   • Network traffic to/from affected systems
   • Similar attack patterns elsewhere in environment

Coordinate containment with Evidence Collection to preserve forensic artifacts before any remediation actions.

Phase 4: Regulatory notification

Objective: Meet supervisory authority notification requirements within statutory timelines Timeframe: Within 72 hours of awareness (GDPR); varies by jurisdiction

1. Prepare notification content

   Compile required information for supervisory authority notification. GDPR Article 33(3) requires:

   • Nature of breach including data categories and approximate number of data subjects
   • Name and contact details of Data Protection Officer or other contact
   • Likely consequences of the breach
   • Measures taken or proposed to address the breach and mitigate effects

   If complete information is unavailable within 72 hours, provide information in phases as it becomes available. Initial notification can state “investigation ongoing” for unknown elements.

2. Determine notification channel

   Supervisory authority	Notification method	Portal/contact
   UK ICO	Online form	ico.org.uk/make-a-complaint/data-protection-complaints/data-protection-for-organisations/
   Ireland DPC	Online form	forms.dataprotection.ie/breach
   France CNIL	Online form	notifications.cnil.fr
   Germany (federal)	Through state authority	Varies by Bundesland
   Netherlands AP	Online form	autoriteitpersoonsgegevens.nl

   For UK ICO, self-assessment tool determines whether notification is required before accessing breach report form.

3. Submit notification

   Complete notification form with prepared information. Record:

   • Submission timestamp
   • Reference number provided
   • Name of person who submitted
   • Copy of submitted information

   Retain evidence of notification timing for compliance documentation.

4. Handle information requests

   Supervisory authorities may request additional information. Typical requests include:

   • Technical details of how breach occurred
   • Evidence of containment measures
   • Data subject notification content
   • Remediation timeline

   Respond to information requests promptly. Delays can result in regulatory action independent of the breach itself.

Phase 5: Third-party breach coordination

Objective: Manage response when breach occurs at third-party processor or affects shared data Timeframe: Throughout incident

Third-party breaches present coordination challenges. The data controller (your organisation) retains notification responsibilities even when breach occurs at a processor.

1. Assess processor notification adequacy

   When notified by a processor of breach, evaluate:

   • Does notification meet contractual requirements (timing, content)?
   • Is information sufficient for your regulatory notification?
   • What investigation access will processor provide?

   +------------------------------------------------------------------+
   |             THIRD-PARTY BREACH INFORMATION REQUEST               |
   +------------------------------------------------------------------+
   |                                                                  |
   |  Request from processor:                                         |
   |                                                                  |
   |  [ ] Exact date and time breach occurred                         |
   |  [ ] Date and time breach discovered                             |
   |  [ ] Nature of breach (attack type, vulnerability)               |
   |  [ ] Data categories affected                                    |
   |  [ ] Number of your data subjects affected                       |
   |  [ ] Your specific data records vs other controllers' data       |
   |  [ ] Containment actions taken                                   |
   |  [ ] Evidence of data access or exfiltration                     |
   |  [ ] Ongoing risks                                               |
   |  [ ] Processor's notification to their supervisory authority     |
   |  [ ] Contact for ongoing coordination                            |
   |                                                                  |
   +------------------------------------------------------------------+

2. Coordinate notification responsibilities

   As data controller, your organisation must notify your supervisory authority. The processor notifies their supervisory authority separately if they are also a controller for other data.

   For multi-controller scenarios (data shared with partners), agree:

   • Which organisation notifies supervisory authority (or whether each notifies independently)
   • Consistent messaging to data subjects
   • Information sharing for investigation

3. Manage donor notification

   For grant-funded programmes, review donor agreements for breach notification requirements. Common donor requirements:

   Donor type	Typical requirement
   USAID	Notify Agreement Officer within 24 hours
   FCDO	Notify programme manager immediately
   EU (DG ECHO, DG INTPA)	Follow Data Protection provisions in grant agreement
   UN agencies	Per data sharing agreement terms

   Donor notification is separate from regulatory notification. Both may be required.

4. Assess contract remedies

   Review processor agreement for:

   • Breach notification timeline requirements (typically 24-48 hours)
   • Investigation and audit rights
   • Indemnification provisions
   • Termination rights

   Document contract compliance or non-compliance for potential future action.

Phase 6: Data subject notification

Objective: Inform affected individuals when breach presents high risk to their rights and freedoms Timeframe: Without undue delay following supervisory authority notification (if made)

Data subject notification is required when breach is likely to result in high risk to individuals. High risk scenarios include: financial data enabling fraud, health data enabling discrimination, authentication credentials enabling account takeover, or data combinations enabling identity theft.

1. Determine notification requirement

   Notification to data subjects is NOT required if:

   • Data was encrypted with keys not compromised
   • Subsequent measures ensure high risk is no longer likely
   • Notification would involve disproportionate effort (use public communication instead)
   • Supervisory authority specifically advises against notification

   Document reasoning if deciding not to notify data subjects after supervisory authority notification.

2. Identify notification method

   Data subject type	Primary method	Backup method
   Current staff	Work email + meeting	Personal email from HR records
   Former staff	Personal email from records	Postal mail to last known address
   Beneficiaries/service users	Method used for programme communication	Partner notification for indirect reach
   Donors/supporters	Email from CRM	Postal mail
   General public	Website notice + media	Social media

   For beneficiaries in contexts without email access, work with programme teams on appropriate notification channels. SMS, community meetings, or partner networks may be required.

3. Draft notification content

   GDPR Article 34 requires notification to include:

   • Nature of the breach in clear, plain language
   • Name and contact details of DPO or other contact
   • Likely consequences
   • Measures taken to address breach and mitigate effects
   • Recommendations for individuals to protect themselves

   See Communication Templates section below for templates.

4. Execute notification

   Send notifications in batches if volume is large. Track:

   • Number of notifications sent
   • Delivery failures (bounced emails, returned mail)
   • Response volume to helpdesk/contact point

   For notifications in multiple languages, ensure translation accuracy. Do not rely solely on machine translation for legal notifications.

5. Provide support to affected individuals

   Based on breach severity and data types, consider offering:

   • Dedicated contact point for questions
   • Credit monitoring service (for financial data breaches)
   • Guidance on password changes and account monitoring
   • Information on recognising and reporting misuse

Phase 7: Post-breach activities

Objective: Document incident, implement improvements, and close response Timeframe: 2-4 weeks following containment

1. Complete breach documentation

   Compile comprehensive breach record including:

   Breach Record Contents:
   - Incident timeline (detection to closure)
   - Technical root cause analysis
   - Data categories and volumes affected
   - Containment actions and effectiveness
   - All notifications made (supervisory authority, data subjects, donors)
   - Copies of notification content
   - Response costs and resource utilisation
   - Third-party involvement

GDPR Article 33(5) requires records of all breaches regardless of notification. Records must include facts, effects, and remedial actions.

2. Conduct post-incident review

   Schedule review meeting within 2 weeks of incident closure. Include all response team members and relevant stakeholders. Review:

   • What happened and why
   • What went well in response
   • What could have been handled better
   • What changes would prevent recurrence
   • What changes would improve response

   Document findings in written report for executive sponsor and board if breach was significant.

3. Implement remediation

   Track remediation actions arising from incident:

   Finding	Action	Owner	Deadline	Status
   Excessive data retention	Implement automated deletion	IT	+30 days	Open
   Delayed detection	Deploy DLP alerting	Security	+60 days	Open
   Slow response assembly	Create on-call rota	IT Director	+14 days	Open

4. Update controls and documentation

   Based on incident learnings:

   • Update risk register with new or modified risks
   • Revise security controls where gaps identified
   • Update this playbook if response process needs improvement
   • Brief staff on new threats or procedures

5. Close incident

   Incident closure requires:

   • All immediate containment complete
   • Regulatory notifications submitted
   • Data subject notifications complete (if required)
   • Post-incident review conducted
   • Remediation actions assigned and tracked
   • Documentation filed

   Executive sponsor signs off on incident closure.

Communications

Stakeholder notification matrix

Communication templates

Supervisory authority notification (initial):

PERSONAL DATA BREACH NOTIFICATION

Controller: [Organisation legal name]
DPO/Contact: [Name, email, phone]
Notification date: [Date]

Nature of breach:
On [date], [organisation] identified [brief description of breach].
The breach involves [data categories]. Approximately [number] individuals
are affected.

Circumstances:
[How breach occurred - e.g., "unauthorised access to cloud storage,"
"credential compromise enabling database access"]

Timeline:
- Breach occurred: [date/time or range]
- Breach discovered: [date/time]
- Breach contained: [date/time or "ongoing"]

Data categories affected:
[List specific categories - names, contact details, financial data, etc.]

Likely consequences:
[Assessment of harm - e.g., "Risk of phishing using contact details,"
"Potential for identity fraud given combination of data elements"]

Measures taken:
- [Containment action 1]
- [Containment action 2]
- [Planned remediation]

Data subject notification:
[Whether notification planned and timeline, or reasons for not notifying]

Further information will be provided as investigation continues.

Data subject notification (high risk breach):

Subject: Important information about your personal data

Dear [Name/recipient],

We are writing to inform you of a data security incident that may have
affected your personal information.

What happened:
On [date], we discovered that [brief, plain language description].
This incident may have exposed the following information about you:
[list data types in plain terms].

What we are doing:
We took immediate action to [containment measures]. We have notified
the Information Commissioner's Office and are working to prevent
similar incidents.

What you can do:
We recommend you:
- [Specific protective action 1 - e.g., "monitor your bank statements"]
- [Specific protective action 2 - e.g., "be cautious of unexpected emails"]
- [Specific protective action 3 - e.g., "consider changing passwords"]

[If offering support:]
We are offering [credit monitoring/other support]. To access this,
[instructions].

Contact us:
If you have questions, contact [name] at [email] or [phone].
We are available [hours/days].

We sincerely apologise for this incident and any concern it causes.

[Signature]
[DPO or senior executive]

Internal staff notification:

Subject: Data security incident - information for staff

Dear colleagues,

I am writing to inform you of a data security incident we are
currently managing.

What happened:
[Brief factual description appropriate for internal audience]

What we are doing:
Our incident response team is [current status]. We have [notifications
made]. [Expected timeline for resolution].

What you may be asked:
If you receive inquiries from [data subjects/media/others], please
direct them to [contact point]. Do not speculate or share details
beyond this communication.

[If staff data affected:]
Your personal data [was/was not] affected by this incident.
[Instructions specific to staff].

Questions:
Contact [internal contact] for questions. A briefing session will
be held [date/time/location].

[Signature]
[Executive sponsor]

Evidence preservation

Preserve the following evidence throughout response:

Seven-year retention aligns with GDPR enforcement period. Coordinate evidence collection with Evidence Collection task procedures.

Breach record documentation

GDPR Article 33(5) requires maintaining records of all personal data breaches. For each breach, record:

+------------------------------------------------------------------+
|                     BREACH RECORD (REQUIRED)                     |
+------------------------------------------------------------------+
|                                                                  |
|  Breach reference: [Unique identifier]                           |
|                                                                  |
|  Facts:                                                          |
|  - Date/time of breach:                                          |
|  - Date/time of discovery:                                       |
|  - How breach occurred:                                          |
|  - Data categories affected:                                     |
|  - Number of records affected:                                   |
|  - Number of data subjects affected:                             |
|                                                                  |
|  Effects:                                                        |
|  - Impact assessment:                                            |
|  - Harm to data subjects (actual or potential):                  |
|                                                                  |
|  Remedial actions:                                               |
|  - Containment measures:                                         |
|  - Recovery actions:                                             |
|  - Preventive measures implemented:                              |
|                                                                  |
|  Notifications:                                                  |
|  - Supervisory authority: [Yes/No] [Date] [Reference]            |
|  - Data subjects: [Yes/No] [Date] [Number notified]              |
|  - If no notification, reasoning:                                |
|                                                                  |
|  Closure:                                                        |
|  - Incident closed date:                                         |
|  - Closed by:                                                    |
|  - Post-incident review date:                                    |
|                                                                  |
+------------------------------------------------------------------+

Maintain breach records even for incidents where notification was not required. Supervisory authorities may request breach logs during audits.

Regulatory timeline summary

    0h           24h          48h          72h         1 week      1 month
    |------------|------------|------------|------------|-----------|
    |            |            |            |            |           |
    v            v            v            v            v           v
 Awareness   Internal     Scope        Authority   Data        Remediation
 clock       escalation   determined   notification subject     progress
 starts      complete                  deadline     notification review
                                       (GDPR)       (if high
                                                    risk)

 +------------------------------------------------------------------+
 |                                                                  |
 |  Key deadlines:                                                  |
 |                                                                  |
 |  GDPR (UK/EU): 72 hours to supervisory authority                 |
 |  Switzerland: 72 hours to FDPIC                                  |
 |  US (varies): California 72h, other states vary                  |
 |  USAID: 24 hours to Agreement Officer                            |
 |  Most contracts: 24-48 hours to data controller                  |
 |                                                                  |
 +------------------------------------------------------------------+

Figure 2: Regulatory notification timeline

See also

• Protection Data Breach Response for breaches involving safeguarding or protection data
• Breach Management for breach management concepts and notification templates
• Data Classification for data classification reference
• Evidence Collection for forensic evidence procedures
• Account Compromise when breach results from credential compromise
• Incident Triage Matrix for incident classification
• Data Protection Policy for policy requirements
• Donor IT Requirements for donor notification requirements