ISO 27001 A.5.2: Assign Security Decisions to the Right People
Security work stalls when everyone knows the task exists but nobody can authorise the next step. ISO 27001 control A.5.2 addresses the definition and allocation of information security responsibilities according to the organisation’s needs. An organisation chart can contribute, but the important outcome is that relevant decisions and activities have understood owners with suitable authority.
What A.5.2 requires in practice
Annex A control A.5.2 asks the organisation to define and allocate information security roles and responsibilities according to its own needs. Two verbs matter. Defining means describing what each role is expected to decide, do or escalate. Allocating means placing those responsibilities with identifiable people or functions, so that nothing important is left unowned.
The words according to the organisation’s needs leave room for judgement. A small company may place several responsibilities with a few managers, while a larger group may spread them across central and local teams. What matters is that the arrangement fits the way the business runs and covers the activities that protect information, from approving access to deciding on risk and handling incidents.
The control does not prescribe job titles, a particular matrix or a minimum number of security staff. The result an assessor tests is simple: for a given security activity, can the organisation show who is responsible and that the person knows it?
Start with decisions that cannot be left ownerless
Take a real information flow or service and ask who can decide how it is protected. The person maintaining a platform may not have authority to accept a business risk or approve access to customer information. Distinguish the owner of the information or service from the person administering its technology.
Define responsibilities in terms people can recognise: the decision they can make, the work they must coordinate and the issue they must escalate. Avoid assigning “all security” to one specialist while purchasing, staffing and service changes remain controlled elsewhere. Security specialists can advise and coordinate; process owners still need to make the decisions within their authority.
Make delegation visible without losing accountability
Delegation can be useful when a specialist has the skills to perform a task. It should preserve an owner who understands what was delegated and how satisfactory completion will be established. A provider carrying out an access review, for example, may prepare evidence while an internal information owner decides whether access remains justified.
A responsibility matrix is one possible tool. Test it before extending it across the business: can two people read a row and reach the same conclusion about who approves the decision? Multiple accountable names without a decision rule often reproduce the ambiguity the matrix was meant to remove. Link defined authority to access rights where systems enforce approval or administration permissions.
Check capability, capacity and cover
An assigned person needs sufficient knowledge, time and access to relevant information. A manager cannot meaningfully accept a security risk if its consequences and uncertainties have not been explained. Identify the support required and whether a deputy needs separate preparation rather than simply inheriting a title during an absence.
For groups, central ownership can set a consistent method while local managers identify operating differences. Clarify which decisions require group approval and which remain local. Include handovers between time zones and contract boundaries. The objective is a working chain of responsibility, not central approval of every routine action.
Why defined responsibilities matter to the business
Security stalls when everyone agrees a task matters but nobody has authority to approve the next step. Clear ownership shortens decisions, avoids duplicated or missed work and means incidents are met by people who already know their part. It also stops the common pattern of assuming that one specialist is accountable for everything.
Customers and assessors ask who accepts a risk or approves access to sensitive information, and unclear answers undermine confidence quickly. In groups that operate across several countries or rely on providers, defined responsibilities also make the boundaries between central, local and external teams visible. That reduces disputes and delays when something needs urgent action.
How to implement A.5.2
Begin with real decisions rather than an organisation chart, and describe responsibilities in terms people can recognise. Clear ownership usually improves faster when the first changes are small and visible to the people affected.
- Pick several actual flows, such as onboarding a customer or granting privileged access, and ask who may decide at each step.
- Separate the owner of information or a service from the person who administers its technology.
- Write each responsibility as the decision someone can make, the work they coordinate and the matter they must escalate.
- Check that each person has the knowledge, time and information to carry the responsibility, and arrange trained cover for absences.
- Where work is delegated to a specialist or provider, keep an internal owner who understands what was delegated and how completion is judged.
- Make sure systems that enforce approval or administration rights reflect the authority you defined.
- Review responsibilities when services, structure or suppliers change, and test that two readers reach the same conclusion about who decides.
Illustrative managed IT example: a customer access exception
A hypothetical managed IT business receives a request to keep a former project member’s customer access open temporarily. Its service desk can technically make the change, but the contract manager owns the customer relationship and the information owner must assess the justification.
The business defines who obtains the customer’s decision, who evaluates internal risk and who implements the agreed action. It also identifies cover outside normal hours. A later sample shows that service desk staff route the decision correctly rather than interpreting technical capability as approval authority.
Evidence that responsibility works
The selected control calls for defined and allocated responsibilities; it does not prescribe a particular RACI chart or job title. Useful evidence can include role descriptions, delegated authority, service agreements, communicated assignments and actual decisions. Keep relevant information controlled through the ISMS rather than creating a disconnected security chart.
Test a recent exception, incident or change. Ask the initiator, decision-maker and implementer independently who had authority. Compare their answers with the records. Common weaknesses include a departed owner still named in procedures, a deputy unable to access essential information and a provider assuming that the customer approved an action because nobody objected. Address the specific gap before adding more job descriptions.
Resolve the ownership gaps behind recurring delays
Discuss your security responsibilities with Sterling. A scoped engagement can connect governance, provider interfaces, documentation and Effivity ISO & GRC automation software with learning for role holders. ISO/IEC 27001 Awareness gives managers the ISMS foundation for those decisions. Wider authorised scanning and findings review can be included as agreed; continuing certification preparation supports the programme while an independent body decides the outcome. Return to organisational controls.
Frequently asked questions
Must a small company appoint a full-time security manager?
A.5.2 does not prescribe that job arrangement. Duties can sit within existing roles when competence, capacity and authority are adequate. Identify conflicting responsibilities and arrange appropriate separation or checks.
Can a supplier own an internal business risk?
A supplier may manage tasks or risks within its own service, but the organisation needs appropriate internal ownership of its exposure and decisions. Contract wording and the actual relationship should make the distinction clear.
How can we tell whether a responsibility matrix is useful?
Use it to follow a real decision with a contested or unusual outcome. If the participants still cannot identify the authorised decision-maker and escalation route, revise the allocation rather than adding more abbreviations.
Illustrative BPO example: closing a client operation
A hypothetical BPO provider closes one client campaign while employees transfer to another. Human resources handles employment changes, operations controls work allocation and IT controls accounts. Nobody initially owns the reconciliation of the old client’s information, shared folders and outstanding provider access.
Management appoints an operational owner to coordinate closure, with specific evidence from each function and an escalation route for missing items. The resulting handover is checked against actual services and data. This complements responsibilities after employment changes without confusing staff transfer with the complete closure of a client service.