Phishing

An accounts clerk receives a message that seems to come from a supplier and asks for new bank details; the email may look familiar, but the request could redirect a real payment. CISA describes phishing as bait that gets people to open harmful links or attachments or share information, and NIST also treats it as a small-business cyber risk.

Both emphasise that messages can appear to come from trusted sources. Common lures include a locked account, overdue invoice, parcel problem or urgent instruction from an executive, so confirm the claim independently before acting.

An attacker might use a lookalike domain, a compromised genuine mailbox or a message within an existing thread, and familiar names and old context do not authenticate a new payment request. Check the exact sender route and, more importantly, the action requested.

The target may be a password, one-time code, bank transfer or document; some links lead to counterfeit sign-in pages and attachments may carry malware, and a seemingly harmless request to 'review' a file can still expose a device or account. Business email compromise overlaps with phishing when messages impersonate executives or suppliers to move money, and the fraud may not contain a link at all, so a transfer instruction sent from a plausible address still needs payment controls.

Look beyond email too, because texts, messaging apps and voice calls can carry a false delivery, tax or account story, and the same independent-verification principle applies even when the channel feels personal. Train staff to use a known reporting path, aiming for quick escalation without shame, including when someone has already clicked, since delay can give an attacker more time to use stolen credentials or contact colleagues.

If a suspicious message could be genuine, do not use the phone number or website provided within it to verify; find an independent number in a trusted supplier record or official site. For suppliers, bank-account changes deserve an extra control, since a callback to a previously verified contact and a separate approver can reduce the chance that a deceptive message alone changes payment details, and the verification should be documented in the vendor record.

Email filtering and security tools can block some attempts but cannot prove that every delivered message is safe, so payment approvals, least-privilege access and multi-factor authentication provide additional defences. Multi-factor authentication is not magic, because attackers can try to capture codes, prompt approval fatigue or exploit an already active session, so staff should report unexpected sign-in prompts rather than approve them to make the notification disappear.

A phishing exercise can reveal a training need: if twelve of eighty staff click a simulated message, the click rate is 15%, but that metric alone does not measure overall resilience, and a good reporting rate and secure payment process also matter. Avoid turning exercises into public blame, since people may hide real mistakes if they fear punishment; use results to improve recognition, reporting routes and technical controls, then test whether behaviour changes.

A response plan should be ready before an incident, because security staff may need to isolate a device, reset affected credentials, revoke sessions and inspect account activity, while finance may need to contact the bank quickly after a fraudulent transfer. Preserve the suspicious message through the organisation's reporting process without forwarding a dangerous attachment widely, acknowledge any reporter's concern without assuming the sender's identity, follow applicable incident and notification rules if private data or money may be affected, and remember that for an owner, phishing defence is a routine of checking high-risk actions, not a one-time training slide.