ISO 27001 Annex A 5.2: security roles without a security team

The auditor pulls a risk from your register and asks to speak to the owner named against it. That person left in the spring, or has never heard of the duty. ISO 27001 Annex A 5.2, information security roles and responsibilities, is where that moment is tested, and a firm of 25–250 people with no security department feels it hardest.

This guide covers what the control asks, how it separates from Clause 5.3 and Clause 7.2, and how to build a one-page structure that survives joiners and leavers. It is written for security managers, fractional CISOs and operations leads who carry these duties as second hats.

What does ISO 27001 Annex A 5.2 require?

ISO 27001 Annex A 5.2 requires the organisation to define who carries each information security duty, allocate those duties to named people, and communicate the allocations to them. Owners cover protecting assets, running processes and accepting residual risk. Allocations must be written down, shared with the people concerned and kept current.

The control is smaller than it first reads. ISO 27001 roles and responsibilities need no particular job titles and no team. You decide who protects which assets, who runs which processes, who owns which risks and who signs off the exposure that remains.

Delegation is fine. A support lead can run supplier checks on the owner's behalf, but accountability stays with the person the duty was assigned to.

An auditor looks for four things:

• Defined. Each duty is described as a task, not a topic.
• Allocated. One named person holds each duty, not a team alias or a shared mailbox.
• Communicated. The holder knows about the duty, and you can show how they were told.
• Current. The names match who works for you today and what they can access.

The control is preventive. Duties without a named holder don't get done, and that absence is how incidents start. Every other safeguard depends on someone operating it, so the allocations reach past governance into HR: job descriptions, contracts and the joiner–leaver lifecycle.

At this size every duty is a second hat. When no name sits against a task, the honest answer to "who reviews access?" is "nobody". After an incident, lawyers and regulators ask the same question with higher stakes: who was responsible, and did they know?

How does Annex A 5.2 differ from Clause 5.3 and Clause 7.2?

Annex A 5.2 tests whether security duties are allocated and understood across the organisation. Clause 5.3 tests whether top management has assigned ISMS authority, and Clause 7.2 tests whether the people holding those roles are competent. The three pair up in audit, so the evidence should line up.

Clause 5.3 is the leadership half. Top management assigns and communicates authority for the ISMS, the information security management system. At board level, the NCSC Cyber Governance Code of Practice sets out the governance actions directors need to take ownership of, so a security lead's authority should trace back to leadership.

Clause 7.2 is the competence half. It asks whether the people holding roles have the skills to carry them out. A named owner with no relevant training is a competence gap, not an allocation gap.

Each touchpoint leaves a different trail:

• Annex A 5.2: the matrix, registers and job descriptions showing named allocation.
• Clause 5.3: a terms-of-reference line and management review minutes showing leadership endorsement.
• Clause 7.2: role-specific training records showing the holders can do the job.

Build this evidence once. A single matrix with a version history, one leadership line in the minutes and role-linked training records answer all three.

Take one sampled interview. The auditor asks the named risk owner what the duty involves, which is 5.2. Then comes who gave them authority to accept the risk, which is 5.3, and what training prepared them, which is 7.2. One conversation tests three clauses, and a gap in one trail tends to expose the others.

Keep the three apart in your documents too. If the leadership authority line is buried inside the roles matrix, the Clause 5.3 evidence is hard to find, and interview time goes on hunting for it.

Does ISO 27001 Annex A 5.2 need a full-time CISO at 25–250 staff?

No. Annex A 5.2 needs a named, competent security lead with real time allocated, not a full-time CISO. At 25–250 staff that is usually a fractional appointment or a senior engineer or operations lead with the duty made explicit, while leadership keeps accountability and the ICO's security guidance calls for a designated individual.

Enterprise role lists assume a full-time CISO and a dedicated SOC. Those are written for organisations with a department. The ICO guide to data security asks for something smaller: clear accountability, and a designated individual with day-to-day responsibility and appropriate authority for security.

Three candidates usually fill the lead seat:

• Fractional CISO. Brings experience and builds the structure, which suits a firm with no security background in-house.
• Senior engineer. Has the technical depth, but the time competes with delivery unless it is carved out.
• Operations lead. Strong on process, suppliers and people, though technical duties need a named engineering owner alongside.

Whoever it is, "supported" has a concrete meaning. The role carries protected time, a budget line and the authority to ask other teams for access reviews or evidence. Without those, the title is decorative, and an auditor reads the gap as a resourcing failure rather than commitment.

The lead's week is modest: chairing the access review, keeping the RACI current, collecting evidence and escalating when an owner doesn't act. It is a fraction of a working week, but it is a fraction that has to be protected.

Piling every security duty on one willing person isn't ownership. It's a single point of failure with a job title.

Spread the duties instead. Leadership holds accountability, one lead coordinates, and named owners carry the register entries. Each hat stays light enough that none of them needs a new hire.

How do ISO 27001 information security policies and job descriptions document roles?

ISO 27001 information security policies anchor the allocation of duties; job descriptions and employment terms carry the actual tasks. Write each duty in plain, role-specific language, such as 'reviews production access quarterly', rather than citing the standard. Generic citations do not survive an auditor's interview with the role holder.

The policy suite from Annex A 5.1 is the anchor. An approved information security policy states which roles exist and who answers for what in principle. The job description then translates those principles into tasks the holder recognises as their own.

