There is a particular failure mode in ISO 27001 implementations that experienced auditors recognize within the first hour of a certification audit. They sit down with the CISO, ask about the management review, and the CISO reaches for a folder of beautifully formatted documents — minutes, metrics, action logs. Everything looks right on paper.
Then the auditor asks a simple question: when was the last time the CEO personally reviewed the risk register? The pause that follows tells them everything they need to know.
Clause 5 of ISO 27001 is the leadership clause — and it is the most commonly misunderstood requirement in the standard. Organizations read it as a documentation task: get the CEO to sign the policy, minute the management review, assign the CISO as 'responsible for information security', and move on. What the standard actually requires is something harder and more valuable: genuine executive ownership of information security as a business management function, not a delegated IT project.
This article explains what Clause 5 requires, why the distinction between nominal and real leadership matters, how to write an information security policy that satisfies both auditors and organizational reality, and how to structure ISMS roles so accountability is clear, complete, and actually exercised.
Clause 5 at a Glance
Clause 5 contains three sub-clauses that together establish the human governance architecture of the ISMS:
5.1 — Leadership & Commitment Top management obligations — non-delegable | 5.2 — Information Security Policy The governing policy document | 5.3 — Roles, Responsibilities & Authorities Who owns what in the ISMS |
These three sub-clauses are sequential by design. Leadership commitment (5.1) creates the conditions for a meaningful policy (5.2). A meaningful policy requires clearly assigned roles to implement and maintain it (5.3). All three are required — and all three have specific evidence requirements that auditors will test.
Clause 5.1 — Leadership and Commitment
ISO 27001 places nine specific obligations on top management in Clause 5.1. They are listed explicitly as things top management 'shall' do — not things they may delegate to a CISO, an IT manager, or a compliance team. The 'shall' language is deliberate: ISO is signaling that these responsibilities sit at the executive level and cannot be contracted away.
Understanding each obligation — and what evidence demonstrates compliance — is essential for both the ISMS implementation team and for the executives themselves. The table below maps every 5.1 requirement to its practical meaning and the evidence auditors look for:
| Clause 5.1 Requirement | What it actually means | Evidence auditors look for |
| Take accountability for the effectiveness of the ISMS | The CEO or equivalent cannot claim the ISMS is the CISO's responsibility. Accountability for whether the ISMS works sits at the top. | Signed information security policy. Participation in management reviews. Documented decisions on risk appetite. |
| Ensure information security policy and objectives are established and compatible with strategic direction | The policy must reflect what the business actually does and is trying to achieve — not be a generic document imported from a template library. | Policy document with CEO signature. Objective-setting records from management review. Alignment with business strategy documentation. |
| Ensure integration of ISMS requirements into the organization's processes | Security cannot be a separate IT project. It must be embedded in HR onboarding, procurement, product development, customer onboarding, and change management. | Procurement policy referencing security requirements. HR onboarding checklist including security training. Change management procedure with security assessment gate. |
| Ensure the resources needed for the ISMS are available | Budget allocation, staffing, tooling, and time for ISMS activities must be actively provided — not just nominally approved. | Budget records showing ISMS allocation. Staffing plan with ISMS responsibilities. Tool and platform procurement records. |
| Communicate the importance of effective information security management | Top management must visibly champion security — in all-hands meetings, in onboarding, in incident response — not just sign documents. | Communication records (town halls, emails, policies). Training completion records. Security awareness program ownership. |
| Ensure the ISMS achieves its intended outcomes | Setting objectives (Clause 6.2) and measuring whether those objectives are met (Clause 9.1) are management-level responsibilities. | Objective-setting records. Performance metrics reviewed in management review minutes. Corrective action records for missed objectives. |
| Direct persons to contribute to the effectiveness of the ISMS | All staff with security responsibilities must be directed — not just informed. Responsibilities must be assigned, resourced, and held accountable. | Role descriptions with security responsibilities. Accountability structure in RACI or equivalent. Performance review integration of security responsibilities. |
| Promote continual improvement | The directive for the ISMS to improve must come from the top. Management review outputs must include improvement decisions, not just status reports. | Management review minutes showing improvement decisions. Corrective action closure records. Year-on-year ISMS maturity assessment. |
| Support other relevant management roles to demonstrate leadership in their areas | The CEO must create conditions where department heads take security seriously in their own domains — not just defer to the CISO. | Business unit security objectives. Department-level security KPIs. Evidence of non-IT management participation in risk assessments. |
| THE DELEGATION BOUNDARY | Top management can delegate management of the ISMS to a CISO or security team. They cannot delegate accountability for its effectiveness. The distinction matters in a regulatory context: when OJK or Bank Indonesia investigates a security incident, the question they ask is not 'who was the CISO?' — it is 'what did leadership know, when did they know it, and what decisions did they make?' |
Real vs. Nominal Leadership: The Difference Auditors Test
ISO 27001's leadership requirements can be satisfied in two fundamentally different ways. The first is nominal compliance — signing the policy, attending the annual management review, approving the ISMS budget as a line item in the IT budget. This produces the right documentation and passes a superficial audit review.
The second is genuine compliance — where top management actually understands the organization's risk posture, makes informed decisions about risk treatment, visibly champions security culture, and holds the ISMS accountable for delivering outcomes. This produces both documentation and a functioning management system.
Experienced auditors know the difference. They probe it through specific questions, cross-references between documents, and conversations with non-security staff. The table below maps six specific signals that distinguish real leadership from nominal compliance:
| Signal | Nominal leadership (fails audit intent) | Real leadership (passes audit intent) |
| Management review attendance | CEO attends annually, reads pre-prepared summary, approves recommendations without discussion | CEO chairs the review, asks specific questions about risk register changes and incident trends, challenges metrics that seem too good |
| Information security policy | CEO signs a template policy. Has not read it. Cannot explain what the organization's risk appetite is. | CEO co-authored the policy's risk appetite statement. Can articulate why specific risks are accepted or treated. Reviews it annually. |
| Security incident response | CEO is informed after containment. Not involved in decisions. Focused on PR. | CEO is part of the escalation path for high-severity incidents. Participates in post-incident reviews. Ensures learnings are addressed. |
| Budget allocation | Security budget is part of IT budget, approved without specific discussion of ISMS needs. | Security budget is a line item with documented rationale. CEO has reviewed and approved the ISMS-specific resource requirements. |
| Staff awareness messaging | Security awareness is an IT initiative. No visible executive sponsorship. | CEO opens the annual security awareness campaign with a personal message. Security is visibly a leadership priority. |
| Risk treatment decisions | High risks are treated by the IT team without business owner involvement. Risk owners are unaware they own risks. | Risk owners are business managers who actively participate in risk treatment decisions and formally accept residual risks. |
| Indonesian regulatory context: OJK's IT governance assessment framework for financial institutions evaluates board and executive engagement with IT risk — including information security — as a distinct assessment dimension. Organizations where the board cannot demonstrate active oversight of information security risk face adverse findings in supervisory assessments, independently of whether they hold an ISO 27001 certificate. The certificate and the genuine governance behavior are not the same thing. |
Clause 5.2 — Information Security Policy
The information security policy is the most visible document in the ISMS. It is the first thing auditors request, the document regulators are most likely to ask for, and the foundation on which all more specific security policies and procedures are built. Getting it right matters more than most organizations realize.
ISO 27001 sets specific requirements for what the policy must contain. These are not suggestions — they are mandatory requirements that auditors check directly. A policy that is missing any of these elements has a gap that will be raised as a nonconformity:
| Policy requirement (Clause 5.2) | What it means in practice | Required |
| Appropriate to the purpose of the organization | The policy must reflect what your organization actually does — its sector, its data types, its regulatory environment. A generic template that does not mention UU PDP for an Indonesian data processor is not appropriate. | ✓ YES |
| Includes information security objectives or provides a framework for setting them | Either state the objectives directly in the policy, or describe how objectives will be set and reviewed. The objectives themselves are required by Clause 6.2 — the policy must at minimum reference them. | ✓ YES |
| Includes a commitment to satisfy applicable requirements | Explicitly states that the organization will comply with applicable laws, regulations, contractual requirements, and its own ISMS requirements. This is the legal and regulatory commitment in writing. | ✓ YES |
| Includes a commitment to continual improvement | States explicitly that the ISMS will be continuously improved — not just maintained at current levels. | ✓ YES |
| Available as documented information | The policy must be a controlled document — versioned, dated, signed, and retained. Not a draft, not an email, not a slide deck. | ✓ YES |
| Communicated within the organization | All employees must be aware of the policy. Evidence of communication includes intranet publishing, email distribution, and training records. | ✓ YES |
| Available to interested parties as appropriate | Regulators, key clients, and certification bodies may request the policy. It must be available to them — typically a summary version for external stakeholders. | ✓ YES |
What a Good Information Security Policy Actually Looks Like
The most common policy failure is generic content that could apply to any organization. A policy that states 'we are committed to protecting the confidentiality, integrity, and availability of our information' is true but useless — it tells auditors and staff nothing specific about this organization's security approach.
A strong information security policy is specific about the organization's context. It names the regulatory frameworks the organization is subject to — not generically but by name: UU PDP No. 27/2022, POJK 11/POJK.03/2022, PBI No. 23/6/PBI/2021. It states the organization's risk appetite in terms that are meaningful for the business. It identifies the information security objectives or describes how they will be set. It is written in language that a non-security employee can understand and act on.
A policy that runs to 20 pages of technical requirements is not an information security policy — it is a security standard. The policy is the high-level governance document. Supporting policies and procedures operationalize it. Both are needed, but they serve different purposes and audiences.
| Policy structure recommendation: The information security policy (Clause 5.2) should be a concise, signed, CEO-level document — typically 2–4 pages — that states the organization's commitment, its risk appetite, its regulatory obligations, its objectives framework, and its accountability structure. Everything more specific — access control policy, cryptography policy, supplier security policy — belongs in the supporting policy suite, not in the top-level document. |
Version Control and Communication
The policy must be available as documented information — meaning it must be versioned, dated, and controlled. Every revision should be approved by top management, recorded with a change history, and redistributed to all relevant parties. Auditors will check whether the version on the intranet matches the version in the ISMS document register. Discrepancies are minor nonconformities but signal broader document control weaknesses.
Communication of the policy to all staff is explicitly required. Evidence includes intranet publication records, email distribution logs, policy acknowledgment records, and training completion data showing that staff have read and understood the policy. Annual policy refresh training is the most common mechanism — it simultaneously satisfies the communication requirement and provides evidence of the awareness obligation from Clause 7.3.
Clause 5.3 — Organizational Roles, Responsibilities, and Authorities
Clause 5.3 requires top management to assign and communicate the responsibilities and authorities for roles relevant to information security. The standard specifically requires that two categories of roles are assigned: those who ensure the ISMS conforms to the requirements of ISO 27001, and those who report on the performance of the ISMS to top management.
This is deceptively simple. The complexity is in building an accountability structure where the right people own the right things, where the boundaries between roles are clear enough to prevent gaps and overlaps, and where the people assigned to roles actually know they have them and what is expected.
The Full ISMS Accountability Architecture
ISO 27001 does not prescribe specific job titles — it describes functions. How those functions are distributed across roles depends on the organization's size and structure. The table below maps the key ISMS functions to typical organizational roles, with clear distinction between what each role owns, can delegate, and cannot delegate:
| Role | Owns in the ISMS | Can delegate | Cannot delegate |
| CEO / Managing Director | Ultimate accountability for ISMS effectiveness; risk appetite decisions; information security policy approval; management review chair | Day-to-day ISMS management; technical control implementation; risk assessment execution | Delegate accountability for ISMS effectiveness; sign away responsibility for security incidents to the CISO |
| CISO / Head of Information Security | ISMS operational management; risk assessment methodology; control selection and oversight; internal audit program; incident response leadership; reporting to top management | Control implementation to technical teams; awareness training delivery; physical security to facilities management | Accept residual risks on behalf of risk owners; approve budget for ISMS — that requires management authorization |
| Risk Owners (Business Managers) | Approval of risk treatment decisions for risks in their domain; acceptance of residual risks; accountability for control effectiveness in their area | Risk assessment execution to security team; control implementation to IT | Delegate accountability for residual risk acceptance; claim ignorance of risks in their domain after risk assessment |
| IT / Engineering Teams | Technical control implementation; vulnerability management; access management operations; security monitoring; incident technical response | Nothing — technical implementation is their core ISMS contribution | Set risk appetite; approve scope changes; accept risks on behalf of business owners |
| HR Department | Security screening in recruitment; security obligations in employment contracts; onboarding security training delivery; offboarding access revocation process | Technical access revocation to IT | Define information security policy; approve security budget |
| Legal / Compliance | Regulatory requirement identification; data processing agreement review; breach notification legal obligations; contractual security requirement interpretation | Technical implementation of compliance controls to security team | Make risk treatment decisions; approve security architecture |
| Internal Audit | Independent ISMS audit execution; nonconformity identification; corrective action verification; reporting to top management | Nothing — independence requires direct reporting, not delegation | Implement controls they may later audit; report only to CISO (must have path to top management) |
The CISO's Position in the Accountability Structure
A common organizational mistake is positioning the CISO as the person who is accountable for information security outcomes — full stop. This misunderstands both the CISO's role and the leadership requirements of ISO 27001. The CISO is accountable for managing the ISMS — designing it, running it, reporting on it, and continuously improving it. Accountability for the outcomes of information security risk — for whether the organization's risk exposure is acceptable — sits with the risk owners and ultimately with top management.
This distinction matters practically. If a high-severity risk is identified and the CISO recommends treatment but the business owner declines to allocate the required budget, the CISO has fulfilled their responsibility by raising and documenting the risk. The business owner and top management bear the accountability for the residual risk that results from the budget decision. A CISO who accepts risk on behalf of business owners without their explicit, documented consent is taking on accountability that is not theirs to carry.
| Role clarity as a cultural signal: The clearest sign that roles are real rather than nominal is when business managers outside IT spontaneously reference their security accountability. When the Head of Product asks the security team to review a new feature's data handling before launch — not because a process requires it, but because they understand it is their responsibility — Clause 5.3 is functioning as intended. This does not happen through an RACI document alone. It requires the organizational behavior that genuine top management commitment (5.1) creates. |
Communicating Roles
Assigning roles is not sufficient — they must be communicated. Auditors will check whether the people assigned to ISMS roles know they have them. Common evidence includes: signed role descriptions that explicitly include ISMS responsibilities, inclusion of security responsibilities in job descriptions and performance objectives, documented awareness that specific individuals have been assigned as risk owners for specific risks, and RACI matrices that are accessible to relevant staff rather than filed in the ISMS document archive.
The communication requirement is particularly important for risk owners. Risk owners who do not know they are risk owners will not participate in risk treatment decisions or accept residual risks — which means those decisions are being made informally, without documentation, in a way that fails both Clause 5.3 and Clause 6.1.3. An annual risk owner briefing — documenting that business managers have been briefed on the risks assigned to them — is a practical and auditor-friendly approach.
Required Outputs from Clause 5
Clause 5 produces four specific outputs that auditors will examine during a certification audit. Understanding what each output requires — and what the difference is between an explicitly mandated document and an implied requirement — helps prioritize documentation effort:
| § | Required document / output | Status | What auditors examine |
| 5.1 | Management review minutes (ongoing) | Required | Minutes from management reviews demonstrating top management engagement — agenda items, decisions made, actions assigned. Absence is a major nonconformity. |
| 5.2 | Information Security Policy | Explicit | A controlled, signed, dated policy document meeting all Clause 5.2 content requirements. One of the most scrutinized documents in a certification audit. |
| 5.3 | Roles and responsibilities documentation | Required | Documented assignment of ISMS roles — typically in an RACI matrix, role descriptions, or equivalent. Auditors will ask who is responsible for what and expect documented evidence. |
| 5.3 | Communication of roles to relevant persons | Required | Evidence that people assigned ISMS roles know they have those roles — awareness training records, role acceptance letters, or signed role descriptions. |
The information security policy (5.2) is the only explicitly named document in Clause 5 — its absence is a clear major nonconformity. The management review minutes and role documentation are required by implication — without them, it is impossible to demonstrate that the explicit requirements are being met. In practice, auditors treat all four outputs as mandatory.
Common Clause 5 Nonconformities and How to Avoid Them
Leadership defined as the CISO, not top management
The standard is clear: Clause 5.1 obligations belong to top management — the CEO, the board, the managing director. Organizations that assign all Clause 5.1 responsibilities to the CISO have created a structural nonconformity. The CISO can support and implement the leadership obligations, but the accountability must sit at the top.
Information security policy that is not approved by top management
Policies approved and signed by the CISO, Head of IT, or Compliance Manager — rather than the CEO or equivalent — do not satisfy the leadership requirement. The policy is the governance instrument of top management. It must carry their explicit authorization, not just awareness.
Management review minutes that are templated summaries
Minutes that repeat the same language in every review — 'the ISMS continues to operate effectively' — without specific data, specific decisions, and specific actions assigned to named individuals signal that the management review is a documentation exercise rather than a genuine governance activity. Auditors look for evidence of actual deliberation: questions raised, data examined, decisions made, and follow-up tracked.
Roles documented but not communicated
An RACI matrix filed in the ISMS SharePoint folder that nobody except the CISO knows exists does not satisfy the communication requirement. Evidence of communication means records showing that the relevant people have been informed of their roles — not just that the document exists.
| The leadership gap in Indonesian organizations: In Bitlion's implementation work, the most common leadership gap in Indonesian mid-market organizations is not malicious neglect — it is organizational structure. Many Indonesian companies run information security as a function within IT, with the CTO as the executive sponsor rather than the CEO or board. This structure works operationally but creates a systemic Clause 5.1 gap: the CEO is not directly engaged with information security risk, and the management review is an IT governance activity rather than a board-level governance activity. Correcting this requires explicit restructuring of the ISMS reporting line — typically elevating the CISO to report to the CEO or establishing a formal information security steering committee with board-level participation. |
Why Clause 5 Is Worth the Organizational Effort
Clause 5 is the hardest clause to implement well precisely because it requires changing how an organization thinks about security — from a technical function owned by IT to a business management function owned by leadership. That change does not happen through a policy document or an RACI matrix. It happens through sustained, visible executive engagement over time.
The organizations that have made this transition consistently report that it changes the quality of every other ISMS activity. Risk assessments become more honest because business managers participate in them. Risk treatment decisions become better because they are made with full organizational context. Incident responses become faster because escalation paths are clear and exercised. Audits become less stressful because the evidence reflects what the organization actually does, not what it claims to do.
Clause 5 is not just a compliance requirement. It is the organizational transformation that makes the ISMS worth building.