Damian Osei was, by every account I later collected, a well-liked IT operations manager. He had been with Calderwood Freight Systems for eleven years, survived two changes of ownership, and was the person the finance director called when the transport management system (TMS) misbehaved on a Friday afternoon. He was also, without anyone quite deciding it should be that way, the sole system administrator for the TMS, the person who set up new supplier accounts inside it, and — because "it saves time" — the person with authority to approve supplier payment batches above a threshold that, in practice, nobody enforced.
Over eighteen months, Damian created a shell logistics vendor, "Fenmoor Haulage Partners," routed real-looking invoices for haulage capacity that was never used, and approved the payments himself inside the same system he administered. Because he also had unrestricted database access, he could — and did — delete the audit log entries that would have shown a single user both creating the vendor record and approving its first three payments. By the time an external auditor doing pre-acquisition due diligence noticed that Fenmoor Haulage Partners had no VAT registration on file and no correspondence trail beyond invoices, Calderwood had paid out just over $640,000 that finance could not account for against any delivered service.
There was no single catastrophic control failure here — no missing firewall, no unpatched server. The company had a password policy, a backup routine, even a half-finished information security policy sitting in a shared drive. What it did not have was a working answer to three questions: who, specifically, is responsible for information security decisions in this business; is any one person able to both create and approve the same transaction, or request and grant their own access; and does any manager actually check that the answer to the first two questions holds true day to day. Those three questions are, almost word for word, what ISO/IEC 27001:2022 Annex A controls 5.2, 5.3, and 5.4 exist to force an organization to answer — in writing, with evidence, and on a schedule an auditor can test.
This is the article I wish someone had handed Calderwood's board eighteen months earlier. It walks through all three controls as a connected system rather than three unrelated checkboxes, because in practice they are the same problem viewed from three angles: define the roles (5.2), keep the roles from colliding into fraud or error (5.3), and make sure line managers — not just the security team — actually enforce the outcome (5.4).
Who this is for, and what you'll walk away with
This is written for ISMS managers, CISOs, internal auditors, and general managers in small-to-mid-size organizations who are past the "we have a policy" stage of ISO 27001 and now need to build the actual accountability structure an external auditor will test during Stage 2 and every surveillance audit after it. It assumes you already understand, at a high level, what an ISMS is and why you're pursuing certification — if you need that grounding first, our overview of core ISMS concepts covers it. By the end, you'll have a roles-and-responsibilities matrix template, a segregation-of-duties conflict matrix you can adapt to your own org chart, a worked RACI example for a real ISMS activity, and a concrete list of what a line manager needs to do — and be able to show an auditor — to satisfy control 5.4.
"The Fenmoor case wasn't a technology failure. It was an org-chart failure that had been sitting there for a decade, waiting for someone to notice it and someone else to exploit it before anyone did." — Tobias Kwan, Internal Audit Director, Meridian Health Systems
First, untangle the numbers: Clause 5.3 vs. Annex A 5.2–5.4
Before going further, it's worth being precise about something that trips up almost every team new to the standard: ISO 27001's management system clauses (4 through 10) and its Annex A controls both use the number "5," and they are not the same thing.
Clause 5.3, "Organizational roles, responsibilities and authorities," is a requirement on top management, sitting inside Clause 5 Leadership. It obliges the leadership team to assign and communicate responsibilities and authorities for roles relevant to information security — most concretely, the requirement that someone is accountable for the ISMS conforming to the standard and someone reports on ISMS performance to top management. It is short, structural, and about the management system as a whole. If you haven't already read our breakdown of the leadership clause, see ISO 27001 Clause 5: Leadership and Management Commitment Requirements for the full requirement text and audit evidence expectations.
Annex A control 5.2, "Information security roles and responsibilities," is the operational control that makes Clause 5.3 real. It requires the organization to actually define, document, and allocate specific information security responsibilities — not just "someone is accountable for the ISMS" in the abstract, but who owns which asset, who approves which access request, who signs off which risk, and who does what when an incident happens. Clause 5.3 says "assign and communicate roles." Annex A 5.2 says "here is the register of roles, here is who holds each one, and here is the evidence they know it." Annex A 5.3 (segregation of duties) and 5.4 (management responsibilities) then build directly on that foundation — you cannot segregate duties you haven't defined, and a manager cannot enforce a responsibility that was never written down.
Requirement | Where it sits | What it actually demands | Typical evidence |
|---|---|---|---|
Clause 5.1 Leadership | Management system Clause 5 | Top management demonstrates commitment, sets policy, provides resources | Management review minutes, resourcing decisions, policy sign-off |
Clause 5.3 Organizational roles, responsibilities and authorities | Management system Clause 5 | Top management assigns and communicates ISMS-relevant roles, including the role accountable for ISMS conformance | Org chart, appointment letter for ISMS owner, communication record |
Annex A 5.2 Information security roles and responsibilities | Annex A Organizational controls | Specific security responsibilities are defined, documented, and allocated across the organization | Roles matrix, job descriptions, RACI chart, asset/risk ownership register |
Annex A 5.3 Segregation of duties | Annex A Organizational controls | Conflicting duties are separated (or compensated for) to reduce fraud, error, and control bypass | SoD conflict matrix, access reviews, exception register with sign-off |
Annex A 5.4 Management responsibilities | Annex A Organizational controls | Managers actively require staff to follow security policy and procedures | Team briefings, performance objectives, compliance attestations, escalation logs |
For a full map of how all 37 organizational controls relate to each other, our Annex A Organizational Controls overview is worth bookmarking alongside this article, and if you haven't yet nailed down the policy layer these roles sit on top of, start with Information Security Policies: ISO 27001 Control 5.1 Explained.
Control 5.2: Information security roles and responsibilities
The control text is deceptively short: information security roles and responsibilities shall be defined and allocated according to the needs of the organization. Two verbs matter here — defined and allocated — and in fifteen years of ISO 27001 work I have seen far more organizations fail on the second than the first. It's easy to write a document that lists "Information Security Manager" and a paragraph of duties. It's much harder to point to a specific named human being who holds that role today, knows they hold it, and can produce evidence of having exercised it in the last quarter.
Define before you allocate
Definition means writing down, for every role that touches information security in a material way, what decisions that role is authorized to make, what assets or processes it owns, what it's accountable for when something goes wrong, and who it reports to. This is not the same exercise as an HR job description, although the two should be consistent — a role can be defined for ISMS purposes even if it spans several job titles (a "Data Owner" role, for instance, is usually held by whichever department head is closest to a given data set, not by one dedicated job title).
Allocation means naming the actual person, recording the date the assignment took effect, and — critically for control 5.4 later — getting that person's acknowledgment that they understand and accept the responsibility. An auditor testing control 5.2 will almost always ask two questions in sequence: "show me the document that defines this role," followed immediately by "show me the person who currently holds it, and how you know they know." If you can only answer the first, you have a policy, not a control.
Role | Core information security responsibilities | Typically reports to | Realistic time commitment |
|---|---|---|---|
Top management / accountable executive | Ultimate accountability for ISMS conformance and resourcing (Clause 5.3) | Board / audit committee | Quarterly review cadence |
ISMS Manager / CISO | Runs the ISMS day to day: risk assessments, SoA maintenance, audit coordination, policy custodianship | Top management | Full-time in mid-size+ orgs; fractional in small orgs |
Information Security Steering Committee | Cross-functional oversight: approves risk treatment decisions, resolves escalations, reviews KPIs | Top management | Monthly or bi-monthly meeting |
Asset owners | Classify and protect the specific information assets they hold; approve access to those assets | Department head / ISMS Manager (dotted line) | A few hours per month per major asset |
Risk owners | Accept, treat, or escalate specific risks within their domain; sign off residual risk | ISMS Manager | Ongoing, spikes during risk review cycles |
System / application owners | Maintain configuration, patching, and access control for a specific system | IT Manager / ISMS Manager | Varies by system criticality |
Data Protection Officer (where applicable) | Oversight of personal data processing, privacy risk, regulator liaison | Top management (independent line) | Fractional to full-time depending on scale |
IT / Security Operations | Implement technical controls, monitor, respond to alerts | ISMS Manager / IT Director | Full-time operational role |
Internal audit | Independently tests ISMS conformance and control effectiveness | Audit committee / Board (never the ISMS Manager) | Scheduled audit cycles |
HR | Screening, onboarding/offboarding security steps, disciplinary process linkage | HR Director | Ongoing, tied to headcount changes |
All personnel | Apply policy in daily work, report incidents, complete training | Line manager | Continuous |
Notice that internal audit reports away from the ISMS Manager. This is itself a segregation-of-duties decision baked into control 5.2 — the people who build and run the controls should not be the people who independently attest that the controls work, which we'll return to under control 5.3.
Document it somewhere an auditor can find it
Definition and allocation only satisfy control 5.2 if they're captured in artifacts that survive a personnel change. In practice, four documents do the job between them, and most organizations need all four rather than trying to cram everything into one.
Artifact | What it captures | Owner | Review cadence |
|---|---|---|---|
Roles and responsibilities matrix | Every ISMS-relevant role, its scope, and its current holder | ISMS Manager | Annually or on any org change |
Job descriptions / role charters | Security duties embedded into the formal job description for the position | HR + ISMS Manager | At hiring and annual review |
Asset and risk ownership register | Named owner against every asset in the inventory and every risk in the register | ISMS Manager | At each risk assessment cycle |
RACI chart for key ISMS activities | Who is Responsible, Accountable, Consulted, Informed for recurring processes | ISMS Manager | Reviewed with the Statement of Applicability |
Terms and conditions of employment matter here too — Annex A control 6.2 requires security responsibilities to be reflected in employment contracts, and it's worth aligning your role definitions in control 5.2 with what's actually written into those contracts so the two don't drift apart. Similarly, when you allocate privileged system access as part of a role definition, that allocation should be governed by the discipline in control 8.2 Privileged access rights, not left to informal "just give them admin" decisions.
"I ask new clients one question in the first meeting: if your ISMS Manager got hit by a bus tomorrow, could you point to the document that tells the next person what they owned? Half the room goes quiet." — Renata Voss, CISO, Alderstone Financial Group
Common role-definition mistakes worth naming
A handful of failure patterns show up repeatedly across the organizations I've assessed. The first is the "everyone's responsibility" trap — a policy statement that information security is everyone's job, with no named accountable individual behind it, which auditors correctly read as nobody's job. The second is stale allocation: the matrix exists, but it still names someone who left the company eight months ago. The third is scope creep without redefinition — a role's actual duties have expanded well past its written charter, usually because someone competent kept getting handed "just one more thing," until they're effectively running three roles with the oversight of one. The fourth, and the one that connects directly to the next control, is defining roles without ever asking whether any two of them, held by the same person, create a dangerous combination.
Control 5.3: Segregation of duties
If control 5.2 answers "who does what," control 5.3 answers "and is any one person able to do too much of it alone." The control requires that conflicting duties and areas of responsibility be segregated to reduce the risk of unauthorized or unintentional modification, misuse of, or fraud against the organization's assets. It is one of the oldest ideas in internal control — segregation of duties predates information security as a discipline by decades, and shows up in accounting textbooks under the same three-word phrase — but ISO 27001 formalizes it specifically for information and information-processing facilities.
Damian Osei's case is the textbook illustration: the same person could create a vendor, approve payment to that vendor, and erase the log trail that would have shown both actions. Any one of those capabilities alone is a normal, defensible job function. Held together by a single, unmonitored individual, they become what auditors call "the perfect storm" — motive plus opportunity plus the absence of anyone positioned to notice.
Where conflicts classically hide
Segregation-of-duties conflicts cluster around a small number of patterns that repeat across almost every organization, regardless of industry. The pairing to watch for is always some version of "requests or creates" sitting next to "approves or grants" sitting next to "reviews or audits," all held by one person.
Function area | Conflicting duty pair | Why it's dangerous | Related Annex A control |
|---|---|---|---|
Access management | Requesting access and approving/granting access | Self-granted, unreviewed elevated access | 5.18 Access rights |
IT operations | Application development and production deployment | Untested or malicious code reaches production unchecked | 8.31 Separation of dev/test/production, 8.32 Change management |
Finance / procurement | Creating a vendor record and approving payments to that vendor | Enables fictitious-vendor fraud | 5.15 Access control |
Privileged access | Holding privileged/admin rights and being the sole reviewer of privileged-account logs | Ability to act and erase the evidence of acting | 8.2 Privileged access rights, 8.15 Logging |
Security operations | Configuring security monitoring and being the only person who reviews the alerts it generates | Missed or suppressed detections go unnoticed indefinitely | 8.16 Monitoring activities |
Backup and recovery | Administering backups and having sole authority to delete or overwrite backup sets | Evidence and recovery capability can be destroyed together | 8.13 Information backup |
Risk management | Assessing risk in one's own area with no independent challenge | Self-serving risk ratings, understated exposure | Clause 6 risk assessment process |
Incident response | Investigating an incident that implicates one's own actions or team | Conflict of interest, potential cover-up | 5.24–5.28 incident management controls |
Cryptographic key management | Generating and sole custody of encryption keys with no split-knowledge control | A single person can access or destroy protected data unilaterally | 8.24 Use of cryptography |
Build your own version of this table as a living conflict matrix — list every sensitive duty across your organization down one axis and across the other, and mark every cell where the same person or role could plausibly hold both. It doesn't need to be exhaustive on day one; it needs to exist, be reviewed at each risk assessment cycle, and be something you can hand an auditor with a straight face.
When segregation genuinely isn't feasible
Here is where control 5.3 gets realistic, and where the standard explicitly anticipates the objection every small organization raises the first time this topic comes up: "we have eleven people, I cannot have four different humans touch every transaction." ISO 27001 does not require segregation of duties at any cost — it requires that where segregation isn't practicable, compensating controls reduce the same risk by another route. This is the clause that keeps small and mid-size organizations from either faking a control they can't sustain or abandoning the requirement altogether.
"The auditors I respect most don't ask 'do you have four people.' They ask 'if you only have one, who's watching them, and how do you know?' That second question is the whole game for a small company." — Sam O'Donnell, Founder, Fenmoor Analytics (a fictional 18-person SaaS company used here for illustration)
Compensating control | What it substitutes for | Best suited to |
|---|---|---|
Independent periodic review of transactions/logs by someone outside the role | Real-time dual approval | Finance, privileged access, backups |
Mandatory, monitored dual sign-off for high-value or high-risk actions above a defined threshold | Full role separation | Payment approval, production changes |
Enhanced, tamper-evident logging with restricted deletion rights | A second pair of hands watching the first | System administration, log management |
Mandatory vacation / job rotation policy | Ongoing peer oversight | Roles that can't be split but can be temporarily covered |
Board, audit committee, or external advisor review on a fixed schedule | A permanent internal second reviewer | Very small organizations without spare headcount |
Outsourced or third-party review of sensitive functions (e.g., external bookkeeper reconciling internal records) | An internal second set of eyes | Micro-organizations, early-stage startups |
Automated exception alerting (e.g., flag any vendor created and paid by the same user ID) | Manual review capacity | Any organization with a capable ERP/ticketing system |
Documented exception register with named sign-off from a senior manager for every unavoidable conflict | A formal SoD control | Any org, as the audit trail proving the conflict was acknowledged, not ignored |
The exception register deserves special mention because it's the artifact most small organizations skip and most auditors specifically look for. It doesn't need to be complicated — a log entry per unavoidable conflict, naming the roles involved, the compensating control applied, who approved accepting the residual risk, and the date it's next due for review. What an auditor is testing is not whether you achieved a textbook segregation; it's whether you knew about the gap, made a deliberate risk-based decision about it, and are watching it rather than pretending it doesn't exist.
"We had one system administrator for a two-year stretch. The finding wasn't 'you should have hired a second admin you couldn't afford.' It was 'where's your evidence someone else reviewed his privileged activity every month.' Once we produced that log, the finding closed." — Elena Vasquez, Head of Risk, Northbridge Insurance
Segregation of duties by function area
It helps to think about segregation not just as a matrix of conflicting pairs but as a set of default patterns per function, so new hires and new systems get built with the separation in mind from the start rather than retrofitted after an audit finding.
Function area | Default separation pattern | Compensating pattern for small teams |
|---|---|---|
Software development | Developer ≠ production deployer; code review by a second developer before merge | Peer review required even with one deployer; deployment logs reviewed by a manager weekly |
Access provisioning | Requester ≠ approver ≠ implementer | Manager approval logged in the ticketing system even if IT implements and IT requested |
Financial transactions | Initiator ≠ approver ≠ reconciler | External bookkeeper or fractional CFO reconciles monthly |
Vulnerability and patch management | Person identifying a vulnerability ≠ sole person deciding to accept the risk | Risk acceptance requires sign-off one level up the management chain |
Physical access to server/comms rooms | Badge issuer ≠ sole holder of master key | Access log reviewed quarterly by someone outside IT |
HR/security offboarding | Person removing access ≠ sole confirmer that removal is complete | Second person spot-checks a sample of terminations each quarter |
Control 5.4: Management responsibilities
Controls 5.2 and 5.3 build the structure. Control 5.4 makes sure someone with actual authority over people — not just the security team — is pushing that structure into daily behavior. The control requires management to require all personnel and relevant interested parties to apply information security in accordance with the established policy, topic-specific policies, and procedures of the organization. In plain terms: it is not enough for the ISMS Manager to write the rules. Line managers, department heads, and executives have to actively make their own people follow them.
This is the control that most often exists on paper and fails in practice, because it asks something harder than documentation — it asks for a change in how ordinary managers manage. An auditor testing control 5.4 is not looking for another policy document; they're looking for evidence that managers are doing something, repeatedly, that they wouldn't be doing if information security weren't a real expectation of their job.
What "actively enforcing" looks like in evidence
Manager action | What it demonstrates | Evidence an auditor can sample |
|---|---|---|
Security objectives included in staff performance reviews | Security is a real job expectation, not a side note | Performance review templates and completed reviews |
Team briefings on new or updated topic-specific policies | Policy changes reach staff, not just the intranet | Meeting minutes, briefing attendance, Q&A records |
Manager sign-off confirming team completed mandatory security training | Training isn't just "assigned," it's chased to completion | Training completion reports co-signed by managers |
Escalation of policy exceptions to the ISMS Manager rather than silently allowing them | Deviations are visible, not hidden at team level | Exception log with manager as originator |
Enforcing the disciplinary process for confirmed violations | Non-compliance has real consequences | HR disciplinary records tied to security incidents |
Including security compliance in onboarding and offboarding checklists they personally approve | New hires and leavers are handled consistently | Signed onboarding/offboarding checklists |
Reporting team-level security metrics up to the steering committee | Management chain owns outcomes, not just the security function | Steering committee packs, KPI dashboards |
Setting visible personal example (using MFA, reporting own near-misses) | Tone at the top is genuine, not performative | Incident/near-miss reports attributed across seniority levels |
"The single biggest predictor of whether a department passes its ISMS internal audit isn't the department's technical maturity. It's whether the department head has ever, personally, chased someone for skipping mandatory training. That one habit tells you everything about control 5.4 in that team." — Gareth Mbeki, HR Director, Solstice Biotech
Building the evidence trail without building bureaucracy
The trap most organizations fall into with control 5.4 is trying to prove management responsibility with a single annual attestation — "I, department head, confirm my team follows policy" — signed once a year and filed away. Auditors have seen this pattern enough times that it now reads as a red flag rather than reassurance. What holds up better is a lighter-touch, higher-frequency pattern: security as a standing five-minute agenda item in existing team meetings, a quarterly (not annual) manager attestation tied to specific, checkable items, and security metrics that flow into the same management reporting cycle as budget and headcount, rather than living in a separate security-only report nobody outside the ISMS team reads. This connects directly to the resourcing and competence obligations under Clause 7 Support — a manager can't enforce a policy their team was never trained or resourced to follow, so controls 5.4 and Clause 7 should be read together, not in isolation.
A worked RACI example: the annual access review
RACI charts — Responsible, Accountable, Consulted, Informed — are the single most useful artifact for satisfying control 5.2 in a way that also demonstrates control 5.3's segregation logic, because building one forces you to notice when the same name appears in the "Responsible" and "Accountable" columns for a step that should never have both held by one person. Here is a worked example for a process almost every certified organization runs: the periodic access rights review required to support control 5.18.
Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Define review scope and schedule | ISMS Manager | CISO | IT Manager | Steering Committee |
Pull current access listings per system | System Administrators | IT Manager | — | ISMS Manager |
Validate access against current role/employment status | Line Managers | Department Heads | HR | ISMS Manager |
Flag and action excess or orphaned access | IT Operations | IT Manager | Line Managers | ISMS Manager |
Independently sample-test the review for completeness | Internal Audit | Audit Committee | ISMS Manager | Top Management |
Report findings and remediation status | ISMS Manager | CISO | IT Manager | Steering Committee, Top Management |
Two things are worth pointing out in this table. First, notice that the people who pull the access listings (IT Operations) are not the same people who validate whether that access is still appropriate (Line Managers) — that's control 5.3 in action inside a control 5.2 process. Second, Internal Audit sits entirely outside the operational chain, reporting to the Audit Committee rather than to the CISO, which is exactly the independence control 5.2's role definitions should be protecting.
flowchart TD
Board["Board / Audit Committee"]
TM["Top Management<br/>(Clause 5.3 accountable role)"]
SC["Information Security<br/>Steering Committee"]
CISO["CISO / ISMS Manager"]
AO["Asset Owners"]
SO["System Owners"]
RO["Risk Owners"]
SecOps["Security Operations"]
IA["Internal Audit"]
Board --> TM
TM --> SC
SC --> CISO
CISO --> AO
CISO --> SO
CISO --> RO
CISO --> SecOps
Board -.independent reporting line, never through CISO.-> IA
IA -.tests.-> CISO
IA -.tests.-> AO
IA -.tests.-> SO
IA -.tests.-> SecOpsThe dotted lines in that diagram are the whole point of segregation of duties applied at the organizational-design level: Internal Audit is drawn deliberately outside the chain it tests, reporting upward to the Board independent of the CISO's line, so the function that assures the ISMS is never accountable to the function it assures.
Small-organization vs. enterprise patterns
The three controls apply identically regardless of headcount, but the shape of a compliant answer differs enormously between a twelve-person startup and a two-thousand-person enterprise. Auditors calibrate their expectations to organizational size and complexity — what they will not accept, at any size, is the absence of a documented, deliberate answer.
Dimension | Small organization (under ~30 staff) | Mid-size organization (~30–500 staff) | Enterprise (500+ staff) |
|---|---|---|---|
Role structure | Fractional ISMS Manager, often the founder or ops lead wearing the hat | Dedicated ISMS Manager/CISO, small security team | Full CISO function, dedicated risk, GRC, and audit teams |
Segregation approach | Compensating controls dominate; exception register is a core artifact | Mix of true separation for high-risk functions, compensating controls elsewhere | True segregation the default; exceptions are rare and heavily scrutinized |
RACI granularity | One organization-wide RACI covering most ISMS processes | Per-department RACIs for major processes | Per-process, per-system RACIs maintained in a GRC platform |
Management enforcement | Founder/leadership visibly modeling behavior; informal but frequent | Department heads formally briefed each policy cycle; quarterly attestations | Cascaded management objectives, formal compliance scorecards per business unit |
Internal audit independence | Often outsourced to an external assessor for genuine independence | Small internal audit function or co-sourced arrangement | Dedicated internal audit function reporting to the Audit Committee |
Typical auditor focus | Is the compensating-control logic documented and genuinely followed | Is segregation actually implemented where feasible, not just claimed | Are exceptions to segregation formally risk-accepted and time-bound |
Common mistakes across all three controls
Mistake | Why it happens | Consequence at audit | Fix |
|---|---|---|---|
Roles matrix exists but hasn't been updated since a reorganization | Nobody owns keeping it current | Nonconformity: documented information not maintained | Tie matrix review to the annual management review cycle |
SoD "policy" states principles with no actual conflict matrix | Easier to write a paragraph than map real conflicts | Auditor asks for the matrix, finds none, raises a finding | Build the matrix once, review it at each risk assessment |
Compensating controls exist informally but aren't documented or approved | Team knows they cover for each other; nobody wrote it down | Auditor can't verify a deliberate decision was made | Maintain a signed exception register |
Management "responsibility" reduced to a single annual sign-off email | Feels efficient; ticks a box | Reads as a rubber stamp, auditors probe deeper and find nothing behind it | Build recurring, checkable manager actions into existing meeting cadences |
Internal audit reports to the CISO it is meant to test | Convenient reporting line, especially in small orgs | Direct segregation-of-duties conflict at the assurance layer | Route internal audit reporting to the Board/Audit Committee or an independent executive |
Privileged access granted informally "because it's faster" | Time pressure during incidents or onboarding | Undermines both 5.2 role definitions and 5.3 segregation | Formal, logged, time-bound privileged access requests per control 8.2 |
Job descriptions never updated to match the actual roles matrix | HR and ISMS documentation maintained in silos | Inconsistency between contracts and ISMS records surfaces at audit | Joint review of role charters by HR and ISMS Manager annually |
Rolling out controls 5.2–5.4: a realistic implementation timeline
Organizations building this trio of controls for the first time — rather than retrofitting them after an incident, as Calderwood did — tend to underestimate how much of the work is organizational conversation rather than documentation. A realistic rollout, even for a mid-size organization with reasonably engaged leadership, runs eight to twelve weeks end to end.
Phase | Key activities | Typical duration | Primary owner |
|---|---|---|---|
Discovery | Map current (often informal) roles, interview department heads, inventory existing job descriptions | 1–2 weeks | ISMS Manager |
Draft roles matrix | Define roles, scope, and accountable individuals per function | 1–2 weeks | ISMS Manager with department heads |
Build the SoD conflict matrix | Identify conflicting duty pairs, flag unavoidable overlaps | 1 week | ISMS Manager + Internal Audit (or external advisor) |
Design compensating controls | Agree monitoring, review, or dual-sign-off measures for each flagged conflict | 1–2 weeks | Department heads + ISMS Manager |
Formalize management enforcement mechanisms | Build attestation cadence, meeting agenda items, escalation paths | 1 week | HR + line managers |
Communicate and train | Brief all staff on new roles, escalation paths, and expectations | 1 week | Line managers, supported by ISMS Manager |
Pilot cycle | Run one full review/attestation cycle before the certification audit | 2–3 weeks | All role holders |
Internal audit dry run | Independently test the roles matrix, SoD exceptions, and manager evidence | 1 week | Internal Audit |
What an auditor will actually ask for
It's worth rehearsing the evidence request before an assessor makes it, because controls 5.2 through 5.4 are tested almost identically by every certification body — through documents first, then through interviews that check whether the documents match reality.
Control | Document an auditor will request | Interview question an auditor is likely to ask |
|---|---|---|
5.2 Roles and responsibilities | Current roles matrix, asset/risk ownership register | "Who owns this specific risk/asset, and how would I confirm that with them directly?" |
5.3 Segregation of duties | SoD conflict matrix, exception register with sign-off | "Show me a case where one person could do two conflicting things — what's compensating for it?" |
5.4 Management responsibilities | Manager attestations, team briefing records, training completion sign-offs | "What did you personally do this quarter to make your team follow the access policy, specifically?" |
Case study: Calderwood Freight Systems, twelve months after Fenmoor
Calderwood's board, once the $640,000 loss was quantified, didn't simply fire Damian Osei and move on — they brought in an external ISMS lead (a role that, tellingly, hadn't previously existed) to rebuild controls 5.2 through 5.4 from the ground up ahead of a planned certification effort tied to a new enterprise customer's vendor security requirements. The rebuild took four months and centered on three concrete changes: a documented roles matrix separating "creates vendor records" from "approves vendor payments" into two different systems roles held by two different people; a monthly, board-level exception review for the handful of unavoidable overlaps in a still-lean 34-person company; and a requirement that the finance director, not IT, now personally reviewed a sample of vendor payment approvals each month as a standing calendar item — control 5.4 made concrete rather than aspirational.
Metric | Before remediation | 12 months after |
|---|---|---|
Users with both vendor-creation and payment-approval rights | 1 (unrestricted) | 0 (segregated by design) |
Documented SoD exceptions with sign-off | 0 | 6, all reviewed quarterly |
Monthly manager-led payment sample reviews | 0 | 12 conducted, 100% completion |
Time to detect an anomalous vendor pattern in follow-up testing | 18 months (undetected until external audit) | Detected in 11 days during a scheduled review |
Certification outcome | Not previously pursued | Stage 1 and Stage 2 passed with zero major nonconformities related to Annex A 5.2–5.4 |
"We didn't need forty new employees to fix this. We needed one honest conversation about which two jobs could never sit with the same person again, and a finance director willing to actually open the report every month instead of trusting it was fine." — Priya Nathwani, ISMS Manager, Calderwood Freight Systems
Case study: a 14-person analytics firm without the headcount for full segregation
Fenmoor Analytics — a genuinely small data analytics consultancy, fourteen people, no dedicated IT team — is a useful counterpoint because it shows control 5.3 succeeding without ever achieving textbook separation. Their entire infrastructure was administered by a single technical co-founder; there was no realistic path to hiring a second systems administrator purely for segregation purposes, and the auditor doing their certification assessment knew it before walking in.
What passed the audit was not a pretense of separation but a clearly documented compensating-control package: every privileged action the co-founder took in production systems was logged to an immutable, cloud-hosted log store he could not himself delete; a second co-founder, with no technical access of her own, reviewed a sampled export of that log monthly against a simple checklist; and the exception register explicitly named the risk ("single admin, no technical peer review") and the accepted mitigation, reviewed and re-signed by both founders every quarter. The certification body's lead auditor noted in the closing meeting that this was one of the clearer examples of "genuine, proportionate compensating control" he'd seen from an organization of that size that year — precisely because it didn't try to look bigger than it was.
Case study: an enterprise steering committee that stopped rubber-stamping
A regional healthcare group I'll refer to as Solstice Biotech had, on paper, an Information Security Steering Committee that met monthly and had every role from the table above filled. What an internal audit finding surfaced was that "management responsibility" under control 5.4 had quietly become a single slide in that meeting, presented by the CISO, that no department head ever questioned or added evidence to — the committee was informed, not accountable. The fix wasn't structural; it was behavioral. Each department head was assigned a standing item to bring one piece of their own team's evidence (a training completion rate, an access review exception, an incident near-miss) to every meeting, rather than receiving a summary from the security team. Within two quarters, the steering committee's minutes went from a single-page summary to a multi-page record with named departmental accountability entries — exactly the kind of evidence trail that turns control 5.4 from a policy statement into a demonstrable, auditable habit.
Turning accountability into a competitive answer, not just an audit answer
It's tempting to treat controls 5.2 through 5.4 as pure compliance overhead — paperwork that exists because an auditor demands it. The organizations that get the most value from ISO 27001, in my experience, treat this trio the opposite way: as the mechanism that lets them say yes, confidently, when a customer's procurement team or a cyber-insurance underwriter asks "if one of your people wanted to commit fraud or made a serious mistake, who would notice, and how fast." Calderwood couldn't answer that question in a way that mattered until it had already cost them $640,000; Fenmoor Analytics could answer it convincingly at fourteen people because the answer was documented, proportionate, and true. That difference — not the size of the security team — is what a well-built roles, segregation, and management-accountability structure actually buys you: a defensible answer to the question every serious customer, insurer, and regulator eventually asks.
If you're building or tightening this part of your ISMS now, start with the artifacts in this article rather than the org chart in your head: draft the roles matrix, run your duties through a conflict matrix honestly, and give your line managers something concrete and recurring to do rather than an annual attestation to sign. Our Information Security Policy Template gives you a starting structure that already anticipates where role and responsibility language needs to sit, our ISO 27001 Mandatory Documents Checklist tells you exactly which of these artifacts an auditor expects to exist versus which are good practice but optional, and our Internal Audit Interview Question Script includes the exact probing questions auditors use to test controls 5.2 through 5.4 so you can rehearse your own answers before someone external asks them. If you're building this whole part of your ISMS from a standing start, our Complete ISO 27001 Implementation Guide eBook walks the roles-and-governance workstream alongside the rest of the certification path, and if any of the terminology in this article was new to you, our ISO 27001 Glossary of Terms is worth keeping open in a second tab while you build your own matrix.
Get this trio right once, document it honestly, and revisit it on a schedule — and the next Damian Osei in your organization runs into a compensating control long before he runs into an external auditor.