Purpose of the Template
Your team must explain phishing risks to employees without causing alarm. Your CISO wants security awareness that doesn't sound like a compliance lecture. Your DPO needs to ensure training respects privacy while building genuine security understanding.
This template provides three pre-written scripts that integrate human-centered design principles into your security awareness communications. Each script addresses a common security scenario while respecting user autonomy, explaining the "why," and avoiding surveillance-heavy language that erodes trust.
Use these scripts when rolling out new security controls, responding to a near-miss incident, or refreshing your quarterly awareness campaign. The goal is to build security behaviors that stick because people understand the reasoning, not because they fear punishment.
Prerequisites
Before deploying these scripts, confirm:
- Your security awareness program has executive sponsorship. Human-centered approaches work when leadership models the behavior, not just mandates it.
- You've mapped the actual user workflows. These scripts assume you understand where friction occurs in your authentication, data handling, or reporting processes.
- Your incident response plan includes a communication track. If you're using the phishing response script, you need a clear escalation path that doesn't punish reporters.
- You can measure behavior change, not just completion rates. Track phishing click rates, password manager adoption, or incident report volume, not just who clicked "I agree" on the training module.
The Scripts
Script 1: Introducing Multi-Factor Authentication to Non-Technical Teams
Subject line: Why we're adding a second step to login (and what it protects)
Body:
Starting [DATE], you'll see a new step when you log in: a six-digit code sent to your phone or generated by an app.
Here's what's happening. Your password protects your account until someone steals it through a data breach at another site where you used the same password, or through a convincing phishing email. We've seen this pattern in our industry, and we're closing that gap before it affects us.
The second factor (that six-digit code) means even if your password leaks, no one can access your work account without also having your phone. It's inconvenient for about three seconds per login. It's impossible for an attacker halfway across the world.
What you'll do:
- Log in as usual with your username and password.
- Open the [authenticator app name] on your phone.
- Enter the six-digit code you see.
- Check "Trust this device for 30 days" if you're on your regular work laptop.
What we won't do:
We won't track your location through this app. We won't access your personal data. The app generates codes locally on your device; we only verify that the code matches, not where you are or what else is on your phone.
Need help? IT is running drop-in sessions [DATES/TIMES] in [LOCATION] and via [VIDEO LINK]. No question is too basic.
Customization notes: Replace bracketed placeholders with your specifics. If you're using hardware tokens instead of phone apps, adjust the "what we won't do" section to address device tracking concerns. If your organization has a history of surveillance anxiety, add a sentence explicitly stating what logs you keep and how long you retain them.
Script 2: Responding to a Phishing Simulation (When Someone Clicks)
Subject line: You reported something suspicious, here's what happened
Body:
Thanks for forwarding that email to security@[DOMAIN]. You did exactly what we need: when something feels off, you flagged it.
This was a simulation we ran to test our defenses. The email wasn't real, but the technique was; it's a pattern we're seeing in actual attacks against organizations like ours.
What the email did well (from an attacker's perspective):
- It used a real executive's name and mimicked their signature.
- It created urgency ("need this by end of day").
- It asked you to click a link to a document, not download an attachment (which bypasses some filters).
What you can watch for:
Check the actual sender address, not just the display name. Hover over links before clicking; the URL preview often reveals a mismatch. If it's urgent and unusual, verify through a separate channel (Slack, phone, walking to their desk).
What happens now:
Nothing punitive. We're tracking these simulations to see where our training is working and where it's not. If you clicked the link, you'll see a brief explanation page, that's the end of it. No report to your manager, no mark on your record.
We run these because the real attacks are getting better. Your awareness is our strongest control.
Customization notes: If your simulation was punitive (required remedial training, notified managers), rewrite this entirely. Human-centered security means psychological safety, people won't report real threats if they fear consequences for honest mistakes. If you must require follow-up training, frame it as "here's a five-minute module that explains the specific technique" rather than "you failed, complete this course."
Script 3: Announcing a New Data Handling Requirement
Subject line: New rule for customer data in emails, here's the safer alternative
Body:
Effective [DATE], don't email customer account numbers, full credit card details, or health information as plain text, even internally.
Why this matters:
Email passes through multiple servers, gets archived in places you don't control, and stays in inboxes long after the project ends. If someone's account gets compromised six months from now, every sensitive email they ever received becomes exposed.
We've seen this pattern lead to notification requirements under the General Data Protection Regulation and state breach laws. The cost isn't just the fine, it's the customer trust we lose.
What to do instead:
- Use [SECURE FILE SHARE TOOL] for documents containing sensitive data. It encrypts at rest, expires links after [X] days, and logs access.
- Reference account numbers by last four digits only: "account ending in 4829."
- For detailed discussions, move to [COLLABORATION PLATFORM] where we control retention and access.
What this doesn't mean:
You can still discuss customer issues via email. You can still share anonymized data for analysis. You can still use email for most of your work. This is a scalpel, not a sledgehammer, it targets the specific pattern that creates disproportionate risk.
Questions? [DPO NAME] is holding office hours [DATES/TIMES]. The FAQ is at [LINK].
Customization notes: Replace the tools and timelines with your actual infrastructure. If you don't have a secure file share, implement one before announcing this policy, otherwise you're creating friction without offering an alternative, which guarantees workarounds. Adjust the regulation reference to match your jurisdiction (HIPAA for healthcare, GLBA for financial services, etc.).
Customizing the Scripts
Tone calibration: If your organization's culture is more formal, remove contractions and add section headings. If it's more casual, you can go further, but keep the precision around what you're asking and why.
Compliance mapping: Add a parenthetical reference to the relevant control if your audience expects it. Example: "This aligns with NIST Cybersecurity Framework PR.AT-1, which requires security awareness training tailored to roles."
Measurement hooks: Add a feedback mechanism. "Reply with questions" works for small teams. "Take this two-question survey: [LINK]" works for larger rollouts. You're testing whether the message landed, not just whether it was sent.
Cultural adaptation: If your workforce spans multiple languages, translate these scripts and have a native speaker review them. Idioms don't translate cleanly, and security concepts carry different connotations across cultures. "Trust this device" might read as surveillance in one context and convenience in another.
Validation Steps
Before sending any of these scripts:
Test with a representative user. Not your security team, someone from the target audience. Watch where they pause or ask clarifying questions. Those are the sentences that need rewriting.
Confirm your infrastructure supports the ask. If you're telling people to use a secure file share, verify it's actually available, documented, and doesn't require three approval steps to access.
Check your incident response alignment. If the phishing script promises "no punitive action," make sure your IR plan doesn't contradict that. If it does, fix the plan, not the script.
Measure the outcome, not the output. Track whether MFA adoption actually happens, whether phishing click rates drop, whether sensitive data in email decreases. If the metrics don't move, the script didn't work, revise and try again.
Review quarterly. Threats evolve. Your last MFA explanation might not address the new push notification fatigue attacks. Your phishing script might need to cover QR code attacks. Update the scripts as the threat landscape shifts.
Human-centered security isn't about making security easier, it's about making it understandable. When your team knows why a control exists and how it protects them, compliance stops being a checkbox and becomes a shared responsibility.
