Protection Data Breach Response

Protection data breach response addresses incidents where safeguarding records, case management data, or protection information has been accessed, exfiltrated, or exposed. These breaches require a survivor-centred response that prioritises physical safety over regulatory compliance timelines. Standard data breach procedures assume notification benefits affected individuals; protection data breaches present situations where notification itself creates danger.

Activation criteria

Invoke this playbook when any of the following conditions exist:

Do not invoke this playbook for general personal data breaches affecting staff or non-protection beneficiaries. Those incidents follow the standard Data Breach Response playbook. When a breach involves both protection and general data, run both playbooks in parallel with this playbook taking precedence for protection-related decisions.

Roles

The incident commander holds authority to delay regulatory notification when safety assessment indicates risk to survivors. This authority exists because protection data breaches present genuine conflicts between legal compliance and physical safety that do not arise in standard breaches.

Phase 1: Immediate safety assessment

Objective: Determine whether breach creates imminent physical risk to survivors before proceeding with standard incident response.

Timeframe: Complete within 4 hours of breach confirmation

1. Confirm breach involves protection data by reviewing accessed records against protection case registers. Query case management system audit logs for the compromised account or access vector:

   SELECT case_id, case_type, survivor_pseudonym, access_timestamp
   FROM audit_log
   WHERE accessor_id = '[compromised_account]'
   AND access_timestamp BETWEEN '[breach_start]' AND '[breach_end]'
   AND case_type IN ('GBV', 'child_protection', 'trafficking', 'safeguarding')
   ORDER BY access_timestamp;

Record the total count of protection cases accessed and categorise by case type.

2. Assess data sensitivity for each accessed case using the protection data classification matrix. For each case, determine whether the exposed data includes:

   • Survivor identity (name, photograph, biometric)
   • Survivor location (address, GPS coordinates, shelter placement)
   • Perpetrator identity that could be traced to survivor
   • Case narrative revealing circumstances
   • Contact information (phone, email, emergency contacts)

   Cases where location data combined with identity data are exposed represent the highest risk category.

3. Evaluate threat actor capability and intent. Determine whether the breach appears to be:

   • Opportunistic (ransomware, credential stuffing) where attacker sought any valuable data
   • Targeted at the organisation but not specific individuals
   • Targeted at specific cases or survivors

   Targeted breaches require immediate escalation to the incident commander regardless of data sensitivity, as they indicate an adversary with specific interest in protection data.

4. Complete the rapid safety assessment for each high-risk case. The protection lead reviews each case and assigns a safety risk rating:

   • Critical: Perpetrator likely to locate survivor within 24 hours using exposed data. Immediate protective action required.
   • High: Exposed data significantly increases risk to survivor. Protective action required within 72 hours.
   • Medium: Exposed data creates elevated but not immediate risk. Case monitoring and survivor contact within 7 days.
   • Low: Exposed data unlikely to increase risk. Standard notification procedures apply.

   Document the rating and reasoning for each case in the incident log.

5. For any case rated Critical or High, the protection lead initiates the survivor safety protocol immediately, before proceeding to Phase 2. This protocol operates independently of the breach response:

   • Contact survivor through established safe communication channel
   • Assess current safety status
   • Activate safety plan if one exists
   • Coordinate with protection partners for immediate support
   • Do not disclose breach details until safety is secured

Decision point: If any cases are rated Critical, the incident commander must decide whether to pause breach investigation activities that might alert the threat actor to detection. Investigation activities that modify logs or revoke access can signal to an attacker that they have been discovered, potentially accelerating harmful action.

Checkpoint: Phase 1 complete when all accessed protection cases have safety ratings assigned, Critical and High cases have survivor safety protocols initiated, and the incident commander has documented the decision to proceed with investigation.

