A.5.2 Information security roles and responsibilities: evidence

What A.5.2 information security roles and responsibilities asks for in practice

A.5.2 asks the organization to define and allocate information security roles and responsibilities according to its needs. In practice, an auditor who asks who owns security expects a written answer that names people or functions, describes what each one is accountable for, and matches what staff actually do. The control carries forward control A.6.1.1 from the 2013 edition of the standard, and it builds on the clause 5.3 requirement that top management assign authority for the ISMS. Clause 5.3 says who has the authority to run the management system; A.5.2 goes down to the level of individual security responsibilities across the organization, such as who owns a system, who approves access exceptions, and who answers for supplier risk. The hard part is that roles often exist on paper but not in practice. A job description may mention security while the person named never reviews the controls it describes.

Without clear allocation, the risks are predictable. Controls go unowned because everyone assumes someone else runs them, two teams claim the same decision, or a critical task such as reviewing privileged access has no accountable person at all. When an incident happens, unclear accountability slows containment and makes the record of decisions hard to reconstruct. Start by listing the security activities the Statement of Applicability depends on, then assign each one a named owner, a deputy, and a reviewer who is independent of the work. Check that each owner has the time, authority and skills to do the job, and that the assignment is approved by the level of management that holds the authority under clause 5.3.

Record the allocation in a document that is version controlled and easy to find, such as a responsibility matrix or a role register, with the approval date and the review cycle. Confirm with your certification body how it expects roles to be evidenced for your scope, because the depth of evidence depends on the size and complexity of the organization. Then test the record against reality: ask the named owners to explain their responsibilities, and sample a few recent decisions to confirm that the right person made them. A role that cannot be shown in action will not satisfy an assessor, and it will not survive a customer questionnaire either.

Which roles, assets, processes and third parties this control covers

A.5.2 is only as useful as the scope behind it. The cards below cover the decisions that decide who and what must be named: which roles sit inside the ISMS, how small teams handle overlapping duties, who owns assets and processes, and which third parties must have their security responsibilities recorded. Settle these before writing role descriptions, because each one changes the list an assessor will sample.

Which roles fall inside the ISMS

Start with the roles that touch information within the defined scope of the ISMS, including executives, IT operations, developers, HR, legal and facilities staff who handle access or records. Decide whether roles outside the scope still need a documented link to it, such as a group function that supplies shared services. The boundary decision determines which role descriptions exist at all. Check that every role named in the scope statement has a matching description and a named holder.

Overlapping roles in small teams

In a small company one person may be the security lead, the system administrator and the policy owner. This is acceptable only if the organization records each duty separately and confirms that the holder can perform it. Where one person approves their own work, that conflict needs a compensating review, which links to the segregation of duties control. Write down which hats each person wears, and who covers each role during leave or departure.

Named owners for assets and processes

A.5.2 requires responsibilities to be allocated, so each significant information asset, system and security process needs a named owner rather than a team mailbox. The owner approves access, classification and changes, and answers for the control's effectiveness. Pair this with the asset inventory so that every entry shows its owner. Ask an assessor to sample ten assets and check that the owner named in the register agrees with the owner named in the role record.

Process owners across the ISMS

Incident handling, access reviews, backup testing, change approval and supplier review each need an accountable owner who can make decisions and direct staff. Confirm that each process owner has the authority to stop or alter work, not only to report on it. Record the owner in the procedure document itself so that the link between role and process is visible to an auditor reading the procedure, without having to find a separate chart.

Managed service providers with security duties

When a managed service provider runs firewalls, monitors logs or patches servers, it holds security responsibilities that must be recorded. List each provider duty against the internal role that receives its output, and name the internal owner who accepts the risk. Responsibilities that a contract assigns to the provider still need an internal owner who reviews performance. Ask the provider for its own role descriptions and named contacts, and confirm they match the agreement.

Cloud and hosting provider responsibilities

Cloud platforms and hosting companies usually split security duties between the provider and the customer, and the split is documented in their shared responsibility material. The organization must record which duties it keeps, such as identity configuration, data classification and key management, and assign an internal owner to each. Do not assume the provider's certificate covers the customer's own role allocation. Review the split at each significant change in the cloud estate.

