System Handover Under Duress

Duress handover occurs when external actors compel an organisation to surrender control of IT systems, equipment, or data through force, legal authority, or threat. This playbook establishes procedures to protect sensitive information, maintain staff safety, and preserve organisational interests when voluntary compliance is not possible or when coercion leaves no alternative. The procedures apply whether the compelling party is a government authority, military force, or non-state actor.

Activation criteria

Invoke this playbook when any of the following conditions exist:

This playbook does not apply to lawful, non-coercive requests from authorities where normal legal processes can be followed. For routine law enforcement requests, follow your organisation’s legal response procedures. This playbook addresses situations where refusal or delay is impossible or would endanger staff.

Roles

Pre-duress preparation

The effectiveness of duress response depends entirely on preparations made before any incident occurs. Systems and staff must be ready to execute these procedures within minutes, not hours.

Technical preparations

Your infrastructure must support rapid response. Without these capabilities in place, the procedural phases below cannot be executed.

Remote management capability requires that all devices can receive commands from a central management platform without local network access. Mobile Device Management (MDM) enrollment must cover every device that might contain sensitive data. Test remote lock and wipe commands quarterly on representative devices to confirm they function correctly.

Data minimisation reduces exposure before any incident occurs. Sensitive data should not persist on local devices when cloud storage is available. Configure aggressive sync policies so local caches clear after 24-48 hours of inactivity. Protection and safeguarding case data requires special handling and should never reside on devices taken to high-risk locations.

Credential architecture must support rapid revocation. Service accounts should have emergency disable procedures documented and tested. Individual accounts must be revocable within 5 minutes of the decision to revoke. Pre-stage revocation scripts that can disable all accounts associated with a specific office or location.

Duress signals provide a mechanism for staff to indicate they are acting under coercion. A duress PIN entered instead of the normal PIN should trigger silent alerts while appearing to unlock normally. A duress phrase spoken during phone calls alerts the recipient without alerting the coercing party. A duress email signature block inserted into otherwise normal emails signals distress.

Documentation preparations

Maintain current documentation that supports rapid response:

/emergency-response/
  duress-contacts.enc          # Encrypted contact list
  asset-inventory-[location].csv
  credential-revocation-runbook.md
  legal-counsel-retainer.pdf
  insurance-policy-summary.pdf
  data-classification-[location].csv

The asset inventory must identify every device at each location, its MDM enrollment status, and what data classifications it may contain. Update this inventory monthly or whenever devices are deployed or collected.

Staff preparations

All staff in high-risk locations must understand:

1. The duress signal mechanisms and how to use them
2. That compliance with armed demands is expected and correct
3. That no disciplinary action will result from surrendering credentials under threat
4. The difference between information that may be disclosed and information that must be protected even under pressure
5. Post-incident support available to them

Conduct tabletop exercises annually for each high-risk location. The exercise should present a realistic scenario and walk through the decision points in this playbook.

Phase 1: Immediate response

Objective: Protect staff safety while initiating containment Timeframe: 0-15 minutes from incident onset

1. Assess the threat. Determine whether the compelling party is government authority, military, or non-state actor. Identify whether they have legal documentation. Count individuals and note whether they are armed. This assessment takes 30-60 seconds and informs all subsequent decisions.

2. Activate duress signal if possible. Send a predetermined SMS, enter a duress PIN, or use another signal mechanism to alert HQ that the situation is occurring. If electronic signaling is impossible, the absence of a scheduled check-in will eventually trigger concern, but this provides much slower response.

3. Do not physically resist. Verbal objection and requests for documentation are appropriate. Physical resistance against armed actors is not. State clearly: “We will comply with your requests. Please allow me to contact our headquarters.”

4. Request time if possible. Ask for 30 minutes to “prepare systems for handover” or “contact our legal representative.” Some actors will grant this; many will not. Any time gained allows remote containment actions.

5. Identify what they want. Determine whether they want physical devices, access to systems, specific data, or all of the above. This determines which containment actions are relevant and possible.

Decision point: Can you communicate with HQ without endangering staff?

If yes, proceed with Phase 2 in parallel with compliance. If no, comply fully and proceed to Phase 4 when communication becomes possible.

Checkpoint: Staff safety confirmed. Threat assessed. HQ alerted if possible.

Phase 2: Remote containment

Objective: Limit data exposure through remote actions Timeframe: Executes in parallel with Phase 1 if HQ is alerted