+------------------------------------------------------------------+
|                PROTECTION BREACH SAFETY ASSESSMENT               |
+------------------------------------------------------------------+
                              |
                              v
               +--------------+---------------+
               | Breach confirmed involving   |
               | protection data              |
               +--------------+---------------+
                              |
                              v
               +--------------+---------------+
               | Query accessed protection    |
               | cases from audit logs        |
               +--------------+---------------+
                              |
                              v
               +--------------+---------------+
               | For each case: assess        |
               | exposed data elements        |
               +--------------+---------------+
                              |
          +-------------------+-------------------+
          |                   |                   |
          v                   v                   v
   +------+------+     +------+------+     +------+------+
   | Identity +  |     | Identity    |     | Case data   |
   | Location    |     | only        |     | only        |
   | exposed     |     |             |     |             |
   +------+------+     +------+------+     +------+------+
          |                   |                   |
          v                   v                   v
   +------+------+     +------+------+     +------+------+
   | CRITICAL or |     | MEDIUM or   |     | LOW         |
   | HIGH risk   |     | HIGH risk   |     | risk        |
   +------+------+     +------+------+     +------+------+
          |                   |                   |
          v                   |                   |
   +------+------+            |                   |
   | Initiate    |            |                   |
   | survivor    |<-----------+                   |
   | safety      |                                |
   | protocol    |                                |
   +------+------+                                |
          |                                       |
          +-------------------+-------------------+
                              |
                              v
               +--------------+---------------+
               | Document all ratings         |
               | Proceed to Phase 2           |
               +--------------+---------------+

Figure 1: Protection breach safety assessment flowchart

Phase 2: Containment and investigation

Objective: Stop ongoing data exposure and determine breach scope while preserving evidence for potential legal proceedings.

Timeframe: Complete within 24 hours of Phase 1 completion

1. Contain the breach vector. The technical lead executes containment based on breach type:

   For compromised credentials:

   # Disable compromised account immediately
   # Azure AD / Entra ID
   az ad user update --id user@example.org --account-enabled false

   # Revoke all active sessions
   az rest --method POST \
     --uri 'https://graph.microsoft.com/v1.0/users/[user-id]/revokeSignInSessions'

For malware or unauthorised access:

   # Isolate affected system from network
   # Example: Windows Defender ATP isolation
   # Or network-level isolation via firewall rule
   iptables -I INPUT -s [compromised_ip] -j DROP
   iptables -I OUTPUT -d [compromised_ip] -j DROP

For third-party system breach:

• Revoke API tokens and service account credentials immediately
• Disable data sharing integrations
• Contact third party to confirm their containment status

2. Preserve evidence before any remediation. The technical lead captures:

   • Full audit logs from case management system (export to immutable storage)
   • Authentication logs covering breach period
   • Network flow data if available
   • Memory capture from compromised endpoints (if still accessible)
   • Screenshots of any attacker artifacts

   Follow chain of custody procedures from Evidence Collection. Protection data breaches frequently result in legal proceedings, making evidence integrity essential.

3. Determine complete breach scope. Analyse logs to establish:

   • Exact records accessed (not just systems)
   • Duration of unauthorised access
   • Whether data was exfiltrated (network egress analysis)
   • Whether data was modified or deleted
   • Other systems accessed using same credentials

   For protection data, err on the side of assuming exfiltration occurred if you cannot definitively prove it did not. The safety consequences of underestimating scope exceed those of overestimating.

4. Compile affected survivor list. Create a master list of all protection cases with potentially compromised data:

   Case ID	Survivor pseudonym	Data exposed	Safety rating	Case manager	Partner data
   [ID]	[Pseudonym]	[Elements]	[Rating]	[Name]	[Yes/No]

   This list drives all subsequent notification and safety decisions. Store it encrypted with access limited to incident response team members.

5. Assess perpetrator access to exposed data. For each Critical or High rated case, the protection lead evaluates whether:

   • Known perpetrators could plausibly access the exposed data
   • Perpetrators have technical capability to exploit breach (dark web access, data broker relationships)
   • Perpetrators have demonstrated prior surveillance of survivor

   This assessment determines urgency of protective action independent of whether the threat actor was specifically targeting protection data.