How an assessor tests whether roles are defined and allocated

An assessor tests A.5.2 by checking whether the written role descriptions and ownership records match what actually happens in the organization. They start with the documents: the information security roles listed in the ISMS, the named owners for assets and processes, and the responsibilities written into policies. They then compare those documents against org charts, job descriptions, committee terms of reference, meeting minutes and risk register entries that show who made decisions. Interviews with the named people close the loop. The assessor asks each person what they are accountable for, what they have done in that role in the past review period, and who they escalate to. Gaps usually appear where a job description says nothing about security, where an owner was named in a spreadsheet but never briefed, or where a role has no successor when its holder leaves.

A role only counts as credible if the person named knows they hold it and has acted on it. An assessor will look for evidence of that action: a reviewed asset register with the owner's sign-off, an access review the owner completed, a risk treatment decision taken in a meeting, or an incident the owner escalated. A name in a table with no trail behind it is a finding waiting to be written. Ask each role holder to show one recent decision they made, and check that the record exists in the place the organization says it keeps records. Also confirm that deputies or backups are named for critical roles, because assessors often ask what happens when the owner is absent.

ISO/IEC 27002:2022 gives the implementation guidance for this control, and assessors use it as a reference point rather than a checklist. The assessor works from the organization's own needs and the scope of its ISMS, so there is no fixed list of roles that must exist. A small organization may combine several roles in one person, and that is acceptable if the combination is documented, the person is competent for it and no conflict with A.5.3 segregation of duties goes unaddressed. Before the audit, confirm with your certification body how it expects roles to be sampled for your scope, and prepare a short map from each role to the people, documents and records that support it.

What assessors request and where audits find gaps for A.5.2

This table lists the test steps an assessor typically runs for A.5.2, the evidence each step asks for, and the findings that come up most often. Read each row as a question the auditor will ask and the record that should answer it. The main takeaway is that a role is only evidenced when the document, the named person and the operating record all agree.

Test area	Evidence requested	Common findings
Role descriptions	Approved role descriptions for information security roles, showing duties, decision rights and reporting lines, with version and approval date	Roles described generically with no link to specific ISMS tasks, or descriptions that predate the current structure
Named owners for assets and processes	Owner assignments for key information assets and security processes, traceable to the asset inventory and process records	Owners named by job title only, with no individual identified, or owners who do not know they are accountable
Allocation records	Signed or recorded acceptance of each role by the person holding it, plus the approver who allocated it	Roles named but no one accepted them, so the allocation cannot be shown to have taken effect
Interviews with role holders	Assessor questions to named role holders on what they do, what they decide and how they escalate, compared with the written role	Role holders describe duties that differ from the documented role or are unaware they hold the role
Consistency with clause 5.3 and A.5.3	Mapping of ISMS authority from clause 5.3 to the detailed roles, and a check that conflicting duties are separated under A.5.3	Clause 5.3 assigns authority to a role that the A.5.2 descriptions never mention, or one person holds approval and review of the same activity
Change history of role assignments	Version history showing when roles were created, changed, reassigned or removed, with who made each change and why	Owner lists out of date after reorganizations, and departed staff still listed as current holders
Coverage after departures	Evidence that roles were reassigned when a holder left or changed position, with handover records	Departed staff still listed as owners, leaving approvals and reviews with no valid accountable person

How to define and allocate security roles step by step

This sequence turns the roles a business already relies on into a recorded, accepted allocation of information security responsibilities that an auditor can sample against the ISMS. Each step produces a artifact that the next one builds on.

