Awareness training is the one ISMS control that every member of the organization participates in — from the CEO to the most junior contractor. It is also the control that most organizations implement most superficially: a thirty-minute annual e-learning module, a policy acknowledgment form, and a completion percentage that looks good on a dashboard.
The standard requires more than completion records. Clause 7.3 requires awareness — meaning staff actually understand their obligations, know how to report incidents, and grasp the consequences of non-compliance. Clause 7.2 requires competence — meaning people with ISMS responsibilities can actually perform those responsibilities. These are not administrative requirements. They reflect the genuine security reality that human error, credential compromise, and insider threats are consistently among the top three attack vectors for Indonesian organizations.
This article covers what a genuinely effective awareness and training program looks like: the three distinct requirements (awareness, competence, and training actions), a complete 11-module curriculum with delivery formats and evidence requirements, a phishing simulation program, a competence framework for every ISMS role, and the KPI dashboard that demonstrates program effectiveness to management and auditors.
Understanding the Three Requirements: Awareness, Competence, and Training
ISO 27001 contains three distinct but related requirements in Clause 7 that organizations frequently conflate. Understanding the difference is essential for designing a program that satisfies all three independently:
| Dimension | Awareness (7.3) | Competence (7.2) | Training (7.2 action) |
| ISO 27001 clause | Clause 7.3 | Clause 7.2 | Clause 7.2 (competence actions) |
| Who it applies to | All staff and relevant contractors | Persons with specific ISMS roles | Same as competence — role-specific |
| Goal | Know the policy, understand their obligations, know how to report incidents | Have the skills and knowledge to perform ISMS responsibilities effectively | Close identified gaps in competence |
| What adequate looks like | Staff can explain the IS policy, know how to report a phishing email, understand data classification | CISO can run a risk assessment; developers can identify security flaws in code; HR staff can execute secure offboarding | Training delivered, effectiveness verified, gap closed and documented |
| Evidence required | Completion records per staff member per policy version; phishing simulation results | Training certificates, qualifications, competence assessments, or documented experience | Training attendance records; pre/post assessment scores; practical demonstration records |
| Common failure mode | Annual e-learning module ticked but staff behaviour unchanged | 'Our team is experienced' — claimed without documented evidence | Training delivered but never verified as effective |
| Practical example | All staff annual security awareness module + UU PDP obligations briefing | ISMS Lead: ISO 27001 lead implementer certificate; developers: OWASP training; HR: secure onboarding procedure training | Developer secure coding training delivered; verified through next SAST scan improvement |
The distinction matters practically. A developer who has completed the general security awareness module is aware — they know the policy and can report incidents. But they are not necessarily competent in their role unless they have also received secure coding training specific to their work. An ISMS Manager who attends a security conference is informed — but may not be competent unless they can demonstrate the specific skills required by their role through a certificate or assessed experience record.
| THE AWARENESS GAP | The gap between 'completed the training' and 'changed their behavior' is where most awareness programs fail. A staff member can score 100% on a knowledge assessment and still click every phishing simulation link they receive. Awareness programs that measure only completion rates are measuring inputs, not outcomes. Effective programs measure behavioral change — phishing click rates, incident report rates, security question response quality — alongside completion. |
Designing for Behavioral Change, Not Compliance
The most effective security awareness programs are designed backwards from the behaviors they want to produce, not forward from the compliance checkboxes they need to tick. The question is not 'what do we need to tell staff?' but 'what do we need staff to do differently after the training?' and then working backward to design the content and delivery format that most reliably produces that behavioral change.
Three design principles consistently produce more behavioral change than traditional e-learning approaches:
- Relevance to the individual's actual work: A customer service representative does not need an in-depth explanation of SQL injection. They do need a realistic scenario about handling a customer who wants to verify their account details over the phone. Tailored content for different roles produces significantly better retention than universal content.
- Learning through simulated consequence rather than instruction: Phishing simulations, social engineering tests, and realistic scenario exercises that show staff what an attack looks like — and what happens if they fall for it — produce more durable learning than passive instruction about attack vectors.
- Psychological safety for reporting: The most important behavior change an awareness program can produce is the willingness to report suspicious activity, incidents, and mistakes without fear of blame. Programs that punish staff who click phishing simulations produce staff who hide suspicious activity. Programs that treat simulation failures as learning opportunities produce staff who report genuinely.
| Cultural signal for Indonesian organizations: The security reporting culture in many Indonesian organizations is strongly influenced by hierarchy — staff are reluctant to escalate security concerns to managers for fear of appearing incompetent or causing problems. Awareness programs must explicitly address this by creating safe, anonymous, or low-friction reporting channels and by demonstrating (through management behavior) that reporting is valued, not penalized. A no-blame reporting culture is not a soft aspiration — it is a measurable security outcome. |
The 11-Module Awareness Curriculum
The following curriculum covers all mandatory ISO 27001 awareness requirements (Clause 7.3), addresses the competence training obligations for specialized roles (Clause 7.2), and is calibrated to the specific regulatory and threat environment of Indonesian regulated organizations. Each module includes content scope, target audience, delivery format, and required evidence:
| ||||||
| ||||||
| Content: Covers: What is information security and why it matters. The CIA triad explained for non-technical staff. Key obligations under the IS policy. What disciplinary consequences look like. How this connects to UU PDP for staff handling customer data. | ||||||
| ||||||
| Content: Covers: The four classification levels (Public/Internal/Confidential/Restricted). How to identify what level applies to information you work with. Handling requirements for each level — storage, sharing, disposal. What personal data is and why it gets special treatment under UU PDP. | ||||||
| ||||||
| Content: Covers: How phishing emails are constructed — urgency, authority, familiarity. Red flags checklist — signs an email is suspicious. What to do when you receive a suspicious email (report, don't click). BEC (Business Email Compromise) scenarios for finance staff. What to do if you clicked — no blame, report immediately. | ||||||
| ||||||
| Content: Covers: What counts as a security incident (broader than staff expect — includes lost devices, wrong emails, suspicious behaviour). Who to report to and how (CISO / IT helpdesk). What happens after you report — no-blame culture. Why reporting matters for UU PDP compliance. The 14-day notification clock starts on discovery, not confirmation. | ||||||
| ||||||
| Content: Covers: Why strong credentials matter — what an attacker can do with your password. Password managers — how to use them, why they are safe. MFA — what it is, why it is required for all accounts. What to do if you suspect your credentials are compromised. Prohibition on credential sharing. | ||||||
| ||||||
| Content: Covers: Tailgating risks and how to prevent them. Visitor management — who can be in secure areas. Clean desk policy — what must be secured when you leave your desk. Device security — lock screen, no unattended devices in public. Reporting lost or stolen devices immediately. | ||||||
| ||||||
| Content: Covers: Home network security — router settings, avoiding public WiFi for work. VPN usage requirements for accessing production systems. Device security at home — no family use of work devices. Secure video call practices — background awareness, no sensitive discussions in public. Physical document security at home. | ||||||
| ||||||
| Content: Covers: What personal data is under UU PDP — broader than staff assume (email addresses, IP addresses count). Staff obligations as data processors. Customer rights under UU PDP — access, correction, deletion. What to do if a customer requests data deletion. What constitutes a personal data breach. Why the 14-day notification matters. | ||||||
| ||||||
| Content: Covers: Why supplier security matters — supply chain attack scenarios. What security requirements apply to our suppliers. Due diligence process for new suppliers. Data processing agreements — what they are, when they are needed. How to identify and report suspicious supplier behaviour. | ||||||
| ||||||
| Content: Covers: OWASP Top 10 current edition — with code examples. Secure coding standards adopted by the organization. Common vulnerabilities in our technology stack specifically. How to use SAST tooling integrated in CI/CD. Security code review checklist. Responsible disclosure for internally discovered vulnerabilities. | ||||||
| ||||||
| Content: Covers: What being a risk owner means — accountability, not just awareness. How to read and interpret the risk register. How to evaluate and approve risk treatment decisions. What residual risk acceptance means and what you are committing to. How to escalate if you disagree with a risk assessment. The annual risk review cadence and what triggers out-of-cycle reviews. |
| UU PDP content priority: In 2026, Module 08 (UU PDP Personal Data Protection) deserves particular attention for Indonesian organizations. UU PDP enforcement has been active since late 2024, and most Indonesian staff — even in regulated industries — have limited understanding of what personal data is under UU PDP, what their obligations are as data processors, and what the 14-day breach notification clock means in practice. A generic 'data protection' module is insufficient. The training must explicitly cover Indonesian law, by article number, in Indonesian language if the staff audience is Indonesian-speaking. |
The Phishing Simulation Program
Phishing simulations are the closest thing to a controlled experiment for measuring security awareness effectiveness. They provide behavioral data — not self-reported understanding, but observed behavior in a realistic scenario — that completion records cannot provide. For ISO 27001, phishing simulation results serve as evidence of awareness program effectiveness, supporting both Clause 7.3 (awareness of consequences) and Clause 9.1 (performance monitoring).
An effective phishing simulation program follows six phases — from initial design through to trend reporting at management review:
| Phase | Details | Timing |
| Simulation Design | Create a realistic but detectable phishing scenario relevant to your sector. Financial services staff: fake wire transfer authorization request. General staff: fake IT helpdesk password reset. Do not use scenarios so sophisticated that no reasonable person would detect them — the goal is learning, not entrapment. | 2 weeks before send |
| Baseline Measurement | Send first simulation with no prior warning. Record: click rate, credential submission rate, report rate. This baseline shows current susceptibility before the training program begins. Target: establish a starting point, not to fail staff. | Month 1 |
| Immediate Feedback | Staff who click receive an immediate, non-punitive educational intervention — a short explanation of the phishing indicators they missed, what the real consequences would have been, and what they should do next time. This is the most effective learning moment. | Immediately on click |
| Targeted Training | Staff who clicked the simulation (or a defined percentage of highest-risk roles) receive targeted training within 2 weeks. More specific, more interactive, and shorter than the general awareness module. | Within 2 weeks of simulation |
| Re-simulation | Run a follow-up simulation 6–8 weeks after the training. Use a different scenario — same technique, different context. Measure whether the click rate has improved. Document the comparison as evidence of training effectiveness. | 6–8 weeks after training |
| Trend Reporting | Compile quarterly simulation results showing click rate trend, report rate trend, and time-to-report for suspicious emails. Present at management review as an ISMS KPI. Target: click rate below 5% and trending down; report rate above 40% and trending up. | Quarterly reporting |
Target metrics to report at management review: Click rate below 5% (measured quarterly); report rate above 40% (measured quarterly); time-to-report below 2 hours for staff who do report. These targets are aspirational in year one — the realistic trajectory is significant improvement between baseline and 12-month remeasurement rather than immediate target achievement.
| Non-punitive culture note: The strongest evidence that a phishing simulation program is working as designed is an increase in report rate alongside a decrease in click rate. If report rate is not moving upward, staff are encountering suspicious emails but choosing not to report them — which is the more dangerous behavioral pattern. The awareness program should explicitly communicate: 'If you clicked, tell us immediately. No consequences. We want to know.' |
Competence Framework for ISMS Roles
Clause 7.2 requires that persons whose work affects information security performance are competent, and that competence is evidenced through retained documented information. The competence framework below maps specific competence requirements and acceptable evidence for six key ISMS roles. 'Competence' is defined as the demonstrated ability to apply knowledge and skills to achieve intended results — not simply the completion of a training course.
| ISMS Role | Required competence | Acceptable evidence | Review trigger |
| ISMS Manager / CISO | ISO 27001 Lead Implementer qualification (or equivalent demonstrated experience). Risk assessment methodology mastery. Annex A controls knowledge. Indonesian regulatory framework (UU PDP, POJK, PBI, BSSN). Internal audit fundamentals. | Lead implementer certificate; auditor certificate; CPE/CPD log (minimum 20 hours annually); verified experience record reviewed by management. | Annual competence review. Triggered by major standard revision or regulatory change. |
| IT Security Engineer | Technical security controls in scope (firewall, SIEM, endpoint protection, identity management, vulnerability management). Cloud security for deployed platforms (AWS/GCP/Azure as applicable). Incident response technical procedures. Secure configuration management. | Technical certifications (CISSP, CEH, CompTIA Security+, AWS Security Specialty, etc.); training attendance records; technical assessment; hands-on evidence (system configurations, tool outputs). | Annual. Triggered by technology platform change or new security tool adoption. |
| Internal Auditor | ISO 27001 requirements (full Clauses 4–10 + Annex A). Internal audit methodology — evidence collection, sampling, finding classification. Independence requirements. Corrective action assessment. Nonconformity writing. | ISO 27001 internal auditor certificate (IRCA, BSI, or equivalent). At least one observed and one lead audit documented. Sample audit reports demonstrating competent finding identification. | Annual. Triggered by major standard revision. |
| Risk Owner (Business Manager) | Information security risk concepts. How to read and interpret the risk register. Risk treatment decision-making. Residual risk acceptance obligations. Escalation process when disagreeing with risk assessment. | Annual risk owner briefing attendance record. Signed risk acceptance documents from current risk register. Does not require formal certification — adequate awareness evidenced through active participation. | Annual at risk owner briefing. |
| HR — Secure Onboarding/Offboarding | Security obligations in employment contracts. Background check process and requirements. Security onboarding checklist — what triggers LMS enrollment, policy acknowledgment, and system access request. Offboarding access revocation SLA (4 hours) and how to execute it. | HR security responsibilities training attendance. Completed onboarding and offboarding records demonstrating procedure execution. Knowledge check on offboarding SLA. | Annual. Triggered by procedure change. |
| Software Developer | OWASP Top 10 current edition. Secure coding standards adopted by the organization. How to use SAST tooling in CI/CD pipeline. Secrets management requirements. Security considerations in pull request review. Responsible disclosure process. | Secure coding training completion. OWASP awareness assessment score (minimum passing threshold defined). SAST tool usage evidence from CI/CD logs. Participation in security code review. | Annual. Triggered by new technology stack adoption or significant new vulnerability class emergence. |
The competence framework should be reviewed annually and updated when ISMS roles change or when the technical environment shifts significantly — such as when a new cloud platform is adopted or when a major regulatory framework changes. The ISMS Manager's competence is the most critical to maintain current: an ISMS Manager whose knowledge of ISO 27001 is based on the 2013 version and who has not reviewed the 2022 changes is not adequately competent for the current standard.
Evidence Management for Clause 7.2 and 7.3
The evidence requirements for Clause 7.2 and 7.3 are among the most directly testable in an ISO 27001 audit — auditors routinely select staff members and ask to see their training records and competence evidence on the spot. Evidence management must be systematic, not reactive.
What to retain and for how long
- Training completion records (LMS exports): Retain indefinitely while employee is in role + 3 years after departure. Must show staff name, course title, completion date, and version/edition of content.
- Policy acknowledgment records: Retain for each version of each policy — indefinitely while policy is active + 3 years after policy supersession. Must link to specific document version.
- Phishing simulation results: Retain quarterly results indefinitely while program is active. Trend data across simulation cycles is more valuable than individual results.
- Competence records (certificates, training records): Retain while person is in ISMS role + 3 years after role change or departure.
- Risk owner briefing attendance: Retain for each annual briefing cycle + 3 years. Include briefing agenda and signed attendance list.
Making evidence audit-ready
Auditors conducting a sampling exercise for Clause 7.2 and 7.3 will typically select 5–8 staff members and ask for their training records. The evidence must be producible within the audit session — not 'we have records but we'll need to search for them'. Evidence should be organized in the GRC platform or LMS with search capability by staff member, by module, and by completion date.
| The evidence completeness test: Before the Stage 2 audit, run an evidence completeness check against the full staff register for your ISMS scope. For every staff member: (a) Annual security awareness module completed for current policy version? (b) UU PDP training completed (if they handle personal data)? (c) Role-specific competence evidence on file? (d) Policy acknowledgment for current IS Policy version? Any gaps found in this check are gaps an auditor would find. Fix them before audit day, not during it. |
Common Awareness Program Failures
The table below maps the six most common awareness program failures in ISO 27001 implementations, with their audit impact, why they happen, and how to fix them:
| Common failure | Audit impact | Why it matters | Fix |
| Annual e-learning ticked but behavior unchanged | Nonconformity likely | Not a direct nonconformity — but phishing simulations that show a static 20% click rate for three years indicate the program is not working. Auditors will ask about effectiveness measures. | Add behavioral measures: phishing simulation click rate, incident report rate, security question pass rate. If behavior isn't improving, change the training content or delivery format, not just the completion target. |
| Contractors excluded from awareness program | Minor NC likely | Clause 7.3 applies to 'persons doing work under the organization's control' — contractors are in scope. Excluding contractors is a common nonconformity, especially for organizations with large contractor workforces. | Ensure contractor onboarding includes security awareness. Maintain completion records for contractors separately from employee records. Include contractors in phishing simulations. |
| New joiners trained after 90+ days | Minor NC likely | New staff represent the highest awareness risk in their first weeks. Extended delays between joining and security training are minor nonconformities and represent genuine security exposure. | Automate LMS enrollment via HR system trigger on new hire record creation. Set mandatory completion within 30 days. Include security awareness in Day 1 onboarding package. |
| Phishing simulation results show click rate above 15% consistently | Observation | Persistently high click rates signal that the current training is not effective. Auditors will question whether the awareness program is achieving its purpose. Not a direct nonconformity but a significant ISMS effectiveness concern. | Redesign training for the groups with highest click rates. Increase simulation frequency. Provide targeted intervention for persistent clickers. Consider whether delivery format needs to change. |
| Training records not retained or incomplete | Observation | Direct Clause 7.2/7.3 nonconformity. If auditors sample five staff and cannot find training records for one of them, that is an immediate finding regardless of overall completion rates. | Use an LMS that automatically generates and retains completion records. Export and archive records annually. Retain for minimum 3 years per document retention schedule. |
| Training content not updated when regulations change | Observation | Observation at minimum — auditors may note that UU PDP content has not been updated since initial implementation despite regulatory developments. Signals ISMS is not keeping pace with the environment. | Include awareness training content in the annual policy review cycle. Assign a content owner who monitors regulatory updates. Update within 60 days of significant regulatory change. |
The common thread across these failures is the same dynamic seen in policy development failures: the program was designed to satisfy a requirement rather than to produce a security outcome. Annual completion rates look good on a dashboard but tell management nothing about whether the organization is more or less vulnerable to the human-vector attacks that training is supposed to address.
Awareness as the Most Scalable Security Control
The security controls that have the highest coverage and lowest cost per unit of risk reduction in most organizations are not technical controls — they are awareness controls. A staff member who recognizes a phishing email and reports it before clicking stops an attack chain that MFA, endpoint protection, and SIEM alerts might or might not catch. A developer who writes secure code eliminates a vulnerability class that application penetration testing and SAST scanning can only detect, not prevent.
This is the investment case for a genuine awareness program. Not because ISO 27001 requires it — that is a compliance argument. But because human behavior is both the largest attack surface and the most addressable vulnerability in most organizations. A phishing click rate that moves from 24% to 4% over twelve months of a well-designed program represents a more significant reduction in real-world risk than most technical controls can achieve in the same period.
Design the program for the behavioral outcome. Measure it honestly. Improve it when results plateau. That is what Clause 7 is designed to produce — and what actually makes organizations safer.