Checkpoint: Phase 2 complete when breach vector is contained, evidence is preserved, complete affected survivor list exists, and the incident commander has current scope assessment.

Phase 3: Survivor notification decisions

Objective: Determine whether, when, and how to notify each affected survivor, with safety as the primary criterion.

Timeframe: Decision framework complete within 48 hours; individual decisions may extend based on safety assessment

Protection data breaches create a fundamental tension: data protection law requires notification to affected individuals, but notification itself can endanger survivors. GDPR Article 34 provides an exception where notification “is likely to result in a risk to the rights and freedoms of natural persons,” but this exception is rarely invoked and requires documentation. This phase establishes the decision framework and documents reasoning for each case.

1. Apply the survivor notification decision tree to each case on the affected list. The protection lead and legal counsel review each case jointly:

   +------------------------------------------------------------------+
   |              SURVIVOR NOTIFICATION DECISION TREE                 |
   +------------------------------------------------------------------+
                                    |
                                    v
                     +--------------+---------------+
                     | Would notification itself    |
                     | create safety risk?          |
                     +--------------+---------------+
                                    |
                 +------------------+------------------+
                 |                                    |
                 v                                    v
           +-----+-----+                        +-----+-----+
           | YES       |                        | NO        |
           +-----+-----+                        +-----+-----+
                 |                                    |
                 v                                    v
      +----------+----------+              +----------+----------+
      | Can survivor be     |              | Standard            |
      | contacted through   |              | notification        |
      | safe channel?       |              | within 72 hours     |
      +----------+----------+              +---------------------+
                 |
         +-------+-------+
         |               |
         v               v
   +-----+-----+   +-----+-----+
   | YES       |   | NO        |
   +-----+-----+   +-----+-----+
         |               |
         v               v
   +-----+-----+   +-----+-----+
   | Notify    |   | Document  |
   | through   |   | exception |
   | safe      |   | Defer     |
   | channel   |   | until     |
   | within    |   | safe      |
   | 7 days    |   | contact   |
   +-----------+   | possible  |
                   +-----------+

Figure 2: Survivor notification decision tree

2. For cases where notification creates safety risk, document the specific risk factors:

   • Perpetrator monitors survivor communications
   • Perpetrator controls survivor’s devices or accounts
   • Notification would reveal survivor’s location
   • Notification would reveal survivor’s engagement with protection services
   • Survivor is a minor and notification to guardians creates risk

   Retain this documentation for regulatory defence. Supervisory authorities recognise that protection contexts present genuine exceptions, but require evidence-based reasoning.

3. Identify safe communication channels for each survivor. Review case records for:

   • Pre-established safe contact methods (documented in safety plan)
   • Verified alternative phone numbers
   • Trusted third parties who can relay messages
   • Scheduled in-person contact opportunities

   If no safe channel exists and notification creates risk, document this as grounds for deferred notification under GDPR Article 34.

4. Prepare survivor-appropriate notification content. Standard breach notifications assume recipients can take protective action (change passwords, monitor credit). Protection breach notifications must account for:

   • Limited survivor agency in some situations
   • Need to avoid re-traumatisation
   • Potential that survivor is unaware of case existence
   • Different literacy and language requirements

   Develop notification scripts rather than written notices for verbal delivery through case managers.

5. Schedule notification delivery. For notifications proceeding:

   • Critical safety cases: Protection lead personally reviews notification approach before delivery
   • In-person notification preferred where case manager relationship exists
   • Phone notification through verified safe number as secondary option
   • Written notification only where survivor has confirmed safe address and prefers written communication

   Do not use SMS, messaging apps, or email unless specifically verified as safe for that survivor.

Checkpoint: Phase 3 complete when each affected survivor has notification decision documented with reasoning, safe contact channels identified where notification will proceed, and notification scripts prepared.

Phase 4: Partner and authority coordination

Objective: Notify partner organisations whose data was affected and coordinate with regulatory authorities while protecting survivor safety.