Map functions that touch information security
Start by listing every business function, team and external party that makes decisions about, operates or relies on information security. Include IT operations, development, HR, finance, legal, facilities and key suppliers, and note where each one already performs a security task. Work from the organization chart and the process map rather than from job titles alone. The output is a function map or role inventory with one line per function, the security tasks it performs today, and gaps where no one is clearly responsible. The step is done when every task found in the map has a function attached.
Draft role descriptions tied to the ISMS
For each role in the inventory, write a short description covering its purpose within the information security management system, its decision rights, the controls and processes it operates, and the records it keeps. Link each description to the clause 5.3 assignment of ISMS authority so that the reporting line to top management is explicit. Ask the security lead and each function head to review the drafts for accuracy. The output is a role register in which every role has a description, a reporting line and a list of the Annex A controls it supports. The step is done when the register has no role without a stated purpose.
Assign named owners for assets and processes
Take the inventory of information and associated assets developed under A.5.9 and assign a named owner to each asset, and a named owner to each security process such as access reviews, backup testing or vendor reassessment. Owners should be individuals with the authority to decide, not a shared mailbox or a team name. Where an asset has no clear owner, escalate it to the role that holds ISMS authority for resolution. The output is an ownership register that pairs each asset or process with one accountable person and a deputy. The step is done when every asset in the inventory has an owner and every owner appears in the role register.
Record responsibilities in a RACI extract
Build a RACI extract for the activities that matter most to the ISMS, such as policy approval, risk treatment decisions, incident declaration and supplier onboarding. For each activity, mark who is responsible, accountable, consulted and informed, and check that every activity has exactly one accountable role. Where two roles claim the same decision, resolve the conflict with the role holder who has ISMS authority and note the decision. The output is a RACI extract linked to the role register. The step is done when each key activity has one accountable role and no gaps appear when the RACI is read against the asset ownership register.
Obtain acceptance from each role holder
Send each role holder their role description, the assets and processes they own and their RACI entries, and ask them to accept the responsibilities in writing. Acceptance should confirm that the person understands the duties, has the time and authority to perform them and knows whom to escalate to. Record the date and the version of the document they accepted. Chase missing acceptances through the line manager, and return unclear roles to step two rather than accepting them as written. The output is a set of signed or recorded acceptances, one per role holder. The step is done when every role in the register has an accepted version on file.
Record the allocation in controlled documentation
Publish the role register, ownership register and RACI extract in the organization's controlled document system, where each change is versioned and attributable. Give the documents a clear title, a version number, an approval record and a link from the information security policy so that auditors can follow the chain from policy to named owner. Restrict edit rights to the people who maintain the register, and keep read access broad enough that role holders can check their own entries. The output is a published, versioned allocation record. The step is done when an assessor could start from any control and reach the named owner in a few navigation steps.
Set a review trigger for reorganizations and leavers
Define the events that require the allocation to be reviewed, including reorganizations, new business units, mergers, new outsourced services, and the departure or prolonged absence of a role holder. Assign a named owner for watching each trigger, typically HR for leavers and movers and the security lead for structural change. Set a rule that a departing owner must be replaced and their acceptance recorded before the departure is closed. The output is a documented trigger list with responsible owners and a log of reviews performed. The step is done when each trigger has an owner and the first review cycle has been logged against the register.

Evidence that passes an A.5.2 review and how to keep it current

An auditor testing A.5.2 looks for a current, approved picture of who owns information security roles and whether that picture matches reality. The artifacts below connect to each other, so keeping them current depends on tying every change to the events that create it, mainly joiners, movers and leavers.

Role register

The role register lists every information security role, its holder, deputy, reporting line and the date it was last confirmed. It is the first document an assessor opens and the one most likely to drift. Check that every named holder still works in the role, that no role is held by someone who has left, and that each role maps to a clause 5.3 authority or a documented delegation. Review it at least at each management review and whenever a role changes hands.

Role descriptions

Each role description states the responsibilities, decisions the role may make, the information security duties it carries and the competence it needs. Auditors compare these with what people actually do, so a description that promises approval rights the holder never exercises will raise questions. Confirm each description was approved by the appointing authority and that it names the policies and procedures the role maintains. Record the version and approval date on the document itself.

Owner assignments per asset and process

Named owners for assets in the inventory and for information security processes, such as access reviews, vulnerability management or supplier reassessment, show who answers for each item. Sample a few assets from the inventory and confirm each owner still exists in the directory and still works in the function. Owners who leave or change teams are the most common gap at surveillance audits, so tie owner reassignment to the leaver and mover steps in your HR and access workflows.

