If you want your ISMS to survive contact with a certification auditor, Clause 7 is where you prove the system is actually run by capable people with the right tools, not just described on paper.
The audit that stopped at a shared drive
Priya Nandakumar had spent fourteen months getting Solvera Health Analytics ready for its ISO 27001 certification audit. The risk assessment was rigorous. The Statement of Applicability ran to ninety-one controls with clear justifications. The board had signed off on a six-figure security budget. By the time the external auditor, a soft-spoken veteran named Grant Osei, arrived on-site in Austin, Priya was confident Solvera would sail through Stage 2.
It didn't. Grant asked to see the information security policy that all staff had supposedly acknowledged. Priya pulled it from SharePoint. Then Grant asked the same question of three employees on the analytics floor. One produced a PDF dated fourteen months earlier, with a different owner listed and no version number. Another had a printed copy from a laptop bag, three revisions behind. The third couldn't find it at all and pulled up a Google Doc a manager had shared "temporarily" during a project eighteen months prior — a document that had never been formally retired.
Grant didn't need to look any further. He wrote up a major nonconformity against document control, cross-referenced to Clause 7.5.3, and a second, related nonconformity against awareness under Clause 7.3, because if staff didn't know which policy was current, they couldn't credibly be "aware" of it. Certification was delayed ninety days. Solvera's CFO, who had budgeted the audit as a Q2 deliverable tied to a customer contract renewal, had to explain the slip to the board. The direct cost — re-audit fees, consultant time, and a renegotiated contract clause — came to just under $38,000. The reputational cost, Priya told me later, was worse: "We had done the hard analytical work. We got dinged for something that should have been a solved problem in year one."
Solvera's story is common. In my fifteen-plus years assessing and building ISMS programs across more than 200 organizations — health tech, fintech, SaaS, manufacturing, public sector — Clause 7 findings are consistently among the top two or three sources of nonconformities at both Stage 2 and surveillance audits. Not because the requirements are technically hard, but because organizations treat "Support" as administrative housekeeping rather than as operational infrastructure. This article is about closing that gap: giving you the concrete practices and artifacts — a competence matrix, an awareness campaign calendar, a communication plan, and a documented-information control system — that auditors actually check, and that keep your ISMS running when nobody in the room remembers the last policy revision date.
Who this is for / What you'll walk away with
This article is written for ISMS managers, information security officers, compliance leads, and internal auditors who are past the "what is ISO 27001" stage and are now building or operating the management system itself. If you're earlier in the journey, our beginner's guide to ISO 27001 and our explainer on ISMS core concepts are better starting points.
If you're assembling a full implementation program rather than tackling Clause 7 in isolation, our Complete ISO 27001 Implementation Guide eBook walks through how Clause 7 fits alongside the other management-system clauses end to end.
By the end of this article you will walk away with:
A clear, sub-clause-by-sub-clause breakdown of Clause 7.1 through 7.5, with no invented requirements.
A reusable competence/training matrix template and a method for evaluating whether training actually worked.
A twelve-month awareness campaign structure with evidence-collection points built in.
A communication plan table covering internal and external audiences, triggers, channels, and owners.
A full documented-information control system: identification, review/approval workflow, version control conventions, storage and access rules, and a retention/disposition schedule.
An understanding of exactly why document control failures are the single most common Clause 7-related audit finding, and how to design your system so that failure mode can't happen.
Clause 7 at a glance
Clause 7 sits inside the ten management-system clauses (4 through 10) that every ISO 27001:2022-certified organization must satisfy, regardless of which Annex A controls apply. It is the shortest of the "Plan" clauses in terms of page count but arguably the one with the widest evidentiary footprint, because almost every other clause depends on it. You can't execute Clause 6 risk treatment without competent people (7.2). You can't sustain Clause 5 leadership commitment without communicating the policy (7.4, referencing Clause 5: Leadership). And you can't run Clause 9 monitoring or Clause 10 improvement without documented information that's actually under control.
Sub-clause | Title | Core requirement in one line |
|---|---|---|
7.1 | Resources | Determine and provide the resources needed to establish, implement, maintain, and continually improve the ISMS |
7.2 | Competence | Determine, ensure, and evidence the competence of persons whose work affects information security performance |
7.3 | Awareness | Ensure persons under the organization's control are aware of the policy, their contribution, and the implications of nonconformity |
7.4 | Communication | Determine the internal and external communications relevant to the ISMS — what, when, with whom, and how |
7.5.1 | Documented information — general | Maintain the documented information the standard requires plus what the organization determines is necessary for ISMS effectiveness |
7.5.2 | Creating and updating | Ensure proper identification, format, and review/approval when documented information is created or updated |
7.5.3 | Control of documented information | Control availability, protection, distribution, access, storage, retention, version control, and disposition; control externally-originated documents |
A quick terminology note, since it trips up teams migrating from the 2013 revision: ISO 27001:2022 standardizes on "documented information" rather than the older "documents" and "records" split. Anything you create to demonstrate ISMS operation — policies, procedures, matrices, logs, meeting minutes, training records — falls under the same Clause 7.5 controls. If you want the full history of how the standard's language evolved, see our piece on the 2013 vs. 2022 changes and the broader history and evolution of ISO 27001.
7.1 Resources: the clause everyone skips and everyone regrets skipping
Clause 7.1 is a single sentence in the standard: the organization shall determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the ISMS. It sounds like a formality. It is not. In my experience, resourcing failures are the root cause behind a disproportionate share of downstream nonconformities in competence, awareness, and even risk treatment — because when there's no budget line, no headcount, and no tooling, nothing else in Clause 7 has a chance.
Auditors test 7.1 indirectly. They rarely ask "show me your resource plan" as a standalone document (though having one helps). Instead, they infer resourcing adequacy from outcomes: Is the risk register actually being updated? Are training completion rates above single digits? Is there a real budget line for the ISMS in the finance system, or is security work being absorbed as unpaid overtime by an already-stretched IT team? A well-run Solvera-style ISMS treats 7.1 as an annual resourcing exercise tied to the management review required under leadership commitment — not a one-time checkbox.
Resource category | Examples | Typical evidence auditors accept |
|---|---|---|
Human resources | Dedicated ISMS manager, security champions network, internal audit team, part-time SME allocations | Org chart, job descriptions, allocated FTE percentages, RACI matrix |
Financial resources | Tooling budget, training budget, certification/audit fees, consultant retainers | Approved budget line items, purchase orders, cost center reports |
Infrastructure and tooling | GRC platform, document management system, SIEM, vulnerability scanners, awareness training platform | License agreements, system access lists, screenshots of active dashboards |
Knowledge resources | Access to threat intelligence, industry standards, legal/regulatory counsel | Subscription records, consulting engagement letters, knowledge base articles |
Time and scheduling | Protected time for risk assessments, internal audits, management reviews | Calendar invites, meeting minutes, project plans with allocated hours |
Case study: the resourcing gap that became a near-miss. A 140-person fintech client I'll call Ridgeline Capital passed its Stage 1 audit comfortably in early 2024 — the documentation was excellent, largely because a consultancy had built it. Six months later, at Stage 2, the auditor found that the ISMS manager role had been assigned to a compliance analyst as a fourth or fifth responsibility, with zero allocated hours in her actual workload model. Risk treatment plans were twelve weeks behind schedule. The auditor issued a minor nonconformity citing inadequate resource provision under 7.1, directly linked to the stalled risk treatment work under Clause 6 planning. Ridgeline's leadership approved 0.5 FTE of dedicated time within two weeks and cleared the nonconformity at the follow-up review, but the near-miss illustrated the pattern precisely: paper commitment to the ISMS without resourced commitment is the single fastest way to convert a Stage 1 pass into a Stage 2 stumble.
"I've stopped accepting 'we'll find the time' as an answer in management review. If a control needs eight hours a month and nobody's calendar has eight hours a month, the control doesn't exist — it's a hope." — Marcus Feldt, ISMS Lead, Ridgeline Capital
7.2 Competence: proving your people can actually do the job
Clause 7.2 requires four distinct actions, and I find teams typically execute only the first one:
Determine the necessary competence of persons doing work under the organization's control that affects information security performance.
Ensure those persons are competent, on the basis of appropriate education, training, or experience.
Take actions to acquire the necessary competence where gaps exist, and evaluate the effectiveness of those actions.
Retain appropriate documented information as evidence of competence.
Notice what's missing from most organizations' approach: step 3's "evaluate the effectiveness" clause. Sending someone to a training course satisfies step 3's first half. It does nothing to satisfy the second half unless you can show the training changed something — a test score, a reduced incident rate, a demonstrated skill in a tabletop exercise. Auditors have gotten noticeably sharper about probing this since the 2022 revision's emphasis on performance evaluation tightened up across the standard; a training certificate alone is treated as necessary but not sufficient evidence.
Building the competence matrix
The artifact auditors want to see — and the one I build with nearly every client in month one — is a competence matrix. It maps roles to required competencies, current competency evidence, and any gap-closing actions in flight.
Role | Required competency | Evidence of competence | Gap identified? | Action taken | Effectiveness check |
|---|---|---|---|---|---|
ISMS Manager | ISO 27001 Lead Implementer knowledge, risk methodology | Lead Implementer certificate (2023), 6 yrs GRC experience | No | N/A | Annual peer review of risk register quality |
Internal Auditor | ISO 27001 audit techniques, impartiality | Internal Auditor certificate, completed 4 supervised audits | No | N/A | Audit report quality reviewed by ISMS Manager |
Cloud Infrastructure Engineer | Secure configuration of AWS/Azure, Annex A 8.9 config management | AWS Security Specialty cert (expired) | Yes | Re-certification enrolled, mentoring by senior engineer | Recert exam pass + config audit in 90 days |
HR Business Partner | Data protection basics, screening/vetting procedures (Annex A 6.1) | Completed internal onboarding training only | Yes | Enrolled in data protection awareness course | Quiz score ≥ 85%, spot-check of screening files |
Help Desk Analyst | Incident reporting procedure, phishing identification | Security awareness training completion (annual) | No | N/A | Simulated phishing click rate < 5% |
Third-Party Risk Owner | Vendor risk assessment methodology | On-the-job shadowing, no formal certification | Yes | Formal vendor risk training module assigned | Reviewer sign-off on next 3 vendor assessments |
Build this matrix once, then treat it as a living document reviewed at least annually — ideally aligned to your management review cycle. Retain prior versions; auditors sampling for trend evidence will sometimes ask to see last year's matrix next to this year's to confirm gaps were actually closed rather than quietly dropped.
Evaluating effectiveness without over-engineering it
You don't need a learning-and-development department to satisfy 7.2's effectiveness requirement. Proportionate options I've deployed successfully across organizations from 30 to 3,000 employees include: a short knowledge-check quiz immediately after training (with a documented pass threshold); a practical demonstration, such as an engineer walking through a secure deployment checklist; a reduction in a measurable metric, such as phishing simulation click-through rate or mean time to acknowledge an incident; and peer or manager sign-off on work quality following training, such as a supervisor reviewing the first three risk assessments a newly trained analyst completes.
"The question I ask every client is: if I picked someone off your competence matrix at random and asked them to demonstrate the skill you say they have, could they? If the honest answer is 'probably not,' the matrix is fiction." — Renata Souza, Principal Security Consultant
Retaining competence evidence
Retention here is not optional — it's an explicit requirement in 7.2's final clause, and it dovetails directly with the documented-information controls in 7.5. Keep training completion records, certificates, quiz results, and sign-offs for at minimum the duration of the individual's tenure in the role plus one full audit cycle (typically three years, aligned to certificate validity), and longer where the role touches regulated data. We cover a full recommended schedule later in this article.
7.3 Awareness: three things every person under your control must know
Clause 7.3 is narrower than people assume. It doesn't require a comprehensive security education program covering every Annex A control. It requires that persons doing work under the organization's control — employees, and depending on your arrangements, certain contractors and third parties — are aware of exactly three things:
The information security policy.
Their contribution to the effectiveness of the ISMS, including the benefits of improved information security performance.
The implications of not conforming with the ISMS requirements.
That's the letter of the clause. In practice, effective awareness programs go well beyond this floor — because Annex A 6.3 (a control, not a clause requirement) calls for security awareness education and training as an ongoing program, and because auditors treat weak day-to-day security behavior as circumstantial evidence that awareness isn't landing. It is worth being precise about this distinction: Clause 7.3 is a management-system requirement that awareness exists and can be evidenced; Annex A 6.3 is a control you select and implement (almost always) to satisfy it. Confusing the two is common, and conflating them in your Statement of Applicability justification is a frequent minor-finding source.
Aspect | Clause 7.3 (management requirement) | Annex A 6.3 (control) |
|---|---|---|
Nature | Mandatory for all certified organizations | Selected control, justified in the SoA |
Scope | Awareness of policy, personal contribution, nonconformity implications | Ongoing training/education program design and delivery |
Evidence type | Attestations, quiz scores, campaign records | Training curriculum, schedules, attendance logs, content library |
Audit angle | "Do people actually know this?" (interview-based) | "Is there a program, and is it running as designed?" (documentation-based) |
Designing a program that produces evidence, not just attendance
The mistake I see most often is a single annual "click-through" training module treated as the entire awareness program. It satisfies almost nothing on its own — auditors interview staff, and a single stale module from eleven months ago rarely survives three follow-up questions. A defensible program runs continuously, varies its format, and is tied to your actual risk landscape (informed by the risk assessment under Clause 6).
Month | Activity | Format | Target audience | Evidence captured |
|---|---|---|---|---|
January | Annual policy refresh + acknowledgment | E-learning module + digital sign-off | All staff | Completion report, timestamped signatures |
February | Phishing simulation round 1 | Simulated email campaign | All staff | Click rate, report rate, remediation training assigned |
March | Role-based deep dive: secure coding | Workshop | Engineering | Attendance log, quiz results |
April | Physical security walk-through | In-person briefing | Office-based staff | Sign-in sheet, checklist findings |
May | Incident reporting refresher | Short video + tabletop scenario | All staff | Quiz score, scenario debrief notes |
June | Phishing simulation round 2 | Simulated email campaign | All staff | Click rate trend vs. round 1 |
July | New joiner cohort review | Onboarding audit | HR + new hires | Onboarding completion audit |
August | Vendor/third-party awareness briefing | Webinar | Procurement, vendor owners | Attendance log, Q&A record |
September | Social engineering / pretexting briefing | Interactive session | All staff | Poll results, feedback scores |
October | Awareness month campaign (posters, intranet, quiz) | Multi-channel | All staff | Engagement metrics, quiz completions |
November | Phishing simulation round 3 | Simulated email campaign | All staff | Click rate trend, top-clicker follow-up |
December | Annual awareness effectiveness review | Management review input | ISMS Manager, leadership | Trend report presented at management review |
Case study: turning around a chronic phishing problem. A 600-employee logistics company I worked with, referred to here as Ferrocorp, had a phishing simulation click-through rate of 34% at their first assessment — well above the 10-15% range typical in mature programs I've observed. Rather than adding more generic training, we redesigned the program around the calendar structure above, added role-based content for finance and procurement (the two departments most targeted by real business-email-compromise attempts against the company), and introduced immediate, non-punitive "just-in-time" micro-training triggered the moment someone clicked a simulated link. Within three simulation cycles across nine months, the click rate dropped to 9%, and — more importantly for the ISMS — Ferrocorp could show an auditor a documented trend line with dates, cohorts, and corrective actions, which is exactly the effectiveness evidence 7.2 and 7.3 both reward.
"Awareness training that ends in a certificate and nothing else is theater. The programs that hold up under audit are the ones where you can show the number moving." — Dmitri Kovalenko, Head of Security Awareness, Ferrocorp
"We stopped calling it 'training' internally and started calling it a 'campaign.' That single word change got marketing involved, and suddenly we had actual engagement data instead of a spreadsheet of click-through checkboxes." — Aisha Bello, Compliance Manager
If you want a dedicated, step-by-step walkthrough of building an awareness function from zero — curriculum design, vendor selection, and a full annual calendar — we're planning a companion deep-dive, Security Awareness Training Program: A Practical Guide, for this pillar; until it's published, the calendar structure above should get you most of the way there.
Evidence retention for awareness
Keep campaign calendars, content versions, completion/attendance records, quiz results, and trend reports for at least the current certification cycle (three years) plus the prior cycle where feasible, so auditors and your own management review can see multi-year trends rather than a single snapshot.
7.4 Communication: who needs to know what, when, and how
Clause 7.4 requires you to determine the internal and external communications relevant to the ISMS, addressing four elements for each: the subject (what), the timing (when), the audience (with whom), and the method (how). Unlike 7.3, there's no prescribed content here — the standard leaves the actual communications plan to your judgment, provided it's documented and demonstrably followed.
Where organizations go wrong is treating this as one more policy document nobody reads rather than an operational plan that gets used. A communication plan earns its keep when, six months after you wrote it, someone can look at row three and immediately know that a data breach affecting customer data triggers a notification to the DPO within 24 hours and to affected customers within the regulatory window — without needing to improvise under pressure.
What (subject) | When (trigger/frequency) | With whom | How (channel) | Owner |
|---|---|---|---|---|
Information security policy | Annually, and on material revision | All staff | Intranet publication + e-learning acknowledgment | ISMS Manager |
Risk register changes (new/escalated risks) | Monthly | Risk owners, leadership team | Risk review meeting + dashboard | Risk Manager |
Security incident (confirmed) | Within 4 hours of confirmation | Executive team, affected business unit leads | Incident bridge call + written summary | Incident Commander |
Data breach involving personal data | Per regulatory deadline (e.g., 72 hours under GDPR) | Data Protection Officer, regulator, affected individuals | Formal notification per legal template | DPO / Legal |
Internal audit findings | Within 5 business days of audit close | Process owners, ISMS Manager | Audit report + follow-up meeting | Lead Internal Auditor |
Management review outcomes | After each management review | Leadership team, department heads | Meeting minutes + action log | ISMS Manager |
Customer-facing security posture updates | On request / contractually triggered | Customers, prospects (via sales/CS) | Security questionnaire response, trust page | Sales Engineering / Security |
Vendor security requirements | At onboarding and annual review | New and existing vendors | Contract clauses + vendor assessment questionnaire | Procurement / Third-Party Risk |
Regulatory or legal change affecting ISMS | As identified | Compliance, Legal, ISMS Manager | Legal briefing + risk register update | Compliance Lead |
Certification body communications | Per audit schedule | Certification body, ISMS Manager | Formal correspondence, audit portal | ISMS Manager |
Note the overlap with the policy communicated under Clause 5 leadership: top management is required to ensure the policy is communicated, and 7.4 is the mechanism that operationalizes that requirement with actual triggers and owners. Similarly, the incident and audit rows here feed directly into the operational controls covered under Clause 8: Operation.
"The communication plan is the one document I ask new clients to read out loud in a tabletop exercise. If they hesitate on who calls the regulator, the plan isn't real yet — it's aspirational." — Owen Farrelly, Incident Response Advisor
7.5.1 Documented information: what you must actually keep
This is where "Support" stops being soft and becomes the clause auditors probe hardest, because documented information is the evidentiary backbone of the entire audit. ISO 27001:2022 requires two categories of documented information:
Documented information required by the standard itself — the mandatory set explicitly called for across Clauses 4–10 and the Annex A controls you've selected.
Documented information the organization determines is necessary for the effectiveness of the ISMS — everything beyond the mandatory floor that you decide you need to run the system credibly.
Teams frequently treat the mandatory list as the entire scope of Clause 7.5, and then get surprised when an auditor asks for something judged "necessary" that was never mandatory in the first place — a RACI matrix, an exceptions register, a supplier due-diligence log. Below is the mandatory core; treat it as a floor, not a ceiling, and confirm current requirements against the standard text and your certification body's checklist rather than treating any single list as exhaustive.
Documented information | Required by | Typical form |
|---|---|---|
Scope of the ISMS | Clause 4.3 | Scope statement document |
Information security policy | Clause 5.2 | Policy document |
Risk assessment process and results | Clause 6.1.2 | Methodology document + risk register |
Risk treatment process and Statement of Applicability | Clause 6.1.3 | SoA document |
Information security objectives | Clause 6.2 | Objectives register/plan |
Evidence of competence | Clause 7.2 | Competence matrix, training records |
Documented information determined as necessary for ISMS effectiveness | Clause 7.5.1(b) | Varies — procedures, registers, plans |
Operational planning and control records | Clause 8.1 | Change records, project documentation |
Risk assessment results (ongoing) | Clause 8.2 | Updated risk register entries |
Risk treatment results | Clause 8.3 | Treatment plan status |
Monitoring, measurement, analysis, and evaluation results | Clause 9.1 | Metrics reports, dashboards |
Internal audit program and audit reports | Clause 9.2 | Audit plan, individual audit reports |
Management review results | Clause 9.3 | Meeting minutes and action items |
Nonconformities and corrective actions | Clause 10.1/10.2 | Corrective action register |
This list is a starting reference, not a substitute for reading the current standard text or your certification body's own checklist — treat the Mandatory Documents Checklist as the maintained, audit-ready version, and cross-check it against the standard directly during any gap analysis. For a deeper narrative treatment of the full mandatory-documents landscape, see ISO 27001 Mandatory Documents Explained (a companion piece we plan to develop for this pillar). Internal audit reports specifically are worth standardizing early — our Internal Audit Report Template gives you a consistent structure so that findings, evidence, and corrective actions are captured the same way every cycle, which in turn makes your Clause 7.5 evidence trail far easier to defend during surveillance audits.
7.5.2 Creating and updating documented information
Whenever you create or update any piece of documented information, the standard requires you to get right three things: identification and description, format, and review and approval for suitability and adequacy. This sounds procedural, and it is — but it's precisely the procedural rigor that failed at Solvera in the cold open. A document with no title convention, no version number, no defined owner, and no recorded approval is, from an audit perspective, indistinguishable from a document that doesn't exist yet, no matter how good its content is.
Element | Requirement | Practical implementation |
|---|---|---|
Identification and description | Title, unique ID, date, author/owner | Document header block: Title, Doc ID, Version, Owner, Effective Date |
Format | Language, software version, media (electronic/paper), graphics | Standard template with locked header/footer, controlled file types (e.g., PDF for published, editable source in restricted repo) |
Review and approval | Suitability and adequacy confirmed by an authorized reviewer before release | Defined approval workflow with named roles, e-signature or workflow tool sign-off, approval logged with date and approver |
A practical review/approval workflow I recommend as a baseline: draft owner completes the document against the template → subject-matter reviewer checks technical accuracy → ISMS Manager (or delegate) checks alignment with the ISMS and numbering conventions → designated approver (role-based, e.g., CISO or department head) signs off → document is published to the controlled repository and prior version archived, never deleted. Each of those five steps should leave a timestamped trail, whether that's in a lightweight GRC tool, a document management system, or — for smaller organizations — a disciplined use of version history and an approval log spreadsheet. If you're building your policy set from scratch, starting from a structured Information Security Policy Template rather than a blank page makes the identification-and-format requirement far easier to satisfy consistently across every document you produce.
7.5.3 Control of documented information: the section that generates the most findings
If Clause 7 has a single highest-stakes sub-clause, it's 7.5.3. It requires documented information to be controlled to ensure it is available and suitable for use, where and when needed, and adequately protected — from loss of confidentiality, improper use, or loss of integrity. To achieve that, the standard specifically calls out distribution, access, retrieval and use; storage and preservation, including legibility; control of changes (version control); and retention and disposition. It also requires you to identify and control documented information of external origin — supplier contracts, regulatory texts, customer security requirements, and the like — that the ISMS depends on.
Control area | Requirement | What auditors look for |
|---|---|---|
Availability & suitability | Right document, right place, right time | Staff can locate the current version within seconds during interview |
Protection | Confidentiality, integrity, improper use prevented | Access controls on the repository, no editable master files in public shares |
Distribution | Controlled release to intended audience | Distribution list or publication log, no unmanaged copies |
Access | Appropriate personnel can retrieve; others restricted | Role-based permissions, audit trail of access where sensitive |
Storage & preservation | Legible, retrievable, protected from damage/loss | Backup regime, defined retention location, format migration plan (e.g., away from obsolete file types) |
Version control | Only current approved version in active use; history preserved | Version numbering scheme, changelog, superseded versions archived not deleted |
Retention | Kept as long as required by policy, contract, or law | Retention schedule with defined periods per document type |
Disposition | Secure destruction or return when retention expires | Disposal log, secure deletion/shredding evidence |
External-origin documents | Identified and controlled where relevant to the ISMS | Register of external documents (contracts, regulations, standards) with review dates |
The documented-information lifecycle
The lifecycle below is the model I use with clients to visualize how a single piece of documented information — a policy, a procedure, a risk register entry — should move from creation to eventual disposal, with control gates at every transition.
flowchart LR
A[Create / Draft] --> B[Identify: title, ID, owner, version]
B --> C[Review for accuracy & suitability]
C --> D{Approved?}
D -- No --> B
D -- Yes --> E[Publish to controlled repository]
E --> F[Distribute to intended audience]
F --> G[Access & use under role-based controls]
G --> H[Periodic review / change trigger]
H -- Update needed --> B
H -- No change needed --> I[Continue in force]
I --> J[Retention period monitored]
J --> K{Retention expired?}
K -- No --> I
K -- Yes --> L[Disposition: secure destroy or archive per schedule]Version control conventions that actually survive contact with real teams
A version control scheme only works if it's simple enough that a busy department head will follow it without prompting. I standardize on a major.minor numbering system tied to the significance of the change, paired with a mandatory changelog entry.
Version format | When to use | Example | Approval needed? |
|---|---|---|---|
0.x (draft) | Initial drafting and internal review, not yet published | 0.1, 0.2, 0.3 | No — working draft |
1.0 | First formally approved and published version | 1.0 | Yes — full approval workflow |
x.1, x.2 (minor) | Clarifications, typo fixes, non-substantive updates | 1.1, 1.2 | Yes — lightweight review, no full re-approval cycle |
x+1.0 (major) | Substantive changes: scope, ownership, control requirements | 2.0, 3.0 | Yes — full approval workflow, re-communicated to affected staff |
Superseded | Prior version archived, marked obsolete, not deleted | 1.3 (superseded by 2.0) | N/A — retained per retention schedule |
Every controlled document should carry a footer or header showing document ID, current version, effective date, owner, and next scheduled review date. That last field matters more than people think: a document with no review date defaults, in an auditor's mind, to "unmanaged," even if its content happens to be current.
Retention and disposition schedule
Retention periods should be driven by three inputs: what the standard or your own ISMS design requires, what contracts or customers require, and what law or regulation requires (data protection law, sector-specific rules, tax and corporate record requirements). Where these conflict, keep the longest applicable period, and record the rationale.
Document/record type | Minimum retention | Rationale | Disposition method |
|---|---|---|---|
ISMS policies (superseded versions) | 3 years past supersession | Certification cycle + audit trail | Secure archive, then secure deletion |
Risk assessments and treatment plans | 3 years past closure/review cycle | Demonstrate risk management history | Secure archive |
Internal audit reports | 3 full audit cycles | Trend analysis, surveillance audit reference | Secure archive |
Management review minutes | 3 years minimum | Evidence of leadership oversight | Secure archive |
Competence & training records | Duration of employment + 3 years | Evidence of ongoing competence, potential dispute reference | Secure archive, then secure deletion |
Awareness campaign records | 3 years | Trend evidence for effectiveness reviews | Secure archive |
Incident records | Per legal/regulatory requirement, minimum 3 years | Regulatory inquiry, litigation hold potential | Secure archive, legal hold override |
Vendor/third-party assessments | Duration of contract + 2 years | Contractual dispute, due-diligence trail | Secure archive |
Access logs (privileged access) | 1 year minimum, longer if regulated | Security monitoring, forensic need | Automated log rotation with archive tier |
Externally-originated documents (contracts, regulations) | Duration of applicability + 2 years | Legal reference, obligation tracking | Secure archive |
Controlling documents of external origin
Clause 7.5.3 specifically calls out documented information of external origin determined by the organization to be necessary for the ISMS. In practice this includes customer contracts with security clauses, regulatory texts your ISMS must align with, industry standards you reference (including the ISO 27001 standard text itself and any adopted frameworks), and supplier certifications or attestations you rely on for third-party risk decisions. Maintain a simple external-document register: source, document, version/date obtained, relevance to the ISMS, internal owner, and next review date. Without this register, it's common for an organization to be operating against an outdated regulatory text or an expired vendor SOC 2 report without anyone noticing until an incident — or an auditor — forces the question.
Case study: the document control fix that survived a surveillance audit. After Solvera's Stage 2 delay (from our cold open), Priya rebuilt document control from the ground up over eight weeks. She retired every uncontrolled copy she could find — including the eighteen-month-old Google Doc — migrated all controlled documents into a single document management platform with enforced check-in/check-out, applied the version scheme above, and ran a mandatory all-hands communication confirming the one authoritative location for every policy. At the delayed Stage 2 re-visit, Grant Osei sampled five employees across three departments and every one of them located the current policy version within under a minute, matching the master repository exactly. Solvera certified on that visit. At the first surveillance audit fourteen months later, the same document control system produced zero findings — a result Priya attributes less to any single tool and more to having made version discipline a default behavior rather than a campaign.
"The fix wasn't a better document. It was making it structurally impossible for an old version to survive anywhere someone could stumble across it." — Priya Nandakumar, ISMS Manager, Solvera Health Analytics
The most common Clause 7-related audit findings
Across the certification and surveillance audits I've supported or reviewed, a handful of Clause 7 failure patterns recur constantly. Naming them explicitly is the fastest way to inoculate your own program against them.
Finding pattern | Typical clause reference | Root cause | Fix |
|---|---|---|---|
Multiple uncontrolled versions of the same policy in circulation | 7.5.3 | No single source of truth, no enforced repository | Single controlled repository, retire all shadow copies |
Staff unable to state current policy or their security responsibilities in interview | 7.3 | Training treated as one-time event, not ongoing | Rolling awareness calendar with varied formats |
Training completed but no evidence of effectiveness | 7.2 | Completion tracked, comprehension not tested | Add quizzes, practical checks, or metric-based validation |
Competence matrix exists but hasn't been updated in over a year | 7.2 | Matrix built once for certification, not maintained | Tie matrix review to management review cadence |
Approved document has no recorded approver or approval date | 7.5.2 | Informal sign-off via email or verbal agreement | Enforce workflow tool or logged approval step |
Communication plan exists but nobody can recall using it during an actual incident | 7.4 | Plan written for audit, not rehearsed | Include the plan in tabletop exercises |
Resource shortfalls cited as reason for missed risk treatment deadlines | 7.1 | ISMS role under-resourced relative to scope | Annual resourcing review tied to management review |
External-origin documents (contracts, regulations) not tracked or reviewed for currency | 7.5.3 | No external-document register maintained | Establish and assign ownership of the register |
Retention periods undefined or inconsistent across document types | 7.5.3 | No formal retention schedule | Adopt and publish a retention and disposition schedule |
Metrics and KPIs for Clause 7 health
Beyond point-in-time audit evidence, tracking a small set of ongoing metrics gives your management review something concrete to act on, and gives you early warning before a finding becomes a certification risk.
Metric | Target (illustrative) | Data source | Review cadence |
|---|---|---|---|
Competence matrix currency (% roles reviewed in last 12 months) | ≥ 95% | Competence matrix | Quarterly |
Training completion rate (mandatory modules) | ≥ 98% | LMS / awareness platform | Monthly |
Phishing simulation click-through rate | ≤ 10% | Simulation platform | Per simulation cycle |
Policy acknowledgment rate within 30 days of publication | ≥ 95% | Document management / e-signature tool | Per publication |
Documented information with overdue review date | 0 | Document register | Monthly |
Uncontrolled/shadow copies identified during spot-checks | 0 | Internal audit spot-check | Quarterly |
Time to approve a new/updated controlled document | ≤ 10 business days | Workflow tool | Ongoing |
Communication plan triggers executed on time (e.g., incident notifications) | 100% | Incident/communication log | Per event |
How Clause 7 connects to the rest of the ISMS
Clause 7 is easy to under-invest in precisely because its outputs are inputs to everything else rather than visible end products in their own right. The risk assessment methodology from Clause 6 only produces trustworthy results if the people running it are competent (7.2) and adequately resourced (7.1). The policy that Clause 5 leadership commits to communicating only has force if 7.4's communication plan and 7.3's awareness program actually land it with staff. And the operational controls under Clause 8 — change management, supplier management, incident response — all generate documented information that lives or dies by the 7.5 control system. If you're mapping Clause 7 against your broader control framework, our ISMS core concepts explainer and glossary of ISO 27001 terminology are useful companion references, and organizations running parallel or overlapping frameworks may also want our comparison of ISO 27001 against NIST CSF, SOC 2, and PCI DSS, since documented-information and awareness expectations differ meaningfully across those frameworks — a point that also matters if you're pursuing SOC 2 alongside ISO 27001 (cross-pillar – verify).
A 90-day roadmap for standing up Clause 7
If you're building Clause 7 from scratch rather than remediating an existing program, sequencing matters. Resourcing decisions need to land before you can meaningfully assign competence-building actions, and your document control system needs to exist before you publish the first policy version you want people to be aware of. The roadmap below is the sequence I use with clients starting from a low baseline.
Phase | Weeks | Key actions | Deliverable |
|---|---|---|---|
Phase 1: Foundation | 1–3 | Confirm ISMS resourcing (7.1); select and configure document repository; agree numbering/version conventions | Resourcing sign-off, controlled repository live |
Phase 2: Document baseline | 4–6 | Migrate or draft mandatory documented information; retire shadow copies; assign owners and review dates | Document register with 100% of mandatory items tracked |
Phase 3: Competence | 5–8 | Build competence matrix; identify gaps; assign training/certification actions | Competence matrix v1.0, gap remediation plan |
Phase 4: Awareness & communication | 7–10 | Publish communication plan; launch awareness calendar; run first policy acknowledgment cycle | Communication plan v1.0, first awareness campaign evidence |
Phase 5: Validate | 11–13 | Internal spot-check of document control; interview sample of staff on awareness; review competence evidence | Readiness report feeding into management review |
Running these phases in parallel rather than sequentially is tempting when a certification deadline is close, but in my experience it's exactly how organizations end up in Solvera's position — a document control system stood up in week two of a rushed program, with no time left to retire the shadow copies before the audit. Build the foundation first.
Choosing a document control approach that fits your size
Not every organization needs a dedicated GRC platform on day one, and over-buying tooling is its own failure mode — a document management system nobody was trained to use produces the same shadow-copy problem as no system at all. Match the approach to your actual scale and complexity.
Approach | Best fit | Strengths | Risks | Typical cost tier |
|---|---|---|---|---|
Disciplined shared drive with strict permissions and a manual version log | Under ~50 employees, single ISMS owner | Low cost, fast to start | Manual discipline breaks down as headcount or document volume grows | Low |
Cloud document management platform (e.g., SharePoint, Confluence with workflow add-ons) | 50–500 employees | Built-in version history, permissioning, approval workflows | Requires configuration discipline; easy to under-use available controls | Low–medium |
Dedicated GRC/ISMS platform | 200+ employees, multiple frameworks, frequent audits | Purpose-built for evidence collection, control mapping, audit trails | Higher cost, implementation time, potential vendor lock-in | Medium–high |
Hybrid: GRC platform for evidence/control mapping, DMS for document hosting | Complex, multi-framework environments (e.g., ISO 27001 plus SOC 2) | Best-of-both, supports cross-framework evidence reuse | Requires clear ownership of which system is authoritative for what | Medium–high |
Whichever tier you choose, the standard doesn't care about the tool — only whether the control requirements in 7.5.3 are demonstrably met. I have seen shared-drive setups pass audit cleanly and expensive GRC rollouts fail because nobody retired the old SharePoint site running in parallel. For a line-by-line walkthrough of setting up a document control system end to end — templates, workflow diagrams, and a sample register — see our forthcoming companion piece, Document Control for ISO 27001: A Step-by-Step System, referenced throughout this pillar wherever document control comes up in more specialized contexts.
RACI: who owns each part of Clause 7
Ambiguous ownership is a quieter but equally damaging failure mode than missing resources. A RACI matrix for Clause 7 activities — itself a good candidate for "documented information the organization determines is necessary" under 7.5.1 — closes that gap.
Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Determine ISMS resourcing needs | ISMS Manager | CISO / Executive Sponsor | Finance, department heads | Leadership team |
Maintain competence matrix | ISMS Manager | CISO | Department managers, HR | Internal auditor |
Design and run awareness campaigns | Security Awareness Lead | ISMS Manager | Marketing/Comms, HR | All staff |
Maintain communication plan | ISMS Manager | CISO | Legal, DPO, Incident Commander | Leadership team |
Approve controlled documents | Document owner | Designated approver (role-based) | Subject-matter reviewer | ISMS Manager |
Maintain document register and retention schedule | ISMS Manager / Document Controller | CISO | Legal, Compliance | Internal auditor |
Review external-origin document register | Document Controller | ISMS Manager | Legal, Procurement | Third-party risk owner |
The business case: what underinvesting in Clause 7 actually costs
Clause 7 rarely gets its own line item in an ISMS budget proposal, which is exactly why it's the first place corners get cut when a certification project runs late or over budget. I've found it useful, when making the case to a CFO or board, to translate Clause 7 gaps into the same financial language used elsewhere in the business case for certification — a conversation our piece on certification benefits and ROI covers in more depth from the investment side. The table below is illustrative, built from patterns across dozens of engagements rather than any single study, but the order of magnitude holds up consistently.
Underinvestment scenario | Likely consequence | Illustrative cost impact |
|---|---|---|
No dedicated resourcing for ISMS operation (7.1) | Stalled risk treatment, missed audit deadlines | Re-audit fees, delayed contract signing (often five to six figures) |
Competence gaps not tracked or closed (7.2) | Misconfigured controls, weak internal audits | Increased incident likelihood, remediation costs after the fact |
One-off awareness training only (7.3) | High phishing susceptibility, social engineering exposure | Elevated breach probability; a single successful business-email-compromise incident can run into six figures in direct loss alone |
No communication plan rehearsed (7.4) | Slow, improvised incident/breach response | Regulatory penalties for late notification, reputational damage |
Uncontrolled documented information (7.5) | Major nonconformity at audit, policy confusion during incidents | Audit delay costs, consultant remediation fees, delayed certification tied to customer contracts |
None of these costs are hypothetical in the sense that matters to a CFO: they show up as delayed revenue recognition (certification gating a contract), direct remediation spend, or regulatory exposure. Framing Clause 7 investment this way — a few percent of the overall ISMS budget that materially de-risks the rest of the program — tends to land better with finance stakeholders than a compliance-language pitch alone. It's also worth dispelling, in the same conversation, the common misconception that Clause 7 spend is "just training and paperwork"; our myths and misconceptions article addresses several adjacent misunderstandings that tend to surface in the same budget discussions.
How Clause 7 support functions map to Annex A controls
It's worth reiterating a distinction raised earlier in this article, because it affects how you write your Statement of Applicability: Clause 7 is a management-system requirement that applies regardless of scope, while Annex A gives you controls you select to help satisfy it and the rest of the ISMS. Several Annex A controls, across the People, Organizational, and Technological themes of the 93-control, four-theme structure introduced in the 2022 revision, lean directly on the Clause 7 support functions described in this article.
Annex A control area (theme) | How it depends on Clause 7 |
|---|---|
Organizational controls — policies for information security | Requires the policy to be created, approved, and communicated per 7.4/7.5, and reviewed on a schedule tracked via document control |
Organizational controls — compliance with policies and standards | Relies on staff awareness (7.3) of what the policy requires and competence (7.2) to apply it correctly |
People controls — screening, terms and conditions of employment | Requires HR competence (7.2) and documented onboarding records (7.5) |
People controls — information security awareness, education and training | The direct operational counterpart to Clause 7.3, delivered through the program structure covered earlier in this article |
People controls — disciplinary process | Depends on staff having been made aware (7.3) of consequences of nonconformity, and on documented evidence (7.5) of that awareness |
Technological controls — secure configuration, change management | Requires competent personnel (7.2) and controlled change records (7.5) |
If you're working through the full Annex A control set rather than just the Clause 7 intersections, our Annex A — All 93 Controls at a Glance reference and the SoA Template are the two assets I recommend keeping open side by side while you draft control justifications, since a surprising number of SoA justification gaps trace directly back to an unaddressed Clause 7 dependency like the ones in the table above.
What auditors actually ask in interview
Documentation review is only half of how Clause 7 gets tested. The other half happens in staff interviews, where an auditor is deliberately trying to find the gap between what your documented information claims and what people actually know or do. Preparing your team for the style of question, not just the content, materially reduces the odds of an awkward pause turning into a nonconformity.
Sample interview question | What it's really testing | Clause |
|---|---|---|
"Can you show me the current information security policy on your own laptop, right now?" | Whether the controlled version is genuinely what's distributed and accessible | 7.5.3 |
"What happens if you don't follow this policy?" | Awareness of nonconformity implications | 7.3 |
"Who approved this procedure, and when was it last reviewed?" | Whether review/approval metadata is real and current | 7.5.2 |
"How do you know your training actually worked?" | Effectiveness evaluation, not just completion | 7.2 |
"If you spotted a phishing email, what would you do, and who would you tell?" | Practical awareness translating into behavior | 7.3 |
"Show me last year's version of this document." | Version history and retention discipline | 7.5.3 |
"Who do you escalate a security concern to, and how quickly?" | Communication plan knowledge at the individual level | 7.4 |
The pattern across nearly all of these questions: auditors are testing recall and behavior under mild pressure, not whether a policy exists in principle. Running a handful of mock interviews with staff — not just management — ahead of Stage 2 is one of the highest-leverage, lowest-cost preparation steps I recommend, and it routinely surfaces the same gaps a real auditor would find, while there's still time to fix them.
Scaling Clause 7 across multiple sites and subsidiaries
Clause 7 gets meaningfully harder once your ISMS scope spans more than one office, business unit, or legal entity, and it's an area I see multinational clients underestimate. A competence matrix built for a single headquarters function doesn't automatically capture a regional office with different local hiring practices, a different primary language, or different regulatory awareness obligations. A communication plan built around a single leadership team breaks down when a subsidiary has its own incident response chain that needs to plug into the parent company's within a defined time window.
The practical fixes are structural rather than exotic: maintain a single master competence matrix and communication plan template, but allow site- or entity-level annexes that capture local variations (language of training delivery, local regulatory notification obligations, regional escalation contacts). Keep document control centralized in one repository regardless of how many sites exist — a second, "local" repository is exactly how Solvera-style shadow copies start. And when awareness campaigns are translated or regionally adapted, version-control the translated content with the same rigor as the source, including a documented review step confirming the translation preserves the original meaning, since a garbled translation of "report suspicious emails immediately" is a genuine control failure, not a minor localization quirk.
Strategic close
Clause 7 rewards organizations that treat "Support" as infrastructure rather than paperwork. Resourcing, competence, awareness, communication, and documented-information control aren't separate compliance exercises — they're the operating system that makes every other clause credible in front of an auditor and, more importantly, effective in front of a real incident. The organizations that struggle with Clause 7 are almost never the ones lacking sophistication; they're the ones that built excellent controls once and then let the evidence trail — the matrix, the campaign calendar, the version history — go stale. Build the five artifacts in this article, review them on a fixed cadence tied to your management review, and Clause 7 stops being an audit risk and starts being one of the more defensible parts of your ISMS.
If you want a second set of eyes on your documented-information control system, competence evidence, or awareness program before your next audit, PentesterWorld's assessment team can run a focused Clause 7 readiness review alongside our broader ISO 27001 gap analysis and penetration testing services — get in touch to scope a review before your certification body finds the gaps for you.