Information security roles and responsibilities
Roles and responsibilities for information security are to be set out and assigned to people in a way that fits what the organization needs.
What the requirement asks
Roles and responsibilities for information security are to be set out and assigned to people in a way that fits what the organization needs. Purpose: create an agreed, approved structure, understood by everyone, for putting information security in place, running it and managing it. Guidance: assignments follow the information security policy and the topic-specific policies, and cover who protects information and associated assets, who carries out particular security processes, who performs risk management and especially who accepts residual risk (such as risk owners), and the duties of everyone who uses the organization's information and assets. Site-level or facility-level detail is added where needed. A person holding a security responsibility may hand tasks to someone else but stays accountable and should confirm the delegated work was done properly. Each area of responsibility is defined, written down and communicated, and authorization levels are documented. People in security roles need the knowledge and skills the role demands and should get support to stay current. Other information notes that many organizations name an information security manager with overall responsibility, that resourcing and implementation often stay with line managers, that asset owners commonly carry day-to-day protection, and that in smaller organizations security may be part of existing jobs rather than a dedicated post. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.
What the guidance adds
Roles are only real when the authority is written down. The guidance asks for the security responsibilities of every role that touches the system, including the business owners, and for a record that the person knows what they own.
Status of the guidance. The guidance lens for 5.2 reads the draft, which is at stage 40.00 and is not published, against the published ISO/IEC 27001:2022 requirement above. It is our reading, not a quotation, and it is not a requirement.
What good looks like
Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep A documented roles and responsibilities matrix covering asset protection, specific security processes, risk management and residual risk acceptance, and user duties and one live sample together.
Evidence an assessor asks for
- Security organizationA documented roles and responsibilities matrix covering asset protection, specific security processes, risk management and residual risk acceptance, and user duties
- Security organizationNamed risk owners with evidence that they accepted residual risks
- Security organizationDocumented authorization levels for each security role
- Security organizationRecords showing delegated security tasks and the accountable person's confirmation that they were completed correctly
- Security organizationCompetence requirements for security roles with training or certification records and ongoing development
- Security organizationSite-specific or facility-specific responsibility supplements where the organization operates several locations
The question an assessor will ask
An assessor will ask for A documented roles and responsibilities matrix covering asset protection, specific security processes, risk management and residual risk acceptance, and user duties, then trace it to the system it protects. For A.5.2 the test is whether that record ties to a live sample, not whether the control is named in a policy.
Common gaps
- Residual risk is accepted by the security team rather than by the business risk owner
- Responsibilities are defined in a policy but not communicated to the people who hold them
- Delegation happens without any check that the delegated task was performed
- People in security roles have no defined competence requirement or development plan
Before the next audit
Before the next audit, check one live sample for this gap: residual risk is accepted by the security team rather than by the business risk owner.