Signed or recorded acceptances

Holders should accept their roles in a way that can be shown later: a signed acknowledgement, an accepted ticket or a recorded approval in the wiki. The acceptance should reference the role description version it covers. Ask your auditor which form they accept, since the evidence standard is set by the certification body and the organization's own procedure. Re-acceptance is worth requesting whenever a role description changes materially.

Org chart reference

The organization chart does not need to be a detailed diagram, but it must show the reporting lines that support the roles in the register and the authority given to the ISMS. Store the chart with a date and a version, and refer to it from the register instead of copying names into two places. When reorganizations happen, update the chart and the register in the same change so the two cannot disagree at audit time.

Change log of assignments

The change log records each appointment, reassignment, delegation and removal with the date, the approver and the reason. Auditors use it to confirm that roles were allocated deliberately and that gaps were closed quickly, such as when an owner left. Keep the log under version control or in a system that stamps who changed what and when, so entries cannot be altered quietly. Review recent entries against HR movement records each quarter.

What defining security roles costs in money and effort

The table lists each cost component of defining and allocating information security roles, who carries it, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal effort and to frame questions for any partner quote, since no fixed figures are supplied for this control. The main takeaway is that open-source tooling removes license spend but leaves the people time that makes roles credible.

Cost component	One-time or recurring	Who carries it	What drives it
Drafting role descriptions and agreeing responsibilities	One-time, then revised on change	Security lead, HR, legal and process owners	Number of functions, existing job descriptions, how many roles overlap
Managers accepting ownership of assets and processes	One-time, then recurring at each review	Department heads and executives	Number of named asset and process owners and how much time each owner has
Recording roles in a wiki or document system	Setup once, recurring upkeep	Document owner or platform team	Tool choice, access model, and how often records are edited
Hosting and license for a self-hosted wiki or document tool	Recurring	Organization's own infrastructure or cloud team	Open-source licenses carry no license fee, but hosting, backups and patching still apply
Periodic review of roles after reorganizations	Recurring	Security lead and HR	Reorganization frequency, staff turnover, and mergers or new products
Keeping ownership records aligned with the asset inventory	Recurring	Asset owners and IT operations	Number of assets, how often they change, and whether inventory is automated
Auditor sampling of roles and ownership records	Recurring at each audit cycle	Internal evidence owner, plus the independent auditor	Number of samples the auditor selects and how quickly records can be produced
Outside help to draft or review roles	One-time or periodic, by written scope	Organization pays the partner or consultant	Scope agreed in writing, number of teams covered, and whether the organization keeps the work in house

Where a self-hosted wiki keeps role records under version control

A.5.2 expects the organization to define roles and responsibilities and allocate them, but an auditor will also ask where those definitions live, who last changed them and whether an earlier version can be shown. A self-hosted wiki can hold the role descriptions, the named owner register for assets and processes, and the RACI-style allocation of ISMS duties in one place under change control. XWiki is one candidate: every change to a page is kept under version control, recording what changed, when and by whom, and users can compare any two versions and roll back to an earlier one. For a role register, that means an assessor can see that the owner of the asset inventory was a different person in the previous quarter and that the change was made on a known date. Confirm with the vendor and your own environment which XWiki edition, license terms (XWiki is LGPL-2.1-or-later) and extensions you need before you commit to it.

BookStack takes a different approach to the same problem. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. That lets you restrict who can edit the role descriptions for security functions while leaving the rest of the handbook open to the wider team, and it keeps the authority to change a role record with the people who hold that authority. Note that BookStack's permission model governs who may edit and view content; it does not replace the approval step that clause 5.3 and A.5.1 expect, so the approver of each change still needs to be recorded in the document itself or in your change process. Check whether your chosen wiki exposes page history and restore actions to the auditor's sampling method before you rely on it as evidence.