The remote coordinator executes these actions upon receiving a duress signal. The on-site lead cannot safely perform these actions while under observation.

1. Confirm the duress signal is genuine. Call the on-site lead on a pre-agreed number. If they answer with the all-clear phrase, stand down. If they answer with the duress phrase, cannot answer, or the call fails, proceed with containment.

2. Initiate selective session termination. Revoke active sessions for all users at the affected location. This forces re-authentication, which the compelling party may or may not be able to compel.

   # Example: Azure AD session revocation for location
   Get-AzureADUser -Filter "department eq 'Nairobi Office'" |
     Revoke-AzureADUserAllRefreshToken

3. Disable VPN access from the affected location. Block the IP ranges or certificates associated with that office. This prevents network access even if credentials are surrendered.

   # Firewall rule: block office IP range
   iptables -A INPUT -s 203.0.113.0/24 -j DROP

4. Evaluate remote wipe decision. Remote wipe destroys data but also destroys evidence and may anger the compelling party. Wipe only if:

   • The data at risk includes protection/safeguarding cases
   • The compelling party is likely to misuse data against beneficiaries
   • Legal counsel has pre-authorised wipe in this scenario

   If wiping, execute through MDM:

   # MDM wipe command (platform-specific)
   Invoke-DeviceWipe -DeviceId $deviceId -WipeType Full

5. Preserve cloud data. If on-premises systems will be seized, ensure cloud replicas are current. If cloud access will be compromised through credential surrender, create offline backups of critical data to a location the affected credentials cannot reach.

6. Document all actions taken. Record timestamps, commands executed, and decisions made. This documentation supports legal proceedings and insurance claims.

Decision point: Has the on-site situation stabilised or escalated?

If the compelling party has taken what they want and departed, proceed to Phase 4. If staff are detained or the situation continues, maintain communication and proceed to Phase 3.

Checkpoint: Sessions revoked. VPN blocked. Wipe decision made and executed if appropriate. Actions documented.

Phase 3: Controlled handover

Objective: Comply with demands while minimising harm Timeframe: Duration of the incident

When the compelling party remains on-site and demands active cooperation, the on-site lead manages the handover to protect staff while limiting exposure.

1. Provide requested access incrementally. Do not volunteer information beyond what is demanded. If asked for “the password,” provide one password. Do not explain that there are additional systems.

2. Document everything surrendered. Note which devices were taken, which credentials were provided, and what data each provides access to. If documentation is not possible during the incident, reconstruct it immediately afterward.

3. Avoid lying about technical facts. Claiming that data does not exist when it does, or that access is impossible when it is possible, creates legal exposure and may escalate the situation if the deception is discovered. Silence or “I need to check” is preferable to false statements.

4. Use duress accounts if prepared. Some organisations maintain accounts that appear to provide full access but actually provide a limited view. If you have prepared duress accounts for this scenario, provide those credentials.

5. Request documentation of seizure. Ask for a receipt, inventory list, or other documentation of what has been taken. Many authorities will provide this. Non-state actors generally will not, but the request is still appropriate.

6. Note the identities of the compelling party. Names, badge numbers, unit identifications, vehicle descriptions, and any other identifying information supports subsequent legal action and insurance claims.

+------------------------------------------------------------------+
|                    HANDOVER DECISION TREE                        |
+------------------------------------------------------------------+
                              |
                              v
                    +-------------------+
                    | What do they      |
                    | demand?           |
                    +-------------------+
                              |
         +--------------------+--------------------+
         |                    |                    |
         v                    v                    v
  +-------------+     +---------------+    +---------------+
  | Physical    |     | Credentials   |    | Specific      |
  | devices     |     | / Access      |    | data          |
  +-------------+     +---------------+    +---------------+
         |                    |                    |
         v                    v                    v
  +-------------+     +---------------+    +---------------+
  | Surrender   |     | Provide       |    | Export        |
  | devices     |     | requested     |    | requested     |
  | Document    |     | credentials   |    | data only     |
  | serial #s   |     | only          |    | Document      |
  +-------------+     +---------------+    +---------------+
         |                    |                    |
         +--------------------+--------------------+
                              |
                              v
                    +-------------------+
                    | HQ notified?      |
                    +-------------------+
                              |
              +---------------+---------------+
              |                               |
              v                               v
       +-------------+                 +-------------+
       | Yes:        |                 | No:         |
       | Containment |                 | Note for    |
       | in progress |                 | post-event  |
       +-------------+                 +-------------+

