ISO 27001 Auditors Stopped Accepting a Folder of Certificates. Here's What Clause 7.2 Actually Wants Now
November 11, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.
If your ISO 27001 audit binder still contains a folder of old certificates with no link to current roles, you have a Clause 7.2 problem. Auditors now expect documented, role-specific, current proof that the people running your information security management system are competent, not a static archive of credentials nobody has checked against actual job duties in three years.
What does ISO 27001 Clause 7.2 actually require?
Clause 7.2, titled Competence, is one of the few mandatory human-factor requirements in the standard, and it is checked at every certification and surveillance audit. The clause requires organizations to determine the necessary competence of people whose work affects information security, ensure they are competent through education, training, or experience, take actions to fill gaps, evaluate effectiveness, and retain documented evidence of competence. That is five distinct obligations, not one line item, and auditors test all five separately.
The practical failure point is the last one: retaining evidence. For years, many ISMS programs treated this as satisfied by scanning a certificate into a shared drive. That no longer passes. Auditors conducting ISO 27001:2022 reviews now expect a living proof-chain showing, for every individual who touches the ISMS, that their competence is mapped, current, and owned, extending from IT through HR, legal, operations, support staff, and contractors. A certificate in a file with no connection to a defined role and no refresh cycle is treated as weak evidence, not a closed finding.
Why are auditors rejecting evidence that used to pass?
Because the standard separates two different things that most programs conflate: defining what competence a role needs, and proving a named person holds it today. Auditors have learned to probe both. They will check whether the required competencies are defined for particular job roles and whether the relevant people are trained for those competencies, which means a job description that says "security experience preferred" will not satisfy a reviewer looking for a stated requirement tied to a specific credential or skill.
This shift tracks a broader pattern across frameworks, not just ISO 27001. SOC 2 auditors reviewing Common Criteria 2.2 now expect demonstrated competence through behavioral change, not just attendance, meaning a completion log by itself is treated as insufficient. Training and competence evidence has become documented information auditors actively sample, reviewed at both the Stage 1 documentation check and the Stage 2 certification audit under Clauses 7.2 and 7.3. If your evidence trail cannot survive a sampled drill-down to one person's file, it is not evidence, it is paperwork.
What counts as acceptable Clause 7.2 evidence today
The standard itself does not name certifications, but auditors treat professional certifications as strong, fast-to-verify proof precisely because they come with dated issuance, defined renewal cycles, and third-party validation the auditor does not have to build from scratch. Accepted documentation includes training certificates, records of on-the-job training, professional certifications, and documented performance reviews, since ISO 27001 mandates retaining documented information as evidence of competence without dictating the exact form that evidence takes.
Where this gets specific is the renewal requirement. A one-time credential earned five years ago is weaker evidence than one with an active continuing education cycle, because the auditor's underlying question is whether the person is competent now, not whether they once passed an exam. That is why programs increasingly track renewal activity as part of the audit file itself, treating a lapsed credential the same way they would treat an expired policy acknowledgment.
| Evidence type | What an auditor checks | Why it holds up |
|---|---|---|
| Role-competency requirement | Is the skill or credential named in the job description, not implied | Shows Step 1 of Clause 7.2 was actually done |
| Certification record | Issue date, renewal date, issuing body | Third-party verified, dated, hard to fabricate |
| CPE or CPD log | Continuing education tied to the credential | Proves competence is current, not historical |
| Role-to-person mapping | Named individual linked to named role and named requirement | Closes the loop an auditor samples first |
Building that mapping is exactly the kind of control-documentation discipline covered in a governance, risk, and compliance curriculum, and it is worth treating as a program deliverable rather than an audit-week scramble. If you are responsible for standing up this kind of evidence trail, ISC2's CGRC certification is built around exactly this skill set: translating control requirements like Clause 7.2 into documented, auditable authorization and competence packages that hold up under review.
The executive accountability case, not just the audit case
This is not only an audit-readiness problem. When a security incident traces back to a role that was never properly staffed with competent people, Clause 7.2 documentation becomes the record regulators and auditors use to determine whether the failure was a one-off or a governance gap. A company that can show a named, credentialed owner for every ISMS-affecting role has a materially different conversation with an auditor, a regulator, or opposing counsel than one that can only produce a generic training roster.
The same logic is showing up outside ISO 27001. Defense contractors now face DoD clauses requiring them to have and maintain a current CMMC status at the required level for each relevant information system for the life of the contract, which makes maintained status, not a one-time assessment, the ongoing obligation. Whether the framework is ISO 27001, SOC 2, or CMMC, the direction is the same: assessors want to see that competence is owned by a specific person and kept current, not asserted once and left to go stale.
For a CISO or compliance lead building this program, the fastest fix is not a new policy document. It is pairing each ISMS-affecting role with a named person, a stated competency requirement, and a credential with an active renewal cycle, then keeping that mapping current as people change roles. A short overview of how control frameworks, standards, and evidence requirements fit together is available on Forge University's certification resources page, which is a reasonable starting point if you are mapping this out for the first time.
Building the evidence trail before your next audit
Start with the roles that actually touch the ISMS, not your full org chart. Pull the list of people who configure access controls, manage the risk register, run vendor assessments, or respond to incidents, and check whether each of those job descriptions states a specific competency requirement rather than a vague reference to "security experience."
From there, the gap-closing work is straightforward but ongoing. You either confirm the current titleholder has documented, dated proof of the stated competency, or you build a plan to get them there, log the plan, and revisit it on a schedule tied to your surveillance audit cycle. If you want a structured way to close those gaps for your own team, you can start training now and have renewal-cycle documentation ready well before your next Stage 2 review.
None of this is about collecting more paper. It is about making sure the paper you already have actually answers the question an auditor is going to ask: who owns this control, how do we know they are competent, and how do we know that is still true today.