ISO 27001 Clause 5.3: roles, responsibilities and authorities

The enterprise due-diligence questionnaire asks who is accountable for information security. Your honest answer is "the IT team", and the deal waits while you find a name. ISO 27001 Clause 5.3 is the requirement behind that question, and this guide shows operations leaders, heads of engineering and fractional CISOs at 25–250-person firms how to meet it.

You will get the two duties the clause mandates, a role map that avoids "IT" and "HR" as owners, the authority each owner needs, an HR-wired register that keeps ownership current, and the questions auditors ask at Stage 2.

What does ISO 27001 Clause 5.3 require from top management?

ISO 27001 Clause 5.3 requires top management to make sure security roles are assigned and communicated, and to name who holds two specific responsibilities: keeping the information security management system conforming to the standard, and reporting its performance to top management. Deputies, RACI grids and appointment notes make those assignments real.

The clause makes security ownership a leadership decision. The first assignment is a named person accountable for keeping the ISMS in line with the standard. The second is a named route by which leadership hears how that system is performing. At 25–250 people, one leader often holds both, and that is acceptable.

Auditors read the duties as two questions. Who keeps the system conforming, and how does leadership find out whether it does? Each answer needs a name and a document, and the rest of the audit tests whether those answers stay true.

Assignment is only the start. Each duty needs matching authority, the business must be told who holds it, and top management must keep it current as people join, move and leave. A short appointment note, or a paragraph in the security policy naming the person, puts the mandate in writing.

Clause 5.3 does not stand alone. Three neighbouring clauses test it from different angles:

• Clause 5.1, leadership commitment. Assigning roles is one of the concrete acts that evidences commitment, so auditors examine the two together.
• Clause 7.2, competence. Whoever receives a role must be demonstrably competent to hold it, so competence records follow the assignment.
• Clause 9.3, management review. The performance-reporting duty lands here, where leadership actually receives the report.

Leadership decides, the owner acts and the report returns to leadership.

Why does clear security ownership matter for a 25–250-person firm?

At 25–250 people, security accountability defaults to 'IT handles that', and diffuse accountability is how reviews lapse and alerts go unowned. Enterprise buyers, insurers and regulators ask who owns security first, and NIS2 and DORA place that accountability on the management body. A name and reporting line answers all of them.

Diffuse ownership fails quietly. Nobody decides to skip the quarterly access review; the review simply has no name against it. The gap surfaces at an incident or an audit, when it is most expensive.

Security ownership that nobody chose belongs to whoever set up the laptops.

A firm that answers instantly reads as governed. Hesitation reads as risk.

UK guidance points the same way. The NCSC Cyber Governance Code of Practice asks boards to define cyber roles and responsibilities clearly, including ownership at executive level. The NCSC Cyber Security Toolkit for Boards adds a practical test: if senior leaders struggle to say where responsibility sits, there is work to do.

You can run that test in five minutes. Ask your leadership team separately:

• Who is accountable for the ISMS meeting the standard?
• Who tells the board how security is performing?
• Who covers when that person is away?

Matching answers are a commercial asset. The questionnaire gets answered in one line, and the audit conversation starts from strength.

Do you need a roles procedure or a full-time CISO for Clause 5.3?

No. Clause 5.3 requires assignment, not headcount or a standalone roles procedure. At 25–250 people, a COO, head of engineering or fractional CISO can carry both mandated duties, evidenced by job descriptions, an org chart and a one-page RACI. Auditors test that assignments are real and current, not that a procedure exists.

Two over-builds are common. The first is a long roles-and-responsibilities procedure that staff never open and that fails auditor sampling. The second is a full-time hire made to satisfy a clause that asks for no such thing.

A fractional CISO is the sound alternative where nobody in the leadership team has the competence or the time. Whoever holds the duties must be demonstrably competent under Clause 7.2, and leadership must free up the hours the work takes.

These artefacts, which most firms already maintain, carry the evidence between them:

• Written mandate. An appointment note, policy paragraph or board minute naming the person for each of the two duties.
• Org chart and job descriptions that mention security duties, not only job titles.
• One-page RACI. A grid of who is responsible, accountable, consulted and informed, with named individuals, deputies and a visible change history.
• Latest performance pack that went to leadership, with minutes showing it was discussed.
• Proof the register is alive, such as an update traceable to a recent leaver or role change.

A maintained Notion or SharePoint matrix with history beats a procedure nobody opens. Auditors are testing currency and awareness, not document weight.

Sequence matters more than volume. Build the register straight after the security policy under Clause 5.2, because risk owners, competence records and every Annex A control that needs an owner hang off it. That is a few days of work, not weeks.

How do you map security roles without defaulting to 'IT' or 'HR'?

Name one person plus a deputy for each operating role: control owners, asset owners, risk owners, an incident lead and whoever runs internal audit. A department name is not an owner. Keep internal audit independent, so the auditor never marks their own homework, and make sure staff can state their own duties.

At 50 people, expect the same name to appear in several rows. That is fine while the conflicts are separated. The test is whether every row carries two names and a way to reach them.

Build the map in this order:

