---

ISO 27001 Annex A control 5.2 is one of those controls that looks simple on paper, “define and allocate information security roles and responsibilities”, and ISO 27001 only explicitly names two roles that must exist, but in practice, it’s the difference between a tidy, well-run ISMS and one where everyone assumes “IT are doing it”.

This control ensures people know what they’re meant to do for information security, that it’s written down, approved, and communicated, and that accountability rests in the right place (usually with managers and asset owners, not just the security lead).

What the control says

Annex A 5.2 requires your organisation to define and document roles & responsibilities and allocate them based upon your organisation’s specific requirements.

It’s asking you to focus on clearly documenting the roles the ISMS needs to run; this defines who is responsible for each aspect of the organisation’s information security.

In short, you need to;

• Allocate those roles to people or teams
• Make sure they understand what they are responsible for
• Keep people competent and up to date

It is essential that you determine the responsibilities at a high level (i.e., for ISMS governance) and at a lower level (who owns this document, procedure, policy, task, etc.).

It should tie back to your Information Security Policy (Annex A 5.1) and to any topic-specific policies you’ve issued.

---

Why do I need Roles & Responsibilities?

Any project or delivery that I’ve ever been a party to has clearly defined R&Rs, especially if I’m running it. Without them, people assume things like ‘someone else will pick this up’ or ‘it’s not in my job description, so I’m not doing it’. It can actually lead to a toxic culture, in my experience. I’ve often said to teams, “If I throw a ball into a group and shout ‘Catch!’, I don’t expect anyone to, but if I throw a ball and shout ‘Peter! Catch!’, then I expect a better outcome”.

So, without this control and a lack of documented roles and responsibilities, several things can typically happen:

• security tasks fall between the gaps;
• risk acceptance is done informally (or not at all);
• audits fail because “we thought Facilities did that”;
• security becomes “best efforts” instead of “assigned accountability”.

With 5.2 done properly and considered, and document r&r’s, you get:

• clear ownership of assets and controls
• a defined route for approving residual risk
• repeatable processes (backups, access reviews, supplier checks)
• much easier internal and certification audits

By assigning and documenting specific information security responsibilities, individuals are held accountable for their actions, thereby supporting compliance and audit requirements.

Responsibilities explained in this way help organisations meet certification standards such as ISO 27001 by ensuring all responsibilities for information security are defined, allocated, and regularly reviewed.

---

What Roles & Responsibilities Need to be Assigned

If you read the main ISO 27002:2022 standard, you’ll see in Clause 5.2 (not control 5.2!) , that there are two main responsibilities mandated;

1. Someone must ensure the ISMS conforms to the requirements of the ISO 27001 standard itself
2. Someone must report on the performance of the ISMS to top management

It’s a common mistake that people think that’s all that needs to be addressed. I’m sorry to say that if you go into an audit with just those two responsibilities documented, you’ll come unstuck.

If you jump down to the controls and search for the word “responsibilities“, you’ll find 12 uses of that term and a selection of variations. The control 5.2, then, says they must be allocated according to “organisational need”.

So, in practice, minimally make sure someone is responsible for:

#	Responsibility area	What it covers	Typical owner
1	Protecting information and assets	Every information asset (systems, data sets, shared drives, SaaS apps) needs an asset owner who is accountable for its protection. Data owners are responsible for the confidentiality, integrity, and availability (the CIA Triad) of those assets.	Asset owner / data owner (usually the business or service owner)
2	Running security processes	User provisioning and deprovisioning, vulnerability management, incident handling, logging and monitoring, backup checks, change control, and similar operational processes. Each process needs a named role.	System administrators and key operational personnel as part of their job functions
3	Risk management and risk acceptance	Someone has to approve residual risks once treatments have been applied. This is normally the risk owner, who is the business or service owner closest to the risk, not the ISMS manager.	Risk owner (business or service owner)
4	All personnel using information	Every employee has responsibilities based on their job role and business processes: following policies, reporting incidents, classifying information correctly, and protecting credentials.	All employees and contractors
5	Authorisation levels	Defining and documenting who can grant access, who can approve exceptions, and who can approve suppliers. These authorisation levels should be written down, not just understood informally.	Defined per process, usually management or designated approvers

Assigning specific duties and responsibilities based on available resources is essential for effective information security management – you don’t have to overdo it, and remember that a role or responsibility is not the same as a job description. It might be part of your job description (it really should be, but it should not be confused with a job description).

---

Typical information security roles

You don’t have to create lots of new job titles. ISO is happy for you to add duties to existing roles if you’re a smaller organisation. A typical setup I commonly see in SMEs looks like this:

