How to Build a Security Awareness Program from Scratch

Before choosing any training content, run a baseline phishing simulation across the organization and see where things actually stand: overall click rate, reporting rate, and how those numbers vary by department. Skipping this step and jumping straight to a training curriculum almost always results in generic, one-size-fits-all content that spends time on problems the organization may not actually have while missing the ones it does.

Baseline results should be segmented, not just averaged. Finance teams face different attack patterns than HR or IT, and seniority often correlates with different risk profiles, sometimes senior staff are targeted more precisely, sometimes newer staff are less familiar with internal processes attackers try to exploit. Segmenting the baseline by department, role, and seniority tells a security team where to focus first instead of treating every employee identically.

The baseline also becomes the number leadership will compare every future result against, so it is worth documenting the methodology carefully: consistent difficulty tiers, comparable attack types, and a clear record of when the baseline was run. A credible before-and-after story for the board depends on the two measurements being genuinely comparable, not just two numbers that happened to be produced months apart.

Running one phishing simulation a year and calling it a training program does not build the pattern recognition skill that actually reduces risk. Monthly or bi-monthly simulations, spaced out over the year, give people repeated, low-stakes practice at spotting suspicious messages, and spaced repetition is well understood to build durable skills far better than a single concentrated event.

Variety matters as much as frequency. Mixing difficulty levels and attack types across the year, email today, a courier-themed WhatsApp message next quarter, a vishing call after that, keeps the exercise from becoming something people memorize by template rather than genuinely learn to recognize. Varying the sender pretext and the pressure tactic used in each simulation is what keeps the skill general rather than narrow.

At the same time, more frequent is not always better. Simulations run too often, or handled clumsily, create alert fatigue or resentment that undermines the whole program. The better balance is a steady simulation cadence paired with short micro-training modules, five to ten minutes, rather than a lengthy annual course that people click through once a year and immediately forget.

Just-in-time training delivers a short, specific lesson at the exact moment someone clicks a simulated phishing link, while their attention is highest and the mistake is still fresh. That moment is far more valuable for learning than any scheduled training session days or weeks later, because the person is primed to understand exactly what went wrong and why.

This is also why generic annual training tends to underperform. It teaches concepts in the abstract, disconnected from any specific behavior, so the lesson has nothing concrete to attach to. Just-in-time training ties the lesson directly to the exact red flag the person missed in that specific message, which measurably improves retention compared to content delivered on a fixed calendar unrelated to any real event.

The same logic applies to repeat clickers, but the response should escalate in support rather than tone. Someone who clicks repeatedly benefits more from a short coaching conversation with their manager or a slightly more targeted module than from a punitive message. The goal is to close a specific gap in understanding, not to shame someone into compliance.

A program without visible leadership backing tends to stall, since staff treat it as optional and managers deprioritize it. When a senior sponsor, ideally someone at board or executive level, signals that the program matters and personally takes part in simulations, the rest of the organization takes it more seriously. Sponsorship also unlocks the budget and time that a sustained program needs.

The tone leadership sets matters as much as their backing. A program framed as a hunt to catch and punish careless employees breeds fear, and fearful people hide mistakes rather than report them, which is the opposite of what you want. A no-blame tone, where clicking a simulation is treated as a normal learning moment rather than a failure, produces the reporting culture that actually reduces risk.

Be transparent about how simulation data is used. Employees who suspect results will feed into performance reviews or disciplinary action will distrust the whole exercise. Stating clearly that the goal is collective improvement, not individual punishment, and holding to that in practice, is what keeps participation genuine over the long run.

Phishing lures that feel foreign are easy to dismiss and teach very little. In Indonesia, simulations land harder when they mirror real local context: courier and delivery notifications, tax and government-themed messages, HR and payroll announcements, and WhatsApp messages that mimic how colleagues actually communicate.

Language matters as much as scenario. A workforce that primarily reads Bahasa Indonesia should receive training and simulations in Bahasa Indonesia, not English translated at the last minute. Content built bilingually from the start, EN and ID at parity, reaches everyone in the language they think in, which is where genuine recognition of a threat actually happens.

Localization extends to the channels you test. An organization where day-to-day business runs on WhatsApp is not accurately measured by email-only simulations. Reflecting the real mix of email, voice, and messaging in your simulation program gives a truer picture of exposure than any generic, imported template library.

Reporting rate deserves at least as much attention as click rate, arguably more. An employee who reports a suspicious email, even one they almost fell for, shrinks the exposure window for the entire organization during a real attack, because security teams learn about the threat while it is still active rather than after damage is done. Making the reporting button effortless to find and use, and publicly recognizing people who report, reinforces the behavior far more effectively than warning people not to click.

Beyond click rate and reporting rate, a handful of other metrics tell a more complete story: median time to report a suspicious message, the reduction in repeat clickers over successive campaigns, and department-level risk trends over time. Training completion rate, by contrast, is a vanity metric on its own, it says someone opened a module, not that anything changed in how they behave.

When reporting results to leadership, present trends rather than a single snapshot, and connect the numbers to concrete outcomes: falling click rates, rising reporting rates, and the evidence trail that supports compliance reporting for frameworks such as OJK requirements or ISO 27001. Framed this way, the program reads as a measurable risk reduction effort rather than a scorecard designed to catch people out.

A security awareness program is not a project with an end date, it is an ongoing operation. Setting a quarterly review rhythm, where the security team looks at click and reporting trends, repeat-clicker counts, and department-level movement, keeps the program responsive to what the data is actually showing rather than running on autopilot.

Each review should produce concrete adjustments: raising difficulty where results have plateaued, targeting extra support at teams whose trend is worsening, and retiring lures that everyone now recognizes. A program that never changes its templates trains people to spot last quarter's attack, not the next one.

Documenting each review cycle also compounds into the evidence trail that compliance and board reporting depend on. A dated record of what was measured, what was decided, and what changed turns routine operational hygiene into a defensible account of a program that is genuinely improving over time.