ISO 27001 Clause 7.2: proving competence, not just attendance

The auditor asks how you know your platform engineer can handle a live incident. You hand over a training attendance log, which proves they sat in the room and nothing more.

This guide shows how to meet ISO 27001 Clause 7.2 with evidence that survives a live interview. It covers role baselines built on your real stack, a working competency matrix, effectiveness checks, contractor gates and the automation that keeps it all current. It is written for security managers and lead implementers at regulated and tech firms of 25 to 250 people.

What does ISO 27001 Clause 7.2 require of the people behind your ISMS?

ISO 27001 Clause 7.2 requires you to decide the competence each security-relevant role needs and make sure the people in those roles have it, through education, training or experience. You close any gaps, check the fix worked and keep records as proof. Attendance alone proves presence, not capability, so auditors look for verified skill.

The clause breaks into four duties you can work through in order:

• Determine. Decide what competence each role touching your information security management system (ISMS) needs.
• Ensure. Satisfy yourself that the holder has it, through education, training, experience or a mix.
• Act and evaluate. Close any gap deliberately, then check the fix worked.
• Record. Keep documented evidence of all three.

The scope is wider than the security team. Any role whose work shapes a security outcome falls inside: the engineer who writes the deployment pipeline, the administrator who sets storage permissions, the manager who approves access. This is the capability half of a pair. Clause 7.1 asks whether the people and hours exist at all, and Clause 7.3 covers what everyone must understand.

The reason is practical. Most incidents blamed on technology are competence failures in disguise: the misconfigured storage bucket, the over-permissive role, the incident response that made things worse. For a firm of this size the clause forces a healthy decision. You cannot employ every specialism, so you either grow it or buy it in knowingly, rather than discover the gap mid-incident.

The NCSC Cyber Assessment Framework Principle B6 Staff awareness and training makes the same point. Measuring training only by the number of people reached falls short of the principle. Training should give people the cyber security skills their job role needs, based on how they really work with the systems.

How is Clause 7.2 competence different from Clause 7.3 awareness?

Clause 7.3 awareness is universal: everyone understands the security policy, their part in it and the consequences of ignoring it. Clause 7.2 competence is role-specific: the people doing security-relevant work can show they do it well. Awareness is about knowing the rules; competence is about being good at specific things.

Take an 80-person fintech. Every employee needs to know not to share credentials and how to report a suspicious email: that is awareness. Only the platform team needs to design identity policies that hold up under review: that is competence.

The evidence differs too. Awareness leaves briefing records and policy acknowledgements. Competence leaves a role baseline, an assessment against it and a check that training changed something.

The muddle happens when one annual all-hands module is filed under both clauses. Awareness evidence then passes for competence until the first request for a role-specific assessment exposes it. Run the two programmes side by side, but keep their records apart.

How do you set role-specific competencies for engineering, cloud and operations?

Write a short skills baseline for each role family that reflects your actual stack. That means secure development for engineers, cloud configuration for the platform team, incident handling for whoever is on call, data protection for anyone touching personal data. One page per role family is enough, anchored in job descriptions and clause 5.3 role assignments.

Build each baseline in four moves:

1. Start from the duties. Pull security responsibilities from job descriptions and your clause 5.3 role assignments, using a simple accountability matrix to settle who owns what.
2. Name the role families. Engineering, platform and cloud, operations and on-call, and anyone handling personal data cover most firms of this size.
3. List skills against your real stack. For the platform team that might be identity and access policy design on your cloud provider, infrastructure-as-code review and log configuration.
4. Set a required level. Say what good looks like, for example "can lead containment of a compromised credential unaided".

The NCSC 10 Steps to Cyber Security: Engagement and training gives the same order of work. Understand and prioritise the knowledge and behaviours people need before you develop or buy any training. A baseline built from your stack tells you which courses are worth the money and which are generic off-the-shelf filler.

A CV records what someone could do when they joined. The engineer hired for deep AWS experience three years ago may now run Kubernetes workloads they have never configured. Job titles drift in the same way, so assess against the stack you run today, not the one on the CV.

How do you build a competency matrix and close capability gaps?

A competency matrix lists each role, the required level, the current level and the action closing any gap. Close gaps by the cheapest fast route: a course, mentoring, reassigning the work, or hiring or contracting skills in. Then reopen the assessment whenever the stack, a role or an incident changes the picture.

Each matrix row holds five things:

• Role and skill, such as platform engineer and incident containment.
• Required level, taken from the baseline.
• Current level, assessed honestly rather than inferred from seniority.
• Closing action, with a named owner and a date.
• Effectiveness check, so the row ends in evidence rather than intent.

Clause 7.2 accepts four routes to close a gap: training, mentoring from a stronger colleague, moving the work to someone who can do it, and hiring or contracting the skill in. If you cannot justify a full-time specialist, a fractional CISO covers a senior-competence gap. A flexible bank of vCISO, DPO, analyst and audit skills covers the rest, matched to the task rather than a single hire.

Reopen the assessment when any of these happens:

• Platform migration, such as a move between cloud providers or into containers.
• New tooling that changes how security work is done.
• Promotion or transfer into a security-relevant role.
• Post-incident review that exposes a weakness.

