How to Create an Anti-Phishing Policy Employees Actually Follow

Phishing is still one of the biggest cyber risks facing UK businesses, and the challenge is not just technical. It is human. In the UK government’s Cyber Security Breaches Survey 2025, 43% of businesses said they had identified a cyber security breach or attack in the previous 12 months. 

Among organisations that identified a breach or attack, phishing was the most common issue by far, affecting 85% of businesses, and it was also described as the most disruptive type of breach or attack. 

That matters because you can invest in strong filters, better device security, tighter permissions, and smarter monitoring, but if your people are left with a policy that feels like legal paperwork, it will not change behaviour. A policy only works when employees can remember it, trust it, and use it under pressure.

If you want your anti-phishing policy to work in real life, you need to make it practical. It has to fit the pace of everyday work. It has to match the systems your staff use. And it has to feel like guidance that helps people, not wording designed to catch them out.

That approach fits closely with Northern Star’s Anti Phishing service, which is built around prevention, awareness, realistic testing, and rapid support. Northern Star also positions phishing protection as part of a broader security and support model, rather than something that sits off to the side on its own. 

Why so many anti-phishing policies fail

A lot of businesses do have a phishing policy somewhere. The problem is that many of them are written for compliance reviews rather than for busy employees.

They often fail because they are:

  • Too long to remember
  • Too vague to guide action
  • Too technical for non-technical staff
  • Too focused on blame
  • Too disconnected from real working habits

If your policy tells people to “exercise caution when handling suspicious communications”, it may sound sensible, but it does not help much when someone receives what looks like an urgent Microsoft 365 password reset, a supplier invoice update, or a message that appears to come from a senior colleague asking for an immediate transfer.

People need something they can use in the moment. They need a clear rule for what to check, what not to do, and how to report it fast.

Start with the real job of the policy

Your anti-phishing policy should not exist just so you can say you have one. It should do 3 things well:

  • Reduce the chance of a successful phishing attack
  • Make reporting quick and normal
  • Limit the damage if someone makes a mistake

That means your policy should cover more than email warnings. It should connect with your wider IT Support and Management, your Consulting approach, and your day-to-day systems such as Cloud Services / Office 365.

Northern Star’s service pages make that wider model clear, with phishing sitting alongside cloud, support, consulting, and security-related services rather than being treated as a one-off problem. 

Write it in plain English

This is where many policies go wrong. If the wording sounds formal but not usable, employees will switch off.

A strong anti-phishing policy usually defines phishing in plain terms. For example, you can say phishing is any email, text, call, message, or website that is designed to trick you into clicking, logging in, opening a file, sharing information, or sending money.

That is much more useful than a narrow definition that only talks about email. The National Cyber Security Centre describes phishing as scam emails or text messages containing links to malicious websites, or messages designed to trick users into revealing sensitive information or transferring money. 

Your policy should also explain that modern phishing is not always obvious. Some attacks are polished, well-timed, and written in good English. Some are targeted. Some are designed to abuse trust rather than to look visibly suspicious. 

The NCSC specifically notes that scams are getting smarter and can fool experts, which is exactly why your policy needs to focus on simple behaviour, not on assuming people will spot every fake through instinct alone. 

Give employees a short rule they can remember

Your full policy can be a few pages long, but the core behaviour rule should be much shorter.

A useful example is:

  • Stop before clicking
  • Check the sender, link, and request
  • Verify unusual requests a second way
  • Report it quickly
  • Ask for help when unsure

That kind of instruction works because it is easy to recall when someone is rushed.

You can also support the policy with short reference material through your internal training or by linking to practical guidance such as Northern Star’s Latest News, where phishing and wider cyber topics are part of a regular stream of business-focused advice.

Make “verify before acting” a non-negotiable rule

If you want one principle at the centre of the whole policy, this is usually the one.

Employees should be expected to verify unusual or high-risk requests through a second channel before acting. That means calling a known number, checking a known system, or speaking directly to the person involved. It does not mean replying to the same suspicious email and asking if it is genuine.

This is especially important for:

  • Payment requests
  • Bank detail changes
  • Password reset prompts
  • MFA approvals
  • Shared document links
  • Payroll changes
  • Requests involving sensitive data

The NCSC advises people to stop and break contact if something feels suspicious, and to contact the organisation directly using an official route. It also states that official organisations will not ask for login details or ask you to confirm bank account details by email.

That advice translates very clearly into a policy rule your employees can use every day.

Be direct about what employees must never do

A practical policy should state, in simple language, what staff must never do.

For example, your policy can say employees must never:

  • Share passwords
  • Approve MFA requests they did not trigger
  • Change supplier bank details based only on email
  • Enter credentials after following an unexpected link
  • Open unexpected attachments without checking
  • Send sensitive data because a message feels urgent

This is also where your technical set-up matters. The NCSC now recommends that organisations consider phishing-resistant MFA options where possible, rather than assuming every form of MFA gives the same level of protection. 

That does not mean your policy should become too technical. It means your written policy and your technical controls should reinforce each other. If you are reviewing your wider controls at the same time, services such as Penetration Testing, Hardware and Software, and broader IT support can help make sure your environment supports the behaviour you are asking for. 

Make reporting easy and blame-free

A policy is much more likely to work when employees know exactly how to report something and know they will not be punished for speaking up quickly.

Your policy should set out one clear reporting route. That could be a phishing-report button in email, a dedicated security mailbox, a service desk process, or a named IT contact for urgent incidents.

