What Should a Small Business Actually Do About Phishing?

On a Thursday afternoon the finance assistant receives an email from a supplier she has paid many times before. Same signature, same reference format, same slightly formal tone. The only difference is a line saying the bank details have changed, and an attachment repeating the new ones on headed paper. She checks the sender, it looks right, and she pays it. Nothing in that sequence required anybody to be careless.

That is the real shape of the problem, and it is why "train staff to spot phishing" is such an unsatisfying answer. The message was not badly spelled. It arrived in a thread that already existed. The attacker was not testing her attention. They were testing whether one person, acting alone, could move money. Phishing prevention in a small business is mostly about removing that second condition.

So here is the position this piece defends: detection is a weak control and process is a strong one. Filters and training reduce how often a fraudulent request arrives and how often it is believed. Only process decides whether a believed request can do anything at all. Design for the second and the first stops being load-bearing.

Detection is the wrong goal

Every awareness programme carries an implicit theory of victory: if we get people to notice, we win. That theory requires everybody to be correct every time, on the busiest day of their quarter, on a phone, between two meetings. The attacker needs one person to be ordinary once.

Look at the failure from the other end. A fraudulent payment needs three things: a believable request, a person with authority to act on it alone, and a channel with no second check. Training attacks only the first, which happens to be the one you can least control and the one that degrades with tiredness. The other two are yours to design, and they do not get tired.

The same reasoning covers credential theft. A convincing sign-in page works because the credential it captures is usable by whoever holds it. Change that property and the page still fools people, and still achieves nothing. That is the whole idea, applied to authentication instead of to payments.

The technical controls that actually hold

A short list, roughly ordered by what it prevents per hour of effort. None of this needs a security team, a consultant, or a product with a dashboard.

Sign-in that cannot be replayed

The largest single change available to a small organisation is moving from passwords plus typed codes to authenticators bound to the site itself. Passkeys and hardware security keys work because the credential is tied to the origin. A lookalike domain cannot obtain a usable response, however convincing the page is and however tired the person is. NIST describes exactly this property as phishing resistance in its digital identity guidance, and treats a code a human copies between screens as the weaker option for the same reason.

Codes sent by text are better than nothing and worse than they look. They can be read out to a plausible caller, typed into a fake page while the attacker relays them in real time, or intercepted when a phone number is moved to somebody else. Push approvals fail differently: people accept them while distracted, and attackers have learned to send them late in the day.

Email authentication, and what it cannot do

SPF, DKIM and DMARC decide who is allowed to send mail claiming to be your domain. Published properly, they stop one whole class of attack: somebody forging your own domain to your own staff, or to your customers. It is finite work with a definite end, which makes it unusually satisfying for a security task.

What they do not stop is a domain that merely resembles yours, or a genuine supplier whose mailbox has been taken over and is now sending real mail with real history behind it. Those two account for most of the requests that actually get paid. Domain authentication is the floor of the building. It is not the roof, and it was never sold to you as one.

The remainder of the technical layer is maintenance rather than strategy: current software, a password manager so nothing is reused, updates that install without a debate, and somebody who notices when a domain or a certificate is close to expiring. That is precisely what a maintenance arrangement exists to cover. If you inherited a site nobody documented, the order to work through is set out in securing a website you did not build.

Your own site is part of the attack surface

Phishing arrives by mail and does not always end there. A cloned copy of your sign-in page, hosted on a domain one character away from yours, is cheap to build and hard to spot. So is a script added to your own pages by somebody with publishing access and entirely good intentions, which is the failure described in third-party scripts your marketing team added. Both are found the same way, by somebody knowing what is supposed to be there and checking occasionally.

The training that does not work

Awareness training is not worthless. It is oversold, and the version most organisations buy is close to worthless: an annual video, a quiz, a certificate, a box ticked for the insurer.

The failures are specific rather than general, which is good news, because specific failures can be fixed without cancelling the programme.

• Spot-the-typo advice. Fraud that reaches a finance inbox is written properly, often by somebody who has already read the earlier messages in the thread.
• Annual delivery. One session in March does very little for the request that arrives in October, addressed to somebody who joined in July.
• Obviously bad examples. Teaching people to recognise clumsy fakes makes them more confident about the good ones, which is the opposite of the intended effect.
• Blame framing. When reporting a mistake feels dangerous, mistakes stop being reported and start being discovered, and discovery is the expensive version.
• Attendance as the outcome. The measurable output becomes completion. The thing you wanted was a change in what somebody does when a request feels slightly wrong.

The trouble with simulated phishing

Simulations are the most popular intervention and the one we would keep on the shortest leash. Run as a trap, they produce a click rate that falls while nothing underneath it improves, because staff learn the vendor’s templates rather than the pattern. Run punitively, they cost more than they return: they teach people that the security function is something to survive rather than something to call.

