ISO 27001 Control A.5.2: Information Security Roles and Responsibilities

When something goes wrong with security, the first question is usually “whose job was this?” If the honest answer is “everyone’s”, it is nobody’s. A.5.2 exists to prevent that moment. It is the second of 37 organizational controls in our walk through Annex A, and it follows naturally from the policy set in A.5.1: once the rules exist, someone has to own them.

This control often surprises small organizations, because it sounds like an org chart exercise. It is not. It is a practical question about who approves access, who responds to an incident, who owns each risk and each asset, and who steps in when the usual person is on holiday. Most of the answers already exist in people’s heads. The task is to write them down, agree them and make sure nothing falls between two chairs.

What the control requires

Annex A control 5.2 of ISO 27001:2022 states that information security roles and responsibilities shall be defined and allocated according to the organization needs.

The key elements:

Information security roles and responsibilities - the duties that keep information protected, from running the ISMS to owning an asset, approving access or reporting an event
Defined - written down clearly enough that the person and their colleagues understand what is expected
Allocated - assigned to named people or positions, not left floating
According to the organization needs - sized to your structure, risks and size; there is no standard org chart to copy

A.5.2 is a preventive control as classified in ISO/IEC 27002:2022. Annex A states the control; ISO 27002 gives guidance, including that responsibilities should be defined in line with the information security policy and topic-specific policies, that responsibilities for protecting individual assets and carrying out specific security processes should be identified, that responsibilities for risk management activities and the acceptance of residual risks should be defined, and that local responsibilities for sites and information processing facilities should be considered. The guidance also notes that individuals with allocated responsibilities may delegate tasks, but they remain accountable and should check that delegated work is carried out correctly. It further suggests that areas for which individuals are responsible should be defined and that authorization levels are documented.

How to implement information security roles and responsibilities

Start from the work, not the titles

List the security activities that really happen in your organization: approving and removing access, managing suppliers, handling incidents, running backups, patching systems, reviewing policies, training staff, reporting to management, communicating with customers about security. Then ask who does each of them today and who should. Roles follow from the work. In a ten-person company, one person may carry several roles; in a larger organization, they may be spread across departments. Both are fine, as long as nothing is orphaned.

Common roles worth defining include:

Top management - accountable for the ISMS, resources and direction, in line with Leadership and commitment
Information security lead - runs the ISMS day to day, whether a full-time manager, a part-time role or an external vCISO
Asset and risk owners - people accountable for specific information, systems and risks, including accepting residual risk
System and technical administrators - responsible for secure operation, access, patching and backups
Line managers - responsible for their teams’ compliance with the rules
All personnel - responsible for following policies and reporting events

Write it down in a form people will use

A short roles and responsibilities document, or a RACI table (who is responsible, accountable, consulted and informed), covers it. Put role descriptions into job descriptions where it fits, and include security duties in the terms discussed in terms and conditions of employment. Link each topic-specific policy from policies for information security to a named owner, so reviews and updates have someone to drive them. Keep the document short; one that fits on a couple of pages gets read.

This control and clause 5.3, Organizational roles, responsibilities and authorities, overlap on purpose. The clause asks top management to assign responsibility for conformity of the ISMS and for reporting on its performance; the control extends that to the whole range of security duties across the organization. A single, consistent document can serve both.

Cover gaps, deputies and independence

For every important role, name a deputy. People fall ill, take holidays and leave. Cover for the incident contact, the person who approves access and the one who holds the keys to the backups should be explicit, with their contact details available to people who need them.

Look at conflicts, too. The person who requests a privileged access right should not also approve it; the author of a change should not be its only reviewer. The related control on segregation of duties (A.5.3) goes into this in depth, and it comes straight after this one in the series. For now, make a note wherever one person holds a combination of duties that could allow error or abuse without anyone noticing.

Make the roles real: competence, awareness, acceptance

A role is only as good as the person in it. Check that people have the competence to do what the role requires, following the expectations of Competence, and provide training where there are gaps. Brief everyone on who holds which role, so they know where to take a question or report an event; that helps the practice described in information security event reporting. Ask role holders to confirm that they understand and accept their responsibilities, and record it, for instance at onboarding or through the annual policy acknowledgement. Remember that responsibilities can outlast employment: our post on responsibilities after termination or change of employment covers the handover. Review the allocation whenever the organization changes, such as a reorganization, a new product, or a new site, and at least annually alongside your policy review.

Clause 5.1 connection. Leadership and commitment puts top management in charge of resources and accountability for the ISMS.

Clause 5.3 connection. Organizational roles, responsibilities and authorities requires top management to assign and communicate the roles that matter for the ISMS.

Clause 7.2 connection. Competence makes sure that people in these roles have what they need to do the job.

A.5.1 connection. Policies for information security defines the rules, and this control assigns who owns and enforces them.

A.6.2 connection. Terms and conditions of employment is where security responsibilities are set out in employment contracts.

A.6.8 connection. Information security event reporting depends on people knowing whom to tell.

A.7.6 connection. Working in secure areas is an example of a control that needs a named owner for each secure area.

Forward reference. Segregation of duties (A.5.3) and Management responsibilities (A.5.4) follow immediately in the series, and the later control on inventory of information and other associated assets (A.5.9) assigns an owner to each asset.

What auditors check

A documented allocation. Auditors look for a roles and responsibilities document, RACI or equivalent, and check that it is current and approved.

Match with practice. They interview people named in roles and ask what they actually do. A role that its holder cannot describe is a red flag.

Ownership of policies, assets and risks. Expect questions about who owns particular policies, systems and risks, and whether acceptance of residual risk is recorded against a named person.

Coverage and deputies. Auditors check that critical duties have cover, and that the loss of one person would not leave a gap.

Competence. They link roles to training and experience, looking for evidence that role holders are qualified for the work.

Communication. Staff interviews show whether people know who to contact for access, incidents and questions.

Common mistakes to avoid

A role list that mirrors the standard, not the business. Copying titles from a template produces roles nobody recognizes.

“Everyone is responsible” as the only answer. Everyone has duties, but critical tasks still need a named owner.

The security lead as owner of everything. Security cannot be centralized in one person. Asset and risk owners belong in the business.

No deputy. A single point of failure in a role is a risk in itself, especially for incident handling.

Responsibility without authority. If a person is accountable but cannot make or influence decisions, the allocation will not hold.

Never updated. Roles drift after reorganizations and departures. Review them alongside policies and when people change.

Not telling anyone. A well-written document in a folder does little. Make sure people know who holds which role.

How 27kay can help

We help organizations turn a vague sense of “someone looks after that” into clear, lightweight ownership, scaled to your size, whether you have five people or five thousand. As part of ISO 27001 implementation, we map the real security work, draft a roles and responsibilities document with you, and prepare the evidence auditors will ask for. For the full picture, see our ISO 27001 knowledge hub.

If a customer asked you tomorrow who is responsible for your security incident response, would the answer be a name or a shrug? Get in touch - we will help you make it a name.