Extortion Email Playbook: Triage and Response to Data Theft and Sextortion Threats

An extortion email forces a decision before anyone knows whether the threat is real: some come from criminals who genuinely hold your data, and many more are bluffs built from old breach dumps. This playbook template covers the first hours after an extortion message reaches [Organisation], whether it is sent to a shared inbox, an executive or an ordinary member of staff. It separates three cases that need very different responses: real data-theft extortion, a false or recycled claim against the organisation, and mass sextortion scams aimed at individuals. It names the roles, decision points and evidence to preserve, sets out how to verify a claim, and covers law enforcement, sanctions checks, staff communications and the credential resets that follow. It is written for incident responders, legal and privacy leads and approving executives. Replace every [Organisation] placeholder and adapt it to your own platforms, insurer and advisers.

How to use this template

• Adopt it as a sub-playbook of [Organisation]'s incident response plan. See the Incident Response Plan Template.
• Fill in every placeholder in square brackets: names, out-of-band phone numbers, the insurer hotline, the threat intelligence provider and the external counsel retained for extortion matters.
• Treat every claim as unverified until section 3 is complete, and treat every reply to the sender as a decision that only the Incident lead can authorise.
• Decision points are marked D1 to D5. Record each decision, who made it, when and on what evidence.
• Use the companion playbooks where the investigation finds an intrusion: the Ransomware Playbook Template if encryption is found, the Business Email Compromise Response Playbook if a mailbox is compromised, and the Vendor SaaS Breach Response Playbook if the data sits with a supplier.

This template is defensive guidance. It does not cover negotiation tactics; for that see the Ransomware Negotiation Guide. It is not legal advice.

1. Scope and triggers

1.1 This playbook applies to any message received by [Organisation] or its staff, by email, web form, chat or post, that demands payment or another action under threat of publishing, selling or misusing data, or of exposing an individual.

1.2 Variants in scope:

1.3 Triggers: a report to the security mailbox or service desk; a message to an executive or the board secretary; a journalist or threat intelligence provider reporting that [Organisation] is named on a leak site; a supplier telling [Organisation] that it has received a demand about shared data.

1.4 The sending address proves nothing. In the 2025 Oracle E-Business Suite campaign, Google Threat Intelligence Group reported extortion emails sent to executives from hundreds of compromised third-party accounts, and the claims were real. See the Oracle E-Business Suite Cl0p campaign.

2. Roles and contacts

2.1 Keep an out-of-band contact sheet outside the mail system: cyber insurer hotline [number], external counsel [number], incident response retainer [number], threat intelligence provider [contact] and the law enforcement routes in section 7. If mail is compromised, the attacker may be reading the response.

3. Detection and triage

1. Preserve the message (Security analyst, minute 0). Export the original with full headers (.eml or .msg), any attachments and linked URLs (record them, do not click), the recipient list and the time received. Do not forward the message as an attachment around the organisation.
2. Check where it came from. Read the Received chain and the SPF, DKIM and DMARC results. A pass shows only that the sending domain authorised the server; the account itself may be compromised (ATT&CK T1586.002 Email Accounts).
3. Search for siblings. Run a message trace for the sender, subject, cryptocurrency wallet and URLs. Bulk delivery to many staff with the same wallet points to a scam; one targeted message to executives points to a real campaign.
4. Sextortion screen. If the message quotes a password and claims device compromise, check the quoted password against [Organisation]'s directory and password manager records. The NCSC says such passwords have in all likelihood been obtained from historic breaches of personal data, and that a password still in use should be changed immediately.
5. D1: Which variant? (Incident lead, within [2] hours). Classify using the table in 1.2. Sextortion scams with no link to [Organisation] systems move to section 7 staff guidance and close. Everything else continues.

Verifying a data-theft claim

3.1 D2: Credible or not credible? (Incident lead with Legal). Credible if any sample record is genuine and not explained by a known public source, or if logs show matching access. If not credible, record the reasons, keep monitoring for [30] days and do not reply. The Data Extortion Without Encryption Guide explains why theft-only extortion can start months after the data left.

4. Containment

1. Do not engage the sender without a D3 decision. Silence is the default while verification runs.
2. Block the sender, domains, URLs and wallet strings at the mail gateway and purge copies from other mailboxes after evidence is exported.
3. If theft is credible, close the route. Disable or reset the identities used: user accounts, service accounts, API keys, OAuth grants and integration tokens on the affected platform. Revoke sessions, not just passwords. See the Leaked Credential Response Playbook.
4. Restrict the data store: network policies, IP allowlists and export permissions on the affected database, SaaS tenant or file transfer server, while keeping logs intact.
5. D3: Any contact with the extortionist? (Executive sponsor on advice from Legal, insurer and law enforcement). Options: no contact; contact through a specialist only to gain time or proof. Never contact from an individual's own account.