Plain wording looks like this:

• Replace "responsible for information security" with "approves access to the finance system and signs the leaver checklist for their team".
• Replace "supports risk management" with "owns the supplier risk entries and reviews treatment status monthly".
• Replace "complies with ISO 27001" with "reviews production access every quarter and records the outcome".

Keep contracts short and general, and put task-level detail in the job description. A change of duties then needs a revised job description and an acknowledgement, not a contract rewrite.

Even good wording fails when the allocation lives only in people's heads. Everyone "sort of knows" who does what, but nothing shows approval or acknowledgement.

The fix is a trail. Record the policy approval in management review minutes, and capture an acknowledgement when someone joins or their duties change. A tracked read-and-accept in the HR platform does the job at this scale, and the onboarding pack becomes the place a new engineer finds their security duties.

How do you build a one-page RACI and assign register owners?

Build a one-page RACI covering recurring security tasks, such as access reviews, incident response, supplier checks, backup verification and policy upkeep, then give every asset and risk register entry a named owner. Risk owners decide treatment and accept what remains; asset owners approve access and set handling. At 50 people, one page is enough.

Work in this order. Expect a few days of effort once the policy suite exists:

1. Write the leadership line. A board or leadership terms-of-reference entry, echoed in management review minutes, says who answers for the ISMS.
2. Name the day-to-day lead. Choose from the options in the previous section and record the time allocated.
3. Name owners in both registers. A person, never a team, sits against every asset and risk entry.
4. Draw the one-page RACI. List recurring tasks down the side, roles across the top, and exactly one "A" per row. For the quarterly access review, that might read: platform lead R, security lead A, system owners C, leadership I.
5. Write the duties into job descriptions. Use the plain-language pattern from the previous section.
6. Match the matrix to the IdP. If the matrix says only the platform lead administers the cloud estate, the identity provider's groups should say the same.

A RACI that disagrees with your identity provider isn't documentation. It's fiction.

Brief each owner when you name them. A two-line note saying what the entry asks of them, kept beside the register, is the cheapest evidence of communication you will produce.

A 40-tab spreadsheet is over-engineering. Detail beyond a page is usually a second copy of data that already lives in the registers, and second copies drift.

Sequence matters. Do this early, because asset ownership under Annex A 5.9, risk ownership under Clause 6 and conflict-of-duty design under Annex A 5.3 all build on these allocations. Review cadence is covered in the FAQ below.

What do auditors sample and ask about A.5.2 roles?

Auditors pick two or three owners from the asset and risk registers and interview them against their documented duties. They also pull a recent joiner's job description, cross-check the matrix against live IdP permissions, and trace a leaver from the last year. A departed employee still named in a register grades minor; no defined structure grades major.

Expect five questions in the room:

• Who is accountable for information security here, and where is that written down?
• You're named as owner of this risk. What does that involve, and what have you done about it this quarter?
• How does a new engineer find out which security duties come with their job?
• Who can grant admin access to production, and does the documentation agree with the IdP?
• When did you last review these allocations, and what changed?

The questions probe one thing from five angles: whether the structure is real, endorsed, understood, aligned and maintained. Run through them with the role holders before audit week, not in the corridor.

The evidence that proves maintenance, rather than minting for the audit, is mostly a by-product of the build:

• A responsibility matrix whose version history shows edits across the year.
• An org chart showing security reporting lines to leadership.
• Job descriptions carrying tailored duties for the sampled roles.
• Asset and risk registers with current, named owners.
• Management review minutes recording leadership oversight of the structure.
• Leaver and mover records showing ownership was reassigned.
• Role-specific training records for the holders.

At this scale auditors accept lightweight forms over a formal charter nobody updates, so version history matters more than formatting.

The minor and major grades for ghost owners and missing structures come from certification-body norms, not from the standard. The same norms grade a structure leadership plainly hasn't endorsed as major, and one sampled owner unaware of a duty as minor. Repeated minors aggregate to a major as a pattern.

How do you stop ghost owners and role drift with automation?

Stop ghost ownership by treating roles as data: link role records to the HR system so a leaver or role-change event opens reassignment tasks for every asset, risk and duty held. Then run a scheduled job comparing documented allocations with live IdP group membership, so drift surfaces on a dashboard, not in an audit.

Four mechanisms replace the manual habits behind the findings above:

• Matrix as data. Roles, holders and duties are records linked to the HR system, so ownership is queryable and every duty has exactly one accountable name. Orphaned duties show up on a dashboard.
• JML-triggered reassignment. A joiner, mover or leaver event in the HR platform opens tasks for everything the person owned. The ghost-owner gap closes at the moment it opens.
• IAM reconciliation. The scheduled job catches the matrix that names one cloud admin while the IdP shows five.
• Competence tracking. Training requirements attach to the role record, with completion pulled from the learning management system, so the Clause 7.2 evidence assembles itself.

The fossilised annual refresh changes character too. When changes are logged as they happen, the annual review confirms a record maintained all year, and the version history proves it.

The result is the auditor's favourite cross-check, run on yourself continuously. You find the extra admin group on a Tuesday afternoon, not in the closing meeting.

GRCMANA builds this in two parts. Our Fractional CISO engagement opens with this control: it fills the security-leadership seat and builds the registers, matrix and contract wording around it. Our GRC engineering service builds the data and automation layer above that structure.

Frequently asked questions