Timeframe: Begin within 48 hours; complete partner notification within 7 days

1. Identify partner data exposure. Review the affected survivor list for cases involving:

   • Data received from partner organisations
   • Data shared with partner organisations
   • Joint case management arrangements
   • Inter-agency referrals

   Partner organisations have independent notification obligations for their beneficiaries. Your breach creates their breach.

2. Notify affected partners through protection channels. Contact partner protection or safeguarding leads directly, not general IT or communications contacts:

   • Identify specific cases with shared data
   • Share safety assessments for those cases
   • Coordinate notification approach to avoid contradictory messages
   • Document partner notification in incident log

   Use the partner notification template in the Communications section.

3. Prepare regulatory authority notification. GDPR requires notification to supervisory authority within 72 hours of becoming aware of a breach. For protection data breaches:

   • Begin draft notification immediately, even before 72 hours
   • Include clear statement that protection data is involved
   • Document any notification delays justified by safety assessment
   • Request confidential handling given survivor safety implications

   Most supervisory authorities have experience with protection data and will work with organisations on appropriate handling.

4. Coordinate with law enforcement if criminal investigation is warranted. Factors indicating law enforcement involvement:

   • Targeted attack on protection data suggesting perpetrator involvement
   • Significant exfiltration of survivor identities and locations
   • Ransomware where payment consideration exists
   • Insider threat with protection case access

   Involve legal counsel before law enforcement contact. In some jurisdictions, law enforcement notification may create obligations that conflict with survivor safety.

5. Engage external specialist support if needed. Protection data breaches may require:

   • External forensics for complex technical investigation
   • External legal counsel for regulatory defence
   • Specialist survivor support organisations
   • Media relations support if breach becomes public

   Pre-approved vendors from organisational incident response planning should be used where available.

Checkpoint: Phase 4 complete when all affected partners are notified, regulatory notification is filed (or documentation exists for any delay), and law enforcement decision is documented.

Phase 5: Recovery and protective action

Objective: Restore secure operations and implement protective measures for affected survivors.

Timeframe: Begin immediately after containment; complete within 14 days

1. Restore case management system access through secure process:

   • Reset all credentials that may have been compromised
   • Require MFA re-enrollment for affected users
   • Implement additional access controls for high-sensitivity cases
   • Enable enhanced audit logging

   Do not restore access until containment is confirmed complete.

2. Implement case-level protective measures based on safety ratings:

   Critical-rated cases:

   • Relocate survivor if location was exposed and perpetrator poses threat
   • Change all survivor contact methods
   • Update safety plan with breach-informed risk assessment
   • Increase case monitoring frequency

   High-rated cases:

   • Update safety plan
   • Provide survivor with guidance on monitoring for misuse
   • Review perpetrator status and location
   • Increase case monitoring for 90 days

   Medium-rated cases:

   • Notify survivor through safe channel
   • Offer updated safety planning session
   • Document in case record

   Low-rated cases:

   • Standard notification
   • Document in case record

3. Address perpetrator-specific risks. If perpetrator identity was exposed alongside survivor data:

   • Assess whether perpetrator may face retaliation
   • Consider duty of care obligations
   • Document decision reasoning

   This creates ethical complexity: perpetrators have data rights but may use breach response processes to locate survivors.

4. Provide psychological support for affected survivors and staff:

   • Offer counselling support to survivors notified of breach
   • Provide staff debriefing for those involved in response
   • Case managers who delivered notifications require specific support
   • Monitor for secondary trauma in protection team

5. Update protection data security controls based on lessons learned:

   • Implement additional technical controls identified during investigation
   • Review access permissions for protection data
   • Update case management system security configuration
   • Enhance monitoring for protection data access

Checkpoint: Phase 5 complete when case management system access is securely restored, all case-level protective measures are implemented, and support is offered to affected individuals.

Phase 6: Documentation and review

Objective: Complete required documentation and conduct structured review to improve future response.

