ISO/IEC 27001:2022 · derived mapping target
A.5.4Management responsibilities
Make managers actively require staff to follow security policies and procedures within their teams. Leadership backing is what turns written rules into everyday practice.
Mapping at a glance
A.5.4Management responsibilitiesISO/IEC 27001:2022
A.5.4 is covered by 11 Sekit CSF controls. +6 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0002Policy management · ProcesssupportsThis process control runs the recurring routine that puts the policy in front of every employee, giving managers the operational engine A.5.4 needs to enforce it consistently.RCF-0005Roles & responsibilities · ProcesssupportsThis process control confirms that people assigned security duties perform them on a regular, verifiable rhythm, the accountability A.5.4 asks managers to enforce.RCF-0014Exception management · ProcesssupportsThis process control runs exception approvals through a recorded, time-bound flow, giving managers a concrete mechanism to require policy compliance while handling justified deviations.RCF-0017Regulatory compliance · ProcesssupportsThis process control carries out each legal obligation's recurring activities consistently across the company, the operational proof that managers are enforcing policy company-wide.RCF-0020Metrics & reporting · ProcesssupportsThis process control produces security indicators on schedule and reviews them with leadership, giving managers the data to see whether their teams follow policy.RCF-0028Security charter · PolicyenablesThis policy control establishes the signed charter naming an accountable security owner with a mandate to act, the foundation A.5.4's management enforcement depends on.RCF-0029Security charter · ProcesssupportsThis process control demonstrates ongoing leadership engagement through management reviews, budget and recorded decisions, exactly the visible support A.5.4 requires of managers.RCF-0143DevSecOps governance · ProcessrelatedThis process control makes security a recurring part of sprint planning, a development-team instance of managers enforcing security expectations within their own domain.RCF-0397Executive briefings · PolicyenablesThis policy control commits leadership in writing to a fixed briefing cadence, the structure that makes ongoing management involvement in security more than casual interest.RCF-0398Executive briefings · ProcesssupportsThis process control delivers those briefings on schedule and feeds conclusions into budget and priority decisions, showing management responsibility in action rather than on paper.RCF-0431Safety alignment · ProcessrelatedThis process control checks safety impact before every OT-related security decision, a specialised instance of managers taking responsibility for how security is applied within their operations.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
ISO/IEC 42001:2023 — Annex A counterparts
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Information security policy
The written, leadership-approved document that sets the company's security rules: what is protected, how, and who is responsible.
From the Sekit evidence catalog
In practice
In practice this shows up as line managers folding the security policy into everyday supervision: mentioning it at team meetings, correcting a risky habit on the spot, signing off on exceptions their staff request. Auditors rarely test the policy document itself; they ask a manager to describe how they hold their team accountable and check whether management review meeting minutes exist and get followed up. The common failure mode is a policy that only IT ever mentions, so staff treat it as background noise rather than something their own boss cares about.
Common gaps
Management review meetings happen on paper only: minutes exist but list no decisions, owners or follow-up dates, so nothing traces back to leadership action.
Line managers can name the security policy but cannot describe how they enforce it with their own direct reports.
Executive briefings on security posture are scheduled but skipped when the leadership calendar gets busy, breaking the promised cadence.
Questions your auditor will ask
Can you show a manager actively enforcing the security policy with their team?
Point to team meeting notes or a manager's own record where the policy was raised, or an exception request the manager reviewed and signed.
How does leadership stay informed about security risk and posture?
The information security policy names a briefing cadence, and briefing records show leadership received updates on schedule.
Who is accountable for the security programme, and do they have a mandate to act?
A signed charter names an accountable owner and states the budget and authority granted to that role.
What happens when an exception to policy is requested?
The request goes through a recorded approval flow with a defined expiry date, and expired exceptions get revisited rather than left open.
Where regulation demands it
NIS2 1.2 requires named roles, responsibilities and authorities for security decisions, and managers are who must exercise them day to day.
ENS org.1 requires a leadership-approved security policy, the artifact this control's evidence is built around.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.4?”
Also via MCP, free with account