Control Definition
Management at every level must actively require the people they supervise — employees and relevant contractors alike — to apply information security in line with the organization's information security policy, its topic-specific policies, and its procedures.
Control Objective
To make sure managers understand their own role in information security and act so that everyone they supervise knows, accepts, and actually carries out their security responsibilities.
What This Really Means
This is the control that turns your policy library from shelf-ware into management behavior. It is easy to confuse with Clause 5.1 of the standard, which addresses top management leadership over the ISMS — but A.5.4 is aimed at every manager: the engineering team lead, the head of finance, the operations supervisor, the person a contractor reports to. The standard's underlying bet is simple and correct: security lives or dies in the middle layer, because that is where daily tradeoffs between deadlines and discipline actually get decided.
The operative word in the control is "require" — an active verb, not passive endorsement. In practice it means managers brief their people on security expectations before access is granted, chase overdue policy acknowledgments instead of letting them age, make sure their team completes assigned training, give the people who own controls the time and budget to operate them, and escalate noncompliance instead of looking away. A manager who forwards the security policy once a year and considers the job done is not meeting this control.
The evidence of "requiring" is mundane and that is the point: a security objective in a manager's appraisal, a signed new-joiner briefing checklist dated before the access grant, a dashboard showing a team lead cleared their overdue training list, a record of a manager raising a repeat violation through the proper channel. None of these artifacts is exotic — together they prove that supervision of security is happening continuously, not performed for the audit.
Auditors test this control by interviewing line managers, not the CISO. The heart of A.5.4 is what happens when an auditor picks a random manager outside the security function and asks two questions: what are your team's information security responsibilities, and what do you do when someone ignores them? If the answers are specific, match the published policies, and come with examples, the control is working. If the answer is "the security team handles that," the finding writes itself.
Why It Matters
The distance between a written ISMS and a lived one is exactly the width of the management layer. A CISO can publish flawless policies, but only line managers control the moments where security is won or lost: whether the release ships without the review, whether the new contractor starts working before the briefing, whether the awkward incident gets reported or quietly absorbed. When managers signal — by action or by silence — that security is someone else's job, their teams learn within weeks that compliance is optional.
This control is also how the security workload gets distributed at scale. A central team cannot personally chase five hundred policy acknowledgments, verify every joiner was briefed, or notice which team never completes training. Managers can, because supervision is already their job — A.5.4 simply makes security an explicit part of it. Auditors read weakness here as a culture signal: a poor showing on management responsibility reliably predicts findings in awareness, access reviews, and incident reporting, because all of those depend on managers caring.
Where managers do not actively require security, organizations face:
- •A policy-reality gap – staff quietly bypass procedures their own manager never mentions, and the ISMS becomes a paper system that collapses under audit sampling
- •Unresourced controls – control owners are assigned duties but never given the hours or budget to perform them, because their manager never planned for it
- •Suppressed incident reporting – people do not report security events to a manager who shrugs, so incidents surface late or through external parties
- •A toothless disciplinary process – violations never reach the formal process because first-line managers absorb or ignore them, destroying consistency and legal defensibility
- •Stage 2 interview failures – certification auditors interview managers across departments, and answers like "that is IT's problem" convert one weak interview into a systemic nonconformity
Regional Compliance Context
In Indian financial services, management accountability for security is a supervisory requirement, not just an ISO expectation. RBI master directions push regulated entities toward explicit senior and middle management ownership — board-level oversight committees, designated executives accountable for information security, and security performance woven into management goals — and SEBI's CSCRF carries comparable expectations for market intermediaries. If you operate in or sell into BFSI, align your A.5.4 evidence (committee charters, management KRAs, escalation records) with what the sectoral regulator already demands. For organizations handling personal data, the DPDP Act's obligations land on the organization as data fiduciary, which in practice means line managers of teams that touch personal data become the first enforcement layer for purpose limitation and handling discipline well before full compliance obligations arrive on 13 May 2027.
Implementation Guidance
Define Who Counts as Management
Map every layer that directs the work of others, from the executive team down to team leads and the supervisors of contractors. A.5.4 attaches to all of them, not just people with "manager" in their title. Record the result in your roles and responsibilities documentation (A.5.2) so each supervisory role carries an explicit security dimension.
Write Security Duties into Manager Role Documentation
Add a concrete duty list to job descriptions, role profiles, and manager onboarding: brief team members on security expectations before access is granted, ensure policy acknowledgments and training are completed on time, resource the controls their team owns, and escalate noncompliance through the defined path. Specific verbs beat a generic "promotes security culture" line, which auditors rightly treat as decoration.
Equip Managers with a Briefing Pack
Give every manager a short, maintained pack for new-joiner and role-change briefings: the handling rules that apply to the team, acceptable use essentials, the incident reporting path, and where the policies live. Pair it with a one-page checklist the manager and joiner both sign before access is provisioned. This single artifact answers half the audit questions on this control.
Put Security Objectives into Appraisals
Include at least one measurable security objective in every manager's appraisal or goal cycle — on-time training completion for their team, zero overdue policy acknowledgments, closure of audit actions they own. HR should be able to show the objective template, and managers should be able to show their own. This is the strongest available evidence that management is required to require.
Give Managers Team-Level Visibility
Managers cannot chase what they cannot see. Surface per-team dashboards or monthly reports from your LMS, policy tool, or GRC platform showing training status, acknowledgment status, and open exceptions for their direct reports. Route automated nudges to the manager, not just the employee — the manager following up is precisely the behavior this control wants.
Define the Escalation Path for Noncompliance
Document what a manager does on a first violation versus a repeat: corrective conversation, refresher training, formal referral into the disciplinary process (A.6.4). Require escalations to be logged, even informally resolved ones. A defined path protects managers from improvising, protects employees from inconsistency, and produces the records that prove enforcement happens.
Verify and Refresh Annually
Have internal audit sample managers across departments each year: do they know their duties, can they show briefing and follow-up records, have they escalated when needed? Report team-level completion statistics and escalation counts into management review, and refresh the manager briefing pack whenever policies change materially.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.4:
Documentation
- Role profiles or job descriptions for supervisory roles showing explicit information security duties
- Signed new-joiner and role-change security briefing checklists, dated before the corresponding access grants
- Appraisal or objective-setting extracts (redacted) showing security objectives assigned to managers
- Training and policy-acknowledgment completion reports broken down by team or manager, with evidence of follow-up on overdue items
- Escalation records showing managers raised noncompliance and linked it into the disciplinary process where warranted
Interviews
- Line managers sampled across departments — the core test — on their team's security responsibilities and what they personally do about noncompliance
- HR lead on how security duties enter role documentation and appraisals, and how the manager-to-disciplinary-process handoff works
- CISO or security lead on how managers are equipped, measured, and chased when their teams fall behind
Observations
- A manager pulling up their team's live training and acknowledgment status and explaining what they do with it
- A recent joiner's briefing record traced against the date their access was provisioned
- Sampling of appraisal or goal records to confirm security objectives exist for managers in practice, not just in the template
Practitioner Insights
A pattern I see across certification audits: the organization rehearses the CISO for a week, and then the auditor spends Stage 2 talking to a finance manager and an operations supervisor. Auditors pick managers outside IT deliberately, because A.5.4 is about all management — and the moment a manager answers "the security team handles that," the trail of findings starts there and spreads to awareness and incident reporting. My advice is to run mock interviews with five randomly chosen managers a month before the audit and fix what you hear, because that is exactly what the real auditor will do.
In startups the honest objection is "we have no managers — everyone reports to the founders," and the evidence for this control ends up being nothing at all. The fix is lighter than people expect: whoever assigns work owns the requiring. A signed joiner briefing checklist before access, plus a fifteen-minute monthly slot where each lead clears their team's overdue training and acknowledgments, kept in the same ticketing tool you already use, is a complete and convincing evidence trail. The mistake is writing a grand "management commitment statement" instead — auditors want the checklist with last Tuesday's date on it.
Common Challenges & Solutions
Challenge
Managers genuinely believe security is the security team's job and treat policy enforcement as outside their role.
Solution
Make the duties structural, not motivational: write them into role profiles, put one security objective in every manager's goals, and route team compliance dashboards to managers rather than to the security team. Have leadership visibly back the first few escalations. Behavior follows accountability — once a manager is measured on their team's completion rates, the chasing starts.
Challenge
Managers do brief and chase their teams, but nothing is recorded, so there is no evidence of "requiring" at audit time.
Solution
Instrument the behaviors that already happen. A signed briefing checklist per joiner, LMS completion reports filed monthly, a one-line log entry per escalation, security as a standing item in team meeting notes. Keep each artifact under a minute of effort — the goal is a paper trail of normal supervision, not new bureaucracy.
Challenge
Teams conflate A.5.4 with Clause 5.1 and assume board-level commitment statements cover the control.
Solution
Separate the layers explicitly in your ISMS documentation: Clause 5.1 evidences top management leadership (policy approval, resourcing, management review), while A.5.4 evidences every manager requiring security of their own people. Map distinct artifacts to each — a CEO statement proves nothing about whether a team lead briefed last month's new hire.
Challenge
Managers lack the security knowledge to brief their teams confidently, so briefings get skipped or reduced to forwarding a PDF.
Solution
Run a short manager-specific training module covering their five duties, give them the maintained briefing pack with talking points, and offer security-team office hours for questions. Managers do not need to be security experts — they need a script, a checklist, and somewhere to send hard questions.
Challenge
Noncompliance never escalates because managers shield their teams or fear the process is punitive.
Solution
Publish a graduated escalation matrix so the first step is a corrective conversation, not a tribunal, and frame self-reported issues as non-punitive. Track escalation counts in management review — a year of zero escalations across the organization is itself a red flag worth investigating, because it usually means absorption, not perfection.
