The Four-Day-Old Domain and the €148,000 Payment Run

1. Do not change the bank details, and hold the €148,000 line. The payment run is the only irreversible step in the chain, so it goes first. Treasury places the contractor's line on hold pending verification.
2. Preserve the email. Do not delete it, do not forward the PDF onward, do not 'reply to ask a question'. Save the message with full headers to the incident ticket - the headers prove the lookalike origin.
3. Verify out of band with a number you already had. Call the CFO on the internal directory number, not the one in the email signature. The contractor being closed for a holiday does not weaken the check: the correct outcome is 'we cannot verify, so we do not pay'.
4. Check for spread. The same domain has almost certainly mailed other staff. Ask IT to search mail logs for arch-studio-ltd.com, block the domain at the gateway, and warn finance.
5. Check Priya's mailbox and the PDF. Look for new inbox rules or forwarding set up after her reply, and treat the PDF as a possible payload - if she opened it on a workstation, have it scanned. Reset her credentials if she entered them anywhere new.
6. Report it as a phishing incident, not a near-miss email, so the pattern reaches the security team and other AP staff are warned before 16:00.

Controls that failed, in order of importance:

• Out-of-band verification. The callback policy exists but was skipped, and its own reference data was too stale to make the 'official' number useful for the new details. A control whose reference data cannot be used will be bypassed - the policy failure and the data failure are the same finding.
• Sender authentication and display handling. A four-day-old lookalike domain reached the inbox with the real CFO's display name and no external-sender marker. DMARC enforcement plus external tagging would have raised the cost of this attack considerably.
• Payment-change workflow. Changing an existing payee's account is the highest-risk transaction in AP, and here it was a free-text email request with no dual approval, no independently sourced callback and no cooling-off period.

The manager's error is circular authority. 'The CFO signs off on it' only means something if the approver is verified, and the approver is the party being impersonated. Approval by the spoofed identity is not approval; it is the attack completing itself. The second error is treating an urgency signal - in a meeting, cannot take calls, today's run - as a reason to relax a control. Urgency plus a demand to avoid voice contact is the textbook pretext, and a control suspended whenever a request is urgent is not a control.

Technical:

• Enforce DMARC (p=reject) inbound, plus lookalike-domain detection at the gateway - a newly registered domain within a couple of characters of yours should be flagged, not delivered.
• External-sender banner and a display-name-versus-address mismatch warning on every inbound message.
• Block auto-forwarding to external addresses and alert on new inbox rules created for finance staff.

Process:

• Any change to an existing payee's bank details: dual approval by two people outside the requester's reporting line, a callback to a number sourced independently of the request, and a 24-48 hour hold before the first payment to the new account.
• Maintain a verified vendor contact register with two contacts per vendor and re-test it at onboarding and annually. The failure here was that the stale number made the policy unexecutable.
• A payee-change queue that visually distinguishes 'new vendor' from 'changed bank details' so the approver sees the risk, not just the amount.

Detection:

• A weekly report of payment-detail changes and first payments to new accounts, reviewed by finance rather than IT.

Training still matters, but as reinforcement of a workflow that fails closed. Priya behaved better than most - she sought a second opinion. The system gave her manager nothing to check against, which is why the fix is structural.