7.2 — Competence

In plain language

In plain language: 7.2 requires you to figure out what skills someone actually needs to do work that affects information security, confirm they have those skills through education, training, or experience, close any gaps you find, and keep evidence of all of it.

Why this requirement exists

A control assigned to someone without the skill to run it properly is a control on paper only. This requirement forces organizations to connect roles to actual capability, rather than assuming that a job title implies the competence a security-relevant task demands.

Scenario: a company assigns firewall rule reviews to a junior IT support technician with no network security background, because they had spare capacity. The reviews happen on schedule, technically satisfying a process requirement, but nobody with the competence to spot a genuinely risky rule ever actually looks. 7.2 exists to catch that gap before an incident does.

What the standard expects

The standard expects the organization to determine the necessary competence of people doing work under its control that affects information security performance; ensure those people are competent on the basis of appropriate education, training, or experience; where applicable, take action to acquire the necessary competence and evaluate whether that action worked; and retain appropriate documented information as evidence of competence.

In practice

• Map security-relevant roles (ISMS owner, control operators, internal auditors) to the specific skills each one needs, rather than assuming general IT competence covers it.
• Keep a simple competence record per role: what is required, how it was demonstrated (certification, training completion, years of relevant experience), and when it was last reviewed.
• When a gap surfaces — a new hire, a new tool, an expanded scope — treat closing it as an action with a deadline, not a hope.

Evidence the auditor will ask for

• A competence matrix or role profile linking security-relevant roles to required skills.
• Certifications, training records, or documented experience for the people in those roles.
• Evidence that identified competence gaps were addressed, with an evaluation of whether the action closed the gap.

Common pitfalls

• Assuming a job title ("IT manager") automatically implies the specific competence a security task requires.
• No record of why a person was deemed competent — just an assumption with nothing kept as evidence.
• Training completed once, years ago, with no re-evaluation as tools, threats, or roles change.

Related requirements

Parent link: Clause 7 · Support

Frequently asked questions