The ISO 27001 Governance Chain: Why Controls 5.1 Through 5.4 Stand or Fall Together

Here is a situation that shows up in real audits more than it should. The information security policy is impeccably formatted, forty-plus pages, signed by the CEO, uploaded to the company intranet. The ISMS documentation binder is immaculate. And then the auditor asks one follow-up question: “Does the CEO use multi-factor authentication?”

The answer is no. He finds it inconvenient.

That gap, between what is documented and what is lived, is exactly what ISO/IEC 27002:2022 §5.4 exists to close. And it is where most ISMS programs actually break, not in technical controls, not in documentation gaps, but in the visible behavior of the people who sign the policies and quietly exempt themselves from following them.

This post is about why controls 5.1 through 5.4 are not four separate checkboxes on an Annex A gap assessment. They are a governance chain. Each link depends on the one before it. When management behavior (5.4) contradicts the documented roles (5.2) and policies (5.1), segregation of duties (5.3) becomes practically unenforceable, and the entire compliance posture is built on paper.

The Four Controls: What They Actually Do

Most introductions to ISO 27001 treat Annex A as a list to work through sequentially. That reading misses the architecture.

Control 5.1 establishes the information security policy — what practitioners sometimes call “the constitution of the ISMS.” It defines management direction, scope, objectives, and the commitment to continual improvement. It must be approved by top management, communicated to all relevant parties, and reviewed at planned intervals or whenever significant changes occur.

Control 5.2 assigns roles and responsibilities. Every material asset needs a named owner. Every accepted residual risk needs a named risk owner. The critical phrase in the standard: individuals can delegate tasks but they remain accountable. The accountability does not transfer with the work.

Control 5.3 implements segregation of duties. Conflicting duties shall be separated. The standard provides specific examples: initiating versus approving a change, requesting versus provisioning access rights, developing code versus deploying to production. Where full segregation is genuinely infeasible, compensating controls, audit trails, and supervisory review are required.

Control 5.4 is management responsibilities. All personnel shall apply information security in accordance with established policy. Management shall ensure personnel are briefed before access is granted, trained on an ongoing basis, and given adequate resources and project planning time to do security work properly. There must be a confidential, anonymous whistleblowing channel. Management shall visibly enforce what the policy says.

The dependency chain is tight. 5.1 produces the rules. 5.2 names who is accountable for them. 5.3 structures workflows so no single person can both commit and conceal a violation. 5.4 is what makes all three real in daily practice rather than in documentation alone.

This is where the architecture is most vulnerable.

The Technical Layer: How the Cascade Fails

The most common real-world failure sequence runs something like this.

The policy (5.1) exists and has been formally approved. But it was last reviewed 26 months ago. Since that review, the organization completed a cloud migration and rolled out AI tooling to three business units. The policy says nothing about either. The constitution no longer governs what engineers are actually doing day to day.

Because the policy is stale, the roles assigned under 5.2 are misaligned with the current asset landscape. An asset owner was named for the on-premises file server. The equivalent SaaS repository has no named owner. Nobody receives the quarterly access-review reminders because nobody was configured to receive them. An ex-contractor account remains active for seven months after the person’s last day.

Because roles are undefined for newer systems, segregation of duties under 5.3 cannot be enforced consistently across the estate. A senior engineer builds the feature, reviews the pull request, and deploys to production, not out of malice, but because the change management workflow was never updated when the team moved to CI/CD. The standard’s explicit example, developer versus production deployer as incompatible roles, is violated as a matter of routine.

And because none of this surfaces to the managers responsible under 5.4, the cultural signal from leadership is that these controls are optional in practice. When junior staff observe senior leaders sharing credentials, skipping phishing simulations, or pressuring the security team to ship with unresolved findings, the informal rule displaces the formal one. The ISMS becomes documentation auditors see and practitioners quietly ignore.

One specific failure worth naming directly: the CI/CD service account problem. A single service account holding commit, build, sign, push, deploy, and merge-gate authority concentrates in one credential what §5.3 explicitly requires to be separated. Compromise of the runner token is compromise of the production estate. This is not a hypothetical. It is the configuration pattern present in several significant supply chain incidents, and it fails ISO 27001 §5.3 the moment a technical auditor maps the account’s entitlements against the toxic combinations matrix.

The Governance Layer: Why Behavior Beats Documentation

ISO/IEC 27002:2022 §5.4 contains a detail that many practitioners underweight on first read. Management shall provide personnel with adequate resources and project planning time for security work.

This is not only about budget lines. It is about whether delivery pressure can override security gates, and specifically who has the authority and the backing to say no when it does.

In organizations where 5.4 is functioning, a project manager cannot ship a feature with an unresolved critical finding unless a named risk owner accepts the residual risk in writing, with a signed and dated acceptance statement and a defined review date. The security gate has operational teeth because management gave it structural teeth. The CISO has direct reporting access to executive leadership. Security objectives appear in performance reviews with measurable weight.

In organizations where 5.4 is failing, the pattern is recognizable. The security team raises a concern. It gets logged in the tracking system. As the release date approaches, it quietly drops in priority. No signed risk acceptance. No named risk owner. No documented rationale. The finding disappears into backlog, and the next audit will rediscover it.

The governance question auditors are now asking, particularly under frameworks that introduce personal management liability, is: who specifically was responsible for that decision, and what did they sign?

In my Lead Auditor training, the controls that seemed most administrative on paper, 5.1 through 5.4, were the ones our instructors identified as the most frequent root cause of certification failures. Not because documentation was absent. Because the audit evidence revealed the distance between what was approved and what was practiced.