• Information Security Manager / ISMS Owner
  Coordinates the ISMS, maintains policies, tracks risks and actions, and reports to management. Supports the business but is not automatically responsible for every risk.
• Senior Management / Leadership
  Approves the ISMS, sets direction, signs the policy, and accepts major residual risks.
• Asset Owners / System Owners
  Accountable for day-to-day protection of the asset: access, backups (or assurance of them), supplier SLA, classification, and user list.
• Process Owners (e.g. HR, IT, Finance, Operations)
  Own controls inside their processes — HR for onboarding/offboarding, IT for technical controls, Finance for payment systems.
• Risk Owners
  Typically, the person who runs the service or process. They decide whether to accept a risk once it has been treated.
• All Staff / Contractors
  Must follow policies, complete training, report incidents or weaknesses, and protect credentials and devices.

In larger organisations, a chief information security officer (CISO) may lead the information security team, providing support, guidance, and resources to ensure clear roles and responsibilities are maintained and documented across the team.

Depending on size, you might also define: Data Protection Officer (if applicable), Business Continuity lead, Incident Manager, Supplier Manager.

---

How to Implement Roles & Responsibilities under Control 5.2

Here’s a typical approach I might take you through as a client when tackling the R&Rs.

1. Start from the policy
   Your information security policy (5.1) should already say who is responsible for information security overall. Use that as your top-level statement.
2. List the security activities you actually do
   Access control reviews, incident response, risk assessment, supplier due diligence, backup checks, patching, awareness training, and physical security checks. Put them in a simple table.
3. Assign an accountable role to each activity
   Use existing roles where possible: “Head of Operations”, “IT Manager”, “HR Manager”, “Project Manager”. Avoid assigning everything to “IT”.
4. Document it
   The neatest way is a Roles and Responsibilities section in your ISMS manual, and/or a separate Information Security Responsibility Matrix (RACI). That also makes good audit evidence. Personally, I think a RACI matrix in any area of business is a powerful yet simple tool.
5. Communicate it
   Add key responsibilities to job descriptions; include them in induction; reinforce in awareness training; publish the matrix on your intranet/SharePoint.
6. Check competence
   Where you’ve assigned a role (e.g. Incident Manager), make sure the person has the skills or training. The control expects people to be “competent and supported to keep up to date”.
7. Review annually or on change
   If you add a new SaaS platform, buy a company, or change your structure, revisit the matrix. ISO 27001 certification audits will often ask for the current version. To ensure roles and responsibilities are effectively implemented and remain current, regularly review and update your documented procedures as part of your continual improvement process. This supports ongoing compliance and security effectiveness.

An example of a RACI matrix.

I said above that I favour a RACI matrix because it’s unambiguous and easy to create. Yes, it is possible that it creates a bit of friction the first time you go through it with people, but that’s much better than a clash of personalities and assumptions later down the line.

A RACI matrix is a quick way to document who does what across your ISMS. The four letters stand for:

• R – Responsible: the person who actually does the work
• A – Accountable: the person who owns the outcome and signs it off (only ever one per activity)
• C – Consulted: people whose input is needed before the work happens
• I – Informed: people who need to know it has happened, but aren’t involved in doing it

The example below is written for a typical UK SME of 25 to 100 people, where roles often double up. If you’re a 15-person company, the same person might fill three columns at once; if you’re 250-strong, each column is likely a different person. Adjust to suit your reality.

ISMS Activity	Top Management (MD/CEO)	ISMS Manager	IT Lead	HR Lead	All Staff
Approve the Information Security Policy	A	R	C	C	I
Approve topic-specific policies	A	R	C	C	I
Maintain the risk register	I	A, R	C	C	–
Approve residual risks	A, R	C	C	C	–
Run user provisioning and deprovisioning	I	C	A, R	C	–
Manage information security incidents	I	A	R	C	I
Conduct internal audits	I	A, R	C	C	I
Run management review meetings	A	R	C	C	I
Communicate policies to staff	I	A	C	R	I
Deliver security awareness training	I	A	C	R	I
Acknowledge and follow policies	A	I	I	I	R
Report security incidents and concerns	I	I	I	I	R
Approve supplier security arrangements	A	R	C	I	–
Approve changes to the ISMS	A	R	C	I	I

A few things worth noting about this example:

Top management’s role is mostly accountability, not delivery. They sign things off, they own the outcome, but they don’t usually do the operational work. This is exactly what Clause 5.1 (Leadership and Commitment) expects.

The ISMS Manager is the spider in the middle of the web. They’re responsible for most of the day-to-day ISMS activity. In smaller organisations, this role is often held by the same person as the IT Lead, or sometimes by the MD themselves, wearing a second hat. That’s fine, as long as it’s documented.

