Security Survey Template
Use this security survey to get a clean baseline on awareness and everyday security behaviors, plus where controls create friction that drives workarounds. You will also see whether employees know how to report issues and whether they expect blame. Run it as a short pulse or an annual deep dive, then turn the results into training, comms, and process fixes.
Trusted by 5000+ Brands
How to Use This Security Survey (5-minute setup + safe deployment)
- Goal (pick one): Baseline (what employees do today), post-training (what changed), or control rollout (what will block adoption). If you want trend lines, lock a stable core set. Internal starter target: 8-12 core questions (adjust after your baseline and observed completion time).
- Audience (decide coverage): Send company-wide for culture and reporting readiness; use role-based versions for high-risk groups (finance, engineering, customer support, contractors). If your org is small, report one overall view; if your org is large, add department views but only above your minimum group size.
- Privacy mode (set expectations): Use anonymous reporting when you are measuring bypass behavior, fear of blame, or willingness to report mistakes. Use confidential or identified collection only when you have a concrete follow-up workflow and you will restrict access (and say so plainly).
- Segmentation fields (reduce re-identification risk): Keep demographics coarse: department, region, role type (IC/manager), and tenure band (0-6 months, 6-24 months, 2+ years). If any segment could identify a person, collapse categories or suppress the cut.
- Minimum group sizes (set the rule before you launch): Internal starter target: require at least n=10 (or n=15 for more sensitive topics) before showing any breakdown (team, location, role). Adjust after your baseline response volume and privacy risk review. If a manager asks for a cut below the threshold, say no and offer a combined view instead.
- Timing + reminders (protect quality and response rate): Send mid-week, avoid incident weeks and month-end crunch, and keep the invite short and specific (time to complete + why it matters). Internal starter target: run a 7-10 day field period with 2 reminders to non-responders (adjust after your baseline response patterns) (see Fan and Yan's review of factors affecting web survey response rates).
- Invitation script (copy/paste): "Please take our 5-minute security survey by Friday. This is about everyday work (phishing, reporting, data handling, and where tools slow you down). We will report results only in groups above our minimum size, and we are not asking for passwords, MFA codes, or incident details. Your input drives what we fix next." If you see skewed results after heavy reminders, review how response bias can distort security survey results and adjust your follow-up plan.
- Mobile + accessibility (remove friction): Avoid long grids, and use plain words employees already use for tools and channels. Internal starter target: keep completion time to 5-10 minutes for a pulse and cap at 10-15 minutes for a deep dive (adjust after your pilot). Internal starter target: pilot with 3-5 employees in different roles and fix confusing terms before launch (see the University of Minnesota's survey administration checklist).
- When NOT to use a survey: Do not field this during an active investigation or urgent incident response. If you need immediate reporting, route people to your official reporting channels and keep the survey for post-incident learning.
Pick your privacy mode, set a minimum group size for reporting, and schedule your fielding plan. Internal starter target: a 7-10 day window with 2 reminders (adjust after your baseline).
Security Survey Questions (Modular blocks you can toggle)
"Leaders in my area treat security as part of doing the job well (not as an afterthought)."
Why it matters: Culture signals drive what people do when work is busy. If leaders treat security as optional, controls get bypassed.
When to use: Include in every run as your culture anchor for trending.
"I know what data I can share externally (and what I cannot)."
Why it matters: If policy is unclear, people guess. That creates real leakage risk and inconsistent handling.
When to use: Use for baseline and any policy rewrite or classification rollout.
"If I suspect a phishing message, I know exactly how to report it."
Why it matters: Reporting speed matters as much as detection. Confusion here means missed containment time.
When to use: Use after simulations or training, and whenever you change the reporting channel.
"In the last 3 months, I have paused to verify an unexpected request for money, credentials, or sensitive data."
Why it matters: This checks real behavior, not just confidence. It is a practical proxy for social engineering resistance.
When to use: Use in baseline and quarterly pulses; keep the time window consistent for trending.
"I use the approved method to store and share work passwords (I do not use personal notes, chat, or email)."
Why it matters: This measures risky workarounds without collecting secrets. If scores are low, treat it as tooling/training friction, not moral failure.
When to use: Use when rolling out a password manager or tightening access policies. Safety check: do not ask employees to name tools or provide examples of passwords.
"I lock my screen when I step away from my workspace."
Why it matters: Simple physical/device behaviors prevent avoidable incidents, especially in shared spaces and hybrid work.
When to use: Use for office-based teams and any environment with visitors or shared desks.
"If I make a security mistake, I can report it without fear of getting in trouble."
Why it matters: Fear kills reporting. Low scores here usually explain slow containment and hidden near-misses.
When to use: Use in every run; pair with a no-blame message and a simple reporting path.
"Security requirements and tools make it hard to get my work done."
Why it matters: High friction predicts bypass behavior. Treat this as a process/tooling backlog for IT and security engineering.
When to use: Use before and after major controls (MFA changes, device management, DLP) to see where adoption will break.
"The new security control will help me do my job safely."
Why it matters: This is your control-rollout add-on. Perceived usefulness is a leading indicator of adoption risk.
When to use: Add for MFA/password manager/device encryption rollouts, then compare by role and region to target comms and support.
Keep one topic per question, avoid double-barreled wording, and reuse the same response scale each run (see Likert scale options for security awareness questions). Plain wording improves response quality and reduces misinterpretation (see BMJ guidance on Boynton & Greenhalgh (2004), BMJ -- designing your questionnaire).
- Scale default: Use "Strongly disagree" to "Strongly agree" for beliefs and clarity; use "Never" to "Always" for behaviors. Do not mix scales inside one block.
- Wording swaps: Replace "security team" with your team name; replace "report" with your actual channels (ServiceNow/Jira/Slack/email/phone). Add a parenthetical like "(Report via: #security-help or security@company.com)".
- Safety boundary: Do not ask for passwords, MFA codes, or specific incident details. Use scenario-style items ("unexpected invoice request") and process questions ("I know how to report").
Do this now: Internal starter target: pick a stable core of 8-12 questions, then toggle on only the modules that match your goal (post-training, reporting readiness, or control rollout). Adjust after your baseline and observed completion time.
Anonymous vs Confidential vs Identified: Which is right for a security survey?
| Decision | Anonymous (no identity collected) | Confidential (identity collected, restricted reporting) | Identified (identity used in reporting/workflows) |
|---|---|---|---|
| Best use cases | Bypass behaviors, fear of blame, reporting comfort, culture signals. | Follow-up coaching/support, targeted enablement during a rollout, while still protecting employees in reporting. | Training compliance tracking, access/process enrollment, or required attestations (not ideal for sensitive behavior questions). |
| Expected honesty level | Highest for sensitive items. | Medium-high if you clearly limit who can see raw data. | Lowest for anything that feels like performance evaluation. |
| Safe segmentation | Department, region, role type, tenure band (only above your minimum group size). | Same as anonymous, plus limited 1:1 follow-up outside the reporting dataset. | Minimal segmentation; results can quickly feel punitive at team level. |
| How to explain privacy | "We do not collect names. We will only report results in groups above our minimum size." | "We collect identifiers to support follow-up, but we report only in groups above our minimum size. Access is limited to [roles]." | "Responses are linked to individuals and may trigger follow-up." Use only if employees already expect this. |
| Do-not-collect (ever) | Passwords, MFA codes, specific vulnerabilities, detailed incident narratives, names of suspected attackers, or instructions for bypassing controls. | ||
| What to do instead | Ask scenario and process questions ("I know how to report"), and route real incidents to your official reporting channel. Keep survey text focused on behaviors and friction, not incident forensics. | ||
Use anonymous reporting if you are measuring mistakes, workarounds, or fear of blame. If you need follow-up, switch to confidential and restrict access, then report only in groups above your minimum size (consistent with principles in AAPOR's best practices for survey research).
Do this now: Pick one mode and write a privacy promise in the invite and the first survey screen. Internal starter target: keep it to 2 sentences (adjust for your legal and policy requirements).
Scoring and Interpreting Results (turn responses into a prioritized action list)
- Step 1: Lock your score domains (so results map to owners)Use domains that match how work gets fixed: Culture, Policy clarity, Phishing readiness, Data handling, Reporting readiness, and Tool/process friction (add Device/workspace security if you have on-site risk). Internal starter target: 5-7 domains (adjust after your baseline and stakeholder ownership). Safety check: define domains before you look at results so you do not "cherry pick" what looks good.
- Step 2: Convert each domain to a 0-100 scoreFor a 5-point scale, you can map responses to 0/25/50/75/100 and then average within each domain; reverse-score negative items (like friction). If you use a different scale, adjust the mapping but keep it consistent across runs so you can trend, aligned with measurement thinking used in security programs (see ISO guidance on measurement and evaluation in ISO/IEC 27004).
- Step 3: Flag red items that demand action (not debate)Treat these as "stop-the-bleed" signals: employees do not know how to report; employees expect blame for mistakes; employees say they bypass controls to get work done; or employees do not know what data can be shared. If any red item is low, assign an owner (security awareness, IT, GRC, comms) and a fix-by date. Internal starter target: a 30-day first fix (adjust based on effort and risk).
- Step 4: Compare segments safely (and only when groups are big enough)Set a minimum n before you show department/location cuts and apply the same suppression rule every time. Internal starter target: n=10 (or n=15 for more sensitive topics) before showing any segment (adjust after your baseline and privacy review). If you need help planning thresholds and expected completion counts, use sample size guidance for employee surveys.
- Step 5: Turn patterns into a prioritized backlogLook for clusters: if new hires have low policy clarity, fix onboarding; if one region reports high friction, fix tooling or network paths; if managers score low on "no-blame," run manager talking points and update incident comms. Internal starter target: put the top 3 fixes on a 30/60/90 plan and name the owner per fix (adjust after effort sizing).
- Step 6: Code open-text comments into themes (then prove it with quotes)Tag each comment to a small number of themes, count themes, then pick representative quotes that match the counts. Internal starter targets: assign 1-2 themes per comment and use 3-6 representative quotes in your readout (adjust for volume). Avoid overweighting extreme one-offs; use tips for analyzing open-ended survey responses to keep your summary fair and action-focused.
- Step 7: Re-measure with the same core setRe-run the same core questions after you ship fixes. Internal starter targets: 30-60 days after a comms/process change and 60-90 days after a tooling change (adjust based on rollout timelines). If you change question wording, you break the trend line.
| If you see this | Do this fix next | Owner | Measure next run |
|---|---|---|---|
| Low policy clarity | Rewrite policy into 1-page job aids + examples; update onboarding; add "what to do" links inside common tools. | GRC + comms + security awareness | Policy clarity score + "I know what data I can share" |
| Low reporting readiness | Simplify intake (one button/channel); publish no-blame messaging; add a "what happens after you report" explainer. | Security operations + comms | "I know how to report" + "I can report without fear" |
| High tool/process friction | Fix workflows, reduce prompts, improve SSO, add how-to guides, and target office hours for the highest-friction group. | IT + security engineering | Friction score + adoption intent (rollout add-on) |
| Low phishing readiness | Run short scenario training + clear reporting instructions; focus on "verify" behaviors for high-risk roles. | Security awareness | "I know how to report" + behavior frequency item |
Pick your minimum group size, score each domain to 0-100, and publish a short action plan. Internal starter target: publish the top 3 fixes with named owners and a 30/60/90 timeline (adjust after sizing the work).
Frequently Asked Questions
Should an employee security survey be anonymous?
Use anonymous reporting when you are measuring bypass behaviors, fear of blame, or willingness to report mistakes. Choose confidential collection only if you have a clear follow-up workflow, restricted access to raw data, and you will report results only in groups above your minimum size. If your goal is coaching or enrollment tracking, use identified mode and remove sensitive behavior questions.
What should we avoid asking in a security survey?
Do not ask for passwords, MFA codes, specific vulnerabilities, detailed incident descriptions, or names of suspected attackers. Ask safer alternatives instead: scenario questions ("unexpected invoice request"), clarity questions ("I know what data I can share"), and process questions ("I know how to report"). For real incidents, route employees to your official reporting channel, not the survey.
How many questions should this security survey include?
Use a stable core set for trend tracking, then add optional modules based on your goal (post-training, rollout friction, or reporting readiness). Internal starter target: 8-12 core questions and a 5-10 minute completion time (adjust after your baseline and pilot). To keep mobile responses accurate, avoid long grids; if you need more coverage, split it into two pulses a few weeks apart.
How many responses do we need to trust the results?
Aim for broad coverage, then focus on consistent measurement over time rather than chasing a perfect target number. Only compare teams or regions when each group meets your minimum n. Internal starter target: show segment results only when each group has at least n=10 (or n=15 for more sensitive topics) and suppress smaller cuts (adjust after your baseline and privacy review). For planning help, use sample size guidance for employee surveys.
How often should we run a security awareness survey?
Use a pulse-and-deep-dive cadence that matches how fast you can ship fixes. Internal starter target: run a quarterly pulse with a small core set (8-12 questions) and do an annual deep dive with extra modules (adjust after your baseline and program capacity). Keep wording and scales stable so changes reflect real movement, not survey edits.
How do we share results without shaming teams or creating risk?
Share an org-wide summary first, then publish a short action plan with owners and dates. Internal starter target: publish 2-3 prioritized actions and report progress on a 30/60/90-day cadence (adjust after effort sizing). Provide department views only when groups meet your minimum size, and use no-blame language that focuses on fixing training, comms, and tooling.