SekitCrosswalk
ENES
Start now
ISO/IEC 27001:2022 · derived mapping target

A.5.2Information security roles and responsibilities

Assign and document who is responsible for what in information security, so every protection task has a clear owner. Avoid gaps and overlaps by mapping responsibilities to named roles or people.

Mapping at a glance
A.5.2Information security roles and responsibilitiesISO/IEC 27001:2022
RCF-0004Roles & responsibilitiesGovernance & Risk · PolicyRCF-0005Roles & responsibilitiesGovernance & Risk · ProcessRCF-0028Security charterGovernance & Risk · PolicyRCF-0049Ownership & custodiansAsset Management · PolicyRCF-0050Ownership & custodiansAsset Management · Process

A.5.2 is covered by 8 Sekit CSF controls. +3 more in the table below. Open in the full graph →

Mapped from the Sekit CSF

The Sekit controls that cover this requirement, lens by lens.

RCF-0004Roles & responsibilities · PolicyequivalentSekit's Roles & responsibilities policy is the direct implementation of A.5.2: it names a specific owner for overall security and for each recurring duty, which the control asks organizations to document.RCF-0005Roles & responsibilities · ProcesssupportsThe recurring-duty verification process turns the written role assignments into something an auditor can check, supporting A.5.2's requirement that responsibilities are exercised, not only assigned on paper.RCF-0028Security charter · PolicysupportsThe security charter names the accountable owner and grants that person a management mandate, supporting A.5.2's requirement to document who holds overall responsibility for the security programme.RCF-0049Ownership & custodians · PolicysupportsNaming an accountable owner for every system, dataset and device is a narrower application of A.5.2's requirement, mapping responsibility down to the asset level rather than the programme level.RCF-0050Ownership & custodians · ProcesssupportsOwners confirming their assets on a set cadence gives A.5.2's ownership requirement a working process, not a name recorded once and forgotten.RCF-0142DevSecOps governance · PolicysupportsAssigning a named accountable person for development and operations security is a role definition inside a specific function, supporting A.5.2's broader requirement to map responsibilities to people.RCF-0262Roles & communications · PolicysupportsIncident roles, decision authority and deputies are role assignments for a specific scenario, an instance of the same accountability mapping A.5.2 requires across the security programme.RCF-0397Executive briefings · PolicyrelatedRegular executive briefings keep leadership informed on security posture, a related governance practice that reinforces accountability without itself assigning any specific security responsibility.

NIST CSF 2.0 counterparts

Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.

GV.RR-01 Leadership accountability for cyber riskGV.RR-02 Roles and responsibilities establishedID.AM-05 Assets prioritized by criticalityID.AM-02 Software inventory maintainedGV.PO-01 Cybersecurity policy establishedGV.RR-03 Resources allocated for cybersecurityGV.RR-04 Cybersecurity in human resourcesPR.PS-01 Configuration management appliedPR.PS-03 Hardware maintainedGV.OC-01 Organizational mission understoodPR.AT-01 General security awareness trainingRS.CO-02 Stakeholders notifiedRS.MA-01 Incident response plan executed

ISO/IEC 42001:2023 — Annex A counterparts

A.3.2 AI roles and responsibilitiesA.8.4 Communication of incidents

Cyber Essentials counterparts

CE4.1 Manage the account lifecycle

Evidence that proves this control

What an auditor, or Sekit's evidence engine, asks for.

Security roles and responsibilities
The document or chart showing who owns each aspect of security in the company (e.g. a security org chart or a RACI matrix).
From the Sekit evidence catalog

In practice

In a small company this control usually lives as a short table: who owns security overall, who owns incident response, who owns access reviews, mapped to named people rather than job titles that might change. Auditors check the security roles and responsibilities document against the org chart and ask a named owner directly what their duties involve; a mismatch between the document and what the person can describe is the most common finding. The usual failure is a security officer title given to someone with no time carved out for the role, so the duties exist on paper but nobody performs them.

Common gaps

The named security owner changed roles or left the company months ago and the roles document was never updated to reflect who holds the responsibility now.
Responsibilities are described at a general level, such as 'IT manages security', without naming which specific duties, like access reviews or incident triage, that role owns.
The person assigned a security duty was never told about it and cannot describe what the responsibility involves when asked directly.

Questions your auditor will ask

Who is accountable for information security in this organization, and how is that documented?
Point to the security roles and responsibilities document, naming the accountable individual and the date the assignment was last confirmed.
How do you avoid gaps or overlaps between roles?
Show the responsibilities mapped one duty at a time to a single named owner, so each recurring security task has one person accountable for it.
Does the named owner perform their assigned duties on a regular basis?
Provide evidence the duty is exercised on a verifiable rhythm, such as a signed access review log or incident response drill record tied to that person's name.
What happens to a role's responsibilities when that person leaves?
Describe the handover step in the offboarding process that reassigns the departing person's security duties to a named successor before their last day.

Where regulation demands it

NIS2 art. 1.2 (Roles, responsibilities and authorities) requires the same mapping of security duties to named, accountable people.
ENS mp.per.1 (Caracterización del puesto de trabajo) requires each post to have its security responsibilities defined, the same accountability mapping A.5.2 documents.

Related controls

Via the shared Sekit CSF topic, not the framework's own index.

A.5.1 Policies for information securityA.5.3 Segregation of dutiesA.5.4 Management responsibilitiesA.5.9 Inventory of information and other associated assetsA.5.15 Access controlA.5.24 Information security incident management planning and preparationA.5.26 Response to information security incidentsA.5.35 Independent review of information security
Ask Sekura: “What evidence proves A.5.2?”
Also via MCP, free with account