Phishing Survey Template
Send a lightweight (under 5 minutes) employee phishing survey to measure awareness, reporting confidence, and friction in your reporting route. You will get a simple scorecard plus a follow-up plan you can trend over time. If you also want coverage beyond phishing, start from the <a href="/LPC-employee-cyber-security-survey">employee cyber security survey template</a>.
Trusted by 5000+ Brands
When to Use This Phishing Survey (and When Not To)
Baseline before a new or updated awareness program
Use this section to set a repeatable baseline so you can plan training and process fixes with real employee feedback.
Before you send the survey: confirm your reporting route (button, mailbox, ticket, or chat) and your target audience.
Do this now: send the baseline 1-2 weeks before your program changes, aligned to your measurement plan (see NIST SP 800-50r1 security awareness program guidance and the NIST CSRC publication page).
Post-training pulse to check readiness (not real-world susceptibility)
Use this section to confirm employees feel ready to spot and report suspected phish after training.
Before you send the survey: decide what changed (new module, new report button, new mailbox) so you can ask about it.
Do this now: run the pulse 2-4 weeks after training to measure perceived knowledge, confidence to report, and clarity of steps.
After an incident to find breakdowns in reporting and escalation
Use this section to find where people got stuck so you can fix handoffs, tooling, and comms fast.
Before you send the survey: define what you mean by phishing in plain terms (use a shared definition of phishing and related social engineering lures).
Do this now: ask about the reporting path and barriers, then confirm the story with simulation results or email-security telemetry.
Next step: Pick your timing (baseline, post-training, or post-incident), then decide what you want to change first: training content or the reporting route.
Phishing Survey vs Phishing Simulation: What Each Measures
| Category | Phishing survey (what people say) | Phishing simulation or telemetry (what happens) |
|---|---|---|
| Primary use | Measure awareness, confidence to report, and where the reporting flow feels unclear or slow. | Measure observed behavior: clicks, credential entry, attachment opens, and reports. |
| Typical metrics | Self-rated confidence, clarity of steps, perceived barriers (time pressure, fear of blame). | Click rate, report rate, time-to-report, repeat offenders, channel-specific performance. |
| Best timing | Before program changes, 2-4 weeks after training, and after an incident to find friction. | Ongoing campaigns; before and after training to verify behavior change. |
| What it cannot tell you | It will not give your real click rate or true susceptibility. | It will not tell you why employees did not report or what step confused them. |
| Common pitfalls | Blame language reduces honesty; asking for screenshots/links can create data-handling risk. | Over-focusing on click rate can miss reporting barriers and process usability issues. |
| How to pair them (recommended) | Run the survey to find clarity/friction issues, then run simulations to validate behavior. Use the same reporting route and the same definition of phishing across both so results are comparable. | |
Next step: Decide which metric you need next week (clarity/friction vs click/report rate), then plan to pair both in the same quarter.
Customize and Deploy the Survey Fast (Without Reducing Trust)
- Swap in your exact reporting route: Name the button, mailbox, ticket queue, or Teams/Slack channel employees should use. If there are multiple routes, ask which one they use most.
- Tailor to tools: Replace generic terms with Outlook/Gmail, Teams/Slack, iOS/Android, and your phishing-report add-in name. You will get cleaner data and fewer "not applicable" answers.
- Add 2-3 realistic lure examples: Use short descriptions ("fake DocuSign", "missed delivery", "urgent MFA reset"). Do not paste real malicious URLs.
- Keep it under 5 minutes: Start with a core set (10-14 questions). If you add a mini-module, remove 2-3 questions elsewhere (brevity and clear purpose are associated with better web-survey completion; see web survey response-rate fundamentals).
- Branch by role or channel: If someone never uses Teams, do not show Teams-specific reporting questions. Branching reduces drop-off and improves answer quality.
- Choose anonymous vs confidential on purpose: If you want candor about fear of blame, make it anonymous. If you need follow-up on tooling issues, keep it confidential but avoid collecting names in the survey.
- Do not collect risky content: Do not ask for screenshots, suspicious links, sender addresses, or forwarded emails. Keep it to perceptions, steps, and barriers.
- Use non-blaming language: Your invite should say "help us fix the reporting process" not "stop clicking." If you see defensiveness, apply these tactics on how to reduce response bias.
- Protect disclosure: Privacy conditions can change how much people admit in sensitive surveys, so state your anonymity/confidentiality promise clearly (see the randomized trial on privacy conditions and disclosure in sensitive surveys).
- Send a simple invite + 2 reminders: Day 0 invite (why + time), Day 3 reminder, Day 7 final reminder. Keep subject lines consistent so people recognize it.
Subject: Quick 4-minute phishing reporting check
Body: Help us improve how you report suspicious messages. This 4-minute survey is [anonymous/confidential]. Please do not include screenshots or links. We will share back what we change (report button, steps, and training updates).
Next step: Replace the reporting-route text in the first 3 questions, then decide anonymous vs confidential before you send the invite.
Question Bank (Copy/Paste): Awareness, Reporting, and Reporting-Flow Usability
Use this section to copy/paste a tight question set so you can measure awareness and reporting flow issues without turning it into a test.
Before you send the survey: confirm your channels (email, SMS, voice, chat) and your reporting route.
Do this now: pick the core module plus 1 optional mini-module, then keep the rest off.
Module 1: Channel exposure (what employees actually see)
"In the past 30 days, where have you seen suspicious messages at work?"
Why it matters: Your training and reporting prompts should match the channels employees face (email, SMS, Teams/Slack, phone).
When to use: Include in baseline and quarterly pulses to spot channel shifts (for example, more chat-based lures).
Module 2: Recognition knowledge (quick cues, not a quiz)
"Which signs make you most suspicious that a message is a phish?"
Why it matters: You will see which cues employees rely on (sender mismatch, urgency, unexpected attachment, login prompts).
When to use: Use at baseline and after training to check whether key cues stuck.
Module 3: Confidence to report (rating items)
Use a 5-point agreement item for confidence, clarity, and friction. If you need formats, pull from Likert scale question examples.
"I feel confident I can recognize a suspicious message at work."
Why it matters: Low confidence predicts hesitation and delayed reporting, even when the route exists.
When to use: Include in every run as a trend anchor.
"If I suspect a message is a phish, I know exactly what to do next."
Why it matters: This separates "training knowledge" from "ready-to-act" behavior.
When to use: Use after you change the reporting route or publish new instructions.
Module 4: Last-time behavior (keep it low pressure)
"The last time you saw a suspicious message, what did you do?"
Why it matters: You will learn where reporting breaks down (deleted, ignored, asked a coworker, reported).
When to use: Use in baseline and incident follow-ups. Keep options non-judgmental.
Module 5: Reporting path clarity (findability + steps)
"I can find the phishing report option quickly in my primary tool (Outlook/Gmail/Teams/Slack)."
Why it matters: If the report action is hard to find, employees will delay or route around it.
When to use: Use right after you roll out a report button or change UI placement.
"How many steps does it take to report a suspicious message the right way?"
Why it matters: Step count is a simple proxy for friction and training burden.
When to use: Use before and after you simplify the reporting route.
Module 6: Barriers and motivations (what stops reporting)
"What most often stops you from reporting a suspected phish immediately?"
Why it matters: Barriers point to fixes you can ship (clear instructions, fewer steps, manager messaging).
When to use: Always include at least one barriers question so you can act on results.
"I worry I will get in trouble if I report something and it turns out to be harmless."
Why it matters: Fear of blame kills reporting volume. You can fix this with manager talking points and better confirmation messages.
When to use: Use when you suspect under-reporting or after a publicized incident.
Optional mini-module A: Reporting-flow usability (SUS-style, tailored)
"The phishing reporting process is easy to use."
Why it matters: You get a clean usability read without asking employees for screenshots or step-by-step explanations.
When to use: Turn on when you roll out a new report button, form, or ticket workflow.
"I feel confident using the phishing reporting process without help."
Why it matters: Low scores mean you need in-product hints, a 30-second demo, or fewer steps.
When to use: Use in baseline and again after you simplify the flow to show improvement.
Optional mini-module B: Reporting adoption (TAM-style, in plain language)
"Using the report button/channel helps keep me and the company safer."
Why it matters: If employees do not see personal or team value, reporting stays inconsistent.
When to use: Use when you are rolling out reporting to new groups or trying to raise report volume.
"If I suspect a phish this month, I intend to report it using the official route."
Why it matters: This is your leading indicator for reporting behavior, especially when you cannot run constant simulations.
When to use: Use in quarterly pulses to track whether adoption is moving.
Low-risk, high-value segmentation fields (recommended)
- Department (high-level only)
- Role type (individual contributor, people manager, IT/security, customer-facing)
- Primary tools (Outlook vs Gmail; Teams vs Slack)
- Work mode (remote, hybrid, on-site)
Next step: Turn on Modules 1, 3, 5, and 6 for your first run, then add one optional mini-module only if you stay under 5 minutes.
Results Guide: Score Responses and Turn Findings Into Actions
- Step 1: Score four sub-scores (0-100) from your core questions
Use this section to turn answers into a scorecard so you can prioritize fixes fast. Before you score: confirm you used consistent question wording across groups. Do this now: map each question to one bucket. For broader context on measuring awareness programs, see research on cybersecurity awareness measurement.
- Knowledge score: recognition cues + basic understanding of what counts as phishing (higher is better).
- Confidence score: confidence to spot and report (higher is better).
- Reporting clarity score: knows the next step, can find the report option, knows where it goes (higher is better).
- Reporting friction score: fewer steps, less time pressure, fewer blockers (higher is better).
- Step 2: Create one roll-up Risk/Opportunity score
Average the four sub-scores, then weight clarity and friction higher if your reporting route is new. If you want a starter rule (adjust after you see your baseline distribution), use: Risk/Opportunity = (Knowledge + Confidence + 1.5*Clarity + 1.5*Friction) / 5.
- Step 3: Assign starter score bands and ship the matching actions
Use three bands so you can act without over-analyzing. Treat these cutoffs as starter targets and adjust after your first baseline (and your risk tolerance).
- 80-100 (Green): keep training short; publish a single "how to report" card; run light simulations to maintain muscle memory.
- 60-79 (Yellow): ship micro-training (3-5 minutes) on top 2 cues; add in-tool prompts; tighten manager talking points.
- 0-59 (Red): fix the reporting UX first (fewer steps, one route, better placement), then retrain and re-pulse.
- Step 4: Trend it with a baseline -> post-training -> quarterly pulse plan
Keep most of your questions identical so trend lines mean something (a common rule of thumb is roughly 70-80% unchanged). Track baseline, then a post-training pulse 2-4 weeks later, then quarterly pulses for the core module.
Log actions next to the trend line so you can explain changes (new report button, new mailbox, new training module).
- Step 5: Segment safely (and avoid singling people out)
Use this section to segment results so you can target fixes without putting teams on blast. Before you break out results: set a minimum group size and stick to it. Do this now: apply sample size guidance and suppress small groups.
- Report department/role/tool breakouts only when groups are large enough to protect privacy.
- For small groups, report ranges ("about 60-70%") and focus on the process fix, not the team.
- Step 6: Close the loop with a 3-bullet share-back
Share back (1) what you heard, (2) what you changed, and (3) what to do next time. Expect better participation when people see outcomes, and awareness training tends to work best when it is reinforced and repeated (see the systematic review on security awareness training effectiveness).
Next step: Score your first run, pick one Yellow/Red fix you can ship in 30 days, and schedule the post-training pulse date now.
Frequently Asked Questions
How long should a phishing awareness survey be?
Keep it under 5 minutes for broad employee audiences. Start with a core module of about 10-14 questions, then add one optional add-on: a reporting-flow usability mini-module or an adoption mini-module. If you add a module, remove a few questions elsewhere to keep completion high.
Should this survey be anonymous?
If you want honest answers about fear of blame or uncertainty, make it anonymous. If you need to follow up on tool or process issues, keep it confidential and route follow-up outside the survey. Do not collect names, email addresses, or real phishing examples (links, screenshots, forwarded emails) in the survey.
Can this survey tell me our phishing click rate or real susceptibility?
No. A survey measures self-reported behavior and perceptions (confidence, clarity, friction). To get click rate or report rate, use phishing simulations or email-security telemetry, then compare results side-by-side.
How often should we run a phishing survey?
Run a baseline before you change training or the reporting route, then a post-training pulse 2-4 weeks later. After that, run quarterly (or twice a year) to track trends. Keep most questions the same over time and rotate only 2-3 topical items.
How do I segment results without singling out teams or individuals?
Only report breakouts (department, role, tool) when the group is large enough to protect privacy. For small groups, suppress the breakout or report a range instead of exact percentages. Focus your write-up on process fixes and enablement, not blame.
What should we do if employees say they do not know how to report phishing?
Fix the route first: one obvious button or one mailbox, with fewer steps. Add just-in-time prompts in the tools people use (Outlook/Gmail/Teams/Slack), run a 2-minute demo, and publish a single "how to report" card. Then re-run a micro-pulse focused only on clarity and friction.