Security awareness as a control: how do you run an awareness program that auditors accept?
How to run a security awareness program that passes ISO 27001, SOC 2, PCI DSS and GDPR audits: owner, design, population, schedule and evidence.
**Key takeaways.** Treat awareness as a control with an owner, a documented design, a defined population, scheduled operation and retained evidence. Auditors under ISO/IEC 27001, SOC 2, PCI DSS and the GDPR test the same five things. Build the program on the NIST SP 800-50 Rev. 1 life cycle and the evidence falls out of normal operation.
**Key takeaways.** Treat awareness as a control with an owner, a documented design, a defined population, scheduled operation and retained evidence. Auditors under ISO/IEC 27001, SOC 2, PCI DSS and the GDPR test the same five things. Build the program on the NIST SP 800-50 Rev. 1 life cycle and the evidence falls out of normal operation.
Why auditors treat awareness as a control, not a campaign
Most awareness programs are run as communications. Auditors do not test communications; they test controls. A control has a stated objective, an owner, a design that can be read, a population it applies to, a frequency, and evidence that it operated as designed. An awareness program that lacks any one of those fails the test regardless of how good the content is.
Four of the frameworks a Security Awareness Lead is likely to be assessed against say so in their own terms:
- ISO/IEC 27001:2022 lists awareness as Annex A control A.6.3, "Information security awareness, education and training", one of the eight people controls in the 2022 edition (ISO/IEC 27001:2022; control titles per ISO/IEC 27002:2022). A certification auditor samples it like any other Annex A control.
- PCI DSS v4.0 requirement 12.6 requires a formal security awareness program whose intent, in PCI SSC's words, is "that all personnel are aware of the entity’s information security policy and their role in protecting cardholder data" (PCI DSS v3.2.1 to v4.0 Summary of Changes).
- The AICPA Trust Services Criteria place awareness inside the control environment (CC1) and communication and information (CC2) common criteria that every SOC 2 report covers (2017 Trust Services Criteria with revised points of focus, 2022).
- The GDPR makes "awareness-raising and training of staff involved in processing operations" one of the matters the data protection officer monitors, alongside "the related audits" (Regulation (EU) 2016/679, Article 39(1)(b)).
The practical consequence: design the program once as a control, then map it to each framework rather than running a separate campaign for each audit.
What each framework expects you to show
The requirements overlap but are not identical. The table below is what an auditor working from each source will ask for.
| Framework | Clause | What the auditor looks for |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 6.3 | Awareness, education and training delivered to personnel and relevant interested parties, with the control's operation evidenced in the ISMS |
| SOC 2 (TSC 2017, 2022 points of focus) | CC1, CC2 | Management's commitment to competent personnel and internal communication of security responsibilities, with evidence the communication reached its audience |
| PCI DSS v4.0 / v4.0.1 | 12.6.1 to 12.6.3.2 | A formal program; annual review and update; training content that covers phishing, social engineering and acceptable use of end-user technologies |
| GDPR | Article 39(1)(b) | DPO monitoring of awareness-raising and training for staff who process personal data, and the related audits |
PCI DSS is the most prescriptive. Version 4.0 added three sub-requirements: 12.6.2, that the program "is reviewed at least once every 12 months and updated as needed"; 12.6.3.1, that training covers threats to the cardholder data environment "to include phishing and related attacks and social engineering"; and 12.6.3.2, that it covers "acceptable use of end-user technologies". All three were best practice until 31 March 2025 and are now assessed in full (Summary of Changes; PCI SSC, June 2024). PCI SSC has also said that the technical anti-phishing controls in requirement 5.4.1 and the training in 12.6.3.1 are separate requirements; one does not satisfy the other.
Build the program on the NIST SP 800-50 Rev. 1 life cycle
NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program, published in September 2024, replaces the 2003 original and is the most useful single design reference because it is written as a managed life cycle rather than a content guide (NIST SP 800-50r1). It names four phases: plan and strategy; analysis and design; development and implementation; and assessment and improvement. Each phase produces something an auditor can read.
Plan and strategy. Write a program strategy and an operational plan. Name the owner, the sponsor, the audiences, the regulatory drivers, the budget and the reporting method and frequency. NIST expects senior leadership to see "a high-level summary of the CPLP strategic plan, including the goals for and phases of the year-long program". That document is your control design.
Analysis and design. Run a needs assessment. NIST describes the gap as "the difference between the current learning goals (or activities) and the desired state", and expects audiences to be segmented, with role-based content where a work role carries specific risk. Record the population: everyone with a network account is the usual base, with defined sub-populations for people who handle cardholder data, process personal data, or hold privileged access.
Development and implementation. Build and deliver the content. Keep the delivery record per person and per element: who was assigned, when, by which method, whether they completed, and by what deadline. NIST lists "training attendance, performance assessments, and completion rates" as the standard quantitative measures, and expects the tracking method and the consequences of non-completion to be communicated to learners in advance.
Assessment and improvement. Produce an assessment report and review it with senior leadership. NIST specifies its contents: measurements and metrics, regulatory compliance information, and an evaluation of effectiveness drawn from instructor, content and learner feedback. The compliance section answers the questions an auditor will ask: which personnel received the learning element, how participation compares with the target coverage, and whether "individuals in compliance-identified roles met their learning requirements".
The evidence pack auditors accept
Collect these artifacts as the program runs and the audit becomes a retrieval exercise:
- Program charter or strategy, approved and dated, naming the owner and sponsor.
- Population definition with the source of truth (HR system or directory) and the date each list was pulled.
- Content inventory with version, date, the topics covered and the requirement each topic satisfies (for PCI DSS: phishing, social engineering, acceptable use; for the GDPR: handling of personal data).
- Completion records per person, including hire date and completion date for new starters, and the exception list with approvals.
- Policy acknowledgements tied to the current version of the information security policy.
- Annual review record showing what changed in the program and why, dated within the last 12 months.
- Assessment report reviewed with leadership, with minutes or sign-off.
- Phishing simulation results where you run them, reported as trends rather than named individuals.
Two points of failure are common. The first is a population that cannot be reconciled: the training platform says 1,180 people, HR says 1,212, and no one can explain the 32. Reconcile the list before the audit, not during it. The second is a completion rate without a deadline. "94 per cent complete" means nothing unless the design states when completion was due.
Measure behavior, not only attendance
NIST is explicit that program measurement "must go beyond simply achieving compliance" and that the impact on "workforce capabilities, attitude, and behavioral changes must also be measured". Auditors increasingly ask the same question in a different form: how do you know the control is effective, not only that it operated?
Pair each compliance measure with an outcome measure. Completion rate pairs with phishing-simulation click and report rates over time. Policy acknowledgement pairs with the count of acceptable-use incidents. Role-based training for privileged users pairs with the number of access-review exceptions those users generate. Report both in the assessment report, and record what you changed in response. A documented change made because a measure moved is the strongest evidence that the program is a living control.
Running the control in SmartSuite
Treat the program as a control record in Compliance Assessments & Testing: one control, mapped to ISO/IEC 27001 A.6.3, PCI DSS 12.6, the SOC 2 common criteria and GDPR Article 39, with a test schedule, a test procedure that names the evidence above, and a result history. Hold the information security and acceptable-use policies in Policy Management, so that each acknowledgement is linked to the policy version in force at the time, and a policy change triggers a re-acknowledgement task. One set of evidence then serves every assessment.
Key facts
- NIST SP 800-50 Rev. 1 published September 2024; four life-cycle phases; five-phase ADDIE design model (NIST).
- ISO/IEC 27001:2022 published October 2022; awareness is Annex A control 6.3, one of eight people controls (ISO).
- PCI DSS v4.0 published March 2022; v4.0.1 published June 2024 with no requirements added or removed; v4.0 retired 31 December 2024; future-dated requirements, including 12.6.2, 12.6.3.1 and 12.6.3.2, effective 31 March 2025 (PCI SSC).
- PCI DSS 12.6.2: program reviewed at least once every 12 months.
- GDPR Regulation (EU) 2016/679 of 27 April 2016; Article 39(1)(b) names awareness-raising and training of staff involved in processing (EUR-Lex).
- SOC 2 uses the 2017 Trust Services Criteria with points of focus revised in 2022; CC1 and CC2 are common to every report (AICPA).
FAQs
Does an annual e-learning module satisfy ISO/IEC 27001 A.6.3? Only if it is the whole of what the risk assessment says is needed. A.6.3 covers awareness, education and training for personnel and relevant interested parties, and the ISMS must show the control was selected for a reason, operates on a defined population and produces evidence. A single module with no needs analysis, no role-based element and no review record is usually found to be operating but not designed.
How often must PCI DSS awareness training run? Requirement 12.6 treats awareness as an ongoing activity and 12.6.2 requires the program itself to be reviewed at least once every 12 months and updated as needed. Training content must cover phishing, social engineering and acceptable use of end-user technologies. Those three sub-requirements moved from best practice to assessed requirements on 31 March 2025 under v4.0.1.
What evidence does a SOC 2 auditor want for awareness? Evidence that management communicated security responsibilities to the people who hold them and that the communication reached its audience: the program design, the population list, completion records with dates, policy acknowledgements against the version in force, and the review that fed changes back into the program. The common criteria CC1 and CC2 apply to every SOC 2 report whatever trust services categories are in scope.
Who owns awareness under the GDPR, the CISO or the DPO? Both have a role. Article 39(1)(b) gives the data protection officer the task of monitoring compliance, including the assignment of responsibilities, awareness-raising and training of staff involved in processing, and the related audits. The DPO monitors; the organization still has to design and run the program, which in most companies sits with the CISO or the Security Awareness Lead.
Should phishing-simulation results go to the auditor? Yes, as trend data. NIST SP 800-50 Rev. 1 lists "the results of practical exercises" among the quantifiable metrics that demonstrate compliance, and it warns leaders against language such as "users are the weakest link". Report click and report rates by period and population, with the actions taken, and keep named-individual results out of the evidence pack unless a disciplinary process requires them.
Sources
- NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program, September 2024: https://csrc.nist.gov/pubs/sp/800/50/r1/final (PDF: https://doi.org/10.6028/NIST.SP.800-50r1)
- ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection. Information security management systems. Requirements: https://www.iso.org/standard/27001
- ISO/IEC 27002:2022, Information security controls (control 6.3 title): https://www.iso.org/standard/75652.html
- AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022): https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
- PCI SSC, Summary of Changes from PCI DSS Version 3.2.1 to 4.0, Revision 1, May 2022: https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf
- PCI SSC, Just Published: PCI DSS v4.0.1, 11 June 2024: https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1
- PCI SSC, Now is the time for organizations to adopt the future-dated requirements of PCI DSS v4.x: https://blog.pcisecuritystandards.org/now-is-the-time-for-organizations-to-adopt-the-future-dated-requirements-of-pci-dss-v4-x
- Regulation (EU) 2016/679 (General Data Protection Regulation), Article 39: https://eur-lex.europa.eu/eli/reg/2016/679/oj
Related
- Category: Cyber & Technology Risk
- GRC Foundation: Connected GRC for policy owners: connecting policy, controls and training
- GRC Foundation: Control owner evidence guide: what good evidence looks like
- GRC Foundation: Connected GRC for the CISO: turning cyber risk into business risk decisions
- What is: Security awareness training
- Frameworks: ISO/IEC 27001:2022, PCI DSS v4.0.1, AICPA TSC 2017 (2022 POF), EU GDPR
- Products: Compliance Assessments & Testing, Policy Management
- Suite: Compliance Management
Reviewer: to be assigned (security or assurance practitioner with CISSP, CISM or CISA).
Linked Articles
Learn how post-quantum security governance works in Connected GRC by linking cryptographic inventory, assets, vendors, risk, controls, issues, and migration planning.
Use this evidence quality checklist to help control owners submit complete, accurate, period-specific, reviewable evidence for SOX, SOC 2, audit, compliance, and GRC testing.
Learn how to govern vulnerability exceptions and risk acceptance by linking assets, exposure, compensating controls, evidence, approvals, remediation, and dashboards.
Learn the difference between cyber risk quantification and cyber risk management, and how leaders can connect scenarios, assets, controls, issues, risk appetite, and dashboards.
Learn what good GRC evidence looks like for regulators, auditors, and customers, and how Connected GRC links evidence to controls, obligations, issues, audits, and decisions.
Learn what good GRC evidence looks like for control owners, including evidence examples, common rejection reasons, audit-ready standards, and Connected GRC workflows.
Learn how vulnerability management works in Connected GRC by linking vulnerabilities to assets, threats, controls, issues, remediation, vendors, risk, and business impact.
Learn how Cyber Threat Management works in Connected GRC by linking threats, assets, vulnerabilities, controls, incidents, issues, vendors, resilience, and enterprise risk.
Frequently Asked Questions
Answers to the questions readers ask most about this topic.
Evidence management should come after control cleanup because evidence requirements depend on clear controls, scope, owners, frequency, and testing expectations. Automating evidence before control cleanup can accelerate duplicate or low-quality requests.
Control owners should check the control supported, period, scope, population, source system, performer, reviewer, approval, exceptions, remediation evidence, final signoff, and format.
Evidence proves that controls operate. A control without a defined evidence requirement cannot be reliably tested, reused across frameworks, or reported as operating effectively.
Not usually. Customers often need assurance rather than raw internal records. Customer-facing evidence should be current, approved, and safe to share. Sensitive internal evidence should be restricted or summarized where appropriate.
Auditors usually look for evidence that supports the procedure performed, period tested, population reviewed, control objective, exceptions identified, conclusion reached, and remediation or retesting where needed.
A common control framework creates one authoritative control record and maps it to multiple frameworks, obligations, policies, and audits. This reduces separate evidence requests for similar controls and helps teams understand where evidence can be reused.
A screenshot can be good evidence if it shows the relevant system, date, scope, setting, user, or approval. A screenshot without date, system name, context, or reviewer information is often weak.
Control evidence should include the control supported, period covered, population or scope, source system, performer, reviewer, date, exceptions, remediation of exceptions, and approval or conclusion.
Put Connected GRC into action with SmartSuite
Map controls, collect evidence, run assessments, manage remediation, and report readiness - all from a single connected system.