Timeframe: Complete within 30 days of breach containment

1. Complete regulatory documentation:

   • Final breach notification to supervisory authority (if required update from initial notification)
   • Documentation of all notification decisions with reasoning
   • Evidence of survivor notification or documented exception
   • Record of protective measures implemented

   Retain all documentation for minimum 7 years given potential for delayed legal proceedings in protection cases.

2. Complete internal incident report following Evidence Collection template. Protection data breach reports require additional sections:

   • Safety assessment methodology and outcomes
   • Notification exception justifications
   • Partner coordination summary
   • Protective measures by case category
   • Survivor feedback (where safely obtainable)

3. Conduct structured review with incident response team:

   • What worked well in the safety assessment process?
   • Where did tension between safety and compliance create difficulty?
   • Were survivor contact channels adequate?
   • Did partner coordination function effectively?
   • What additional controls would have prevented or limited breach?

4. Update protection data breach procedures based on lessons learned. Changes may include:

   • Modified safety assessment criteria
   • Additional safe contact channel requirements in case intake
   • Enhanced partner coordination protocols
   • Technical control improvements

5. Report to leadership and governance bodies:

   • Board safeguarding committee (if applicable)
   • Donor reporting (if grant-funded data involved)
   • Annual safeguarding report

   Ensure reporting protects survivor confidentiality while providing meaningful governance oversight.

Checkpoint: Phase 6 complete when all documentation is finalised, structured review has occurred, and recommendations are documented for implementation.

Communications

Internal communication

Partner notification template

CONFIDENTIAL - PROTECTION DATA INCIDENT

To: [Partner Organisation] Protection/Safeguarding Lead
From: [Your Organisation] Incident Commander
Date: [Date]
Reference: [Incident reference number]

We are writing to inform you of a data security incident that affects
protection data shared between our organisations.

INCIDENT SUMMARY
Date of discovery: [Date]
Nature of incident: [Brief description]
Data potentially affected: [Description without individual identifiers]

SHARED CASES AFFECTED
We have identified [number] cases involving data shared with your
organisation. Case reference numbers: [List]

We have completed safety assessments for these cases. Our assessment
indicates [summary of safety ratings].

COORDINATION REQUEST
We request coordination on:
- Survivor notification approach for shared cases
- Any additional safety measures for survivors in your care
- Unified messaging if external communication required

Please contact [Protection Lead name] at [secure contact] to coordinate
response.

This notification is confidential and should be handled by protection/
safeguarding staff only.

Survivor notification script template

[For verbal delivery by case manager through safe channel]

OPENING
"[Survivor name], I need to share some important information with you
about your records. Are you in a safe place to talk right now?"

[If no: arrange safe callback time]
[If yes: continue]

CORE MESSAGE
"We recently discovered that someone accessed our computer systems
without authorisation. We believe they may have seen some information
from your case file.

The information that may have been seen includes: [specific elements]

We do not believe [perpetrator name] was involved in this, and we do
not have any indication they have seen this information. We are telling
you so you can be aware and let us know if you notice anything unusual."

SAFETY CHECK
"Has anything happened recently that has concerned you about your
safety? Have you noticed anyone asking questions about you or trying
to contact you unexpectedly?"

SUPPORT OFFER
"We want to help you stay safe. Would it be helpful to review your
safety plan together? We can also [specific support offers relevant
to case]."

CLOSING
"If you have any concerns or notice anything unusual, please contact
me at [safe contact method]. Is there anything else you want to ask
about this?"

[Document survivor response and any follow-up actions agreed]

Regulatory authority notification template

DATA BREACH NOTIFICATION - PROTECTION DATA

SECTION 1: ORGANISATION DETAILS
Organisation name: [Name]
Data Protection Officer: [Name and contact]
Reference number: [Internal reference]

SECTION 2: NATURE OF BREACH
Date/time breach discovered: [DateTime]
Date/time breach occurred: [DateTime or range if uncertain]
Nature of breach: [Description]
Categories of data affected: Special category data - protection/
safeguarding case records including [specific elements]

