Phishing scams policy template explained with examples

Most anti-phishing policies fail in the same way. They tell staff to be vigilant, they are read once during onboarding, and they contain nothing anybody could follow at the moment it mattered.

A policy that works is short, names specific actions, and removes ambiguity about what the organization itself will never ask for. Below is a skeleton to adapt. Fill the bracketed parts, delete what does not apply to you, and keep the whole thing to a page or two.

What to take away

• The policy's real job is to make one behavior normal: stopping and checking, without needing permission.
• Publish what your organization will never do. Ambiguity is what the attack runs on.
• Reporting a mistake must cost nothing, or people will hide it while the damage grows.

1. Scope and owner

State plainly who this covers and who owns it.

This policy applies to everyone working for or with [organization], including contractors and temporary staff, on any device used for work. It is owned by [role] and reviewed every [period], or after any incident.

Name a role rather than a person, so it survives someone leaving.

2. The verification rule

This is the one clause that does most of the work.

Any request that arrives by message, call, or email and asks for a payment, a change to payment details, a password, a one-time code, an installation, or remote access is verified using contact details we already hold, never contact details supplied in the request itself. This applies regardless of who the request appears to come from, including [organization] leadership.

Add the exception path underneath, or people will route around the rule when it blocks something legitimate.

Where verification is not possible and the matter is genuinely urgent, [role] may approve an exception and records the reason.

3. What we will never ask for

Publish this to staff and to customers. It removes the cover the attack needs.

[Organization] will never ask you for a password or a one-time code, will never send new bank details by email, will never ask for remote access to your device from a call you did not make, and will never ask you to keep a payment or a request secret from colleagues.

Put the customer-facing version on your site and in your order confirmations, where it is read at the moment it is useful.

4. Payments and payment changes

The clause that protects the largest single loss.

A change to a supplier's or an employee's bank details is confirmed by telephone on a number held in our own records before the change is made, by a person other than the one who received the request. Payments above [amount] require a second approver. New payees are set up only from a written request verified in the same way.

Set the threshold to a number that is meaningful for your size and low enough that the common case is covered.

5. Authentication baseline

Say what the minimum is rather than describing menus, which move.

Every work account uses a password not used anywhere else, stored in [the approved password manager]. Multi-factor authentication is required on all work accounts. Where the service supports a phishing-resistant method such as a security key or passkey, that method is used for email, administrative accounts, and anything holding money. Backup codes are held by [role].

The public guidance behind that baseline is CISA's advice on turning on multi-factor authentication.

6. Reporting

Make it one action, name it, and make it safe.

Report anything suspicious to [route] immediately, whether or not you interacted with it. If you clicked, typed, paid, or installed anything, report it straight away and do not attempt to fix it first. No one is disciplined for reporting a mistake, or for reporting something that turns out to be harmless. Delay is the only failure this policy recognizes.

That last sentence matters more than the rest of the document. A team that hides clicks is worse off than a team with no policy.

7. Response

Keep it to the sequence people will actually follow under pressure.

On report: preserve the message and any screenshots before deleting anything; if money moved, [role] contacts the bank immediately; if credentials were entered, the password is changed and all sessions are ended; recovery contacts, forwarding rules, filters, and connected applications on the affected account are checked for changes; if software was installed or remote access allowed, the device is disconnected and handed to [role].

The reasoning behind that ordering, and what each step is protecting, is in phishing scams. External reporting routes, and which body handles what, are collected at USAGov's page on where to report a scam.

8. What gets recorded

Every report is logged with the date, the channel it arrived on, what was requested, what if anything was done, and the outcome. The log is reviewed [period] to see what is reaching people and what our controls are missing.

Count reports rather than counting failures. A rising number of reports is usually good news about the culture, not bad news about the threat.

9. Training that is worth the time

Two lines are enough here, and the content matters more than the frequency.

Everyone receives a short briefing on joining and a refresher [period]. Simulated exercises, where used, are run to test controls and are never used to identify or penalize individuals.

An exercise that produces a list of people to embarrass will make the reporting clause in section 6 worthless within a month.

10. Review

This policy is reviewed [period] and after any incident. Changes to how the organization verifies requests are communicated to staff and customers directly, through channels they already use, and never through a link in an unexpected message.

Adapting this honestly

Two cautions. First, none of the above is legal advice, and requirements around reporting, personal data, and payment fraud differ by jurisdiction and sector, so check your own obligations with someone qualified rather than assuming a template covers them.

Second, a policy is not a control. The clauses above only work if the underlying setup exists: unique passwords, strong second factors, a real reporting route somebody monitors, and the account hygiene described in the social media account security audit for any public-facing account. The personal version of the same rules, for the people you cannot write policy for, is in phishing scams rules.

Common questions

How long should the finished policy be?

One or two pages. Anything longer will not be read, and the parts that matter are sections 2, 3, and 6.

Do small teams need this?

Small teams need the payment clause most of all, because they usually have no second approver by default and one person can move money alone.

Should we run simulated phishing exercises?

Only if the results are used to fix controls rather than to name people. Handled badly they train staff to distrust internal communication, which is exactly the wrong outcome.

What about staff who are impersonated to customers?

That is a separate problem with its own response, and it is covered in impersonation scams. Publishing the section 3 list to customers is the cheapest thing you can do about it.

Who should own this if we have no security team?

Whoever controls payments and account administration, because those are the two things the policy protects. Name the role in writing so it is not left to whoever notices.