Business Email Compromise Response Playbook
Handles mailbox takeover and payment-fraud attempts, including bank recall timing and mailbox rule forensics.
Available soon
- Format
- Word
- Size
- 69 KB
- Length
- 21 pages
- Version
- 1.0
- Updated
What's inside
- Scenario and triggers
- Severity mapping
- First-hour actions
- Decision tree
- Role actions by phase
- Evidence preservation
- Communications and regulatory triggers
- Recovery criteria
- Post-incident actions
- Worked examples — a stopped bank-detail change and a mailbox takeover
- Tailoring notes
- Framework references
- Definitions
What changed
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Scenario and triggers
Use this playbook when email is used to steal money or a mailbox is taken over: category IC-03, business email compromise and payment fraud (a mailbox taken over; a request to change bank details; a fake invoice), in the Incident Classification, Severity & Escalation Matrix. It adds the steps for payments and mailboxes to the Incident Response Plan; everything the plan says still applies.
It covers two variants. Many incidents start as one and become the other, so read both.
Variant | What is happening | Category | Example |
|---|---|---|---|
A Someone else's mailbox used against us | A supplier's or customer's real mailbox has been taken over and is used to send us false bank details or invoices. Nothing of ours is compromised; the risk is paying the wrong account. | IC-03 | INC-2026-015 |
B One of our own mailboxes taken over | Someone has signed in to one of our mailboxes. They may read mail, set rules to hide replies, and send false requests to our customers, suppliers or Finance. | IC-04 | INC-2026-017 |
Variant B is category IC-04, account compromise, in the matrix, which has no playbook of its own. For a mailbox, use this playbook's mailbox steps and record the category as IC-04. If the taken-over mailbox is then used to ask for money, the incident is also IC-03: record both and run both variants. For other account compromise (not a mailbox), the plan applies, and this playbook's mailbox steps are a useful guide.
Triggers
Start this playbook on any of these signs. Anyone who sees one reports it at once (IM-01), and nobody pays or changes bank details while it is checked.
Sign | What it looks like | Who usually sees it first |
|---|---|---|
T-01 A request to change bank details | A supplier, customer, employee or landlord asks by email, or in a letter or call that follows an email, to pay into a new account from now on. | Accounts Payable; Payroll |
T-02 An urgent payment request from an executive | An email that seems to come from a director or the chief executive asking for an urgent, confidential payment, often while they are travelling or hard to reach. | Finance; executive assistants |
T-03 An unexpected or changed invoice | An invoice that is not expected, or a real invoice sent again with different bank details or a new reference, sometimes in the middle of a real email conversation. | Accounts Payable |
T-04 A mailbox rule or forwarding nobody set up | A rule that moves, deletes or forwards mail outside, especially mail with words like invoice, payment or bank; or forwarding to an outside address. | The security monitoring provider; the email provider; the user |
T-05 A sign-in from an unusual place | A sign-in to a mailbox from another country, an unfamiliar device, or two places too far apart to travel between; a second factor prompt the user did not ask for. | The security monitoring provider; the user |
T-06 Someone asks about an email we did not send | A customer or supplier asks about a payment request, invoice or shared document from one of our mailboxes; replies arrive to messages nobody sent. | Anyone; customer service |
What a member of staff does on seeing a sign
- Do not pay, change bank details, reply, click links or open attachments.
- Check the request by phoning the person or company on a number already on file, never one in the email (the call-back).
- Report it to the IT service desk on [[service desk number]]. If money has already been sent, call the Finance lead at once as well, on [[Finance lead's number]]: the bank must be called at once.
- If you entered your password on a page reached from an email, say so at once. Nobody is blamed for a report made in good faith (IM-01).
Guidance — delete before approval
Put the four staff steps on one page for Finance, Payroll, executive assistants and customer service, with the numbers filled in.
Severity mapping
The matrix sets the rule (IM-04): “Severity is the highest level any impact area reaches, judged on what the incident has done or is capable of doing. When in doubt, choose the higher level. Severity is reviewed at every update and can be raised by anyone on the response team; it is lowered only by the incident manager, with the reason recorded in the case log.” Judge on what the incident could have done: a stopped payment is judged on the amount that was asked for.
Which severity. The highest row that applies sets it:
Situation | Severity | Why: the matrix criterion it meets |
|---|---|---|
Money at stake (paid, or asked for and stopped) above [[€1,000,000]] | Severity 1 Critical | Severity 1, Financial: “Loss likely above [[€1,000,000]]” |
Money at stake (paid, or asked for and stopped) between [[€250,000]] and [[€1,000,000]] | Severity 2 High | Severity 2, Financial: “Loss likely between [[€250,000]] and [[€1,000,000]]” |
Money at stake (paid, or asked for and stopped) between [[€50,000]] and [[€250,000]] | Severity 3 Medium | Severity 3, Financial: “Loss likely between [[€50,000]] and [[€250,000]]” |
Money at stake (paid, or asked for and stopped) below [[€50,000]] | Severity 4 Low | Severity 4, Financial: “Loss likely below [[€50,000]]” |
One of our mailboxes taken over, an ordinary user, stopped before harm | Severity 3 Medium | Severity 3, Spread: “One user account or device compromised; attacker stopped before harm” |
One of our mailboxes taken over with elevated rights: an administrator, a payment approver, an executive, or a shared finance mailbox | Severity 2 High | Severity 2, Spread: “One system or account compromised with elevated rights, and contained” |
More than one of our mailboxes, or an administrator account, used by the attacker and not yet contained | Severity 1 Critical | Severity 1, Spread: “Malware or an attacker spreading, or administrator-level access to core systems” |
Personal data in the mailbox read, forwarded or downloaded, for a limited number of people (also run the Personal Data Breach Response Playbook) | Severity 2 High | Severity 2, Data: “Personal data of individuals exposed, lost or altered, in limited numbers” |
Our customers received false payment requests from our mailbox | Severity 2 High | Severity 2, Reputation: “Customers or local press aware” |
Who is told, and how often, is in first-hour steps 3 and 6. Most attempts stopped by the call-back are Severity 3; a taken-over finance or executive mailbox is Severity 2 at least.
First-hour actions
The plan's first hour (Incident Triage & First-Hour Assessment Procedure) in its order, with what each step means here. When money has been sent, the bank call comes first of all: it cannot wait for the rest.
# | Step of the plan | In this playbook | Owner |
|---|---|---|---|
1 | Open the case | Record the time of the first report and the time of declaration. Category IC-03 (variant A, or a mailbox used for fraud) or IC-04 (variant B). Note the trigger (T-01 to T-06), the amount and the account involved. | Incident manager |
2 | Set severity and category | On the money at stake and on whose mailbox (Severity mapping). An attempt stopped before payment is still judged on the amount asked for. | Incident manager |
3 | Escalate | Severity 2: Incident manager at once; executive incident lead within 2 hours. Severity 3: Incident manager at once; Head of Information Security the same working day. Tell the finance lead at once whenever a payment or bank detail is involved. | Incident manager |
4 | Contain what is spreading | Run the money steps (M1 to M5) if a payment was made, and the mailbox steps (B1 to B7) if one of our mailboxes is involved, below. Hold the request steps (A1 to A4) for variant A. | Incident manager; Finance lead for money |
5 | Start the reporting screen | Personal data read or sent from the mailbox is a possible breach (GDPR). A large loss can make it a significant incident (NIS2). For financial entities, clients' money affected (DORA). Add the crime report (RD-16) whenever money was lost or asked for, and the insurer (RD-15) when money was lost, or when the policy asks for attempts too ([[policy terms]]). Complete within 4 hours (IM-06). | Incident manager, with the Data Protection Officer |
6 | Set the next update | Severity 2: every 4 hours. Severity 3: every 24 hours. Include the bank's answer on any recall at each update. | Incident manager |
If money has been sent
Speed decides whether money comes back. Call the bank [[within 1 hour]] of finding the payment, day or night.
# | Action | Owner | When |
|---|---|---|---|
M1 | Call the bank's fraud team on [[bank fraud line]] and ask it to recall the payment and contact the receiving bank. Give the date, amount, our account, the receiving account and the payment reference. Write down the time, the name of the person spoken to and the bank's reference. | Finance lead | [[within 1 hour]] |
M2 | Stop further payments to the receiving account: hold any queued payment, lock the supplier or payee record, and check the next payment run for the same details. | Finance lead | At once |
M3 | Report the fraud to the police or the national fraud reporting service (RD-16). The bank may ask for the crime reference. | Finance lead; Legal | Same day |
M4 | Tell the insurer (RD-15): money has been lost, so this is always needed where a cyber policy is held. The insurer is told of an attempt only when the policy asks for it ([[policy terms]]). | Executive incident lead | As the policy requires |
M5 | Keep every record: the fraudulent email with its headers, the payment record and the bank correspondence (Evidence preservation). | Finance lead | At once |
If one of our mailboxes is taken over
Do these in order: B1 to B3 within [[30 minutes]] of declaration; B4 within [[2 hours]]. The incident manager decides; no approval is needed to lock out an attacker (decision rights: “Isolate a system, site or account”, incident manager).
# | Action | Owner | When |
|---|---|---|---|
B1 | Revoke all sessions on the account, so every device signed in to it is signed out, including the attacker's. | Email and office software provider or IT | At once |
B2 | Reset the password and the second factor. Remove every second-factor method registered and register a new one with the user in person or by video, not by email. | Email and office software provider or IT; mailbox user | With B1 |
B3 | Remove rules, forwarding and delegates the user did not set up, and any application given access to the mailbox. Export or photograph them first (Evidence preservation). | Email and office software provider | With B1 |
B4 | Check the audit log for the period since the first unusual sign-in: what was read, downloaded, sent, deleted, and which rules were made. Export it. | Email and office software provider; security monitoring provider | Within [[2 hours]] |
B5 | Look for other mailboxes hit by the same campaign: the same phishing email in other inboxes, sign-ins from the same places, the same rule names. Repeat B1 to B4 for each. | Security monitoring provider | Within [[2 hours]] |
B6 | Block the campaign: remove the phishing email from every mailbox, block its sender and any look-alike domain, and block the fake sign-in page. | Email and office software provider | Within [[2 hours]] |
B7 | Find who received mail from the account while the attacker had it (sent items and the audit log), for decision D5. | Incident manager | Within [[4 hours]] |
If the request came from a supplier's or customer's mailbox
# | Action | Owner | When |
|---|---|---|---|
A1 | Do not act on the email and do not reply to it. Hold the bank-detail change and any payment it asks for. | Finance lead | At once |
A2 | Call back the supplier or customer on the number already on file, not one in the email, and ask whether it sent the request. | Finance lead | Before any change |
A3 | Tell them their mailbox appears to be compromised, by phone and then in writing to a known contact (CT-05 Supplier notice and request for help). | Incident manager | Same day |
A4 | Check recent history with that supplier or customer: other bank-detail changes, invoices or payments in the last [[90 days]], each confirmed by call-back. | Finance lead | Within [[2 working days]] |
Guidance — delete before approval
Set the bank-call target ([[within 1 hour]]) with your bank: ask it now for its fraud line, its out-of-hours arrangement and what it needs from you to recall a payment. Put the number in M1.
Resetting a password alone is not enough: signed-in sessions and rules survive it. B1 and B3 are what lock the attacker out.
Decision tree
Answer these in order at the start, and again at every update. Record each answer, who gave it and when, in the case log.
D1 Has money left our account because of the request? (RS.MI-01)
Answer | What to do |
|---|---|
Yes | Run M1 to M5 now, starting with the bank call ([[within 1 hour]]). Set severity on the amount. Legal advises on recovering the money and on the insurance claim. |
No | Hold the payment and any bank-detail change until the call-back (A2) confirms the request. Severity is still set on the amount asked for. |
Who decides | Finance lead; Incident manager |
D2 Is one of our own mailboxes taken over (variant B)?
Answer | What to do |
|---|---|
Yes | Run B1 to B7. Record category IC-04, and IC-03 as well if the mailbox was used to ask for money. |
No | Variant A: run A1 to A4. Check whether anyone here replied to the attacker with information or documents, and whether our staff entered their passwords anywhere from the same email chain. |
Not yet known | Check the sign-in log for the mailbox the request seems to come from before deciding. A request from our own address is variant B until shown otherwise. |
Who decides | Incident manager |
D3 Does the taken-over mailbox have elevated rights? (Severity mapping)
Answer | What to do |
|---|---|
Yes | At least Severity 2 (Severity 2, Spread: “One system or account compromised with elevated rights, and contained”). Check the audit log for administrator actions, payment approvals and changes to other accounts; reset every credential the mailbox could reach. |
No | Severity on the other rows of the mapping. |
Who decides | Incident manager |
D4 Was personal data in the mailbox read, forwarded or downloaded? (GDPR 4(12), 33(1))
Answer | What to do |
|---|---|
Yes | Run the Personal Data Breach Response Playbook alongside this one. The GDPR clock (RD-06) runs from awareness. The Data Protection Officer assesses the risk to the people concerned. |
No | Record the audit-log evidence in the case log, so the decision that there was no breach can be shown later. |
Not yet known | Treat it as Yes until the audit log (B4) has been checked for the whole period the attacker had access. |
Who decides | Incident manager, with the Data Protection Officer |
D5 Did our mailbox send false requests or phishing to customers or suppliers? (RS.CO-02)
Answer | What to do |
|---|---|
Yes | Warn every recipient by phone or a known contact, not by replying from the affected mailbox: CT-04 Customer notice for customers, CT-05 Supplier notice and request for help for suppliers. Ask them not to pay or click, and to tell us if they already have. |
No | Record the check of sent items and the audit log. |
Who decides | Executive incident lead approves CT-04; Incident manager approves CT-05 |
D6 Are other mailboxes hit by the same campaign?
Answer | What to do |
|---|---|
Yes | Repeat B1 to B4 for each. Several mailboxes at once can raise severity (Spread). |
No | Record how the search (B5) was done and what it covered. |
Who decides | Incident manager |
D7 Was the call-back done before any bank-detail change or payment? (P05 treatment action TA-02)
Answer | What to do |
|---|---|
Yes | Record it: who called, the number used, when, and the answer. |
No | A control failed. Record why, tell the owner of risk R-02 (Chief Financial Officer), and make it a review question. |
Who decides | Finance lead |
D8 Has the crime been reported, and the insurer told? (Reporting duties RD-15, RD-16)
Answer | What to do |
|---|---|
Yes | Record the reference numbers in the case log. |
No | Report the crime (RD-16: [[as soon as practical for suspected crime]]) whenever money was lost or asked for. Tell the insurer (RD-15: [[as the policy requires, often within 48 hours]]) when money was lost, or when the policy asks for attempts too ([[policy terms]]). Where neither applies, record why in the case log. |
Who decides | Executive incident lead; Legal or the Finance lead makes the crime report |
Role actions by phase
Who does what. The placeholders are replaced with names and a deputy for each.
Role | Who | In this playbook |
|---|---|---|
Finance lead | [[e.g. Financial Controller, with the Accounts Payable team]] | Holds payments and bank-detail changes; calls the bank; runs call-backs; corrects payee records. |
Incident manager | [[e.g. Information Security Manager, with a named deputy]] | Runs the playbook; decides the mailbox steps; keeps the case log; runs the reporting screen. |
Executive incident lead | [[e.g. Chief Operating Officer, with a named deputy]] | Told of Severity 2 and above; approves customer notices; tells the insurer. |
Data Protection Officer | [[or the privacy lead where no DPO is appointed]] | Decides with the incident manager whether personal data was exposed (D4); advises on GDPR reports. |
Legal | [[in-house or external counsel]] | Crime report; recovering the money; insurance claim; advice on what we tell customers. |
Communications lead | [[e.g. Head of Marketing and Communications]] | Customer and staff messages from the approved templates only. |
The Tier 1 suppliers this playbook calls on, from the example (Third-Party Security Risk Management pack):
Provider | What it does in an incident (P06 contract) | Your provider and incident line |
|---|---|---|
Email and office software provider (EXAMPLE SUP-005) | Suspends accounts, removes mail rules and supplies mailbox audit logs | [[name; 24-hour incident number; contract reference]] |
Security monitoring provider (EXAMPLE SUP-006) | Detects and alerts around the clock; supplies logs and analysis | [[name; 24-hour incident number; contract reference]] |
Managed IT service provider (EXAMPLE SUP-001) | Isolates networks and systems, rebuilds devices, restores from backup | [[name; 24-hour incident number; contract reference]] |
Contain
Goal: no more money leaves and the attacker is out of every mailbox. Starts at declaration.
# | Action | Owner | When |
|---|---|---|---|
K1 | Money: M1 and M2 — bank called, recall requested, further payments stopped. | Finance lead | [[within 1 hour]] |
K2 | Our mailbox: B1 to B3 — sessions revoked, password and second factor reset, rules, forwarding and delegates removed (within [[30 minutes]]); B4 — audit log checked (within [[2 hours]]). | Email and office software provider or IT | Within [[30 minutes]], and [[2 hours]] for B4 |
K3 | Someone else's mailbox: A1 to A3 — request held, call-back made, sender told. | Finance lead | At once |
K4 | Warn the teams most likely to be targeted next (Finance, Payroll, executive assistants) with CT-03 Staff holding message: what the emails look like and to call back before acting. | Communications lead | Same day |
K5 | Watch sign-ins to the affected mailboxes and to Finance mailboxes for the same places and devices. | Security monitoring provider | From declaration until closure |
Eradicate
Goal: the campaign is removed and nothing the attacker set up remains.
# | Action | Owner | When |
|---|---|---|---|
E1 | Remove the phishing email from every mailbox, block the sender and look-alike domains and the fake sign-in page (B6). | Email and office software provider | Within [[2 hours]] |
E2 | Search every mailbox for rules and forwarding created in the attack period, and remove any not set up by their users. | Email and office software provider | Within [[1 working day]] |
E3 | Check the sign-in log for other accounts used from the same places or devices; run B1 to B4 for each (B5). | Security monitoring provider | Within [[1 working day]] |
E4 | Remove any application or device the attacker registered on the account. | Email and office software provider or IT | With E2 |
E5 | Review every bank-detail change in the last [[90 days]] and confirm each by call-back (A4). | Finance lead | Within [[2 working days]] |
Recover
Goal: the mailbox and the payment records are trusted again.
# | Action | Owner | When |
|---|---|---|---|
V1 | Register the user's second factor again with a phishing-resistant method where the user and system allow it. | IT; mailbox user | Before the mailbox returns to use |
V2 | Return the mailbox to the user, who confirms mail flows normally and nothing unexpected is set up. | Mailbox user | After V1 |
V3 | Correct any payee record changed by the fraud, after a call-back, with a second person checking. | Finance lead | Before the next payment run |
V4 | Tell customers or suppliers who received false requests what to do (CT-04 Customer notice, CT-05 Supplier notice and request for help). | Communications lead | Within [[1 working day]] of D5 |
V5 | Pursue the recall with the bank, and the insurance claim, until closed. | Finance lead; Legal | Until closed |
V6 | At closure, send CT-10 All-clear and thank-you to everyone told earlier. | Communications lead | At closure |
Evidence preservation
IM-07 (Security Incident Management Policy): Evidence must be preserved before systems are wiped or rebuilt, unless waiting would let the harm spread; who handled it, and when, must be recorded.
Evidence is what the bank, the police, the insurer and any authority will ask for, and what shows whether data left. Mailbox logs are kept only for a limited time: export them on the first day.
Evidence | How to preserve it | Who | Before |
|---|---|---|---|
The fraudulent email, with full headers | Save the original message as a file, or have the email provider export it. Do not forward it: forwarding loses the headers. | Incident manager | Deletion |
Mailbox audit log and sign-in log | Export for the whole period since the first unusual sign-in, for every affected mailbox. Extend retention where possible. | Email and office software provider | Retention runs out |
Rules, forwarding, delegates and connected applications | Export or photograph them as found, with the time, before removing them (B3). | Email and office software provider | Removal |
Payment records and bank correspondence | The payment instruction and approval, the bank's recall reference, and every email or letter with the bank. | Finance lead | Closure |
The call-back record | Who called whom, on which number from which record, when, and the answer. | Finance lead | Closure |
The phishing page or link | Record the address from the email; do not visit it. | Security monitoring provider | Block |
Reference numbers | The crime report, insurer and bank references, in the case log. | Incident manager | Closure |
For each item, record who collected it, when and where it is kept (the chain of custody).
Communications and regulatory triggers
Run the reporting screen of the Incident Triage & First-Hour Assessment Procedure within 4 hours of declaration (IM-06): its NIS2, GDPR, DORA questions, and the contract and insurance questions. Record each answer and its reason even when no report is made.
Reports business email compromise can trigger
Duty | Report and deadline | To | When this incident triggers it |
|---|---|---|---|
RD-01 NIS2 | Early warning: within 24 hours of awareness | [[CSIRT or competent authority]] | Rarely: a loss large enough to be severe financial loss for us (NIS2 significant incident). Then RD-02 to RD-04 follow. |
RD-06 GDPR | Notification to the supervisory authority: without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay | [[lead supervisory authority]] | Personal data in the mailbox was read, forwarded or downloaded, and the breach is likely to result in a risk to individuals (D4). |
RD-07 GDPR | Communication to the individuals affected: without undue delay | The data subjects | As RD-06, where the risk to individuals is high (the Personal Data Breach Response Playbook). |
RD-08 GDPR | Breach record: for every personal data breach, notified or not | Kept by us; shown to the authority on request | Every personal data breach from the mailbox, notified or not. |
RD-09 GDPR | Notice to the controller: without undue delay | The controller whose data we process | We act as a processor and the mailbox held the controller's personal data. |
RD-13 DORA | Notice to clients: without undue delay | Clients whose financial interests are affected | Financial entities only: a major ICT-related incident that affects clients' financial interests. |
RD-14 Contract | Notice to customers under contract: [[as each contract requires]] | [[customers with a notification clause]] | A customer contract requires notice, for example because our mailbox sent them false requests. |
RD-15 Insurance | Notice to the cyber insurer: [[as the policy requires, often within 48 hours]] | [[insurer or broker incident line]] | Where a cyber policy is held: when money was lost, or when the policy asks for attempts too ([[policy terms]]). |
RD-16 Law enforcement | Crime report: [[as soon as practical for suspected crime]] | [[national cybercrime reporting service]] | Whenever money was lost or asked for: fraud and attempted fraud are crimes. |
Guidance — delete before approval
A report is never held back to avoid a deadline (decision rights: “Report to an authority”).
Messages
IM-09 (Security Incident Management Policy): Only the communications lead may speak for the organisation about an incident outside it, using the approved templates; nobody else may talk to the media or post about an incident.
Template | Audience | Approver | Use it in this incident when |
|---|---|---|---|
CT-01 Incident alert to the response team | Incident manager, responders, executive incident lead | Incident manager | At declaration, to the response team, the Finance lead and the email provider. |
CT-02 Executive and board briefing | Executive incident lead, crisis team, board chair | Incident manager | For Severity 2, at each update. |
CT-03 Staff holding message | All staff, or the affected site or team | Executive incident lead | To warn Finance, Payroll and executive assistants of the campaign; to all staff if many were sent the phishing email. |
CT-04 Customer notice | Customers whose service or data is affected | Executive incident lead | When our mailbox sent false payment requests or phishing to customers (D5), or a contract requires notice. Send it from a mailbox that was not affected, and follow up by phone. |
CT-05 Supplier notice and request for help | Suppliers involved in the incident or the recovery | Incident manager | When a supplier's mailbox appears compromised (A3), or our mailbox wrote to its staff (D5). |
CT-10 All-clear and thank-you | Everyone told earlier | Executive incident lead | At closure. |
Guidance — delete before approval
Never tell a customer or supplier about the incident by replying in the affected email thread: the attacker may still be reading it.
Recovery criteria
IM-10 (Security Incident Management Policy): A system must not return to normal service until the recovery criteria are met, and backups must be checked for integrity before they are restored.
# | Recovery criterion (IM-10) | How to confirm it here | Confirmed by |
|---|---|---|---|
1 | The cause is understood well enough that the same route in is closed. | How the mailbox was taken (a phishing page, a reused password, a phished code) is known and closed; for variant A, the supplier or customer confirms its mailbox is secure before we accept email instructions from it again. | Incident manager |
2 | Backups or rebuild images were checked for integrity before they were used. | Where mail or files were deleted or changed, they are restored from the provider's retained copies, checked first. Where nothing was restored, record “not applicable” with the reason. | Email and office software provider |
3 | Restored systems are patched, scanned and monitored, with credentials changed where they could have been taken. | Sessions revoked, password reset, second factor registered again (with a phishing-resistant method where possible), no rules, forwarding, delegates or unknown applications remain, on every affected mailbox. | Email and office software provider or IT |
4 | The system owner has tested the service and confirms it works. | The user confirms the mailbox works (V2); the Finance lead confirms every payee record touched is verified by call-back (V3). | Mailbox user; Finance lead |
5 | The monitoring period has started: [[7]] calendar days of closer watching for Severity 1 and 2 before closure. | Sign-in alerts on the affected mailboxes for the monitoring period: 7 calendar days for Severity 2 and above; for Severity 3, the period the incident manager records. | Security monitoring provider |
Closure: “Recovery criteria met, the monitoring period passed without recurrence, and the case log complete.” The money is not a closure test: the recall and the insurance claim can run on after the case closes, tracked as actions.
Post-incident actions
IM-11 (Security Incident Management Policy): Every Severity 1 and 2 incident must have a post-incident review within 10 working days of closure; its actions must have owners and due dates, and the risks it touches must be reassessed (P05 RM-10).
Severity 3 and 4 incidents are reviewed together once a quarter: most attempts stopped by the call-back are reviewed that way, not one by one.
# | Action | Owner | When |
|---|---|---|---|
P1 | Hold the post-incident review with the Post-Incident Review Template for Severity 1 and 2 incidents, within 10 working days of closure: how the attacker got in, whether the call-back ran, how long the bank call took. | Head of Information Security | Within 10 working days of closure |
P2 | Reassess the risks touched in the Information Security Risk Register (Information Security Risk Management pack). In the example: R-02 “Payment fraud through a compromised supplier email account” (owner Chief Financial Officer) and R-09 “Staff account taken over through phishing” (owner HR Director). P05 rule RM-10: “A trigger forces reassessment of the risks it touches within [[10]] working days.” | Each risk's owner | Within the RM-10 window |
P3 | Check progress on the treatment for R-02: TA-02, “Call-back verification of every change to supplier bank details, and a payment verification service”, owner Chief Financial Officer, due 30 Nov 2026, in progress (EXAMPLE). Report any incident where the call-back was missed to its owner. | Chief Financial Officer | At the review |
P4 | Update the payment process where the review finds a gap: who may change bank details, the call-back, a second approver. | Finance lead | Within [[30 days]] |
P5 | Share the pattern with staff in the next awareness message: what the emails looked like and what stopped them. | Head of Information Security | Within [[30 days]] |
P6 | Update this playbook: contacts, the bank's fraud line, triggers, and anything that was slow. | Incident manager | Within [[30 days]] |
Worked examples — a stopped bank-detail change and a mailbox takeover
EXAMPLE, not part of the playbook. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Replace every name, time and figure with your own.
Variant A — INC-2026-015: false bank details from a supplier's mailbox
Case | INC-2026-015 |
|---|---|
What happened | An email from a real packaging supplier's mailbox asked Accounts Payable to change its bank details before a €84,000 payment run. The call-back to the number on file found the supplier had not sent it. No payment was made; the supplier was told its mailbox was compromised. |
Category and severity | IC-03; Severity 3: €84,000 was at stake, so judged on the amount asked for (Severity 3, Financial: “Loss likely between [[€50,000]] and [[€250,000]]”). No mailbox of ours was involved. |
Roles | Incident manager: Information Security Manager. Reported by: Accounts Payable clerk. No executive incident lead: Severity 3. |
Root cause | The supplier's mailbox was taken over; our call-back check worked as designed. |
Screen | NIS2: Not significant: no disruption or loss. GDPR: No personal data breach of ours. DORA: Not applicable. |
Time | After declaration | What happened | Playbook step |
|---|---|---|---|
Before the report | — | An email from the supplier's real mailbox asks Accounts Payable to change its bank details before the payment run | Trigger T-01; A1: request held |
Before the report | — | Call-back to the number on file: the supplier had not sent it | A2 and D7 Yes |
2 Sep, 10:15 | 25 min before declaration | Reported by: Accounts Payable clerk | IM-01 |
2 Sep, 10:30 | 10 min before declaration | Triage starts | Before the playbook (IM-02) |
2 Sep, 10:40 | +0:00 | Declared Severity 3, IC-03 | First hour 1 to 3 |
2 Sep, 11:05 | +0:25 | Contained: no payment made; the supplier told its mailbox was compromised | D1 No; A3 with CT-05 |
2 Sep, 14:30 | +3:50 | Attempted payment fraud reported to [[the national fraud reporting service]]; the insurer was not told, as nothing was lost and the policy does not ask for attempts | D8: RD-16 made; RD-15 not needed |
4 Sep 2026 | — | Closed | Recovery criteria |
The call-back is the control that stopped it. Risk R-02, “Payment fraud through a compromised supplier email account”, is why it exists; treatment action TA-02, “Call-back verification of every change to supplier bank details, and a payment verification service”, is in progress, due 30 Nov 2026. Severity 3, so reviewed with the quarter's other Severity 3 and Severity 4 incidents, not one by one. (EXAMPLE)
Variant B — INC-2026-017: a staff mailbox taken over
Case | INC-2026-017 |
|---|---|
What happened | The security monitoring provider alerted on a sign-in to a sales administrator's mailbox from another country and a new rule forwarding mail outside. Sessions were revoked and the password reset within 40 minutes. The audit log showed no mail had yet been forwarded. |
Category and severity | IC-04, handled with this playbook's mailbox steps. Declared Severity 2: until the audit log was checked, Data and Legal and regulatory were judged at Severity 2, as personal data might have gone (IM-04: when in doubt, the higher level; D4 not yet known). Lowered to Severity 3 at 22 Sep, 15:20 by the incident manager, with the reason recorded: the mailbox audit log showed no mail had been forwarded or read by the attacker, so no personal data had gone. Final: one ordinary user's mailbox, stopped before harm (Severity 3, Spread: “One user account or device compromised; attacker stopped before harm”). |
Roles | Incident manager: Information Security Manager. Reported by: Security monitoring provider (SUP-006). |
Root cause | A convincing phishing page captured the password; the account's second factor was a text message that the attacker also phished. |
Screen | NIS2: Not significant. GDPR: No personal data disclosed (audit log checked); recorded as assessed, not a breach. DORA: Not applicable. |
Time | After declaration | What happened | Playbook step |
|---|---|---|---|
22 Sep, 14:10 | 15 min before declaration | Monitoring alert: sign-in from another country and a new rule forwarding mail outside | Triggers T-05 and T-04 |
22 Sep, 14:18 | 7 min before declaration | Triage starts | Before the playbook (IM-02) |
22 Sep, 14:25 | +0:00 | Declared Severity 2, IC-04 | First hour 1 to 3; D2 Yes; D4 not yet known |
22 Sep, 14:50 | +0:25 | Contained: sessions revoked and password reset, 40 minutes after the alert | B1 to B3 |
22 Sep, 15:20 | +0:55 | Lowered to Severity 3: the mailbox audit log showed no mail had been forwarded or read by the attacker, so no personal data had gone | B4; D4 No; severity lowered with a reason (IM-04) |
22 Sep, 15:30 | +1:05 | Mailbox back in use | Recover V1 and V2 |
24 Sep 2026 | — | Closed | Recovery criteria |
The audit log (B4) showed no mail had been forwarded, which answered D4 (No) and D5 (No) and let the incident manager lower the severity 55 minutes after declaration, before the Severity 2 notice to the executive incident lead (within 2 hours) fell due. The second factor was a text-message code the attacker also phished: this is why recovery criterion 3 asks for a phishing-resistant method where possible, and why risk R-09, “Staff account taken over through phishing”, is reassessed. (EXAMPLE)
Tailoring notes
Guidance — delete before approval
Small organisation: the person who pays the bills may also be the person who handles the incident. Keep the call-back as an absolute rule, and have a second person approve any change of bank details. Ask your bank for its fraud line now and write it into M1. If an outside company runs your email, agree in advance that it will revoke sessions and export audit logs on request, at any hour.
Regulated entity: a NIS2 essential or important entity checks whether a large loss makes it a significant incident. A DORA financial entity classifies the incident under Delegated Regulation (EU) 2024/1772 and, when it is major, reports on RD-10 to RD-13; where clients' financial interests are affected it tells them without undue delay (RD-13). Where client money or client mailboxes are involved, add your financial competent authority and any payment-services duties to Communications and regulatory triggers. The Data Protection Officer decides with the incident manager whether exposed mail is a notifiable breach.
Outsourced IT or a managed service provider: the email provider (and often a managed IT provider) does B1 to B6. Check its contract obliges it to act on your request out of hours and to supply audit logs (the Third-Party Security Risk Management pack's incident clauses), and that someone at your organisation can still revoke sessions if it cannot be reached. Make sure the provider's own administrator accounts use a phishing-resistant second factor.
Payroll and employees: a request from an “employee” to change the account their salary is paid into is the same fraud. Apply the call-back to Payroll too, using the contact details on the employee's record.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2022/2554 (DORA), Delegated Regulations (EU) 2024/1772 and 2025/301, Implementing Regulation (EU) 2025/302.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.26 — Response to information security incidents | First-hour actions, Decision tree, Role actions by phase |
ISO/IEC 27001:2022 | Annex A 5.28 — Collection of evidence | Evidence preservation: headers, audit logs, bank records |
ISO/IEC 27001:2022 | Annex A 5.25 — Assessment and decision on information security events | Severity mapping; the two variants and their categories |
ISO/IEC 27001:2022 | Annex A 8.15 — Logging | B4 and Evidence preservation: audit and sign-in logs exported |
NIST CSF 2.0 | RS.MI-01 — “Incidents are contained” | Money steps M1 and M2; mailbox steps B1 to B3; request steps A1 to A3 |
NIST CSF 2.0 | RS.MI-02 — “Incidents are eradicated” | Eradicate E1 to E5 |
NIST CSF 2.0 | RS.AN-03 — “Analysis is performed to establish what has taken place during an incident and the root cause of the incident” | B4, B5 and D2 to D6: what happened and how the attacker got in |
NIST CSF 2.0 | RS.AN-07 — “Incident data and metadata are collected, and their integrity and provenance are preserved” | Evidence preservation |
NIST CSF 2.0 | RS.CO-02 — “Internal and external stakeholders are notified of incidents” | D5 and Messages: customers, suppliers and staff told |
NIST CSF 2.0 | GV.SC-08 — “Relevant suppliers and other third parties are included in incident planning, response, and recovery activities” | The email provider and monitoring provider in the response |
NIS2 — Directive (EU) 2022/2555 | Article 23(3) — an incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned”, or has affected or is capable of affecting others “by causing considerable material or non-material damage” | RD-01: when a loss makes it a significant incident |
GDPR — Regulation (EU) 2016/679 | Article 4(12) — “personal data breach” means “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed” | D4: mail read or forwarded is a personal data breach |
GDPR — Regulation (EU) 2016/679 | Article 33(1) — notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a later notification gives reasons for the delay | RD-06 |
DORA — Regulation (EU) 2022/2554 | Article 19(3) — where a major ICT-related incident has an impact on the financial interests of clients, inform them without undue delay of the incident and of the measures taken | RD-13: clients whose financial interests are affected |
DORA — Delegated Regulation (EU) 2024/1772 | Article 8 — an incident is major where it affects critical services and either meets the data-loss threshold in Article 9(5)(b) or meets two or more of the other materiality thresholds | Tailoring notes: classifying a major ICT-related incident |
Definitions
Term | Meaning in this playbook |
|---|---|
Audit log | The email provider's record of sign-ins and of what was done in each mailbox: messages read, sent, deleted, and rules created. |
Awareness | The moment the reporting clocks start: the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. |
Business email compromise | Fraud that uses a real or convincing email to get money or information: false bank details, fake invoices, or requests that seem to come from an executive. Category IC-03 in the matrix. |
Call-back | Checking a request by phoning the person at a number already on file, never one given in the request itself. |
Closure | Recovery criteria met, the monitoring period passed without recurrence, and the case log complete. |
Containment | The incident can no longer spread or cause new harm, even though systems may not yet be restored. |
Forwarding | A mailbox setting that sends a copy of every message, or some messages, to another address. |
Incident | An event, declared by the incident manager, that has compromised, or threatens to compromise, the availability, authenticity, integrity or confidentiality of our data or services, and needs a managed response. |
Mailbox rule | An instruction in a mailbox that moves, deletes or forwards messages automatically. Attackers use rules to hide replies and copy mail out. |
Major ICT-related incident | DORA's term, for financial entities only: an ICT-related incident with a high adverse impact on systems that support critical or important functions, as tested by Delegated Regulation (EU) 2024/1772. |
Message headers | The technical record at the top of every email showing where it really came from and the route it took. Forwarding a message loses them. |
Personal data breach | GDPR's term: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. |
Phishing-resistant method | A second factor that cannot be passed on through a fake sign-in page, such as a security key or a passkey tied to the real site. Text-message and typed codes can be. |
Recall | A request by our bank to the receiving bank to freeze and return a payment sent because of fraud. It works best within hours. |
Second factor | Something beyond the password needed to sign in: a code, an app prompt or a security key. |
Session | The signed-in state a device keeps after a sign-in, so the user is not asked again. Resetting a password does not always end existing sessions; revoking them does. |
Significant incident | NIS2's term: an incident that has caused or could cause severe operational disruption or financial loss to us, or considerable damage to others. Reported to the authority on NIS2's clock. |