Figure 1: Handover decision tree for on-site lead

Decision point: Have the compelling party departed?

If yes, proceed immediately to Phase 4. If staff are being detained or removed from the location, the remote coordinator assumes lead responsibility and coordinates with legal and executive leadership.

Checkpoint: Demands met to extent required for staff safety. Documentation captured. Compelling party has departed or situation has stabilised.

Phase 4: Post-handover containment

Objective: Prevent further compromise from surrendered access Timeframe: 0-4 hours after compelling party departs

1. Conduct staff welfare check. Account for all staff. Determine whether anyone was detained, injured, or requires support. Arrange psychological support for affected staff.

2. Execute comprehensive credential rotation. Assume all credentials at the affected location are compromised. Rotate:

   • All user passwords for affected staff
   • All service accounts that affected staff could access
   • All API keys and tokens used by systems at that location
   • WiFi pre-shared keys
   • Any shared credentials (which should not exist, but often do)

3. Revoke all sessions and tokens. Force re-authentication across all systems. This includes cloud services, VPN, and any federated applications.

   # Comprehensive session revocation
   for user in $(cat affected_users.txt); do
     az ad user revoke-signed-in-sessions --id $user
     # Also revoke from each integrated application
   done

4. Assess data exposure. Using the documentation of what was surrendered, determine:

   • What data could the compromised credentials access?
   • What data was on surrendered devices?
   • Was any data deleted before or during the incident?
   • What data remains at risk if the compelling party retained access?

5. Isolate compromised network segments. If network equipment was compromised or credentials for network management were surrendered, treat the entire network segment as hostile. Route traffic from that location through additional inspection or block it entirely until equipment can be verified or replaced.

6. Notify affected parties. If personal data of beneficiaries, partners, or donors was potentially exposed, initiate breach notification procedures. Protection data exposure requires immediate coordination with safeguarding teams.

+-------------------------------------------------------------------+
|                POST-HANDOVER CONTAINMENT SEQUENCE                 |
+-------------------------------------------------------------------+
|                                                                   |
|  Time    Action                           Responsibility          |
|  -----   -------------------------------- ----------------------- |
|  T+0     Staff welfare check              On-site lead            |
|  T+15m   Credential rotation initiated    Remote coordinator      |
|  T+30m   Session revocation complete      Remote coordinator      |
|  T+1h    Data exposure assessment draft   Remote coordinator      |
|  T+2h    Network isolation verified       Remote coordinator      |
|  T+4h    Affected party notification      Communications lead     |
|          decision                                                 |
|                                                                   |
+-------------------------------------------------------------------+

Figure 2: Post-handover containment timeline

Checkpoint: Staff accounted for. Credentials rotated. Sessions revoked. Exposure assessed. Network isolated if required.

Phase 5: Recovery and documentation

Objective: Restore operations and preserve evidence for legal/insurance purposes Timeframe: 4-72 hours after incident

1. Document the complete incident timeline. Working with all involved staff, reconstruct a minute-by-minute account of what occurred. Include:

   • When the compelling party arrived
   • What they said and did
   • What was demanded and surrendered
   • What actions staff took
   • When the compelling party departed
   • What containment actions were executed remotely

2. Preserve all evidence. Retain logs, communications, photographs (if any were taken safely), and any documentation provided by or taken from the compelling party. Store this in a location inaccessible from the compromised location.

3. Engage legal counsel. Provide the documented timeline and assess:

   • Legal options in the relevant jurisdiction
   • Reporting obligations to authorities
   • Liability exposure for data that was compromised
   • Insurance claim requirements

4. Notify insurers. Most cyber insurance policies require notification within 24-72 hours of an incident. Provide the documented facts without speculation about fault or coverage.

5. Assess operational restoration. Determine whether the affected location can resume operations. Consider:

   • Is it safe for staff to return or remain?
   • Can compromised systems be rebuilt or replaced?
   • Is the compelling party likely to return?
   • Should operations relocate?

6. Replace compromised infrastructure. Devices that were seized and returned should not be trusted. Devices that remained on-site during the incident may have been tampered with. The safest approach is complete replacement with freshly imaged equipment.

