Clause 7 requires five support elements: resources, competence, awareness, communication, and documented information. Auditors check that you defined requirements first, such as what competence means for a given role, before producing matching records. Your immediate next steps are a competence matrix, an evidence map, and one controlled document register.
TL;DR:
- Define what competence each security role requires before collecting certificates, then document task evidence, evaluation dates, reviewers, and whether training improved performance.
- Tie resource approvals to Statement of Applicability controls and approved budget or staffing decisions so auditors can trace each required capability to funding.
- Policy acknowledgements must identify the dated version, while interviews and incident drills test whether employees, contractors, and temporary staff understand their duties.
- Maintain one controlled document register with a named owner, approval history, a single current version, access rules, and retention schedule; scale detail to organizational complexity.
- Set each communication’s audience, timing, method, and trigger, then log messages against the plan; an untracked plan is treated as no plan.
Table of Contents
- 7.1 Resources: Scope, Responsibilities, and Audit Evidence
- 7.2 Competence: Building and Evidencing Role Competence
- 7.3 Awareness: Proving People Understand the ISMS, Not Just Received It
- 7.4 Communication: A Simple, Auditable Communication Plan
- 7.5 Documented Information: Practical Controls for Creation, Update, and Control
- What Auditors Look for and How to Run a Self-Audit Before They Arrive
- Where Teams Actually Get Clause 7 Wrong
- Sizing the Clause 7 Effort With ISMS Calculator
- FAQ
- Sources
7.1 Resources: Scope, Responsibilities, and Audit Evidence
Resources under Clause 7 cover more than headcount. They include people, time, infrastructure, budget, and external services such as penetration testing or legal advice. An auditor wants to see that someone with authority decided these resources were adequate for the information security management system, not that they simply exist somewhere in the organization.
Top management carries this responsibility, and the standard expects visible proof of it. A signed budget approval tied to a specific ISMS objective works. So does a board minute referencing a staffing decision for the security function. Vague statements about “sufficient resources” without a decision trail rarely satisfy an auditor looking for traceability between intent and action.
Keep the following on hand for review:
- A resource register listing roles, tools, and budget lines mapped to ISMS objectives.
- Approved budget documents showing sign-off dates and approvers.
- Role time allocation statements for part-time security responsibilities.
- Supplier or contractor agreements covering outsourced security functions.
Link resource decisions back to your Statement of Applicability. When a control in the SOA requires a specific tool or skill set, your resource register should show where that requirement was funded or staffed. This connection is often the first thing an auditor traces, and a missing link here creates a finding even when the resource itself exists.
Pro Tip: Keep resource approvals in the same register you use for objectives, so an auditor can trace funding to purpose in one document instead of three.
7.2 Competence: Building and Evidencing Role Competence
The standard sets out four ordered steps: determine the competence needed for roles affecting security performance, ensure people have that competence through education, training, or experience, take action to close any gaps, and retain documented evidence of all of it. Skipping the first step is the most common reason competence evidence gets rejected at audit, because a certificate means nothing if no one defined what competence the role actually required.
A competence matrix is the most reproducible way to satisfy this clause. Build it with these fields:
- Role or job title.
- Tasks that affect information security performance.
- Required competence for those tasks, stated specifically rather than generically.
- Evidence held, such as a certificate, a training record, or documented experience.
- Date of last evaluation and who reviewed it.
According to practitioner analysis of Clause 7 audits, auditors frequently reject competence evidence when certificates are presented without a defined competence requirement behind them, and recommend a competence matrix as the practical fix. AuditBadger’s breakdown of common Clause 7 findings treats this gap as the single most frequent failure pattern in the clause.
Evaluating whether training actually worked matters more than the training itself. Post-training quizzes, observed task performance, and peer review all count as evidence of effectiveness, and any one of them strengthens a competence file far more than an attendance sheet alone. For internal auditors and technical staff, keep CVs, prior assessment records, and independence statements where the role requires separation of duties. Our practical guide to audit evidence covers acceptable formats for these records in more detail.
Pro Tip: When a role lacks a formal certificate, document years of relevant experience against the specific task list instead. A manager’s written evaluation mapped to the role’s tasks often carries more weight than a generic course completion.
7.3 Awareness: Proving People Understand the ISMS, Not Just Received It
Awareness is not the same as distribution. Sending a policy by email and logging that it was sent proves delivery, not understanding. Clause 7.3 asks whether people grasp the security policy, how their role contributes to the ISMS, and what happens when requirements are not followed, and auditors often test this directly by interviewing staff rather than reviewing paperwork alone.
A workable awareness program includes:
- Onboarding sessions that cover policy, role contribution, and consequences of non-conformity.
- Signed acknowledgements tied to a specific, dated version of the policy.
- Periodic refreshers scheduled on a fixed cadence rather than ad hoc.
- Incident-reporting drills that test whether staff know what to do, not just what they were told.
- Coverage for contractors and temporary staff, who are frequently excluded and then flagged in audit.
What matters at audit is the link between a record and a specific version of a document. An acknowledgement log that cannot show which policy version an employee signed for is weak evidence. Refresher schedules and drill reports close that gap by showing the program runs continuously rather than once at hiring.
Pro Tip: Rehearse a short interview with a handful of staff before the audit window, asking them to explain their role’s security responsibilities in their own words. If they cannot, the acknowledgement log will not save you.
7.4 Communication: A Simple, Auditable Communication Plan
Clause 7.4 asks for a plan, not a philosophy. The standard expects you to define what you communicate, when, with whom, and how, and a one-page table usually covers it. Common triggers worth planning for include security incidents, policy changes, scheduled management reporting, and notices to suppliers whose services touch your ISMS scope.
A communication plan that satisfies an auditor typically includes:
- A list of communication types mapped to intended recipients.
- Defined timing, such as “within 24 hours” for incident notifications or “quarterly” for management review summaries.
- The method used, whether email, a ticketing system, or a scheduled meeting.
- A log of actual communications sent, cross-referenced to the plan item that triggered them.
Evidence here does not need to be elaborate. Meeting minutes that reference a specific plan item, a distribution log showing a policy update reached its intended audience, and a sample message tied to an incident notification are all sufficient when they trace back to the plan itself. A plan with no corresponding log is treated the same as no plan at all.
7.5 Documented Information: Practical Controls for Creation, Update, and Control
Clause 7.5 is where most document-control debt accumulates, and it is also the subclause auditors spend the most time testing. The standard requires control over identification, format, review and approval, version control, access, storage and preservation, and retention and disposition, extending to documents of external origin when your ISMS depends on them.
Document control controls should include identification, review and approval, version control, storage and preservation, distribution and access, and retention and disposition, extending to external-origin documents when necessary. This is stated directly in the standard’s 7.5.2 and 7.5.3 requirements.
The controls that make this workable in practice:
- A named document owner for every controlled document, not a department.
- Identification metadata: title, date, version, and author on every record.
- A defined review and approval step before a document becomes active.
- Version control that prevents two “current” copies existing at once.
- Access control matched to sensitivity, with logs where access needs to be auditable.
- Retention and disposition rules stated per document type, not assumed.
A single source of truth with page history, an explicit owner field, and a review-date field solves the version-drift problem that trips up most organizations at audit, and for end-of-life hardware you can leverage compliant device disposal services to get certified evidence of secure disposal, according to AuditBadger’s practical guidance on Clause 7 document control. The standard itself notes that the extent of documented information should be proportionate to your organization’s size and complexity, so a five-person team does not need the same document architecture as a 500-person enterprise.
The most common failure mode is drift: a policy gets updated locally, shared informally, and never makes it back into the controlled register, leaving multiple versions in circulation with no clear owner. Our detailed walkthrough of Clause 7.5 document control covers how to build a register that avoids this. Auditors typically expect to see a document register, an approval trail for each controlled document, access logs where relevant, and a retention schedule that states how long each record type is kept and how it is disposed of.
Pro Tip: Build your document register before you build your policies. Retrofitting ownership and version control onto existing documents takes far longer than starting with the structure in place.
What Auditors Look for and How to Run a Self-Audit Before They Arrive
Auditors testing Clause 7 follow a consistent pattern: sample a handful of staff for interview, check whether competence requirements trace to specific evidence, and cross-reference tasks against the records you present. The most commonly rejected evidence types share a root cause: a certificate presented without a defined competence requirement behind it, or an emailed policy with no acknowledgement that can be recalled by version.
Run through this before an audit window opens:
- Pull three roles at random and confirm their competence requirements are written down, not assumed.
- Check that every acknowledgement log ties to a specific, dated policy version.
- Trace one resource decision from the Statement of Applicability to an approved budget line.
- Confirm your document register has no document without a named owner.
- Ask two or three staff members to explain their security responsibilities without prompting.
| Record type | What auditors check | Common gap |
|---|---|---|
| Competence matrix | Requirement defined before evidence collected | Certificate with no stated competence requirement |
| Acknowledgement log | Tied to a specific policy version | Log shows delivery, not version or understanding |
| Document register | Named owner per document | Multiple “current” copies with no single owner |
| Communication log | Cross-referenced to a plan item | Messages sent with no plan item to trace back to |
Rehearsing interviews with staff and walking through your own register before the auditor does catches most of these gaps early, and it costs nothing beyond an afternoon.
Where Teams Actually Get Clause 7 Wrong
Most teams treat Clause 7 as a paperwork exercise and start by collecting certificates, acknowledgement forms, and policy PDFs before anyone has written down what competence or awareness is supposed to look like for a given role. That order is backward, and it is why so many audits turn up findings on evidence that technically exists but doesn’t answer the question an auditor is actually asking.
Define the requirement first. What does “competent” mean for this specific role, in this specific task list? Only then does it make sense to go looking for evidence that satisfies it. The same logic applies to documentation: proportionate and centralized beats exhaustive and scattered every time, and a five-page register that everyone actually updates outperforms a fifty-page one that drifted out of date six months ago.
Certificates alone rarely close the gap for technical or audit-adjacent roles. A short written assessment, a manager’s evaluation against the task list, or documented years of hands-on experience often demonstrates competence more convincingly than a course completion slip, and auditors tend to agree.
— Martin
Sizing the Clause 7 Effort With ISMS Calculator
Figuring out how much time and budget Clause 7 will actually take is its own planning problem, separate from understanding the clause itself. We built ISMS Calculator to answer that question directly: our real-time calculator gives you a tailored cost and effort estimate based on your company size, industry, and current security maturity, benchmarked against model reference values so you know whether your plan is realistic before you commit to it.
Our toolkit includes a maturity assessment across ISO domains, which is useful for spotting exactly where your Clause 7 gaps sit relative to resources, competence, or documentation before you build a remediation plan. If you want a fast first read, run our free 2-minute readiness check to surface where Clause 7 evidence is thin and get a prioritized list of what to fix first. For a more hands-on pass, our ISO 27001 Readiness Assessment walks through evidence assembly in more depth. Either way, you leave with a clearer view of what Clause 7 will cost in time and budget, not a guess.
FAQ
Can you explain ISO 27001 in a simple way?
ISO 27001 is an international standard that sets requirements for building and running an information security management system, covering everything from leadership commitment to risk treatment and support functions like Clause 7. It gives organizations a structured way to protect information and prove that protection to customers, regulators, and auditors.
Is ISO 27001 outdated?
No. The current published edition is ISO/IEC 27001:2022, which remains the active standard organizations certify against.
What are the mandatory clauses in ISO 27001?
Clauses 4 through 10 are mandatory for any organization claiming conformity, covering context, leadership, planning, support, operation, performance evaluation, and improvement. Clause 7, the support clause, sits in the middle of that sequence and underpins the evidence used to satisfy several of the others.
What is clause 7.1 in ISO 9001?
This question usually comes up because ISO 27001 shares a similar high-level structure to other standards, but the two standards are distinct. ISO 27001’s Clause 7.1 addresses resources for an information security management system specifically, while other standards might address resources for a quality management system, and these should not be treated as interchangeable despite the similar numbering.
What is ISO 27001 Clause 7 support?
Clause 7 is the support section of ISO/IEC 27001, covering resources, competence, awareness, communication, and documented information. It requires organizations to define what each of these means for their context, then produce evidence that matches those definitions, which is exactly what auditors test during certification and surveillance visits.
Sources
- Archive
- ISO/IEC 27001:2022 - Information Security Management System
- ISO 27001 Clause 7: Support — Competence, Awareness, and Documented Information (AuditBadger)