The Compliance Layer: Regulatory Teeth on Management Accountability

ISO 27001 certification requires external surveillance and recertification audits. But the compliance landscape around management accountability has expanded well beyond the standard itself, particularly for US-market organizations.

SOX §404 has required segregation of duties over financial reporting controls since 2002. Every US public company has been managing this for over two decades. The question ISO 27001 surfaces is whether those SoD principles extend into information security operations beyond financial transaction workflows. For most large organizations, the answer should be yes, and auditors increasingly expect to see the mapping.

SEC Regulation S-K Item 106 (17 CFR §229.106) now requires public companies to disclose in their annual 10-K filing how management assesses and manages cybersecurity risk, management’s role in implementing cybersecurity programs, and board oversight of cybersecurity risk. This is a direct compliance hook for §5.4: what management does, or visibly fails to do, is now a disclosed material fact subject to investor scrutiny and enforcement action.

NIS2 Article 20 makes management bodies in in-scope entities directly responsible for approving cybersecurity risk-management measures and overseeing their implementation. The Directive further requires that management bodies can be held liable for infringements of the cybersecurity risk-management obligations set out in Article 21, with the precise scope and mechanism of personal liability depending on each Member State’s national implementation. As of 2026, regulators across the EU are increasingly emphasizing board accountability, but enforcement practices and personal-liability mechanisms remain uneven across Member States and are still developing.

This provision represents one of the strongest regulatory expressions of what ISO/IEC 27001 Clause 5 (Leadership) has long required in principle: senior management must not merely delegate cybersecurity responsibilities but must actively direct, support, and oversee them.

The combined picture: the management behavior gap that §5.4 addresses is no longer a certification concern only. It is a disclosure and personal liability concern in multiple jurisdictions. The CISO who cannot demonstrate visible management enforcement has a compliance problem with consequences that now extend beyond the ISO audit cycle.

What This Means for the GRC Analyst on the Ground

When assessing an organization's compliance with controls 5.1 through 5.4, the documentation is the starting point, not the conclusion. Here is what to look for, and what to produce as audit-ready evidence.

For 5.1: Pull the information security policy with full version history. Compare the date of last management-approved review against every significant event since: cloud migration, AI tool adoption, remote-work shift, M&A, major incident, new regulation. If significant events occurred without a corresponding policy update, that is a finding. The evidence artefact to produce: policy document with version history, approval records, and a gap table mapping events against review cycles.

For 5.2: Request the asset register with named owners and the risk register with signed, dated residual risk acceptance statements. Then verify gaps: assets with no named owner, accepted risks without a signing date, risks accepted by individuals who have since left the organization or changed roles. The evidence artefact: a RACI matrix with named individual ownership mapped against the asset and risk registers, verified against current HR records.

For 5.3: Do not accept the RBAC role list at face value. Request a sample of 10 recent production changes and trace initiator, approver, and implementer as three distinct identities. For development workflows, check whether engineers can merge their own pull requests without a second reviewer. For CI/CD pipelines, identify whether any service account combines build, deploy, and approval authority. The evidence artefact: the toxic combinations matrix with a corresponding IGA or access-review report showing either zero open violations or documented, time-bounded accepted exceptions with compensating controls.

For 5.4: Most analysts stop at training completion rates. The actual evidence question is whether management visibly enforces what the policy requires. Ask for the last disciplinary action for a security violation at the director level or above. Ask for MFA enrolment rates broken down by grade, including the executive team. Ask for the most recent case where a delivery deadline conflicted with a security finding, and what the documented outcome was. Ask whether security objectives appear in performance reviews with measurable targets. The evidence artefact: a KPI dashboard showing security objective completion rates by organizational grade, confirmed as reviewed by executive leadership at a defined cadence.

A risk register row worth adding: “Management behavior gap for §5.4 Likelihood: Medium; Impact: High; Control owner: CHRO + CISO; Control: Security objectives in performance management, executive MFA enrolment reporting, board-level culture metrics; Residual risk: Accepted, reviewed annually.”

Five Things I would Do This Quarter as Auditor

1. Audit your policy review trigger list. Enumerate every significant change in the past 24 months and map each one against your policy change log. Gaps between events and policy updates are findings, not backlog items.

2. Run a named-owner coverage check on your top 50 assets by business criticality. Remove any owner who has departed or changed roles. Fill gaps before the next audit cycle, not during it.

3. Map your CI/CD and automation service accounts against your SoD toxic combinations matrix. Any account combining build, deploy, and approval authority is a §5.3 nonconformance. Document either the remediation plan or the compensating controls with explicit supervisory review evidence.

4. Pull the most recent disciplinary action for a security policy violation at each organisational grade, including senior leadership. If none exists above a certain level, that is your §5.4 culture finding. Document it. It tells you where tone-from-the-top failed.

5. Add MFA enrolment rate by grade, including the C-suite and board, to your executive risk committee pack. If any grade is below 100%, that is your management responsibilities finding. For publicly traded companies: this governance posture is what SEC Item 106 disclosures are describing. Make sure what you report externally matches what the evidence supports internally.

ISO/IEC 27001:2022 Annex A references: §5.1, §5.2, §5.3, §5.4 (ISO/IEC 27002:2022 guidance). US compliance anchors: SOX §404, 17 CFR §229.106 (Regulation S-K Item 106). EU references: NIS2 Article 20.