A competency matrix nobody has touched since the last platform migration describes a company that no longer exists.

An annual sweep catches these events months late. Tie the reassessment to the change itself, so the migration ticket closes only when the affected role families have been re-scored.

Track each closing action to completion in the same matrix, with its budget line beside it. Auditors ask for the training plan and its budget because they show the gaps you found were resourced.

A gap you identified and never funded stops being analysis. It becomes evidence against you.

How do you prove training actually worked?

Prove training worked with an observable signal beyond attendance. That could be a post-course assessment with a pass mark, performance in an incident exercise, supervisor sign-off, or a measurable drop in configuration errors. Course completion shows someone watched; an effectiveness check shows something changed. Auditors increasingly test this step, and firms often miss it.

The ICO Data Protection Audit Framework on Training and Awareness expects an assessment at the end of training to test understanding, which could include a minimum pass mark. A pass mark gives the quiz a defined failure condition. Without one, a quiz is decoration.

Match the signal to the skill. Knowledge suits an assessment, judgement under pressure suits an exercise, and day-to-day craft suits a supervisor's sign-off. Pick one primary signal per role and record the result against its matrix row. The table below compares five options.

Ask of every line in your training plan: what would we see if this had worked? If the answer is nothing observable, the line is not yet a control. Add the signal before you buy the course.

Do contractors and third-party suppliers fall under Clause 7.2?

Yes. Anyone working under your direction whose output affects security sits inside Clause 7.2, whatever their employment status. Contractors, consultants and outsourced developers need their competence checked before access is granted, with qualification expectations written into the contract. Contractor competence gaps are among the most common audit findings.

Run a pre-access check in three parts:

1. Define the expectation. State the skills the work needs, using the same baseline as employees in that role family.
2. Verify before access. Check qualifications or demonstrable experience, and keep the vetting record.
3. Write it into the contract. Include the qualification expectations and your right to see evidence of them.

For an outsourced team, ask the supplier for competence evidence per named individual and hold it in your matrix beside employees. A supplier's general assurance about its staff does not tell an auditor who touched your production environment.

The usual failure is one of ownership, not technology. Procurement signs the contract, engineering grants access, and nobody owns the competence check in between. The gate described in the automation section below closes that gap.

What do certification auditors test for Clause 7.2, and where do firms fail?

Auditors pull a couple of security-relevant roles end to end, from baseline through assessment, gap action and effectiveness check. They also interview staff live, asking them to walk through their procedures. Roles that plainly affect security but have no defined requirements grade major. Missing effectiveness evidence, unfunded gaps or unvetted contractors grade minor, adding up to major as a pattern.

Expect these questions, and have the matching evidence ready:

• "How did you decide what skills this role needs?" Show the job description and the role baseline.
• "Show me how this engineer was assessed against that baseline." Show the matrix row with required and current level, plus the assessment record.
• "You ran training in the spring. How do you know it worked?" Show the score, exercise result or sign-off from your effectiveness check.
• "What checks were done on this contractor before they got access?" Produce the vetting record and the contract clause that required it.
• "You migrated platforms last year. What did that do to your competency requirements?" Show the reassessment the migration triggered.

The live interview is what makes this clause distinctive. Staff are asked to walk through procedures they are supposed to operate, so the owner of incident handling should be able to describe it unprompted. A ten-minute conversation tests what a folder of attendance certificates cannot, and a rehearsal in a team meeting costs almost nothing.

Grading follows certification-body practice. Each minor finding is survivable alone, but the same weakness across several sampled roles reads as a pattern and adds up to major. Fix the process that produced the gap, not just the sampled example.

Assemble your ISO 27001 7.2 evidence pack before the audit:

• The competency matrix with roles, required levels, current state and closing actions
• Job descriptions carrying explicit security responsibilities and qualification criteria
• Certification and training records with dates, so currency is visible
• The training plan and its budget
• Effectiveness checks: assessment results, exercise performance, supervisor sign-offs
• Development logs and internal assessment results for key security roles
• Contractor vetting records and the contract clauses that required them

How can you automate competence tracking with HR, LMS and contractor gates?

Join the competency matrix to your HR system so a new hire or role change opens an assessment task automatically. Pull effectiveness evidence from the LMS, incident exercises and pipeline error rates. Raise alerts before certifications lapse, and block contractor access until competence evidence is uploaded. The control then enforces itself.

Four automations do most of the work:

• Matrix joined to HR. Competency records keyed to the HR system mean a role change opens a task, instead of waiting for the annual sweep.
• Effectiveness from live signals. An LMS webhook posts assessment scores to the matrix row, and exercise results and pipeline error rates arrive from systems you already run.
• Expiry as an event. A certification or mandatory-training lapse alerts the owner before it becomes a finding.
• Contractor gate. The onboarding workflow refuses to grant access until competence evidence is attached.

Humans keep the judgement calls: setting the required level, deciding whether an exercise performance was good enough, signing off a supervisor assessment. If you automate only two things first, choose the HR join and the contractor gate, because they remove the most manual chasing.

Done this way, the evidence builds as a by-product of how the firm already works, and the audit sample becomes a read-out rather than a rehearsal.

Frequently asked questions