Whichever tool you choose, decide three things before the first audit: which page is the single authoritative register of owners, who is permitted to change each role description, and how a change is linked to the approval that authorized it. Ask your implementation partner to set up the permission structure and a sample change so that you can show the history, the comparison and a restore to an assessor. Keep a record of the access settings themselves, since an auditor who finds that the owner of the register can also edit it unchecked will treat the register as weaker evidence.

Who owns A.5.2 in-house, who can help and where the auditor stops

Your organization owns A.5.2. The control asks you to define and allocate information security roles and responsibilities according to your needs, and only your leadership can decide who holds which duty, how much authority each role carries and whether the allocation fits how the business actually runs. The people named in the roles must accept them, because an assignment that nobody has agreed to will not survive an audit interview. Your organization also remains accountable for every named owner after the project ends.

Decisions on role design: Leadership chooses which roles exist, such as an ISMS lead, asset owners and process owners, and where each one sits in the reporting line.
Acceptance of roles: Each named individual confirms in writing that they understand and accept the responsibilities assigned to them.
Ownership of assets and processes: Business owners decide who is accountable for each asset and process, and they keep that record current when people move.
Link to clause 5.3: Your management assigns ISMS authority and reporting to the ISMS, which the A.5.2 allocation must match.
Ongoing upkeep: Your staff update the register when roles change, and they review it at planned intervals.

Before engaging anyone, confirm that you can name the person accountable for each role and that they have the time and authority to act on it.

Common gaps in security role definitions and how to close them

Roles under A.5.2 often fail in practice rather than on paper: the names are right, but nobody has accepted them, kept them current, or checked how they overlap. The cards below cover five gaps that recur in readiness reviews, each with a closing action the organization can complete and show as evidence.

Roles that exist only in policy

A policy names a Chief Information Security Officer, a risk owner or an incident coordinator, but no one has been appointed to the post and no one knows the role applies to them. Auditors test this by asking the named person to describe the role and by checking whether the duties are being performed. Close it by issuing a role description for each named role, obtaining the appointee's signed acceptance and recording the appointment in the ISMS record.

Owners named but not accepted

Asset owners and process owners are listed in an inventory without knowing they are accountable for it. When an incident or audit sample reaches them, they do not know what they are expected to approve, review or maintain. Close it by sending each owner a short written list of their responsibilities, asking them to confirm it, and keeping the confirmations with the inventory so that acceptance can be sampled.

Role lists not updated after reorganization

Mergers, team splits and leaver events leave the role register pointing at departed staff or at teams that no longer exist. The gap shows up when a reviewer finds an approval routed to someone who left months earlier. Close it by tying the role register to the reorganization and leaver processes, so that every structural change triggers a documented review of affected roles and their named holders.

Overlapping responsibilities without conflict checks

One person may hold the access approver, change approver and security monitoring duties for the same system. Because the overlap is never recorded, nobody checks whether a single person can request, approve and verify the same change. Close it by mapping each role's duties against the others and flagging combinations that need separation, then linking the flags to the segregation of duties control (A.5.3) and documenting any compensating measures.

Third-party responsibilities left unrecorded

Managed service providers, cloud operators and outsourced developers often run controls the organization assumes are covered, yet the role register lists only internal staff. When an incident occurs, it is unclear who the provider contacts and who makes the decision. Close it by recording each external party's security responsibilities and the internal role that oversees them, and by checking that the contract and supplier records match the register.

How much work A.5.2 takes and what buyers ask before hiring help

How long does defining information security roles take for a small team?

No researched figure exists for this, so the honest answer depends on how many people, systems and business units the organization has. For a small team, the work is mostly writing a short role description for each security function, naming an owner for each important asset and process, and agreeing who approves exceptions. Much of that can be done in a few working sessions with leadership. The effort grows with the number of systems and suppliers that need named owners. Ask any partner to break the estimate into discovery, drafting, review and recording, and to state which of those steps your own staff will perform.

Can one person hold several information security roles?