It should also say what employees should do if they think they have already clicked, downloaded, logged in, or replied. The answer should always be to report it immediately.

That matters because phishing is disruptive even when it does not lead to a full compromise. The Cyber Security Breaches Survey 2025 highlights the time-consuming nature of phishing, including the staff time needed for reporting, investigation, and follow-up training.

A useful line to include is this: if you think you may have made a mistake, report it straight away. Early reporting helps protect the business and is always better than staying silent.

For UK reporting outside your organisation, the government also advises suspicious emails can be forwarded to report@phishing.gov.uk, while suspicious text messages can be forwarded to 7726.

Fit the policy around how your people actually work

A phishing policy should reflect real workflows, not ideal ones.

Your finance team may work quickly under deadline pressure. Your directors may send short urgent messages. Your sales team may spend all day opening attachments and links. Your remote staff may switch between devices and locations. Your new starters may be keen to act fast and avoid appearing unhelpful.

The UK government’s 2025 survey also found that cyber security policies commonly cover areas such as data storage, what staff are allowed to do on IT devices, cloud use, remote or mobile working, and network-connected devices. That is a good reminder that phishing policy should not be isolated from wider operational policy.

So instead of writing generic wording, build your policy around real examples such as:

  • Invoice approval requests
  • Supplier bank changes
  • Login prompts for Microsoft 365
  • Shared file requests
  • HR document links
  • Delivery or courier messages
  • Executive impersonation
  • Unexpected text messages to work mobiles

That makes the policy feel real. It also makes it more likely that staff will recognise a suspicious pattern before they act.

Make managers follow it too

If leaders do not follow the policy, no one else will take it seriously.

Your anti-phishing policy should apply to everyone, including directors and senior managers. It should also make clear that managers are expected to support careful checking, not undermine it with messages that reward speed over sense.

Managers should be expected to:

  • Support employees who pause to verify requests
  • Avoid criticising sensible caution
  • Follow the same reporting process themselves
  • Reinforce that urgency is not proof of legitimacy

This matters because some of the most effective phishing attacks are built around seniority, authority, and pressure. If your culture tells people to obey first and question later, the policy will struggle.

Explain what happens after a report

Employees are more likely to report something if they know the process is real and useful.

Your policy should briefly explain what happens next. For example, you may review the message, block the sender or domain, warn other users, reset credentials, check the device, or escalate to your security team.

That kind of clarity helps people understand that reporting is part of response, not just an administrative step.

This is where a joined-up provider can make a difference. Northern Star presents its model as one that combines Security Services, day-to-day support, and wider project or multi-site delivery through services such as Global Support and International Projects, European IT Support, and Migrations (Platform to Platform). That matters because phishing responses often cut across support, security, accounts, users, and locations. 

Keep the policy short, but reinforce it often

The policy itself does not need to be long. In most businesses, 2 to 4 pages is enough if the writing is clear.

What matters more is repetition.

Your policy should be backed up by:

  • New starter onboarding
  • Short refresher training
  • Realistic phishing simulations
  • Manager reminders
  • Quick-reference guides
  • Follow-up after near misses

The NCSC’s guidance on phishing defence emphasises a multi-layered approach that improves resilience while minimising disruption to user productivity. That is exactly the right mindset. You are not trying to create fear. You are trying to make safe action feel normal and quick.

What a strong anti-phishing policy should include

A clear structure usually helps. Your policy should cover:

  • Purpose of the policy
  • Who it applies to
  • Plain-English definition of phishing
  • Staff responsibilities
  • Verification rules for unusual requests
  • Reporting process
  • Immediate steps after a mistake
  • Training and simulations
  • Consequences of repeated or deliberate non-compliance
  • Review cycle

That is enough to keep it useful without turning it into a handbook no one reads.

FAQs

How long should an anti-phishing policy be?

Usually, 2 to 4 pages is enough. You want enough detail to guide behaviour, but not so much that people cannot absorb it. The part employees need to remember day to day should fit on 1 page.

Should your phishing policy sit inside a wider cyber security policy?

It can, but a separate anti-phishing policy often works better because it is easier to communicate and easier for employees to use. It should still align with your wider device, cloud, remote working, and incident response policies.

Should employees be disciplined for clicking a phishing email?

Not automatically. If you create a blame-heavy culture, people will hide mistakes. Early reporting is far more valuable than silence. Formal action is usually more appropriate where there is deliberate disregard for clear policy or repeated refusal to follow essential steps.

What is the most important rule in the whole policy?

Verify unusual requests through a second channel before acting. That single rule can prevent payment fraud, credential theft, fake login approvals, and data loss.

How often should the policy be reviewed?

At least once a year, and sooner if your systems, cloud tools, approval processes, or working practices change. You should also review it after any real incident or pattern of failed phishing simulations.

Final thoughts

A good anti-phishing policy is not about sounding strict. It is about making the right action easy.

If your people know what phishing looks like, understand the moments where they must slow down, feel comfortable reporting concerns quickly, and trust that they will be supported when they speak up, you are far more likely to reduce real risk.

That is the difference between a policy that exists on paper and one that actually changes behaviour.

If you want help building an anti-phishing approach that fits the way your business really works, speak to Northern Star about Anti Phishing, explore how its wider Why Us approach supports joined-up service delivery, or get in touch to discuss a practical cyber security plan for your team.