Annex A 5.4: Management Responsibilities

Annex A 5.4 is one of the fastest ways auditors assess whether your ISMS is real or performative. If management responsibilities are vague, security becomes “the security team’s problem,” and controls drift, exceptions pile up, and basic governance breaks during incidents. This control pushes you to make managers part of the operating model: they must communicate expectations, enforce compliance in their teams, and support the security program with decisions, resources, and follow-through.

For a Compliance Officer, CCO, or GRC lead, the practical problem is rarely writing another policy. The problem is converting security intent into management action that you can prove happened. That means mapping responsibilities to specific roles, creating management-run routines (approvals, reviews, acknowledgements, escalations), and producing evidence that shows managers did the work and addressed findings.

This page gives requirement-level implementation guidance you can put in place without redesigning your entire ISMS, aligned to ISO/IEC 27001’s information security management approach ¹ and the public index of Annex A controls ².

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.4 implementation expectation (Management Responsibilities).” ³

What the operator must do

Because the full ISO standard text is licensed, treat the excerpt as a control intent statement: management must be assigned responsibility for information security and must actively drive compliance with information security requirements. Practically, you need to show three things during audit or customer diligence:

1. Clear accountability: named roles in management are responsible for enforcing security requirements within their scope.
2. Active direction and oversight: management communicates requirements, makes security decisions (approvals, exceptions), and monitors follow-through.
3. Proof of operation: records exist that show management responsibilities were carried out consistently, not only defined on paper.

This is where teams commonly fail: they can show an Information Security Policy, but cannot show which managers operationalize it, how often, and what evidence proves it ran ¹.

Plain-English interpretation (what this means in practice)

Annex A 5.4 asks: “Who in management is responsible for making security happen, and can you prove they did it?”

In practice, auditors look for a management chain of custody:

• Security requirements exist (policies/standards).
• Management assigns responsibility to real roles (not a generic “IT”).
• Managers communicate expectations to their teams.
• Managers approve or reject risky actions (access, exceptions, changes).
• Managers respond when requirements are missed (remediate, discipline, retrain, or adjust controls).
• You can show evidence for all of the above.

Who it applies to (entity and operational context)

Applies to: organizations implementing or maintaining an ISO/IEC 27001 ISMS, including service organizations that rely on consistent execution across teams ¹.

Operational contexts where Annex A 5.4 is tested hard:

• High-change environments: frequent releases, infrastructure changes, or onboarding where managers must enforce process gates.
• Decentralized operations: multiple departments or regions where security cannot be centralized.
• Third-party heavy stacks: many external providers where managers request, approve, and renew access and contracts.
• Regulated customers / enterprise diligence: customers expect governance proof, not assertions.

What you actually need to do (step-by-step)

Step 1: Define a “management responsibilities” control card (make it executable)

Create a one-page control card (runbook) that states:

• Objective: ensure management assigns and enforces information security responsibilities.
• Scope: which business units, systems, and sites are included.
• Owner: a named role (often CISO/Head of Security for design; business leaders for execution).
• Operators: people managers, system owners, process owners.
• Cadence and triggers: new hire onboarding, role changes, access changes, policy updates, incidents, audit findings.
• Exception rules: who can approve deviations and how they are recorded. This aligns with the practical expectation that teams can show ownership, cadence, and evidence ¹.

Tip: Put this control card in the same place as other ISMS controls so it becomes auditable and versioned.

Step 2: Build a RACI that pins responsibilities to management roles

Create a RACI that maps at minimum:

• Business unit leaders
• Department heads
• Engineering/IT management
• HR management
• Procurement/Vendor management leadership
• ISMS leadership (CISO/Head of Security)
• Compliance/GRC lead

Focus the RACI on decisions managers must make, for example:

• Approve access to sensitive systems
• Approve exceptions to security standards
• Confirm completion of required training for their teams
• Sign off remediation timelines for findings in their area
• Sponsor resources for risk treatment activities

Step 3: Convert policy expectations into manager workflows (where evidence naturally forms)

Policies don’t create audit trails. Workflows do. Implement these manager-operated mechanisms:

1. Manager security onboarding checklist

   • Manager confirms new hire role access needs.
   • Manager confirms security training completion.
   • Manager acknowledges key policies for the role.

2. Access approval and periodic confirmation

   • Manager approves initial access requests with a business justification.
   • Manager confirms ongoing need when roles change or during periodic access reviews.

3. Exception process with management sign-off

   • Document exception request, risk rationale, compensating controls, expiry date.
   • Require management approval for the owning team plus security review.

4. Findings ownership and closure

   • Assign findings to a management owner with due dates.
   • Require a closure note and validation evidence (screenshots, tickets, change records).

These are the routines that prove management responsibility exists beyond org charts.

Step 4: Define a minimum evidence bundle (so you’re never scrambling)

Write down, for each workflow above:

• Inputs (requests, tickets, forms)
• Approvals (manager sign-off, timestamps)
• Outputs (access granted, exception logged, remediation completed)
• Storage location (GRC tool, ticketing system, HRIS export)
• Retention expectation (align with your internal retention schedule)

This “minimum evidence bundle” approach is a proven way to avoid audit gaps ¹.

Step 5: Run control health checks and manage remediation to closure

