Phishing: your domain, mailbox and payments need different controls

38 per cent and 88 per cent answer different questions

The Cyber Security Breaches Survey 2025/2026 found that 38 per cent of all UK businesses had identified phishing. Among businesses that identified any breach or attack, the figure was 88 per cent. These are two views of the same survey, with different denominators.

Published on 30 April 2026, the report draws on a weighted survey of 2,112 businesses, interviewed between August and December 2025 about the preceding twelve months. Identified attacks are not necessarily successful intrusions; undetected activity is missing. These are UK findings. The practical question is what a suspicious message could persuade someone in your business to do. [1]

Phishing in UK businesses: two different bases

38%

of all UK businesses

88%

of businesses identifying at least one breach or attack

Identified does not mean successful

The figures cover identified phishing attacks, including attempts. They are neither attacker success rates nor estimates for businesses worldwide or in Germany.

Source: DSIT · Cyber Security Breaches Survey 2025/2026 · published 30 April 2026

Sample: 2,112 businesses; subgroup identifying any breach or attack: 1,026. Results are weighted.

United Kingdom · fieldwork August to December 2025

Businesses identifying phishing in the twelve months before their interview. The percentages have different denominators: they cannot be added together or read as a change over time.

Domain protection tackles one kind of impersonation

SPF, DKIM and DMARC help receiving mail services check whether a message is authorised to use a domain. DMARC connects the visible sender domain to an aligned SPF or DKIM check and publishes instructions for failures. An enforced rejection policy makes that exact domain harder to spoof. It does not establish who wrote the message or whether its contents are true.

Start with your legitimate senders: mailboxes, invoicing software, newsletters and external services. Check their authentication before tightening the policy. A separately registered lookalike domain is outside your DMARC policy. Messages sent through a compromised genuine mailbox can also pass domain checks. [2] [3] [5]

The mailbox needs its own access control

Multifactor authentication protects account access. CISA recommends phishing-resistant methods such as FIDO2/WebAuthn, which bind authentication to the intended service. A one-time code does not offer the same phishing resistance.

The useful question goes beyond whether MFA is switched on. Which accounts does it cover, which sign-in methods remain available, and how does recovery work? Start with administrators and accounts handling invoices or sensitive data. Give each exception an owner and a date for removal. Even a well-protected sign-in cannot establish that an invoice is correct. [4]

Changed bank details need independent confirmation

When bank details change, the decisive control belongs in the payment process. The FBI advises verifying such changes directly with the requester. Use a number already known to you or a separate contact route agreed in advance. A telephone number supplied in the questionable email is not independent evidence.

Replying in the same thread is also insufficient if someone controls the mailbox. We recommend recording the verification before changing bank details and separating that check from payment approval where staffing allows. Urgency should not override the rule. Otherwise, the exception becomes the easiest route around the control. [5] [6]

Match the control to the attack route

The controls work together. This distinction helps close a specific gap without expecting one setting to provide comprehensive protection. [2] [3] [4] [5] [6]

Swipe or scroll sideways to read the table.

Where each control helps, and where it stops
Attack route	Relevant control	Limit
Your exact sender domain is spoofed	SPF/DKIM with enforced DMARC	Does not protect separate lookalike domains
Access to a genuine mailbox is phished	Phishing-resistant MFA	Does not validate invoice contents
Lookalike domain or familiar display name	Mail filtering and a separate verification route	A familiar name is not proof of identity
Bank details are changed in a payment request	Independent confirmation before approval	Works only if exceptions are checked too

Let IT and finance walk through the same request

For a short internal review, use an explicitly fictional supplier request to change bank details. Ask IT to explain the sender checks that would be visible. Ask finance to show where it would find a trusted callback number and who would approve the change. Leave real payment records untouched.

Record each missing responsibility and the next concrete action. An incomplete sender inventory, an unprotected sign-in and an unverified bank change are different jobs. Keeping them distinct turns a general demand for better phishing protection into work that someone can own and finish.

Sources

Related assessment

Security Assessment

Explore the service scope