Clause 7 is the infrastructure clause. It is where the ISMS gets the resources, skills, processes, and documentation it needs to function as something more than a planning exercise. Without Clause 7's requirements being genuinely met, the risk assessment outputs from Clause 6 have no reliable mechanism for being implemented, monitored, or communicated — and the management system structure from Clauses 4 and 5 has no operational substance.
The five sub-clauses — resources, competence, awareness, communication, and documented information — might seem mundane compared to the analytical work of Clause 6. In practice, Clause 7 failures are among the most common sources of audit findings and real-world security incidents. Undertrained staff fall for phishing attacks. Undocumented procedures produce inconsistent security decisions. Poor document control means policies are applied inconsistently because different teams are working from different versions. Resources allocated in name but not in practice mean controls are never fully implemented.
This article covers each Clause 7 sub-clause with the depth it deserves — what it requires, what adequate implementation looks like, and what auditors examine to test compliance.
Clause 7 at a Glance
Clause 7 contains five sub-clauses that together constitute the operational support infrastructure of the ISMS:
7.1 Resources People, tools, budget, time | 7.2 Competence Skills, training, evidence | 7.3 Awareness All staff security awareness | 7.4 Communication What, when, who, how | 7.5 Documented Info Document control & retention |
Clause 7.5 — documented information — is the most extensive sub-clause. It governs not just the creation and control of ISMS documents, but the entire lifecycle of all documented information that the ISMS requires or produces. Every policy, risk register entry, audit record, training completion record, management review minute, and corrective action is 'documented information' subject to Clause 7.5's controls.
Clause 7.1 — Resources
ISO 27001 requires the organization to determine and provide the resources needed to establish, implement, maintain, and continually improve the ISMS. The standard does not specify what those resources are — it requires the organization to determine them, based on the scope and complexity of the ISMS and the risk assessment findings.
Resource adequacy is one of the harder things to evidence in an audit. Saying 'we have the resources we need' is self-referential — auditors look for evidence that a deliberate determination was made, that the determination was based on ISMS requirements rather than budget convenience, and that the resources allocated are actually sufficient for the work the ISMS requires. The table below maps the five categories of ISMS resources to what adequate provision looks like, how to evidence it, and the most common gap pattern:
| Resource type | What adequate looks like | How to evidence it | Common gap pattern |
| People | Staff with defined ISMS responsibilities — ISMS Manager/CISO, risk owners in each business unit, IT security engineers, internal auditors, and an awareness training coordinator. | Organizational chart showing ISMS roles. Job descriptions including security responsibilities. RACI matrix. Signed role acceptance records. | ISMS responsibilities assigned informally with no documented role definition — cannot be evidenced and creates accountability confusion. |
| Budget | Approved financial allocation for ISMS activities — tooling, external audits, certification body fees, consultant support, training programs, and control implementation costs. | Annual budget document showing ISMS line items. Purchase orders for security tools. Certification body invoices. Training provider contracts. | Security budget absorbed into general IT budget with no ISMS-specific allocation — makes it impossible to demonstrate that resources are adequate for ISMS needs. |
| Technology & Tools | GRC platform, SIEM/logging tools, vulnerability scanners, access management systems, encryption tools, backup systems, and any other technology required to implement Annex A controls. | Asset register listing ISMS-supporting tools. Procurement records. Tool configuration evidence (screenshots, audit logs). Licensing documentation. | Tools acquired but not configured for ISMS use — a SIEM that generates logs but has no alert rules or review process provides no risk reduction. |
| Time | Protected time in staff schedules for ISMS activities — risk assessment reviews, internal audits, management reviews, awareness training, policy reviews, and corrective action closure. | Calendar records showing scheduled ISMS activities. Management review minutes showing attendance. Internal audit schedule and completion records. | ISMS activities consistently deferred because 'there is no time' — signals that time has not been formally allocated and the ISMS is not integrated into operational rhythms. |
| External Support | Consultant support for gap assessment, policy development, and audit preparation. Legal advice on regulatory interpretation. External penetration testing. Certification body services. | Consultant engagement letters. Penetration test reports. Legal advice records. Certification body correspondence. | Over-reliance on external consultants without building internal capability — creates ISMS that cannot be maintained without ongoing consultant involvement. |
| THE RESOURCE ADEQUACY TEST | A practical test for whether ISMS resources are adequate: could the ISMS survive the loss of its primary security person for three months? If the answer is no — if all ISMS knowledge and capability is concentrated in one person with no documented procedures, no cross-trained backup, and no external support relationships — then resources are inadequate by the standard's intent, even if a budget line exists. |
Clause 7.2 — Competence
Clause 7.2 requires the organization to determine the necessary competence for persons doing work that affects the organization's information security performance, ensure those persons are competent based on appropriate education, training, or experience, and retain documented information as evidence of competence.
The most important word is 'retain'. Competence claims without evidence do not satisfy the standard. If an auditor asks how the ISMS Manager is qualified to run an ISO 27001 risk assessment, the answer must be accompanied by evidence — a certificate, a training record, documented experience, or a combination. The answer 'they have ten years of security experience' requires corroboration, not just assertion.
Competence Requirements by ISMS Role
The following table defines the competence requirements and acceptable evidence for each key ISMS role in a typical Indonesian regulated organization:
| ISMS Role | Competence requirements | Evidence of competence |
| ISMS Manager / CISO | ISO 27001 lead implementer or auditor qualification; risk assessment methodology; Annex A controls knowledge; Indonesian regulatory frameworks (UU PDP, POJK, PBI, BSSN) | Lead implementer certificate; training records; CPE log; LinkedIn certifications |
| IT Security Engineer | Vulnerability management tools; SIEM configuration and monitoring; access management systems; encryption protocols; incident response procedures; cloud security (AWS/GCP/Azure) | Technical certifications (CISSP, CEH, CompTIA Security+, cloud certs); training completion records; hands-on evidence (system configs, audit logs) |
| Risk Owner (Business Manager) | Understanding of information security risk concepts; ability to review and approve risk treatment decisions; knowledge of information assets in their domain; UU PDP obligations for their function | Risk owner briefing attendance records; signed risk register entries; annual risk management training completion |
| Internal Auditor | ISO 27001 requirements knowledge; audit methodology; evidence sampling techniques; nonconformity classification; corrective action assessment; independence principles | ISO 27001 internal auditor qualification; audit methodology training; completed audit reports demonstrating competent findings |
| HR (Security Onboarding) | ISMS scope and policy overview; staff security obligations in employment contracts; background screening procedures; access revocation process | HR security responsibilities training records; onboarding checklist with security items; offboarding procedure sign-off records |
| Software Developer | Secure coding standards (OWASP Top 10); SAST/DAST tooling; dependency vulnerability management; secrets management; security review in CI/CD; data classification and handling | Secure coding training completion; OWASP awareness assessment; participation in code security reviews; tool usage logs |
| All Staff | Information security policy awareness; data classification and handling; phishing recognition; incident reporting procedure; acceptable use of IT systems; physical security obligations | Annual awareness training completion records; phishing simulation results; policy acknowledgment records |
When Competence Gaps Are Found
Clause 7.2 requires that when competence gaps are identified, the organization takes actions to acquire the necessary competence — and evaluates the effectiveness of the actions taken. This is a loop: identify gap, address it, verify the address worked. An organization that identifies a gap in developer secure coding competence, puts developers through training, and then fails to verify whether the training changed behavior has completed only part of the requirement.
Acceptable actions for addressing competence gaps include: training and education, mentoring by competent colleagues, process redesign to reduce reliance on individual competence for high-risk decisions, and hiring. The action must be proportionate to the risk created by the competence gap.
| Competence vs. awareness: These are different requirements. Competence (Clause 7.2) applies to people with specific ISMS roles — they must have the skills to perform their responsibilities. Awareness (Clause 7.3) applies to all staff — they must understand the policy, their obligations, and how to report incidents. A developer who has taken the organization's general awareness training but has not completed secure coding training is aware but not competent in their role's security requirements. |
Clause 7.3 — Awareness
Clause 7.3 requires that persons doing work under the organization's control are aware of: the information security policy, their contribution to ISMS effectiveness and the benefits of improved security performance, and the implications of not conforming to ISMS requirements.
The scope is deliberately broad — 'persons doing work under the organization's control' includes not just employees but contractors, temporary staff, and any other individuals whose work falls under the organization's operational direction. A contractor who accesses your systems and handles your customer data is within scope of Clause 7.3.
Designing a Security Awareness Program That Changes Behavior
The standard requires awareness — not just training completion. These are different. An employee who completed the annual e-learning module but still clicks every phishing simulation link is compliant with the letter of the training completion requirement but not with the spirit of the awareness requirement. The most effective awareness programs design for behavioral change, not administrative completion.
The table below provides a complete awareness program structure for an Indonesian regulated organization — mapping topics to audiences, frequency, delivery formats, and evidence records:
| Awareness topic | Audience | Frequency | Delivery format | Evidence record |
| Information Security Policy & Employee Obligations | All staff | Annual (+ new hire onboarding) | E-learning module + policy acknowledgment sign-off | LMS completion records; signed acknowledgments |
| Data Classification & Handling | All staff | Annual | E-learning with scenario exercises | LMS completion records; assessment scores |
| Phishing & Social Engineering Recognition | All staff | Bi-annual training + quarterly simulations | Interactive training + live phishing simulations | Training records; simulation click-through rates; trend data |
| Incident Reporting — How and When to Report | All staff | Annual + after significant incidents | Short video + quick reference card | Training records; incident report volume as proxy metric |
| Physical Security & Clean Desk Policy | All staff (office-based) | Annual | Briefing + physical walkthrough exercise | Attendance records; clean desk audit results |
| UU PDP — Personal Data Obligations | All staff handling personal data | Annual + when regulations update | Targeted e-learning with Indonesian regulatory context | Completion records differentiated by role; assessment pass rate |
| Risk Owner Responsibilities | Business managers (risk owners) | Annual risk owner briefing | Facilitated session with risk register review | Attendance records; signed risk acceptance documents |
| Secure Development Practices (OWASP) | Software developers & QA | Annual + on new framework adoption | Technical workshop + code review exercise | Training records; secure coding assessment results; SAST tool findings trend |
| Supplier & Third-Party Security | Procurement, vendor management, IT | Annual + on significant new supplier onboarding | Briefing on supplier security requirements and due diligence process | Training records; supplier assessment completion rates |
Measuring Awareness Effectiveness
Clause 7.3 awareness programs should be measured, not just delivered. Useful metrics include: phishing simulation click-through rates over time (trending down indicates effective awareness), incident report volume from non-IT staff (trending up indicates better reporting culture, not more incidents), security knowledge assessment scores, and policy acknowledgment completion rates.
These metrics should be reported at management review — they provide evidence that the awareness program is functioning as intended and create accountability for continuous improvement. A phishing simulation click-through rate that has been static at 18% for two years despite annual training is a signal that the training content or format needs redesigning, not repeating.
| Bitlion awareness integration: Bitlion's platform tracks awareness training completion, phishing simulation results, and policy acknowledgment records against individual staff profiles and team completion rates. This enables real-time visibility into awareness gaps — identifying which teams or roles have the lowest completion rates — and generates the evidence records auditors require without manual reporting overhead. |
Clause 7.4 — Communication
Clause 7.4 requires the organization to determine what internal and external communications are necessary for the ISMS — covering what will be communicated, when, to whom, who will communicate it, and the processes by which communication will occur.
This is often treated as a minor clause, addressed with a brief 'communication plan' document that satisfies auditors and is then forgotten. That is a missed opportunity. A well-designed communication plan is one of the most practical tools for keeping the ISMS operationally alive — ensuring that the right people receive risk information, audit findings, regulatory updates, and performance metrics at the right time, through the right channels.
| What | To whom | When | How | Evidence |
| Information Security Policy | All staff, contractors, relevant third parties | On publication; annually during awareness cycle; on policy update | Company intranet, email distribution, onboarding pack | Distribution records; intranet publish date; acknowledgment records |
| ISMS performance metrics | Top management, risk owners | Monthly dashboard; quarterly risk report; annual management review | Secured ISMS dashboard; management review pack; risk register access | Dashboard access logs; management review minutes; risk owner briefing records |
| Security incident alerts | Relevant staff and management based on severity | Immediately on detection (P1/P2); within 24hr (P3); weekly digest (P4) | Incident management platform alerts; direct escalation for high severity | Incident log with notification timestamps; escalation records |
| Risk assessment findings | Risk owners, top management, ISMS steering group | On completion of risk assessment; when significant new risks are identified | Risk register access; risk owner briefing sessions; management review | Risk owner briefing attendance; risk register access logs; management review minutes |
| Regulatory updates (UU PDP, POJK, PBI, BSSN) | ISMS Manager, Legal, relevant business units | On publication of new regulations or amendments | Legal/compliance team briefings; ISMS Manager notification; policy impact assessment | Legal briefing records; context analysis update records; policy review records |
| Audit findings and corrective actions | Auditees, process owners, top management | Within 5 working days of audit completion; monthly CAR status update | Audit report distribution; corrective action register; management review | Audit report distribution records; CAR register; management review minutes |
| Third-party / supplier security requirements | Suppliers, contractors, cloud providers | On contract execution; on significant ISMS scope change; annually | Supplier security addenda; contractual obligations; supplier briefings | Signed supplier agreements; supplier awareness records; third-party audit results |
Internal vs. External Communication
Internal communications cover all ISMS-related information flows within the organization — from the CISO to management, from the security team to staff, from risk owners to their teams. External communications cover information flows to regulators, clients, suppliers, certification bodies, and the public.
External communication requirements deserve particular attention in the Indonesian context. UU PDP Article 46 imposes a 14-working-day breach notification obligation to KOMINFO — the external communication process for security incidents must include a defined escalation path that reaches the notification decision-maker within that window. OJK and Bank Indonesia have their own reporting requirements for significant security incidents. These regulatory communication requirements must be explicitly addressed in the communication plan, not just in the incident response procedure.
| Regulatory communication as ISMS output: The communication plan is the document that connects the ISMS's operational security activities to the regulatory reporting obligations that create the most significant legal exposure. An organization that has a strong ISMS but no documented process for triggering the UU PDP 14-day notification has a gap in one of the highest-consequence requirements in the standard's operating environment. |
Clause 7.5 — Documented Information
Clause 7.5 is the most detailed sub-clause in Clause 7 and governs all documented information in the ISMS — both the documents that ISO 27001 explicitly requires and the documents the organization determines are necessary for ISMS effectiveness.
The standard has two categories of documented information requirements: 'documented information required by this document' (the explicitly required documents — SoA, risk assessment results, management review minutes, etc.) and 'documented information determined by the organization as being necessary for the effectiveness of the ISMS' (the organization's own policies, procedures, work instructions, templates, etc.). Both categories are subject to the full document control requirements of Clause 7.5.2 and 7.5.3.
Document Control Requirements: The Full Picture
Clause 7.5.2 specifies what document control must cover. The table below maps each requirement to its practical meaning and an implementation example:
| Clause 7.5 Requirement | What it requires | Implementation example |
| Identification and description | Each document must have a unique identifier, a title, version number, date, and author/approver identification. | ISMS-POL-001 | Information Security Policy | v2.1 | 2026-01-15 | Approved: CEO |
| Format and media | The format (digital, paper, or both) and storage medium must be defined. Digital-only is acceptable for most ISMS documents, provided access and backup controls are in place. | All ISMS documents stored in controlled SharePoint library with version history enabled; physical copies maintained only for emergency procedures. |
| Review and approval for suitability and adequacy | Documents must be reviewed before approval and re-reviewed when updated. Evidence of the review and approval must be retained. | Document review checklist completed by ISMS Manager; approval signature by CEO for policies, CISO for procedures. |
| Available and suitable for use, where and when it is needed | The right people must be able to access the right documents at the right time. Restricted access controls are fine, but legitimate users must not be blocked from documents they need. | ISMS intranet accessible to all staff; privileged ISMS documents (risk register, SoA) accessible to ISMS roles only; offline emergency kit for incident response. |
| Adequately protected | Documents must be protected against unauthorized access, modification, and accidental deletion. Backup and version control are implicit requirements. | Access controls on ISMS SharePoint library; change tracking enabled; automated daily backup; version history retained for minimum 3 years. |
| Distribution, access, retrieval, and use | The process for how documents are distributed, who can access them, how they can be retrieved, and how they are used must be defined and controlled. | Document distribution matrix specifying who receives each document type; access request process for restricted documents. |
| Storage, preservation, and legibility | Documents must remain readable and accessible for their required retention period. Formats that may become unreadable over time require migration procedures. | PDF/A format for long-term retention; annual legibility verification for documents older than 3 years; migration from proprietary formats when tools are retired. |
| Control of changes (version control) | All changes to controlled documents must be tracked — who changed what, when, why, and what the change was. Superseded versions must be retained but clearly marked as obsolete. | Change log embedded in each document; version comparison available in document management system; obsolete versions archived with date and reason for supersession. |
| Retention and disposition | Each document type must have a defined retention period after which it is either archived or securely disposed of. Retention periods must reflect legal and regulatory obligations. | Policy documents: retain 3 years after supersession. Audit records: retain 5 years. Risk assessment results: retain for full 3-year certification cycle plus 2 years. |
The Minimum ISMS Document Set
Organizations frequently ask what the minimum set of ISMS documents is. The answer depends on scope and complexity, but a baseline ISO 27001:2022 implementation for an Indonesian regulated organization typically requires the following controlled documents:
- Information Security Policy (explicitly required — Clause 5.2)
- ISMS Scope Statement (explicitly required — Clause 4.3)
- Risk Assessment Methodology (required to demonstrate Clause 6.1.2 consistency)
- Risk Register / Risk Assessment Results (explicitly required — Clause 6.1.2)
- Risk Treatment Plan (explicitly required — Clause 6.1.3)
- Statement of Applicability — SoA (explicitly required — Clause 6.1.3)
- Information Security Objectives Register (explicitly required — Clause 6.2)
- Competence Records for ISMS roles (explicitly required — Clause 7.2)
- Awareness Training Records for all staff (explicitly required — Clause 7.3)
- Internal Audit Program and Reports (explicitly required — Clause 9.2)
- Management Review Records / Minutes (explicitly required — Clause 9.3)
- Nonconformity and Corrective Action Records (explicitly required — Clause 10.1)
Beyond these explicitly required documents, a functioning ISMS also requires a supporting policy suite — access control policy, cryptography policy, supplier security policy, incident management policy, data classification policy, and others — plus procedures that operationalize the policies. The exact suite depends on which Annex A controls are applicable per the SoA.
| Document minimalism: More ISMS documents is not better. A smaller set of well-maintained, actually-used documents is more valuable than an exhaustive library that staff don't consult and that nobody maintains. Every document in the ISMS creates a maintenance obligation — it must be reviewed, updated when the business changes, and evidenced as current at every audit. Only create controlled documents that serve a genuine operational purpose. |
Required Outputs from Clause 7
Clause 7 produces five categories of documented outputs that auditors will examine. Three are explicitly required by the standard's text; two are required by implication:
| § | Required document / output | Status | What auditors examine |
| 7.2 | Competence records for ISMS roles | EXPLICIT | Retained evidence that persons with ISMS responsibilities have the required competence — training certificates, qualifications, or experience records. Must be retained as documented information. |
| 7.3 | Security awareness training records | EXPLICIT | Completion records for all staff awareness training, phishing simulation results, policy acknowledgment records. Must be retained. Completeness is tested — auditors will sample staff to verify. |
| 7.4 | Communication plan / register | Required | Documentation of what ISMS-related information is communicated, to whom, when, and how. Not explicitly named but required to demonstrate systematic communication management. |
| 7.5 | Documented information itself (all ISMS documents) | EXPLICIT | All documented information required by the standard — policies, procedures, risk register, SoA, audit records, management review minutes, corrective actions. Each must be controlled per Clause 7.5.2 and 7.5.3. |
| 7.5 | Document control procedure / framework | Required | The process by which ISMS documents are created, reviewed, approved, distributed, retained, and disposed of. Auditors will test document control by examining version histories and access controls. |
The competence records and awareness training records are particularly frequently tested during audits because they are highly specific — an auditor can sample five staff members, ask for their training completion records, and immediately assess whether the clause is being met. Organizations that cannot produce these records for staff sampled during audit face certain nonconformities.
Common Clause 7 Nonconformities
Training completion records that are incomplete or unretained
The most common Clause 7 finding is incomplete awareness training records — staff who have not completed the annual training cycle, contractors who were never enrolled, or records that exist in an LMS that nobody has verified covers all in-scope staff. Evidence completeness matters: an auditor who samples five staff members and finds one with no training record will raise a nonconformity regardless of how high the overall completion rate is.
Competence claimed without evidence
Security team competence is frequently asserted without documentation. 'Our CISO has 15 years of experience' is a claim, not evidence. ISO 27001 requires retained documented information as evidence of competence — which means something that can be produced and examined. CV records, training certificates, or a documented competence assessment with supporting rationale all qualify. Verbal assertions do not.
Document control that exists on paper but not in practice
A document control procedure that specifies version control, review cycles, and approval authorities — but where the actual ISMS documents are found in multiple versions across different SharePoint libraries, email attachments, and personal drives — is not functioning. Auditors test document control by asking which version of a policy is current and then checking whether the version number, date, and approval signature on the document in use match the controlled master. Discrepancies are immediate findings.
Awareness program that never changes
An awareness program running the same content, in the same format, at the same cadence every year without any evidence of effectiveness measurement or content improvement is a signal that the program exists for compliance rather than behavioral impact. The best ISMS awareness programs evolve: they refresh content in response to new threats, adjust delivery format based on completion and engagement data, and add new modules when the regulatory or threat environment changes.
| The document graveyard problem: Many organizations accumulate ISMS documents over successive implementation and audit cycles without ever retiring obsolete ones. Policies that were superseded three years ago remain visible on the intranet alongside current versions. Procedures that reference systems that no longer exist are never removed. Old risk assessments are not archived or clearly marked as superseded. This creates a document graveyard — a set of controlled documents that nobody uses and that contradict the current state of the ISMS. Auditors will find and raise these inconsistencies. Annual document review cycles with explicit obsolescence decisions are the preventive measure. |
Clause 7 as the Operational Backbone
Clause 7 is not glamorous. No consultant leads a workshop on 'documenting competence records' or 'setting document retention periods'. But the organizations that invest properly in Clause 7 — that build genuinely skilled ISMS teams, run awareness programs that change behavior, manage communications systematically, and maintain clean, current documentation — find that every other ISMS activity is easier and more credible.
The risk assessments are better because the people doing them are competent. The controls are implemented more reliably because procedures exist and staff know what they are expected to do. The audits produce fewer findings because the evidence is organized and current. The management reviews are more productive because the metrics and records needed to inform good decisions are available and trustworthy.
Clause 7 is the operational backbone of the ISMS. Treat it as infrastructure, invest in it deliberately, and the entire management system runs more smoothly as a result.