Often yes in a small organization, but the standard asks you to define roles according to your needs, and it does not forbid combining them. The risk is conflict. A person who approves a change should not also be the only person who checks it, and the same applies to granting and reviewing access. Where roles must be combined, record the combination, the reason and the compensating checks in the role descriptions. A.5.3 covers how to separate conflicting duties, so review that control before you combine roles that touch access or change approval.

What does the work need from management?

Management must make the decisions that roles depend on: who has authority to approve the ISMS, who can accept risk, and how much budget and time each owner can give. Clause 5.3 requires top management to assign responsibilities and authorities for the ISMS and to communicate them. In practice, leadership should sign off the role list and confirm that named people accept their responsibilities. Without that sign-off, owners are named on paper but have no authority to act, which assessors tend to notice quickly.

Can the organization define its roles without outside help?

Yes, for many organizations this is feasible internally, provided someone understands the standard and has authority to pull leaders together. The work is documentation and decision-making rather than technology. Outside help is most useful when no one has the time or independence to draft the roles, or when leaders disagree about ownership. Whatever you choose, the organization owns the decisions. A partner can prepare drafts and records, but it cannot assign responsibilities on your behalf or stand in for your management.

How does A.5.2 relate to A.5.3 and clause 5.3?

Clause 5.3 requires top management to assign responsibilities and authorities for the ISMS, so it sets the top-level assignment. A.5.2 asks you to define and allocate information security roles and responsibilities according to your needs, which goes further down into named functions and owners. A.5.3 then asks you to separate conflicting duties so that no single person can misuse or bypass a control alone. Treat them as a sequence: clause 5.3 assigns ISMS authority, A.5.2 describes and allocates the detailed roles, and A.5.3 checks that those roles do not conflict. ISO/IEC 27002:2022 gives implementation guidance on A.5.2 if your team needs more detail.

What does bringing in a partner change in cost?

A partner changes who does the drafting and coordination work, not who owns the decisions. Costs usually come from the partner's time to run discovery workshops, draft role descriptions and asset owner records, and prepare evidence for the auditor. Those costs are typically one-time, while your internal time for reviews and owner duties recurs. Ask for a fixed-scope quote that lists the deliverables, the number of workshops, the systems in scope and what your staff must provide. Also confirm whether the partner will maintain the records afterward or hand them over.

Does a partner's work mean the roles will pass certification?

No. Only an independent certification body can decide whether your ISMS meets the standard, and DeployOpen prepares systems and evidence without issuing audit reports or certificates. A good role record shows assessors who is accountable and how that is communicated, but it does not guarantee a result. Before hiring anyone, ask how they will prepare the records and how they will keep the organization in charge of the decisions the auditor will test.

How DeployOpen prepares role records and evidence for an A.5.2 assessment

DeployOpen's work on A.5.2 starts with a written scope, not with a role chart. Before any work begins, the engagement defines which roles, asset owners and process owners are in scope, which systems will hold the register, and what the organization expects to show an assessor. The organization still decides who holds each role. DeployOpen then prepares the place where those decisions live: a self-hosted wiki or register on infrastructure the organization controls, with a structure for role descriptions, named owners for assets and processes, and the links to the clause 5.3 assignment of ISMS authority. Ask for the deliverables list, the hosting location and the handover format in the quote before agreeing scope.

The evidence structure matters as much as the content. A role record is only useful to an assessor if it shows who approved it, when it changed and what it replaced. Wiki platforms such as XWiki keep page version history that records what changed, when and by whom, and allow comparison and rollback, which is the kind of trail a sampling assessor will ask for. Access to edit those pages should follow the role model of the tool, for example the role-based permissions in BookStack, so that owners can maintain their own entries without being able to alter the records of others. Confirm with your own platform team which version history and permission features your chosen tool supports before the build starts.

DeployOpen also supports the organization through a readiness review before any external assessment. The review checks that each role has a description, an accountable owner and an alignment with segregation of duties under A.5.3, and that the people named have accepted their responsibilities in a way the organization can evidence. Findings go back to the organization, which decides what to change. An independent auditor or certification body decides whether the control is met and issues any report or certificate. DeployOpen does not issue audit reports, attestations or certifications.

A.5.2 Information security roles and responsibilities