Newsletter
The Soft Control That Auditors Eventually Notice
· 11 min read
Every security program has a few controls that everyone likes to call “soft,” usually because they are hard to buy, hard to automate, and hard to summarize in a dashboard.
Competence is one of them.
A firewall can be inventoried. A phishing test can be graphed. A policy can be approved, versioned, and filed. Competence is less cooperative. It appears in the judgment of an administrator deciding whether an access request is wrong, a developer deciding whether a shortcut is safe enough, a manager deciding whether a data use needs escalation, or an executive deciding whether an AI vendor is selling capability or theater.
Because competence is awkward to measure, many organizations quietly demote it to training. Training is then demoted to awareness. Awareness is then reduced to an annual module, a completion report, and the hope that the auditor does not ask a better question.
That is a mistake. The major security, privacy, and AI governance frameworks do not treat human capability as decoration. They use different words: competence, awareness, role-based training, literacy, workforce development, knowledge, skills, abilities, proficiency. But the direction is much the same. A control environment operated by unprepared people is not a control environment. It is a collection of intentions.
This matters to the person running the ISMS. It also matters to the CHRO. For the security officer, competence is evidence: it helps show that responsibilities have been assigned, that people can perform them, that gaps have been found, and that the management system is improving. For the CHRO, competence is leverage: it turns cybersecurity learning and development from a thin compliance ritual into a defensible investment in organizational capability.
The two offices should be having the same conversation more often.
The standards are less vague than the culture around them
ISO 27001 is often discussed as if it were mainly a documentary exercise: policies, risk registers, statements of applicability, access reviews, supplier controls, incident procedures, internal audits. These things are visible. They are also easier to collect before an audit. Yet ISO 27001 is a management-system standard, and management systems require competent people. The organization must know what competence is necessary, ensure that people have it, maintain awareness, and retain evidence. ISO 27002, the companion guidance standard, points in the same direction for the controls that sit around the ISMS, including the human ones.
NIST is blunter. SP 800-53 includes controls for security and privacy literacy training, role-based training, training records, and security and privacy workforce development. Its workforce-development control is especially important because it does not stop at “conduct training.” It points toward the knowledge, skills, and abilities needed for security and privacy duties, role-based training programs, and standards for measuring and building qualifications.
SP 800-50 goes further still. It treats cybersecurity and privacy learning as a managed program, with objectives, assessments, evaluation, metrics, and improvement. The question is not merely whether people sat through training. The question is whether the program changed what the organization can do.
NIST CSF 2.0 says the same thing in a more executive vocabulary. Its Protect function includes awareness and training outcomes: personnel should have the knowledge and skills to perform general tasks with cybersecurity risk in mind, while people in specialized roles should have the knowledge and skills to perform the tasks their roles require. NICE, the NIST workforce framework, supplies the grammar for making this operational. It describes cybersecurity work and learner capabilities in a common language, so that organizations can identify, recruit, develop, and retain talent.
AI governance is moving in the same direction. ISO 42001 gives organizations a management-system structure for AI. The NIST AI Risk Management Framework recognizes that AI risk is shaped by the people who design, deploy, operate, approve, monitor, and govern AI systems. Their competencies, skills, and capacities are part of the risk picture, not a side issue.
Privacy follows the same pattern. A privacy program cannot rest on policy acknowledgments and legal templates alone. People who collect, use, share, retain, delete, analyze, procure, or govern personal data need to know what decisions they are making. They need to know when to stop, when to escalate, and when an apparently routine use of information has become something else.
One can argue over clauses, mappings, audit technique, and the right level of evidence. But the larger point is no longer obscure. The frameworks have already made competence part of the control environment. Many organizations have simply not caught up.
Completion is not competence
The reason so many companies get this wrong is that completion is easy to count.
An employee completed security awareness training. A developer completed secure-coding training. A manager completed privacy training. A privileged administrator completed administrator training. A new AI-use policy was acknowledged by the workforce.
All of that may be useful. None of it proves competence by itself.
A developer can complete secure-coding training and still produce familiar vulnerabilities. A help-desk employee can complete social-engineering training and still be unprepared for a targeted call from someone impersonating a senior executive. A procurement manager can complete vendor-risk training and still treat security as a questionnaire to be forwarded rather than a risk judgment to be made. A business leader can approve an AI tool after a polished demo without understanding the data, monitoring, explainability, or accountability questions that should have come first.
The gap between completion and competence is where much security theater lives.
A better program begins with the work itself. What must this person be able to decide or do? What does good judgment look like in that role? What evidence would persuade a skeptical reviewer that the organization has more than a training transcript?
For some roles, the answer is basic but important. A general employee should know how to recognize and report suspicious activity, handle sensitive information appropriately, and understand the organization’s basic rules. For other roles, the answer is more demanding. A system administrator, incident responder, developer, privacy lead, data owner, procurement manager, or AI product owner carries responsibilities that require more than awareness.
Role-based training exists because role-based risk exists.
The audit file should tell a better story
The weakest audit file says: here are the policies, here are the training slides, here are the completion rates.
The stronger audit file says something different. It explains which roles matter to security, privacy, and AI governance; what responsibilities attach to those roles; what skills and knowledge are required; how the current state was assessed; which gaps were found; what learning plan followed; how improvement was measured; and how the program changed after incidents, audits, exercises, business changes, technology changes, and new risks.
That story is much harder to fake. It is also much more useful.
For the ISMS owner, it connects competence to risk treatment and control operation. For HR and L&D, it connects learning to business resilience and regulatory defensibility. For executives, it makes the budget conversation less sentimental. The issue is not whether the company values employee development in the abstract. The issue is whether the organization has the human capability needed to operate the control environment it claims to have.
That is a different argument. It is also a better one.
HR should not be a bystander
Security teams often complain that the business does not take security seriously. HR teams often complain that compliance training is dumped on them without a real capability model. Both complaints are usually fair.
The answer is not for security to become HR, or for HR to pretend it can define cybersecurity competence alone. The mature model is joint ownership.
Security defines the risks, control responsibilities, and failure modes. Privacy defines the obligations around personal information and the decision points that require escalation. AI governance defines the responsibilities around model selection, data use, human oversight, monitoring, and accountability. HR and L&D translate those requirements into job architecture, learning pathways, assessment methods, records, development plans, and promotion criteria.
This is where the CHRO has more power than many security leaders realize.
If cybersecurity competence remains outside the talent system, it will remain fragile. It will depend on heroic individuals, informal apprenticeships, tribal knowledge, and a few overworked specialists who know how things actually run. When they leave, the control environment leaves with them.
But if competence is built into role definitions, onboarding, manager expectations, career pathways, assessment, and development planning, it becomes part of the institution. That is what management systems are supposed to do: make important things less dependent on memory, luck, and personal virtue.
Start where bad judgment would hurt
A company does not need to boil the ocean. It should start with the roles where poor judgment would do the most damage.
Privileged administrators are an obvious group. So are developers, incident responders, security analysts, data owners, procurement staff, privacy personnel, HR staff handling sensitive information, finance personnel vulnerable to fraud, executives who approve risk, and anyone selecting or deploying AI-enabled systems.
For each group, ask a plain question: what must this role be able to do under real conditions? The administrator must be able to recognize an access request that violates policy. The developer must be able to apply secure-design principles to the software the organization actually builds. The incident responder must be able to distinguish noise from escalation-worthy evidence. The procurement manager must be able to see when a vendor’s security claims are unsupported. The HR leader must be able to recognize when employee data is being used in a way that changes the privacy risk. The executive sponsor of an AI system must be able to ask the questions that separate governed adoption from wishful procurement.
Those are not generic awareness outcomes. They are performance expectations.
Once they are defined, a learning program has something to aim at. Assessment has something to test. Measurement has something to measure. Auditors have something better to review than a completion spreadsheet.
The real compliance case for L&D
There is a weak way to argue for cybersecurity L&D: the standards require training, so we need budget.
There is a stronger way: the standards require a functioning management system, and the management system depends on competent people.
That argument is harder to dismiss. It does not reduce L&D to compliance. It raises L&D to the level of risk management. People are not merely recipients of security instructions. They are operators of the control environment. Their judgment is part of the system. Their gaps are system gaps. Their improvement is control improvement.
This matters more as the burden on employees rises. Security teams are dealing with more tools, more alerts, more suppliers, more identity complexity, more cloud sprawl, more regulatory pressure, and more AI-enabled change. Privacy teams are being asked to govern uses of data that move faster than policy review. Executives are being asked to make technology decisions in markets thick with exaggeration.
In that environment, annual awareness is not a serious answer.
The serious answer is a competence system: defined roles, mapped skills, measured gaps, targeted learning, evidence of improvement, and continual adjustment as the risk environment changes.
Competence is one of the hardest controls to build because it cannot simply be installed. It has to be cultivated, measured, and maintained. That is precisely why it matters.
Policies, frameworks, and privacy notices protect nothing on their own; the people who use them well do.
The audit trail should show that the organization knows this.
The budget should show it too.
Sources and control references
For ISO standards, readers should verify the exact wording in their licensed copy of the standard. ISO’s public pages confirm the scope and purpose of the standards, but ISO standards text is copyright-protected.
ISO/IEC 27001:2022 and ISO/IEC 27002:2022: the relevant ISO 27001 references are Clause 7.2 Competence, Clause 7.3 Awareness, Clause 7.5 Documented information, Clause 9.1 Monitoring, measurement, analysis and evaluation, and Clause 10 Improvement. The most relevant Annex A references are 5.2 Information security roles and responsibilities, 6.3 Information security awareness, education and training, and 6.8 Information security event reporting. ISO describes ISO/IEC 27001 as the ISMS requirements standard and ISO/IEC 27002 as guidance for implementing and improving information security controls.
Source: https://www.iso.org/standard/27001
ISO/IEC 42001:2023: for AI governance, the useful management-system references are Clause 5.3 Organizational roles, responsibilities and authorities, Clause 7.2 Competence, Clause 7.3 Awareness, Clause 7.5 Documented information, Clause 9 Performance evaluation, and Clause 10 Improvement. ISO describes ISO/IEC 42001 as specifying requirements for establishing, implementing, maintaining, and continually improving an AI management system.
Source: https://www.iso.org/standard/42001
ISO/IEC 27701:2025: for privacy management, the relevant references are the standard’s management-system requirements for establishing, implementing, maintaining, and continually improving a PIMS, especially competence, awareness, documented information, performance evaluation, and improvement. ISO describes ISO/IEC 27701:2025 as Information security, cybersecurity and privacy protection — Privacy information management systems — Requirements and guidance.
Source: https://www.iso.org/standard/27701
NIST SP 800-53 Rev. 5: use the Awareness and Training family and selected Program Management controls: AT-2 Literacy Training and Awareness, AT-3 Role-Based Training, AT-4 Training Records, PM-13 Security and Privacy Workforce, and PM-14 Testing, Training, and Monitoring. PM-13 is especially useful for the human-capital argument because it addresses knowledge, skills, abilities, role-based training, and standards for measuring and building individual qualifications.
Source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
NIST SP 800-50 Rev. 1: use this as the primary NIST source for building a cybersecurity and privacy learning program. It supports a lifecycle approach to awareness, training, education, behavior change, metrics, evaluation, and continual improvement. NIST states that the guidance includes suggested metrics and evaluation methods to improve and update the program as needs evolve.
Source: https://csrc.nist.gov/pubs/sp/800/50/r1/final
NIST Cybersecurity Framework 2.0: use PR.AT Awareness and Training. The relevant outcomes are PR.AT-01, general personnel knowledge and skills for cybersecurity-risk-aware tasks, and PR.AT-02, specialized-role knowledge and skills for relevant tasks.
Source: https://www.nist.gov/cyberframework
NIST NICE Framework / SP 800-181 Rev. 1: use this for role-to-task-to-skill mapping. NIST describes the NICE Framework as a common language for cybersecurity work and learner capabilities, intended to help stakeholders identify, recruit, develop, and retain cybersecurity talent.
Source: https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center
NIST Privacy Framework 1.0 Core: use GV.AT-P Awareness and Training and GV.MT-P Monitoring and Review. GV.AT-P covers privacy awareness education and training for the workforce and third parties engaged in data processing so that they can perform privacy-related duties and responsibilities.
Source: https://www.nist.gov/privacy-framework
NIST AI Risk Management Framework 1.0: use GOVERN 2.1, GOVERN 2.2, MAP 1.2, and MAP 3.4. These support the case for defined AI risk roles and responsibilities, AI risk-management training, documentation of AI actors’ competencies and skills, and assessment of operator or practitioner proficiency. The AI RMF specifically references interdisciplinary AI actors’ competencies, skills, and capacities in MAP 1.2.
Source: https://www.nist.gov/itl/ai-risk-management-framework
NIST SP 800-171 Rev. 3: for CUI/CMMC-oriented environments, use 03.02.01 Literacy Training and Awareness and 03.02.02 Role-Based Training.
Source: https://csrc.nist.gov/pubs/sp/800/171/r3/final
NIST SP 800-171A Rev. 3: use this for the assessment side of the argument. The assessment procedures include examination of training materials and records, interviews with personnel responsible for role-based security training, and testing of mechanisms for managing role-based training and awareness.