Set a recurring check where you sample:

• Access approvals are present and attributable to managers.
• Exceptions have expiries and are re-approved or closed.
• Findings have owners and closure evidence.

Track failures as remediation items with owners and target dates, then validate closure ¹.

Where Daydream fits naturally: If you manage multiple controls and need consistent evidence capture, Daydream can standardize control cards, evidence bundles, and recurring health checks so managers produce the same audit-ready artifacts across teams.

Required evidence and artifacts to retain

Use this as your audit checklist:

Governance and accountability

• Management responsibilities control card (current version + prior versions)
• RACI matrix (dated, approved)
• Role descriptions or responsibility statements for key management roles

Management direction in operations

• Access request approvals showing manager approval and justification
• Exception register with management approvals and expiries
• Risk acceptance records (where applicable) signed by appropriate management
• Meeting minutes or decisions showing management action on security items (steering committee, ops reviews)

Oversight and follow-through

• Control health check results and sampling notes
• Remediation tracker with assignments, due dates, and closure validation
• Evidence of communications to staff (manager announcements, policy acknowledgements tied to teams)

Common exam/audit questions and hangups

Auditors and customer assessors tend to press on these:

• “Who in management is responsible for enforcing security requirements for system X?”
  Hangup: you name a team, not a role, or you can’t show it in writing.

• “Show me an example where a manager rejected or corrected a non-compliant request.”
  Hangup: only approvals exist; no evidence of challenge/oversight.

• “How do managers handle exceptions, and how do you ensure exceptions expire?”
  Hangup: exceptions exist but have no expiries or re-approval trail.

• “How do you know managers actually perform these responsibilities?”
  Hangup: you rely on policy attestation only, not operational records.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Responsibilities live only in a policy	Policies don’t show execution	Create workflows (approvals, registers, sampling) with traceable logs
“Security owns everything”	Managers disengage; audit sees weak governance	Assign business and IT managers as operators; security designs and verifies
No exception expiry	Permanent risk acceptance by accident	Require expiry dates and re-approval, track in a register
Evidence is scattered	Audit prep becomes a scavenger hunt	Define evidence bundles and a single system of record per artifact type
No follow-up on findings	Shows lack of oversight	Track remediation to validated closure with management owners 1

Enforcement context and risk implications (practical)

No public enforcement cases were provided in the source catalog for this specific control. Operationally, the risk is still real: when management responsibility is unclear or unprovable, audits and customer diligence often conclude your ISMS is not effectively implemented. That increases the chance of:

• delayed certifications or surveillance nonconformities,
• failed customer security reviews,
• repeat control failures because nobody owns remediation.

Treat this control as a governance multiplier: it determines whether other controls stay healthy.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Draft and approve the Annex A 5.4 control card (owner, scope, triggers, exceptions). ¹
• Publish a management-facing RACI and get explicit acceptance from department leaders.
• Stand up an exception register with required fields (owner, rationale, compensating controls, expiry, approver).
• Pick your system of record for evidence (GRC tool, ticketing, or a controlled repository with naming standards).

By 60 days (Near-term)

• Implement manager approval points in access request flows for sensitive systems.
• Roll out a manager onboarding checklist for new hires and transfers.
• Define minimum evidence bundles for: access approvals, exceptions, findings closure. ¹
• Run your first control health check sample and log issues.

By 90 days (Operationalized)

• Demonstrate two full cycles of management action: approvals/exceptions plus a health check plus remediation closure evidence. ¹
• Add Annex A 5.4 review to management meeting agendas (security steering or operational reviews) and retain minutes/decisions.
• Tune based on audit-style feedback: tighten RACI, clarify approval thresholds, fix evidence gaps.

Frequently Asked Questions

Does Annex A 5.4 require a formal “security steering committee”?

The requirement is management responsibility and active oversight, not a specific committee structure. A steering committee is a common way to produce repeatable decisions and evidence, but meeting minutes from existing leadership forums can also work.

Who should be the control owner: the CISO or a business executive?

Typically security leadership owns the control design and assurance, while business and IT managers own day-to-day execution in their areas. Auditors mainly care that responsibilities are assigned, accepted, and evidenced in operations.

What’s the minimum evidence to prove “management responsibilities” are operating?

Keep a RACI or responsibility statement, plus operational records that show managers approving access, approving/renewing exceptions, and owning remediation items through closure. Evidence should be attributable (names/roles) and time-bound (dates/timestamps).

How do we handle management responsibility in a small company where one person wears many hats?

Assign responsibilities to roles the company actually has (for example, “Head of Engineering” and “Operations Lead”) and document delegation where needed. Small orgs pass audits when responsibilities are explicit and the evidence trail is consistent.

Can HR own parts of this control?

Yes. HR often owns onboarding/offboarding workflows and policy acknowledgements, which are core to management enforcement. You still need business managers to approve access needs and enforce team compliance.

How do we keep this from turning into a paperwork exercise?

Anchor evidence to workflows you already run (access requests, ticket approvals, change management, findings remediation). If managers do security work inside normal systems, evidence becomes a byproduct instead of a separate reporting burden.

Footnotes

1. ISO/IEC 27001 overview

2. ISMS.online Annex A control index

3. ISO/IEC 27001 overview; Source: ISMS.online Annex A control index