The version worth running is small, frequent, unscored, and followed immediately by an explanation of what the message was doing. And it should measure reporting rather than clicking. A workforce that reports quickly is worth more than a workforce that clicks rarely, because a report is the only signal that reaches you before the money leaves.

The process changes that beat both

This is the part that genuinely works, and most of it costs nothing beyond agreement and the willingness to write six sentences down where people can find them.

1. Bank details change out of band, never inside the thread. Any request to change payment details is verified by calling a number you already held before the request arrived. Not the number in the email. Not the number on the new letterhead.
2. Two people above a threshold you set once. Where the threshold sits is a business decision. The rule is that the second person is genuinely separate and genuinely permitted to refuse.
3. A named list of who can authorise a payment. Written down, short, and reviewed whenever somebody joins or leaves. Urgency from a person who is not on that list is the signal, whatever their title says.
4. Supplier records that change through one route only. If bank details live in the accounting system, they change in the accounting system, by somebody holding that permission, leaving a record behind.
5. A refusal sentence everybody is allowed to use. Agreed in advance: I will confirm this on the number we already hold and come back to you. Nobody should have to invent that line under pressure from a name they report to.
6. One reporting channel with no penalty attached. Somewhere to forward anything odd, watched by a person who replies. Speed of reporting is the control you are actually buying.

Two of those six deserve to live in software rather than in memory. A supplier record that cannot be edited without an approval step, and a payment run that refuses to release a changed account number without a second sign-off, are ordinary workflow and integration work. A control that lives in a system is the one still standing during a week when everybody is busy, which is the week the request will arrive.

Make the request impossible, not merely detectable

The reframe worth pushing hardest: stop asking whether you would spot it, and start asking what the message needs to achieve and whether that path exists at all.

Take the invoice case. If bank details can only change through a verified call to a number you already had, the fraudulent email has nowhere to land. The attacker can be perfect. The message can be indistinguishable from a real one. It still fails, because the route it depends on was closed before it arrived.

Take credential theft. If sign-in is bound to the origin, a fake page collects something unusable. Take the request for gift cards that appears to come from a director. If everybody knows the organisation never asks for that, the message is self-defeating rather than merely suspicious, and nobody has to make a judgement call about their own boss under time pressure.

Assume the message is perfect and the reader is tired. Whatever still holds under those two assumptions is your actual security posture.

What each control stops, and what it leaves open

Most security shopping goes wrong because the second column gets read and the third one does not.

When one gets through anyway

Assume one succeeds, because the entire point of the design above is that a single success should not be catastrophic. What matters then is sequence, and speed inside that sequence.

Call the bank before the internal discussion, because recall attempts get harder by the hour. Reset the credentials on the affected account and on its recovery routes. Then look for the mail rule or forwarding address the attacker created to hide replies, which is the step teams miss most often and the one that decides whether the intrusion is genuinely over. Write the timeline down while it is fresh.

Recovery depends on decisions taken months earlier. Whether your backup is a backup or just a copy in the same place is the question that decides how bad a bad day becomes, and it is answered by restoring one, not by reading a green tick on a dashboard.

If customer data was touched, part of what happens next is contractual rather than technical. What a data processing agreement should say before you sign it covers the clauses deciding who tells whom, and how quickly, which is a poor thing to be reading for the first time on the day itself.

Write the findings up properly afterwards rather than as a panicked note in a chat thread. A finding needs a severity, a priority and a recommendation, kept separate from one another; assessment tooling such as Prooflin exists to resolve those into a report somebody can actually review, and our parent company has written about what separates a defensible finding from an alarming one in the anatomy of a finding.

Where we would start, in one week

Week one is not a project. Turn on phishing-resistant sign-in for the email accounts that can reset everything else. Write the payment verification rule in a single paragraph and send it to everybody who touches money. Agree the refusal sentence out loud, in a meeting, so that nobody has to be brave later. Publish the reporting channel, then reply to the first person who uses it within the hour, because that reply sets the culture more firmly than any course will.

The honest limitation: none of this helps against an attacker already sitting on somebody’s laptop. Malware watching a live session does not need to phish anybody, and process controls cannot see it. That is a different problem with different answers, and for most small organisations it is the smaller of the two, which is why we would still spend the first week on the request path rather than on endpoint tooling.

One condition changes the advice. If your organisation moves money for other people, or holds credentials that open somebody else’s systems, then you are a supplier inside a larger supply chain and the bar is higher than anything described here: separate duties formally, log access, and expect to be asked for evidence rather than assurances. If you are not sure which of the two you are, describe how money leaves your organisation and start the conversation there.