How to Write an Employee Phishing Reporting Policy
A practical outline for a reporting policy employees actually follow: what to report, one reporting path, response commitments, and the no-blame rule.
Most employees who receive a suspicious email do nothing with it. Not because they do not care, but because the path is unclear. Should they forward it? To whom? Will they look paranoid if it turns out to be a newsletter? Will they get in trouble if they already clicked?
A phishing reporting policy answers those questions once, in writing, before the next suspicious message arrives. It is one of the cheapest security documents a business can produce, and one of the few that changes behavior on day one.
What the policy has to accomplish
A reporting policy is not a legal document and it should not read like one. It has one job: remove every reason an employee might hesitate to report. That means it must answer four questions in plain language:
- What should I report?
- How do I report it?
- What happens after I report?
- What if I already clicked?
If your draft answers those four questions on a page or two, it is doing its job. If it takes ten pages of definitions to get there, employees will not read it, and a policy nobody reads protects nobody.
Tell people what to report
Be generous with examples. Employees hesitate most when a message is only slightly off, so the policy should make clear that "slightly off" is exactly what you want reported: unexpected password reset emails, invoice or bank detail changes, executives asking for urgent favors, document shares from unfamiliar senders, MFA prompts nobody triggered, and text messages or calls that push for quick action.
Then set the threshold explicitly: when in doubt, report. Employees should never be expected to decide whether something is definitely malicious. That is the security team's job. The employee's job ends at "this feels wrong."
Make the how one step
Every extra step in the reporting path costs you reports. The best version is a report button in the mail client, one click and done. If you do not have that yet, name a single address or channel and keep it stable.
Whatever the path, the policy should name exactly one. A policy that lists three options with caveats ("forward to IT unless it is after hours, then...") reintroduces the hesitation you are trying to remove.
Promise what happens next
This is the section most policies skip, and it is the one that builds trust. Commit to what the employee will experience after reporting: an acknowledgment, a review of the message, and feedback on what it was. When people hear back, even briefly, they report again. When reports disappear into silence, they stop.
The same section should cover the clicked case. An employee who clicked, replied, or entered credentials needs to know that reporting immediately is the expected and welcomed move, and the policy should say what to do in that moment. Pair this with a phishing incident response plan so the team receiving the report has its own script for what happens next.
Put the no-blame rule in writing
If you keep one sentence from this article, keep this one: the policy must state, explicitly, that nobody will be punished for reporting, including when they report their own click.
Fear is the biggest reporting killer. An employee who thinks a click means discipline will stay quiet and hope nothing happens, which hands the attacker the one thing they need most: time. A written no-blame commitment, signed off by leadership, is what makes fast self-reporting rational. This applies to phishing simulations too: if simulations feel like traps, trust in the whole program erodes.
Roll it out and keep it alive
A policy in a shared drive is furniture. Announce it briefly, walk through it in onboarding, and collect a simple acknowledgment so you have a record of who has seen it. That acknowledgment also becomes useful evidence when insurers or auditors ask how employees know what to do with suspicious email.
Then revisit it once a year and after any significant incident. If an incident revealed a gap, the policy is where the lesson gets written down.
Start from a template, not a blank page
You do not need to draft this from scratch. Our free employee phishing reporting policy template is an editable document with all the sections above: what to report with examples, a single reporting path, response commitments, the clicked-link steps, the no-blame commitment, and an acknowledgment page. Replace the bracketed fields with your own contacts and reporting channel, and you have a working policy in an afternoon.
Sources and further reading
Related resources
How phishable is your team?
Take the free 2-minute assessment to see where your human layer is strong and where attackers still have an easy path. Then see how PhishAlertPro combines reporting, AI-assisted triage, simulations, and awareness training.