“All Staff” only appears as Responsible for two activities, but those two are the foundation of a working ISMS: people actually following the policies and actually reporting incidents. Without those, the rest is paperwork.

Auditors don’t expect a perfect RACI. They expect a documented one that matches what actually happens. A simple table like this, kept current and reviewed annually, is enough to satisfy Control 5.2 in most SME audits. If your reality is messier than your RACI, fix the RACI; if your RACI is more elaborate than your reality, simplify it.

Build a RACI Matrix for Your Organisation With My RACI Tool

If you aren’t sure what roles and responsibilities you might need for your small business, then try my tool, which will help guide your thinking.

---

What Auditors Will Look For

Roles & responsibilities will encompass lots of things. The auditor will expect it to be documented at a high level in the ISMS, but will then look at each document, policy, and procedure to ensure R&Rs are clear there as well. So, an ISO 27001 auditor will normally ask for:

• An organisation chart or governance diagram showing who is responsible for information security. I usually put a high level one in the ISMS handbook if you are creating one, along with a description of the business, as this helps them with context.
• a roles and responsibilities document or RACI linked to your information security policy
• job descriptions (or similar) that contain information security duties for key roles
• evidence of communication (induction, awareness training, policy sign-off)
• and sometimes records of risk acceptance to confirm it was done by a proper risk owner, not just “the security person”

Auditors may also check that information security policies are communicated to all interested parties and stakeholders, and that compliance with relevant regulations is demonstrated. They’ll also test it verbally: “If you found a laptop was lost, who would you tell?”, “Who can approve a supplier that will host personal data?”, “Who signs off access rights?”. If staff can answer, your 5.2 is working.

---

Common Issues I Find During Internal Audits

• Everything sits with IT or the InfoSec Manager – That breaks the spirit of 5.2. Business owners must own business risks. Business processes should be owned by the relevant function, etc. Just slapping it all on one person is lazy and dangerous for everyone. Possibly unavoidable in a micro-organisation, but for most SMEs, you need to ensure the right job sits with the right person, and you can defend the decision. I recently performed an internal audit for a 40-person SaaS company where the risk register listed 30 risks, but only the InfoSec Manager was listed as the owner of every single one. I had to flag the nonconformity because risk acceptance can’t be done by the person who runs the ISMS; it has to sit with the business.
  
• No owners for cloud/SaaS – “Because it’s SaaS” is not a reason to avoid assigning an owner. Someone must own the supplier, the data and users in that platform. When you look at the control around cloud services (5.23) it sits right beside supplier management (5.22), and that’s by design. They want someone to ensure that cloud services are owned, overseen, and managed.
  
• No link to risk management – 5.2 should connect to Clause 6.1 (actions to address risks and opportunities). If there’s a risk, there’s a risk owner. I cannot tell you how many times I find risk logs without owners for residual risk and activities within the risk treatment plan.
  
• Nothing written down – “Everyone knows” is not compliant. It has to be defined, allocated, and communicated. Write. It. Down!
  
• No competence – You named an Incident Manager, but never trained them how to manage incidents. As part of 27001 Clause 7.2, you must ensure the competence of the ISMS responsibilities you’ve assigned to people.
  

---

How does ISO 27001 Control 5.2 link to other clauses and controls

• Annex A 5.1 – Policies for information security: 5.2 is how you make 5.1 real. Policy says what; 5.2 says who.
• Clause 5 – Leadership: leadership must assign roles and responsibilities for the ISMS.
• Clause 7.2 – Competence: once you’ve assigned roles, you must ensure the people in those roles are competent.
• Annex A 5.9 – Inventory of information and other associated assets: once you have asset owners, 5.2 gives them accountability.
• Annex A 5.3 – Segregation of duties: where duties must be separated, 5.2 is part of the documentation for that.

---

FAQs

---

Conclusion

Control 5.2 isn’t difficult, but it’s one of the most commonly underthought controls in the standard. The temptation is to default to “the InfoSec Manager owns it” or “IT looks after that”. Both are wrong, and both create audit findings.

Document who does what, who signs it off, who needs to know, and who needs to be consulted. Keep the matrix simple, keep it current, and make sure the people named in it know they’re included. That’s most of the way there.

If you’d like a ready-made RACI matrix template you can adapt to your organisation, the Iseo Blue ISO 27001 Toolkit includes one, along with every other document you need for certification. Or, if you’d rather talk through how to right-size roles for your specific structure first, the free 30-minute consultation is genuinely free and 30 minutes long.

---