SECTION 3: INDIVIDUALS AFFECTED
Number of individuals: [Number]
Categories: Beneficiaries receiving protection services

SECTION 4: LIKELY CONSEQUENCES
[Description of potential harms, noting physical safety risks
specific to protection data]

SECTION 5: MEASURES TAKEN
Containment: [Description]
Notification to individuals: [Completed/In progress/Pending with
reasoning]

NOTE: Due to the nature of protection data, notification to some
affected individuals has been delayed where such notification
would create risk to their physical safety. Documentation of
case-by-case safety assessments is available for review.

SECTION 6: CONTACT FOR FOLLOW-UP
[Contact details]

Evidence preservation requirements

Protection data breach evidence requires additional handling beyond standard evidence collection procedures:

Chain of custody enhancement: All evidence must document who accessed protection case information, not just who handled evidence. This enables subsequent verification that breach response itself did not further expose survivor data.

Survivor data in evidence: Where evidence includes protection case content, apply the same access restrictions as case data itself. Forensic copies containing survivor information require encrypted storage with access limited to named incident response team members.

Retention for legal proceedings: Protection cases frequently result in legal proceedings years after initial incident. Retain all evidence for minimum 10 years or until advised by legal counsel that retention is no longer required.

Evidence that may endanger survivors: If evidence collection would require documenting specific survivor locations or identities in a form less protected than case records, consult with legal counsel before proceeding. The duty to preserve evidence does not override duty to protect survivors.

+--------------------------------------------------------------------+
|                 MULTI-AGENCY COORDINATION STRUCTURE                |
+--------------------------------------------------------------------+
|                                                                    |
|  +------------------+                      +------------------+    |
|  |  YOUR            |                      |  REGULATORY      |    |
|  |  ORGANISATION    |                      |  AUTHORITY       |    |
|  |                  |                      |                  |    |
|  |  Incident        +--------------------->+  Supervisory     |    |
|  |  Commander       |  72hr notification   |  Authority       |    |
|  |                  |  + updates           |  (ICO etc)       |    |
|  +--------+---------+                      +------------------+    |
|           |                                                        |
|           |                                                        |
|           v                                                        |
|  +--------+---------+                      +------------------+    |
|  |  Protection      |                      |  LAW             |    |
|  |  Lead            +--------------------->+  ENFORCEMENT     |    |
|  |                  |  If criminal         |                  |    |
|  +--------+---------+  investigation       |  (if engaged)    |    |
|           |            warranted           +------------------+    |
|           |                                                        |
|           |                                                        |
|     +-----+------+-----------+                                     |
|     |            |           |                                     |
|     v            v           v                                     |
|  +---+---+   +---+---+   +-------+                                 |
|  |Partner|   |Partner|   |Partner|                                 |
|  |Org A  |   |Org B  |   |Org C  |                                 |
|  |       |   |       |   |       |                                 |
|  |Protect|   |Protect|   |Protect|                                 |
|  |Lead   |   |Lead   |   |Lead   |                                 |
|  +---+---+   +---+---+   +---+---+                                 |
|      |           |         |                                       |
|      |           |         |                                       |
|      +-----------+---------+                                       |
|                  |                                                 |
|                  v                                                 |
|        +---------+---------+                                       |
|        |  COORDINATED      |                                       |
|        |  SURVIVOR         |                                       |
|        |  NOTIFICATION     |                                       |
|        |  APPROACH         |                                       |
|        +-------------------+                                       |
|                                                                    |
+--------------------------------------------------------------------+

Figure 3: Multi-agency coordination structure for protection data breaches

Resource requirements

See also

• Data Breach Response for general breach procedures
• Protection Data Principles for guiding principles
• Safeguarding Case Management Security for system security
• Survivor Data Rights for rights framework
• Evidence Collection for evidence procedures
• Consent in Humanitarian Contexts for consent considerations