Skip to content
compliancebase
ISO 27001A.5 — Information security roles and responsibilities

A.5.2

Information security roles and responsibilities

ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026

Objective

Assign, document, and communicate information security roles and responsibilities across the organization so accountability for ISMS outcomes is unambiguous.

Points of focus

  • RACI or ownership matrix maps every ISMS process to a named individual and a backup
  • Roles cover engineering, security, legal/privacy, and executive sponsorship
  • Role changes trigger updates to the matrix and any dependent access
  • Ownership is communicated in onboarding, not just buried in a policy PDF

Implementation notes

Build a single ownership matrix — not a policy clause — that names an accountable owner and a backup for every ISMS process: risk register, SoA maintenance, access reviews, incident response, vendor risk, and business continuity. Tie it to the org chart so it updates when someone changes teams or leaves, and review it at every management review, not just at renewal. Publish it somewhere engineers actually look, such as an internal wiki or onboarding doc, rather than a security policy PDF nobody opens after signing. When a startup runs a lean security function, one person may hold several roles — document that explicitly and name a delegate for at least the highest-risk processes, incident response and access reviews, so a single absence does not stall operations or an audit.

Audit tip: Ask three engineers, not just the ISMS owner, who is responsible for access reviews, incident response, and vendor risk. If the names do not match the matrix, the control fails regardless of the paperwork.

Evidence auditors typically request:

  • RACI/ownership matrix listing risk owner, SoA owner, access-review owner, incident commander, and vendor-risk owner
  • Security policy set showing named approvers and version history, not just a role title
  • Onboarding materials or internal wiki page where new engineers can find who owns what
  • Org chart snapshot cross-referenced against the ownership matrix at the last management review

Common gaps

  • Ownership matrix names a person who left the company months ago
  • Only one person can approve access reviews, vendor risk, and the SoA, with no backup, so audits stall when they are on leave
  • Roles exist in the policy but engineers describe a different informal owner in interviews
  • Security champions or delegated reviewers in product teams are undocumented

Cross-Framework Mapping

FrameworkRequirementImplementation note
ISO 27001A.5.2This control
SOC 2CC1.3SOC 2 CC1.3 asks for the same organizational chart and authority structure — reuse the ownership matrix instead of maintaining two separate documents.

Primary sources

Frequently Asked Questions

No. It requires clear, documented accountability. A five-person startup can satisfy this with a named CTO as risk owner and a documented backup — what fails is undocumented or contradictory ownership, not a small headcount.

A.5.1 sets the policy content; A.5.2 assigns who is accountable for executing and maintaining it. Auditors check both: does the policy exist, and does a named person actually run it?

Update the ownership matrix immediately and reassign dependent access, such as approver groups and ticket queues, before the next control operates. A stale owner name is one of the most common Stage 2 findings.

No, but they need enough context to step in during an absence or turnover. Document handoff notes and give backups read access to the relevant systems so they are not starting from zero.

Framework versions referenced in this page:

  • ISO/IEC 27001 — ISO/IEC 27001:2022

Last verified: July 2026 · Primary sources linked above