1. List what needs an owner. Start from the risk register, the asset inventory, your selected Annex A controls and the incident process.
2. Assign one named person to each. Choose the individual with the authority and context to act.
3. Add a deputy to every item.
4. Check audit independence. Whoever audits a control must not own it.
5. Record it in the RACI and the job descriptions you already maintain.
6. Tell people. Onboarding covers what each person owns, and the RACI sits somewhere findable.

Internal audit needs its own thought, because the obvious auditor in a small firm is the person who runs the controls. Swapping works well: the head of engineering audits people controls, and the people lead audits engineering. Where a control cannot be swapped, buy in an external internal auditor for it.

Three pitfalls appear when the steps are skipped:

• Department owners. "IT" or "HR" in the accountable column means nobody in practice, and auditors treat group assignments as unassigned.
• No deputies. One person's holiday stalls incident response or a review cycle.
• Documented but never communicated. The matrix looks complete, but nobody was told.

A matrix that staff contradict in interview is fiction, however immaculate it looks.

Not every role is an owner role. Every member of staff carries baseline security duties, such as following the acceptable use policy, protecting the information they handle and reporting incidents promptly. Give those duties one row in the RACI and one line in onboarding, so the interview question "what are your security responsibilities?" has an answer for everyone, not only the named owners.

How do you give each Clause 5.3 owner the authority to act?

Authority means the owner can actually do the job. The person owning access reviews needs administrative visibility of the identity provider; the person accountable for conformance needs a budget line and a route to the board. The ICO expects permissions to be validated against documented access rights and removed when no longer needed.

The ICO security outcomes guidance adds a limit: access should go only to people who reasonably need it to do their job. Read alongside Clause 5.3, duty and access are two halves of one test: an owner without the access cannot discharge the duty, and a leaver who keeps it is a risk.

Pair every duty with the authority that makes it real:

• Access review owner: visibility of the identity provider groups they review.
• Conformance owner: a budget line for tooling and audits, plus a standing slot with the board.
• Incident lead: authority to pull engineers in and take affected systems out of service.
• Risk owner: authority to schedule treatment, or a named person to escalate to when they cannot.

Write the authority beside the duty, in the appointment note or the RACI. A duty without authority is a name on a list. If the escalation route already names who the owner goes to, a blocked treatment reaches a decision instead of a backlog.

Time is authority too. If a role adds hours of work, say whose workload it displaces and tell the owner's line manager, or the duty will lose to the day job.

How do you automate Clause 5.3 role governance with HR and IdP data?

Treat the ownership register as data joined to HR. A joiner, mover or leaver event flags every control, risk and policy the person held; a scheduled orphan check surfaces items without an employed owner; and an identity provider comparison flags authority drift. Reassignment becomes a triggered task, not an annual archaeology dig.

The wiring starts with the HR platform. The reassignment task goes to the person's manager and the register owner, and it must close before the offboarding workflow can complete. The register's change history then becomes the evidence, with no separate record to keep.

A role register reviewed once a year is wrong for most of the year.

Orphan detection covers the gaps between events. The scheduled check turns the ghost-owner failure into an alert instead of an audit finding. Authority drift checks work the same way: compare identity provider group membership with assigned duties and flag any holder who lost the matching access.

Reporting then falls out of the data. The leadership pack draws on ISMS metrics you already collect, so the performance-reporting duty is a by-product of operating the system, not a quarterly deck-building exercise.

A workable build order for a 50-person firm:

1. Pick one register. Retire parallel spreadsheets that disagree with each other.
2. Key owners to the HR identity, such as the employee record or work email, not a typed name.
3. Connect the joiner, mover and leaver feed so changes raise reassignment tasks.
4. Schedule the orphan check.
5. Schedule the identity provider comparison.
6. Feed the leadership pack from live metrics.

Each mechanism leaves its own evidence trail:

What will auditors ask about Clause 5.3, and how is it graded?

Auditors ask who is accountable for the ISMS, how the board hears about performance, and what happened to a named leaver's responsibilities. Missing both mandated assignments, or having no reporting route to leadership, grades major. A ghost owner, missing deputy or lagging matrix grades minor, though a pattern aggregates to major.

Expect the questions in roughly this form:

• "Who is accountable for this management system meeting the standard, and where is that written down?"
• "How does the board find out how security is performing? Show me the last report and the minutes."
• "What are your security responsibilities?" Interviewees across sessions get this one, and their answers are checked against the matrix.
• "This person left in June. Walk me through what happened to everything they owned."
• "You gave this role the duty. Do they have the access and budget to do it?"

Auditors sample three things: the ownership matrix against interview answers, a recent leaver or mover traced through the register, and access rights checked against assigned duties. Interviews produce the most surprises, because staff answer from memory and the document cannot help them.

Grading follows certification-body practice on absence versus weakness. If a required assignment does not exist at all, the requirement is absent and the finding is major. If the assignment exists but operates imperfectly, the finding is minor, and repeated minors in one area aggregate because a pattern suggests the system is not working.

Rehearse the same three samples before Stage 2:

1. Trace a leaver. Pick someone who left recently and show where each responsibility went.
2. Interview three staff. Ask what their security responsibilities are, then compare the answers with the matrix.
3. Check the identity provider. Match two owners' access to their assigned duties.

With an engineered register, each test has a ready answer. The leaver trace is a ticket, the matrix is current and the performance pack is already built, so the audit room becomes a demonstration instead of an interrogation.

Frequently asked questions