ISO 27001 Clause 7.2: Competence

Clause 7.2 requires your organization to ensure that everyone doing work that affects information security performance is competent to do it. This goes beyond just hiring qualified people - it means defining what competence each role needs, assessing whether people meet that bar, closing gaps through training or other actions, and keeping evidence that you did all of this. Without Clause 7.2, your ISMS roles are assignments on paper with no guarantee the people filling them can actually deliver.

What the clause requires

ISO 27001:2022 Clause 7.2 sets out four specific requirements:

a) Determine the necessary competence of persons doing work under the organization’s control that affects information security performance.

b) Ensure those persons are competent on the basis of appropriate education, training, or experience.

c) Where applicable, take actions to acquire the necessary competence and evaluate the effectiveness of those actions.

d) Retain documented information as evidence of competence.

Two things worth noting. First, the clause applies to anyone whose work affects information security - not just the security team. Developers writing code, system administrators managing infrastructure, HR staff handling employee data, and the ISMS manager all fall within scope. Second, the standard accepts three routes to competence: education, training, or experience. A senior engineer with ten years of infrastructure security experience does not need the same training as a junior developer joining their first role.

How to define and build competence

Map competence requirements to roles

Start with the roles you defined under Clause 5.3 and ask: what does each person need to know to fulfill their information security responsibilities?

For a 20-person SaaS company, competence requirements typically look like:

• ISMS manager: Understanding of ISO 27001 requirements, risk assessment methodology, internal audit processes, and how to report to leadership. Often demonstrated through a lead implementer or lead auditor certification, or equivalent experience from a previous implementation.
• Developers: Secure coding awareness (OWASP Top 10), understanding of access control principles, knowledge of the organization’s change management and code review processes.
• System administrators / DevOps: Secure configuration of cloud infrastructure, logging and monitoring setup, backup and recovery procedures, vulnerability management.
• All employees: Recognizing phishing attempts, secure password practices, incident reporting procedures, understanding of the information security policy.

You do not need a 50-page competence framework. A simple table mapping roles to required competencies is enough for most organizations.

Assess gaps and take action

Once you have defined what competence each role needs, compare it against what people actually have. This is where you identify gaps - and Clause 7.2 requires you to close them.

Common actions include:

• Formal training - ISO 27001 lead implementer for the ISMS manager, secure coding training for developers, cloud security certifications for infrastructure staff
• On-the-job mentoring - pairing junior staff with experienced colleagues during incident response or risk assessments
• Self-directed learning - access to platforms like SANS, Pluralsight, or vendor-specific security training
• External expertise - a vCISO or consultant to provide hands-on guidance while building internal capability

The standard also requires you to evaluate whether your actions worked. If you sent someone on a secure coding course, did their code review findings improve? If you ran phishing simulations after awareness training, did click rates drop? Evaluation does not have to be elaborate, but it should exist.

Retain evidence

Clause 7.2 explicitly requires documented evidence of competence. Auditors will ask for it. Practical evidence includes:

• Training certificates and course completion records
• CVs or resumes showing relevant qualifications and experience
• Records of internal training sessions with attendance lists
• Results from competence assessments or security knowledge tests
• Phishing simulation results showing improvement over time
• Professional certifications (ISO 27001 Lead Auditor, CISSP, AWS Security Specialty, etc.)

Keep this organized and accessible. A shared folder or your compliance platform works - you do not need a dedicated training management system unless the organization is large enough to justify one.

Connecting 7.2 to the rest of your ISMS

Clause 7.2 sits between resources and awareness, and the three clauses work together. Resources provide the budget for training. Competence ensures the right people have the right skills. Awareness ensures everyone else understands their baseline responsibilities.

Clause 5.3 connection. Roles and responsibilities define who does what in the ISMS. Clause 7.2 ensures the people assigned to those roles can actually perform them. Assigning someone as a risk owner without ensuring they understand risk assessment methodology is a gap.

Clause 7.1 connection. Resources include the training budget needed to develop competence. If leadership commits to the ISMS under Clause 5.1 but provides no training budget, Clause 7.2 cannot be satisfied.

Clause 7.3 connection. Awareness covers what all employees need to know about information security - the policy, their contribution to the ISMS, and the consequences of not conforming. Competence goes deeper: it is the specific skills and knowledge required for people whose work directly affects security outcomes.

Clause 6.1 connection. Your risk assessment may identify competence-related risks - for example, a single point of failure where only one person understands a critical security function. The treatment for that risk is a competence action: cross-training, hiring, or documentation.

What auditors check

Auditors treat Clause 7.2 as evidence that your ISMS is operated by people who know what they are doing.

Competence requirements documentation. Auditors expect to see a record of what competence each information security role requires. This does not need to be a formal competence matrix - but there should be something that shows you have thought about what skills each role needs.

Evidence of competence. For each person in an information security role, auditors ask for evidence that they meet the competence requirements. This is where training certificates, CVs, and assessment records come in. If the ISMS manager has no ISO 27001 training and no prior implementation experience, auditors will question how they can ensure the ISMS conforms to the standard.

Gap closure actions. If you identified competence gaps, auditors want to see what you did about them. Did you arrange training? Hire someone with the right skills? Bring in external support? And did you evaluate whether those actions worked?

Training records completeness. Auditors sample training records across the organization. If your awareness training shows 60% completion, that is a finding - not because the training content is wrong, but because 40% of people have not demonstrated the baseline competence the ISMS requires.

Consistency with actual capability. Auditors interview people in security roles and ask practical questions. If someone is listed as the risk owner for cloud infrastructure but cannot explain how risks are assessed or what controls are in place, that is a competence gap regardless of what certificates they hold.

Common mistakes to avoid

Treating competence as a one-time activity. Competence requirements change as the organization evolves - new technologies, new threats, new regulations. A developer competent in on-premises security may need new skills after a cloud migration. Review competence requirements at least annually and after significant changes.

Confusing awareness with competence. Awareness training (Clause 7.3) is necessary but not sufficient for Clause 7.2. Showing everyone a 20-minute phishing awareness video does not make your ISMS manager competent to run risk assessments. Competence requires deeper, role-specific skill development.

No evaluation of training effectiveness. Sending people on courses and collecting certificates satisfies the letter of the clause but misses the intent. The standard requires you to evaluate whether actions to acquire competence actually worked. Track whether training translates into better outcomes - fewer misconfigurations, faster incident response, improved risk assessment quality.

Ignoring contractors and third parties. If your ISMS scope includes work performed by contractors or outsourced teams, their competence matters too. You do not need to train them directly, but you need evidence that they have appropriate competence - through contractual requirements, certifications, or capability assessments.

Over-engineering the framework. A 15-person startup does not need a formal competence management system with detailed skill matrices for every employee. A simple table of roles, required competencies, and evidence is enough. Scale to your organization’s size - auditors expect proportionate effort, not enterprise bureaucracy.

How 27kay can help

We help organizations define competence requirements that match their risk profile and team structure - practical frameworks auditors accept without unnecessary overhead. As part of ISO 27001 implementation, we set up the competence documentation, identify gaps, and recommend training that addresses them. For organizations that need ongoing security leadership, our vCISO service brings the competence your ISMS needs without a full-time hire. For the full picture, see our ISO 27001 knowledge hub.

Not sure whether your team has the competence auditors expect? Get in touch - we will assess your current capabilities and tell you exactly where the gaps are.