ISO 27001 Control 5.2: Information Security Roles and Responsibilities

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” — but in practice it’s the difference between a tidy, well-run ISMS and one where everyone assumes “IT are doing it”.

Top management demonstrates commitment by establishing a framework for information security roles and responsibilities, and holds overall responsibility for ensuring these are clearly defined and properly allocated.

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

What the control says (in plain English)

Annex A 5.2 requires your organisation to focus on defining and clearly documenting the information security roles it needs; this defines who is responsible for each aspect of the organisation’s information security;:

allocate those roles to people or teams;
make sure they understand what they are responsible for;
and keep them competent and up to date.

The purpose is to establish a clear, understood structure for implementing, operating and managing information security across the organisation — not just inside IT.

It is essential that these roles and responsibilities are effectively implemented as part of the organisation’s information security procedures and overall implementation, ensuring the organisation’s information security is managed in line with best practices.

It should tie back to your information security policy (Annex A 5.1) and to any topic-specific policies you’ve issued.

Why it matters

Without this control:

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

With 5.2 done properly you get:

clear ownership of assets and controls;
a defined route for approving residual risk;
repeatable processes (backups, access reviews, supplier checks);
and 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 needs to be assigned

ISO/IEC 27002:2022 expands on this and gives a useful list of what must have an owner. In practice, make sure someone is responsible for:

Protecting information and assets
Every information asset (systems, data sets, shared drives, SaaS apps) should have an asset owner who is accountable for its protection. The data owners are responsible for the confidentiality, integrity, and availability (the CIA Triad) of these information assets.
Running security processes
Things like user provisioning/deprovisioning, vulnerability management, incident handling, logging/monitoring, backup checks, change control — these are processes, and each one needs a named role. System administrators and key personnel are often responsible for running these security processes as part of their job functions.
Risk management and risk acceptance
Someone has to approve residual risks. That’s normally a risk owner (often the business/service owner) — not the ISMS manager.
All personnel using information
All employees and each employee have responsibilities based on their job functions and business processes: follow policies, report incidents, classify information correctly, protect credentials.
Authorisation levels
Who can grant access? Who can approve exceptions? Who can approve suppliers? These levels should be defined and documented.

Assigning specific duties and responsibilities based on available resources is essential for effective information security management.

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 looks like this:

Information Security Manager / ISMS Owner
Coordinates the ISMS, maintains policies, tracks risks and actions, reports to management. Supports the business but is not automatically owner of every risk.
Senior Management / Leadership
Approves the ISMS, sets direction, signs the policy, 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, 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.

Delegation vs accountability

The standard makes a useful point: people with information security responsibilities can delegate tasks, but they remain accountable and must check the task was done.

Example: the asset owner can ask IT to run a quarterly user access review report, but the owner still has to review and sign it off. Accountability stays close to the business process.

How to implement Annex A 5.2 (practical approach)

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.
List the security activities you actually do
Access control reviews, incident response, risk assessment, supplier due diligence, backup checks, patching, awareness training, physical security checks. Put them in a simple table.
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”.
Document it
The neatest way is a Roles and Responsibilities section in your ISMS manual, or a separate Information Security Responsibility Matrix (RACI). That also makes good audit evidence.
Communicate it
Add key responsibilities to job descriptions; include them in induction; reinforce in awareness training; publish the matrix on your intranet/SharePoint.
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”.
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.

What auditors will look for

An ISO 27001 auditor will normally ask for:

an organisation chart or governance diagram showing who is responsible for information security;
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 pitfalls

Everything sits with IT
That breaks the spirit of 5.2. Business owners must own business risks.
No owners for cloud/SaaS
“Because it’s SaaS” is not a reason to avoid assigning an owner. Someone must own the data and users in that platform.
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.
Nothing written down
“Everyone knows” is not compliant. It has to be defined, allocated, and communicated.
No competence
You named an Incident Manager, but never trained them. Auditors notice.

How this links 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 documenting that.