ISO 27001 Clause 7: Support — Competence, Awareness, and Documented Information
Clause 7 of ISO 27001:2022 covers five support requirements. 7.1: provide the resources the ISMS needs. 7.2: determine the competence needed for security-relevant roles, ensure people have it, close gaps through training or hiring, and retain documented evidence of competence. 7.3: everyone working under your control must be aware of the security policy, how they contribute to the ISMS, and what happens when requirements are ignored — awareness is about them knowing it, not you having sent it. 7.4: determine what gets communicated about security, when, with whom, and how. 7.5: documented information must be properly created (identified, reviewed, approved) and controlled (available where needed, protected, version-controlled, with retention and disposition handled). The audit pattern to know: competence and awareness evidence is among the most frequently rejected — a completion certificate with no defined competence requirement behind it, or an emailed policy nobody can recall, doesn't demonstrate what the clause asks. Define what competent means per role first; then the records you already have start counting.
Clause 7 never gets a keynote. It's the support clause — resources, competence, awareness, communication, and document control — the plumbing that every other clause assumes is working. But it earns its place in this series for a practical reason: Clause 7 produces some of the most frequently rejected evidence in ISO 27001 audits. Not missing evidence — rejected evidence. Records that exist, get presented, and don't demonstrate what the clause actually asks. This is part four of our clauses 4–10 series (hub, Clause 6 previous).
7.1 — Resources
What it requires: determine and provide the resources needed to establish, implement, maintain and continually improve the ISMS. One sentence, no listed sub-requirements.
There's no standalone "resources register" to produce. 7.1 is audited through symptoms: risk treatments stalled for lack of budget, an ISMS owner with no allocated time, internal audits skipped because everyone was busy. Those findings technically land elsewhere (Clause 6, 9, 10), but the root-cause conversation comes back to 7.1 — and to Clause 5, since providing resources is one of top management's explicit commitments.
7.2 — Competence
What it requires: four steps, in order — determine the necessary competence of people whose work affects information security performance; ensure they're competent on the basis of education, training, or experience; take actions to acquire missing competence and evaluate whether the actions worked; and retain appropriate documented information as evidence.
Here's why competence evidence gets rejected: teams skip step one. They present training certificates, but there's no definition of what competence each role requires — so the certificate proves attendance, not competence. The auditor's question is always "competent against what?"
What works in practice: a short competence matrix — for each security-relevant role (ISMS owner, engineers with production access, internal auditor, whoever reviews vendors), the competence it requires and how each holder meets it: relevant experience, a certification, completed training. Two columns of honesty beat a folder of certificates. Note the standard accepts experience as a basis — your senior engineer's decade of production work is valid evidence once it's written down against a defined requirement. One special case worth naming: the internal auditor, whose competence (and independence) auditors check specifically.
7.3 — Awareness
What it requires: persons doing work under the organization's control shall be aware of the information security policy, their contribution to the effectiveness of the ISMS (including benefits of improved performance), and the implications of not conforming with ISMS requirements.
Note the framing: they shall be aware — a state in people's heads, not an artifact in your inbox. This is the second great evidence-rejection zone. "We emailed the policy at onboarding" evidences distribution, not awareness. Certification auditors test 7.3 by walking the floor (or the video call): they ask a random engineer what the security policy means for their work, how they'd report an incident, what happens if access rules get bypassed. Blank stares convert into findings no matter how good the paperwork is.
What works in practice: lightweight but real — a short onboarding security briefing with acknowledgment, periodic refreshers (annual is customary), incident-reporting drills or phishing awareness where risk-appropriate, and policy acknowledgments tracked per person so you can show coverage. Also note the scope: "under the organization's control" includes contractors, the population most often missing from awareness records.
7.4 — Communication
What it requires: determine the need for internal and external communications relevant to the ISMS, including what to communicate, when, with whom, and how. (The 2022 revision trimmed this list down from the 2013 version's five items — the substance is a simple communication plan.)
What works in practice: a half-page table. Rows like: security incidents → affected customers → per contract/DPA timelines → email from the ISMS owner; ISMS performance → top management → quarterly → management review; policy changes → all staff → on change → Slack + acknowledgment; breach notifications → regulator → statutory deadline → designated contact. Most companies already do all of this; 7.4 just wants it decided in advance rather than improvised mid-incident.
7.5 — Documented information
What it requires: three parts. 7.5.1: the ISMS includes the documented information the standard requires plus whatever the organization determines is necessary — the standard explicitly notes that the extent differs by organization size and complexity, your license to keep documentation proportionate. 7.5.2 (creating and updating): appropriate identification (title, date, author, reference), appropriate format, and review and approval for suitability. 7.5.3 (control): documented information must be available where and when needed and adequately protected — with distribution and access, storage and preservation, version control, and retention and disposition all addressed. Documents of external origin (customer security requirements, vendor reports) fall under the same control.
Translated out of standards-speak: every ISMS document needs an owner, an approval trail, a current version people can find, and a decision about how long records live. A wiki or document platform with access control, page history, and a review-date convention satisfies 7.5 comfortably — the failure mode isn't tooling, it's drift: three versions of the access control policy in three places, none marked current. Our internal policy management guide covers the practical setup.
Common Clause 7 nonconformities
- Competence evidence with no competence definition — certificates presented against requirements that were never written down.
- Awareness that stops at distribution — sent ≠ known; staff interviews expose it immediately.
- Contractors outside the loop — awareness and competence records covering employees only, while contractors hold production access.
- Uncontrolled documents — no versioning, no approval trail, or the classic: the policy PDF on a shared drive that diverged from the wiki version a year ago.
- No retention decisions — records kept forever by accident or deleted by accident, neither of which is a disposition policy.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
The bottom line
Clause 7 rewards the same discipline as the rest of the standard: define the requirement before collecting the proof. Write the competence matrix, run awareness people can actually recall, decide communications in advance, and keep one controlled current version of everything. None of it is hard; all of it is checkable — which is precisely why auditors like testing here. Next in the series: Clause 8, Operation — the short clause where your entire Annex A implementation formally plugs into the management system.
Frequently asked questions
What competence records does ISO 27001 require? +
Clause 7.2 requires four things in order: determine the necessary competence of people whose work affects information security performance, ensure they're competent on the basis of education, training, or experience, take actions to close gaps (and evaluate whether the actions worked), and retain appropriate documented information as evidence. The reason competence evidence gets rejected in audits is that teams skip the first step: they present training certificates without ever defining what competence each role requires, so the certificate proves attendance, not competence. The practical fix is a short competence matrix — each security-relevant role, the competence it requires, and how each holder meets it. Note that experience is an explicitly valid basis: a senior engineer's production track record counts once it's documented against a defined requirement.
How do auditors test security awareness under ISO 27001? +
By talking to your people. Clause 7.3 requires that persons working under the organization's control are aware of the security policy, their contribution to the ISMS, and the implications of not conforming — a state in people's heads, not an artifact in your inbox. Certification auditors test it by asking randomly selected staff what the security policy means for their work, how they'd report an incident, and what happens when access rules are bypassed. "We emailed the policy at onboarding" evidences distribution, not awareness, and blank stares convert into findings regardless of paperwork. What works: a short onboarding security briefing with tracked acknowledgment, periodic refreshers, and coverage that includes contractors — the population most often missing from awareness records.
What does ISO 27001 Clause 7.5 require for document control? +
Clause 7.5 has three parts. 7.5.1: the ISMS must include the documented information the standard explicitly requires plus whatever your organization determines is necessary — with a note that the extent varies by size and complexity, which is your license to keep documentation proportionate. 7.5.2 (creating and updating): appropriate identification (title, date, author, reference), appropriate format, and review and approval for suitability. 7.5.3 (control): documents must be available where and when needed and adequately protected, with distribution and access, storage and preservation, version control, and retention and disposition all addressed — including documents of external origin like customer security requirements. A wiki with access control, page history, and a review-date convention satisfies it; the common failure is drift — multiple divergent versions with none marked current.