7. Conduct staff debriefing. Within one week, gather affected staff to review what occurred, what worked, what did not work, and what should change in procedures or preparations. This is separate from the formal incident documentation and focuses on learning and support.

Checkpoint: Timeline documented. Evidence preserved. Legal and insurance notified. Operational restoration decision made.

Communications

Communication templates

Legal counsel notification:

Subject: URGENT - Duress incident at [Location]

[Time]: Our [Location] office experienced a duress incident.

Compelling party: [Government authority / Military / Other]
Documentation provided: [Warrant / Court order / None]
Staff status: [All safe / X detained / Other]
Systems surrendered: [List]
Credentials compromised: [List]

We require immediate legal guidance on:
1. Reporting obligations in [Jurisdiction]
2. Legal options available
3. Insurance notification requirements

Contact: [Name] at [Number]

Board notification:

Subject: Security incident - [Location] - Immediate awareness

At [Time] today, [Location] office was subject to forced entry /
legal seizure by [Party]. All staff are [safe / accounted for /
X detained].

IT systems and data were [surrendered / seized]. Containment
actions have been executed to prevent further access. Legal
counsel has been engaged.

Full briefing will follow within [X hours]. No media statement
has been issued. Please direct any inquiries to [Communications lead].

Insurance notification:

Subject: Cyber incident notification - Policy [Number]

Insured: [Organisation]
Policy number: [Number]
Date of incident: [Date]
Location: [Location]

Nature of incident: Systems and credentials surrendered under
duress to [Government authority / Other]. Remote containment
actions executed.

Assets affected:
- [X] devices surrendered
- [Y] user credentials compromised
- [Z] systems potentially accessed

Data potentially exposed: [Categories]

We are notifying you within [X hours] of the incident as required
by policy terms. Full documentation will follow.

Contact: [Name], [Title], [Number]

Donor notification:

Subject: Security incident affecting [Project/Grant]

Dear [Contact],

We are writing to inform you of a security incident affecting
operations under [Grant number / Project name].

On [Date], our [Location] office was subject to [forced entry /
legal seizure]. Staff cooperated with authorities and are safe.

Data potentially affected: [Description relevant to grant]
Actions taken: [Summary of containment]
Ongoing risk: [Assessment]

We are [continuing / suspending] project activities while we
assess the situation. We will provide an updated assessment
within [X days].

We are available to discuss this incident at your convenience.

Media statement (if required):

[Organisation] confirms that our [Location] office experienced
a security incident on [Date]. Staff are safe. We are cooperating
with relevant authorities and have taken steps to protect our
systems and data. We are unable to provide further details at
this time as the matter is under review.

Contact: [Media contact], [Email]

Evidence preservation

Preserve the following for legal proceedings and insurance claims:

All evidence must be preserved in a location that compromised credentials cannot access. If your primary cloud storage was potentially compromised, use a separate storage service with distinct credentials for evidence preservation.

System recovery if returned

If seized equipment is returned, do not reconnect it to organisational networks. The equipment may have been modified to provide ongoing access to the compelling party. Recovery procedures:

1. Image the returned device for forensic analysis before any other action. This preserves evidence of any modifications.

2. Compare the image to known-good baselines. Look for:

   • Modified system files
   • Additional user accounts
   • Unusual scheduled tasks or services
   • Modified boot sectors
   • Hardware modifications (requires physical inspection)

3. Do not trust the device regardless of forensic findings. Absence of detected modifications does not prove absence of modifications. The safest approach is to retain the device for evidence and deploy replacement equipment.

4. If the device must be reused due to resource constraints, perform a complete wipe and reinstallation from trusted media. Do not restore from backups that may have been taken after compromise.

Post-incident review

Within two weeks of the incident, conduct a formal review addressing:

1. Preparation adequacy: Were pre-duress preparations sufficient? What was missing?
2. Response effectiveness: Did staff know what to do? Did remote containment execute successfully?
3. Communication gaps: Were the right people notified? Was notification timely?
4. Recovery completeness: Have all compromised systems been addressed?
5. Ongoing risk: Is the location safe for continued operations?
6. Procedure updates: What changes should be made to this playbook or related preparations?

Document findings and update preparations for all high-risk locations based on lessons learned.

See also

• Operational Security
• Device Security in Hostile Environments
• Data Protection at Borders
• Data Evacuation
• Technology Handover
• Data Breach Response
• Protection Data Breach Response