Evidence to preserve: the original messages with headers; every sample and file listing with hashes; leak site screenshots captured by the threat intelligence provider with timestamps; identity provider, platform, proxy and firewall logs for the claimed window plus [90] days before; the decision log. Extend log retention now, before it rolls over. See the Digital Forensics (DFIR) Guide.

5. Eradication

1. Find the entry point: stolen or infostealer credentials without MFA, an exploited internet-facing application, a connected app or a supplier. In the Scania insurance portal breach, a partner's credentials, believed stolen by malware, were used to download claim documents, and employees received extortion emails the next day.
2. Rotate every credential that could reach the data: human accounts, service accounts, database users, API keys, access keys and OAuth client secrets for the affected platform and anything sharing those secrets. Non-human credentials are often missed because nobody is prompted to change them. See the Secrets Rotation Runbook Template.
3. Remove persistence: new accounts, API clients, scheduled exports, forwarding rules and remote tools.
4. Patch the exploited weakness and confirm with a scan.
5. D4: Eradication complete? (Incident lead) when no attacker activity has been seen since rotation and every persistence item is removed.

6. Recovery

1. Re-enable services with MFA enforced on every account that reaches the data, and restricted export rights.
2. Agree a data review: which records, whose, how sensitive. This drives notification in section 7.
3. Keep the threat intelligence provider watching leak sites and markets for [90] days after any deadline passes.
4. Prepare for publication: legal holding statements, customer support scripts and fraud warnings for affected people.

Payment and sanctions considerations (D5)

• Payment buys a promise, not deletion. UK law enforcement, through the NCSC, says it does not encourage, endorse or condone the payment of ransom demands, and paying makes future targeting more likely.
• Payment does not remove notification duties. Data protection and contractual duties apply whether or not anything was paid. See the Breach Notification Laws by Country Guide.
• Sanctions screening is mandatory before any payment is even considered. In the US, OFAC's updated ransomware advisory of 21 September 2021 sets out the sanctions risk of facilitating payments and the steps OFAC treats as mitigating, including prompt reporting to and cooperation with law enforcement. In the UK, OFSI publishes financial sanctions guidance for ransomware, and since 28 January 2026 the UK Sanctions List is the single source of UK designations. Screening by counsel and the insurer must cover the wallet, the group and any intermediary. See the Ransomware Payments and Sanctions Guide.
• D5 is a board-level decision taken by [Executive sponsor and CEO] with written advice from Legal, the insurer and law enforcement liaison. [Organisation]'s default position is: [no payment].

7. Communication and notification

7.1 Staff advisory for sextortion waves (adapt and send from a known internal address):

• Do not reply and do not pay. The NCSC warns that paying will likely encourage more scams.
• If the email shows a password you still use anywhere, change it now and turn on MFA; tell the service desk if it is a work password.
• Report the email to [security mailbox]. Individuals in the UK can also forward scam emails to the NCSC Suspicious Email Reporting Service; anyone who has already paid should contact the police on 101.
• If you are being threatened with a real image, or a child is involved, speak to [HR and safeguarding lead] in confidence and report to the police. You will be supported, not judged.

8. Post-incident review

1. Hold the review within [10] working days with security, legal, privacy, the data owner and communications.
2. Build the timeline: first access, exfiltration, first extortion message, detection, D2, rotation, notification.
3. Record why the theft was not detected earlier and which control would have stopped it.
4. Update the verification table and the staff advisory with what was learned.

Implementation guidance

• Pre-contract the help you need: a threat intelligence provider that checks leak sites and infostealer logs on request, external counsel experienced in extortion, and an insurer briefing on its notification rules. See the Dark Web Monitoring Guide.
• Make verification possible: keep a data inventory that maps record types to systems, so a data owner can recognise a sample quickly, and retain identity and egress logs for at least [12] months.
• Reduce sextortion impact: ban password reuse, check staff credentials against breach corpora, and cover sextortion scams in awareness training so staff report rather than panic. See the Phishing Incident Response Playbook.
• Small organisations: combine roles, but keep the insurer number, Report Fraud or IC3 route and the "do not reply, do not pay" rule on one printed page.
• Large organisations: brief the executive assistants and board secretary, who often receive targeted extortion mail first, and run a tabletop exercise with a realistic sample file every year.

References: NCSC: Sextortion scams, how to protect yourself · NCSC: Mitigating malware and ransomware attacks · Report Fraud: Report cyber crime and fraud · FBI IC3: Public service announcement on reporting to ic3.gov · OFAC: Publication of Updated Ransomware Advisory · OFSI: Financial sanctions guidance for ransomware · MITRE ATT&CK: Financial Theft · NIST: SP 800-53 Rev. 5

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Data Extortion Without Encryption Guide · Email Identity and BEC Guide · Business Email Compromise Response Playbook · Ransomware Response and Recovery Guide · Threat Intelligence Guide