Security Awareness Program Design

This security awareness training helps employees recognize common cyber threats, understand effective program patterns, and avoid common pitfalls.

My workspace28 minFree to watchDownloads

What you’ll learn

01Security Awareness Program Example: Patterns, Strengths, and PitfallsWelcome. Today we're working through a concrete security awareness program example, and asking a practical question. What does a real program actually look like, day to day, once the launch communications are over? We'll examine it through three lenses. First, recurring patterns that show up across organizations. Second, provable strengths, the things we can point to with evidence. And third, common pitfalls that quietly erode programs over time. Our contract with you is simple. Decision-ready takeaways for security, IT, risk, learning and development, compliance, and program reviewers. On scope, one distinction matters early. Awareness, role-based training, education, and culture are related but not interchangeable. Conflating them weakens programs, because each answers a different question and needs different measures. A phishing awareness campaign, for instance, does not satisfy role-based obligations for privileged users. We'll move through program anatomy, governance, patterns, strength cases, failure modes, measurement, and adaptation. As we go, compare each point against your own operating constraints. Next, we'll define the boundary more precisely in What Counts as a Security Awareness Program.adaptivesecurity.com github.laiyagushi.com github.com+22 min
02What Counts as a Security Awareness ProgramLet's take a moment to define what we actually mean by a security awareness program, because the definition shapes everything that follows. We treat it as a governed, risk-based, continuous learning capability, one designed to change workforce behavior, not just deliver content. In practice, it has four layers: broad awareness for everyone, role-based training for specific functions, professional education for security specialists, and event-driven reinforcement when threats or incidents demand it. The standards frame this in slightly different ways. NIST SP 800-50 Revision 1, published in 2024, describes a five-phase Cybersecurity and Privacy Learning Program lifecycle. ISO 27001 separates competence, in clause 7.2, from awareness, in clause 7.3 and Annex A control 6.3, which tells us those are distinct obligations. And NIST CSF 2.0 splits general training under PR.AT-01 from role-specific training under PR.AT-02. So let's correct a few assumptions up front. Completion does not equal capability. A hundred percent pass rate does not equal safety. And phishing simulation alone is not a program. With that shared definition in place, let's look at how a representative program is actually put together.smartfense.com adaptivesecurity.com doi.org+22 min
03Anatomy of a Representative ProgramLet us walk through the anatomy of a representative program. Six core components tend to show up: governance, risk assessment, content design, delivery, measurement, and improvement. Remove any one and the program starts to drift. The cadence usually layers as well. An annual baseline sets the floor, quarterly campaigns go deeper, monthly micro-learnings keep it present, and just-in-time nudges land when risk is highest, like a suspicious email report or a new phishing lure. Then there are named roles. A program owner, security champions in the business, H R and L and D, G R C, and an executive sponsor. If roles are unnamed, accountability defaults to the security team, and that rarely holds. The artifacts make this concrete: a charter, a R A C I matrix, a training matrix, an annual calendar, and a metrics dashboard. NIST Special Publication eight hundred dash fifty describes three delivery models: centralized, centralized policy with distributed delivery, and fully distributed. Each trades control against local relevance. The honest question is which model fits your structure and risk appetite right now. Next, we examine governance, charter, and decision rights.adaptivesecurity.com github.laiyagushi.com github.com+22 min
04Governance, Charter, and Decision RightsLet's turn to governance: the charter and its decision rights. First, be clear about what a charter is. It is a governing document that assigns authority, scope, and funding before training design begins. It is not a training plan. Training plans list audiences, modules, and delivery dates. A plan can change quarterly without changing the program's authority. A charter stays stable enough to guide those changes. Second, name your decision rights. Who approves scenarios, particularly high-risk simulations? Who decides data use? Who signs off on budget changes, exceptions, and program termination? Write these into a decision-rights matrix with a named final decision maker, required consultees, and an escalation path. Third, match cadence to decision speed. A working group meets monthly on delivery, exceptions, and open risks. A steering committee meets quarterly on priorities and cross-functional issues. Executive leadership receives a concise quarterly briefing. Finally, state amendment authority in the charter. The program owner handles minor content or scheduling changes. Steering approves scope and metric changes. Executives approve material funding or risk-appetite shifts. Without that, scope creep quietly erodes the program. Next, we will look at patterns that recur across effective programs.adaptivesecurity.com github.laiyagushi.com github.com+22 min
05Patterns That Recur Across Effective ProgramsLet's look at the patterns that show up again and again in programs that actually change behavior. First, targeting is risk-based, driven by exposure and leverage, not by the org chart. Finance rehearses business email compromise. Developers rehearse secrets management. Second, positive reinforcement beats shame. When reporting takes one click and near-misses are treated as useful signals, people report earlier and more often. Third, just-in-time prompts land at the moment of risk, such as a short module right after a simulated click, when the lesson connects to a real behavior. Fourth, metrics should be transparent and trended over time, segmented by department, so we can see where the program is gaining traction and where it is not. Fifth, programs iterate continuously. If a module stops engaging, retire it rather than reissuing the same content. None of these patterns is a guarantee. But as a set, they tend to reflect programs that treat security awareness as an operating capability, not a calendar event. As you compare this against your own program, ask which of these you have clearly in place, and which are still aspirational. Next, we'll look at how these patterns differ across maturity stages.adaptivesecurity.com lorikeetsecurity.com community.trustcloud.ai+22 min
06Patterns by Maturity StageLet's look at how program patterns shift by maturity stage, using the SANS five-stage model: Non-Existent, Compliance Focused, Behavior Change, Culture Change, and Optimization. The timelines here are useful, because they set realistic expectations. Stage two compliance programs often assemble in about one month, since the goal is meeting minimum training requirements rather than shaping behavior. Stage three, behavior change, typically shows measurable results within six to twelve months, when you focus on a small set of high-impact behaviors. Stage four, organization-wide culture change, commonly takes three to ten years, depending on size, complexity, and existing culture. Notice too how metrics evolve: completion rates at stage two, then detection and recovery times as you mature. And scaling requires dedicated staff, program age, and cross-department partnerships, especially with human resources, communications, and operations. The takeaway: one stage at a time. Next, we'll examine strengths: what the example program does well.sans.org sans.org sans.org+21 min
07Strengths: What the Example Program Does WellSo let's shift from design questions to observable strengths. What does this example program actually do well? Start with sponsorship. Leaders don't just sign off. They train, they receive briefings, and they report human-risk trends. That visibility changes how the program is perceived. Then, measurable risk reduction. The program tracks phishing susceptibility, credential submission, report volume, and time to report. Notice that it doesn't rely on click rate alone. A falling click rate can simply mean users learned the templates. Reporting behavior is the stronger signal. Next, blended delivery. A mandatory baseline, role-based modules, simulations, and just-in-time learning. Inclusive design matters too. For global, multilingual, hybrid, and shift-based workforces, localization and accessibility are requirements, not extras. Finally, two structural strengths. A feedback loop where simulation results, employee reports, and real incidents drive documented content changes. And audit-ready design. Versioned curriculum mapped to controls, per-employee records, and review minutes. The takeaway here is that strength comes from evidence, feedback, and documentation working together. Case Evidence: What Measurable Strength Looks Like.2 min
08Case Evidence: What Measurable Strength Looks LikeLet's ground this in evidence. These four programs show measurable strength. Vendée Habitat, around three hundred staff, cut vulnerability from twenty percent to two percent over three years. Reports now exceed two hundred per month, and a real CEO fraud attempt was stopped. At lastminute.com, with seventeen hundred employees, the vulnerability index halved in twelve months, using Slack coaching and twenty four micro-sessions a year. CoreDux, roughly three hundred users, dropped phish-prone rates from about twelve percent to a five percent average, reaching two percent in recent campaigns, with around nine hundred emails reported in six months. And YAMAM Group, about eighty staff, reduced click-through from twenty four point six four percent to one point four one percent, a ninety four percent cut in eight months. Notice what these claims share. An honest baseline, steady or rising simulation difficulty, and reports climbing while clicks fall. That combination is what credible strength looks like. Next, we turn to pitfalls, where awareness programs commonly fail.2 min
09Pitfalls: Where Awareness Programs Commonly FailLet's turn to the pitfalls, the places where awareness programs most commonly fail. First, compliance theater. One hundred percent completion and a high click rate prove nothing about real resilience. Second, annual-only training. Knowledge decays, and most of the year stays uncovered. Third, blame-oriented simulations. Leaderboards and discipline kill reporting, which is exactly the signal you need. Fourth, generic modules. One course for developers, finance, and frontline staff satisfies nobody. Fifth, weak measurement and easy templates. A ninety percent pass rate often signals inflated results, not real skill. And sixth, under-resourcing, ignored local culture, and distress-based lures erode trust. Notice a theme: these pitfalls reward looking good over being safer. As we compare this with our own programs, a useful question is which of these patterns we could honestly find in our own reporting. Next, we look at the evidence on training effectiveness.2 min
10The Evidence on Training EffectivenessLet's look at what the evidence actually says about training effectiveness. The largest test to date involved roughly nineteen thousand five hundred employees at U C San Diego Health. Annual awareness training showed no significant relationship to phishing failure. Embedded training, the lesson shown after someone clicks, reduced click likelihood by only about two percentage points, and seventy five percent of users engaged with that material for under a minute. A fintech reproduction with twelve thousand five hundred eleven participants found neither lecture nor interactive training improved clicking or reporting. What did predict behavior was lure difficulty. Under the NIST Phish Scale, click rates doubled from about seven percent on easy lures to fifteen percent on hard ones. The pattern across these studies points one direction. Training as commonly deployed is a weak control. Its measured effect is small, and it fades. That does not mean abandoning awareness work. It means pairing it with reporting channels, just-in-time coaching, and technical controls that carry the real protective load. Measuring Strength Without Gaming Metrics.2 min
11Measuring Strength Without Gaming MetricsLet's talk about measuring strength without gaming your own metrics. We can group indicators into two buckets. Leading indicators show where behavior is heading: enrollment, completion, report rate, and time to report. Lagging indicators show what already happened: click rate, credential submission, repeat failures, and real incidents. Click rate gets all the attention, but the report-to-click ratio is the clearest sign of program health. If reports outnumber clicks, your people are actively defending the organization, not just avoiding the lure. Here's the trap. A falling click rate only counts if difficulty holds. If your simulations get easier while clicks drop, you have taught template recognition, not resilience. So trend click, leak, and report together. When Pistachio held difficulty constant at roughly fifty percent hard simulations, clicks fell twenty-seven percent while reports fell only nineteen percent, and the report-to-click ratio rose from one point three to one point eight. That is resilience building. And avoid vanity metrics that reward hiding incidents or easy lures. Next, let's look at adapting the example to your own context.sans.org2 min
12Adapting the Example to Your Own ContextLet's bring this back to your own context. Adapting the example is not about copying it. It is a five step sequence, plus a checklist we keep returning to. Step one, baseline before you build. Run a simulation and audit your existing content. Then map what you find to a maturity model, so your starting point is evidence, not opinion. Step two, map stakeholders and secure executive sponsorship early. Without a senior sponsor, most programs stall. Step three, select your delivery mix. Workforce, budget, and regulation should drive that choice, not vendor defaults. Step four, define a few outcome metrics and baseline them before you intervene. A handful of meaningful measures beats a long list nobody reviews. Step five, pilot one audience, learn from it, then scale. Document the decisions and the trade-offs along the way. Finally, the checklist. Copy governance, reporting culture, and measurement discipline. Those three hold up across most contexts, and they are usually where adaptation succeeds or quietly fails. Next, we move into the reviewer's playbook: evidence, questions, and red flags.sans.org2 min
13Reviewer's Playbook: Evidence, Questions, and Red FlagsLet's move on to the reviewer's playbook, where we turn all of this into concrete evidence requests, questions, and signals. Start with the documents: the program charter, the risk assessment, versioned content, and per-person completion records. Then ask the owners three questions. How is content refreshed, how is success defined, and what triggers remediation? Their answers tell you whether the program is governed or just running on autopilot. Now for red flags. Perfect completion is one, because it usually means the tests are too easy. No executive sponsor is another. Punitive simulations that punish clicks instead of teaching, and stale templates that employees recognize. Green flags look different: risk-based targeting, calibrated difficulty, trended metrics rather than single snapshots, and triaged reports where employees who report get feedback. One more discipline for reviewers: separate design gaps from evidence gaps. A missing record is not the same as a missing control. Name the owner and the date for every finding, so it can actually be closed. Next, we'll pull this together into a ninety-day action plan and key takeaways.adaptivesecurity.com2 min
1490-Day Action Plan and Key TakeawaysLet's close with a concrete ninety-day plan and a few takeaways you can carry into your own program. In the first thirty days, stand up a working reporting channel, run a blind baseline simulation, and name owners across security, HR, IT, and GRC. Blind meaning employees don't know it's a test, so the baseline reflects real behavior. Days thirty-one to sixty: publish that baseline, segment by exposure and leverage, and start monthly micro-learning. Then days sixty-one to ninety: deliver just-in-time coaching after a click, build a dashboard tracking click, leak, and report rates, and hold your first management review. Two takeaways. Patterns beat one-off tactics, and behavior change against stable scenario difficulty is what proves strength, not a single good month. Our commitment: pick one high-impact behavior, instrument it, and change something visible within ninety days. Thank you for working through this with us. You have the evidence and the pattern library now, so go instrument one behavior and let the trend line make your case.adaptivesecurity.com lorikeetsecurity.com community.trustcloud.ai+22 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.15 pages · 4.0 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.15 pages · 15.4 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.15 pages · 3.9 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.