ISO 27001 Annex A 5.2 – Information Security Roles and Responsibilities focuses on making sure that information security responsibilities are clearly defined, assigned, communicated and understood within the organization.
Information security cannot be the responsibility of the IT or security team alone.
Management, employees, contractors, system owners, HR, developers, administrators, suppliers and other relevant stakeholders may have security responsibilities depending on the organization’s size, structure and risks.
The objective of A.5.2 is to establish clear accountability so that people know:
- Who is responsible?
- Who approves?
- Who performs the activity?
- Who reviews it?
- Who needs to be informed?
What Does ISO 27001 Annex A 5.2 Require?
Annex A 5.2 requires information security roles and responsibilities to be defined and allocated according to the organization’s needs.
In practical terms, an organization should be able to demonstrate that:
- Information security responsibilities have been identified.
- Responsibilities have been assigned to appropriate roles.
- Relevant personnel understand their responsibilities.
- Management responsibilities are clearly established.
- Responsibilities are communicated.
- Responsibilities are maintained when the organization or its systems change.
The exact job titles do not need to be the same for every organization.
A large organization may have a CISO, while a 30-person startup may assign information security responsibilities to an ISMS Manager, CTO, Security Lead or another competent person.
Why Is A.5.2 Important?
Without clearly assigned responsibilities, security activities can fall between departments.
For example:
The company requires quarterly user access reviews.
But who performs the review?
- IT?
- HR?
- Application owner?
- CISO?
- Department manager?
If nobody has been assigned responsibility, the control may not operate effectively.
A.5.2 helps establish clear accountability.
What Information Security Roles Should an Organization Define?
The roles depend on the organization’s size and structure.
A typical organization may define:
| Role | Typical Information Security Responsibility |
|---|---|
| Board / Top Management | Overall direction and accountability |
| CEO / Executive Management | Management support and resource allocation |
| CISO / Security Manager | Information security program |
| ISMS Manager | ISMS implementation and maintenance |
| IT Manager | IT infrastructure security |
| System Owner | Security of specific systems |
| Data Owner | Classification and protection requirements |
| HR | Joiner, mover and leaver processes |
| Legal / Compliance | Legal and regulatory requirements |
| Procurement | Supplier security requirements |
| Developers | Secure development practices |
| Employees | Following security policies |
| Internal Auditor | Independent assessment |
| Incident Response Team | Security incident response |
A small organization may combine several of these responsibilities into one or two people.
Management Responsibilities
Top management plays an important role in A.5.2.
Management should ensure that appropriate authority and responsibility exist for information security.
Typical management responsibilities include:
- Establishing information security direction
- Approving security policies
- Providing appropriate resources
- Supporting the ISMS
- Assigning responsible personnel
- Reviewing information security performance
- Ensuring security requirements are integrated into business processes
Example
For a startup:
CEO
↓
Provides management commitment
CTO / ISMS Manager
↓
Owns information security implementation
Engineering / IT
↓
Implements technical controls
Employees
↓
Follow security requirements
This creates a simple accountability structure.
What Activities Are Required to Implement A.5.2?
Activity 1: Identify Required Security Responsibilities
Start by identifying all important information security activities.
For example:
- Risk assessment
- Risk treatment
- Access management
- Security monitoring
- Incident management
- Vulnerability management
- Backup
- Business continuity
- Supplier security
- Asset management
- Security awareness
- Policy management
- Internal audit
- Compliance monitoring
- Security testing
Then determine who is responsible for each activity.
Activity 2: Define Information Security Roles
Create a formal list of information security roles.
For example:
ISMS Manager
Responsible for:
- Maintaining the ISMS
- Coordinating risk assessments
- Maintaining the Statement of Applicability
- Coordinating internal audits
- Monitoring corrective actions
- Coordinating management reviews
IT Manager
Responsible for:
- Infrastructure security
- User administration
- Backup
- Patch management
- System configuration
HR
Responsible for:
- Employee onboarding
- Security awareness coordination
- Employee termination notifications
- Maintaining personnel records
System Owner
Responsible for:
- System-specific risks
- Access approvals
- System security requirements
- Periodic access reviews
Activity 3: Assign Responsibilities Using a RACI Matrix
A RACI matrix can make responsibilities much clearer.
RACI means:
- R – Responsible: Performs the activity
- A – Accountable: Ultimately accountable for the outcome
- C – Consulted: Provides input
- I – Informed: Needs to know about the activity
Example
| Activity | CEO | ISMS Manager | IT | HR | System Owner |
|---|---|---|---|---|---|
| Approve security policy | A | R | C | I | I |
| Risk assessment | I | A/R | C | C | C |
| User access management | I | A | R | C | C |
| Employee onboarding | I | C | C | A/R | I |
| Security incident | I | A | R | C | C |
| Security awareness | A | R | C | R | I |
| Internal audit | I | C | C | C | I |
| Access review | I | A | R | I | R |
The exact assignments should reflect the organization’s actual structure.
Activity 4: Document the Responsibilities
Responsibilities can be documented through:
- Information Security Policy
- ISMS Manual
- Roles and Responsibilities document
- Job descriptions
- RACI matrix
- Committee terms of reference
- Process documents
- Procedures
- Organization charts
The important point is consistency.
If the RACI says one person is responsible but the job description assigns the responsibility to someone else, the organization should resolve the inconsistency.
Activity 5: Communicate Responsibilities
Defining a role is not enough.
Relevant personnel should understand what they are responsible for.
Communication may happen through:
- Employee onboarding
- Job descriptions
- Security awareness training
- Role-specific training
- Team meetings
- ISMS meetings
- Emails
- Policy acknowledgment
- Security committee meetings
Activity 6: Ensure Competence
People assigned security responsibilities should have appropriate competence for the role.
For example:
A person responsible for:
- Vulnerability management
- Security incident response
- Risk assessment
- Internal auditing
- Cloud security
may require appropriate knowledge, experience or training.
Evidence can include:
- Certifications
- Training records
- Experience
- Job descriptions
- Competency assessments
- Training completion records
Activity 7: Review Responsibilities When Things Change
Roles should not remain static when the organization changes.
Review responsibilities when:
- A new employee joins
- Someone leaves
- A manager changes
- A new department is created
- A new application is introduced
- A company acquires another company
- The ISMS scope changes
- Outsourcing occurs
- A new regulation applies
- A major security incident occurs
For example, if the person responsible for incident management leaves the company, the organization should assign the responsibility to another competent person.
What Events Should Trigger an A.5.2 Review?
A.5.2 should be considered during significant organizational changes.
| Event | Required Action |
|---|---|
| New employee in security role | Assign and communicate responsibilities |
| Employee leaves | Reassign responsibilities |
| Promotion / role change | Review responsibilities |
| New application | Assign system owner |
| New cloud environment | Assign cloud/security responsibilities |
| New regulation | Review compliance responsibilities |
| Outsourcing | Define supplier responsibilities |
| New business unit | Review security ownership |
| Security incident | Review accountability and escalation |
| ISMS scope change | Review roles and responsibilities |
| Organizational restructuring | Update RACI and job descriptions |
Example: A.5.2 for a SaaS Startup
Consider ABC SaaS Pvt. Ltd.
The company has:
- 40 employees
- 1 CTO
- 1 IT administrator
- 2 security professionals
- 20 developers
- HR
- Finance
- Customer Support
The company does not have a dedicated CISO.
It does not need to create a CISO position simply to satisfy A.5.2.
Instead, it assigns responsibilities based on its actual structure.
Responsibility structure
CEO
- Overall management accountability
- Approves information security policy
CTO
- Overall technology security responsibility
- System and infrastructure security
ISMS Manager
- Maintains ISMS
- Coordinates risk assessment
- Coordinates audits
- Maintains compliance documentation
IT Administrator
- User accounts
- Endpoint management
- Backup
- System administration
Engineering Lead
- Secure development
- Code security
- Vulnerability remediation
HR
- Employee onboarding/offboarding
- Security awareness coordination
Employees
- Follow security policies
- Protect company information
- Report security incidents
This is a perfectly reasonable model for a small organization if responsibilities are clearly assigned and effectively implemented.
Example: Access Management Responsibility
Consider a simple joiner process.
Step 1
HR informs IT that a new employee is joining.
Step 2
The employee’s manager identifies required applications.
Step 3
The system owner approves application access.
Step 4
IT creates the account.
Step 5
The employee receives security requirements.
Step 6
Periodic access review is performed.
Now there is a clear chain:
HR → Manager → System Owner → IT → Employee
Each participant has a defined responsibility.
Evidence an ISO 27001 Auditor May Request
An auditor may look for evidence that responsibilities are actually defined and implemented.
Governance documents
- Organization chart
- Information Security Policy
- ISMS Manual
- Roles and Responsibilities document
- RACI matrix
Individual responsibility evidence
- Job descriptions
- Employment responsibilities
- Role assignments
- System ownership records
Communication evidence
- Training records
- Security awareness records
- Meeting minutes
- Policy acknowledgment
- Onboarding records
Competence evidence
- Training certificates
- Security certifications
- Experience records
- Competency assessments
Operational evidence
- Access approval records
- Incident response assignments
- Risk assessment records
- Internal audit assignments
- Security committee records
Common A.5.2 Mistakes
1. “IT is responsible for security”
This is usually too vague.
Information security responsibilities extend beyond IT.
HR, management, employees, procurement, legal and business owners may all have relevant responsibilities.
2. Creating roles that don’t exist
Do not create a fictional organizational structure simply to satisfy ISO 27001.
If your organization has 20 employees, you may not need:
- CISO
- Deputy CISO
- Security Director
- Security Committee
- Data Protection Officer
unless those roles are actually required.
Assign responsibilities to existing competent personnel where appropriate.
3. No system owners
Organizations sometimes identify applications but do not identify who owns them.
For important systems, establish ownership.
4. RACI does not match reality
A RACI matrix is useful only if people actually perform the responsibilities assigned to them.
5. Responsibilities are documented but not communicated
People should know what they are expected to do.
6. No replacement for critical roles
If one person is responsible for a critical security activity, consider what happens when that person is unavailable.
7. Responsibilities are not updated after organizational changes
A responsibility matrix should evolve with the organization.
ISO 27001 A.5.2 Audit Checklist
| Question | Yes/No |
|---|---|
| Are information security responsibilities defined? | ☐ |
| Are responsibilities assigned to appropriate personnel? | ☐ |
| Is management accountability defined? | ☐ |
| Are system and information owners identified where appropriate? | ☐ |
| Are security responsibilities included in relevant job descriptions? | ☐ |
| Is a RACI matrix available where useful? | ☐ |
| Are responsibilities communicated? | ☐ |
| Do responsible personnel have appropriate competence? | ☐ |
| Are responsibilities assigned for incident management? | ☐ |
| Are responsibilities assigned for risk management? | ☐ |
| Are access management responsibilities defined? | ☐ |
| Are supplier security responsibilities defined? | ☐ |
| Are internal audit responsibilities independent where required? | ☐ |
| Are responsibilities reviewed after organizational changes? | ☐ |
| Is evidence available to demonstrate implementation? | ☐ |
Practical Implementation Model
A simple A.5.2 implementation can follow this lifecycle:
Identify Security Activities
↓
Identify Required Roles
↓
Assign Responsibility
↓
Define Accountability
↓
Document RACI / Job Responsibilities
↓
Communicate Responsibilities
↓
Ensure Competence
↓
Perform the Activities
↓
Review Responsibilities
↓
Update When the Organization Changes
Policy vs Responsibility vs Evidence
A useful way to understand A.5.2 is:
Policy
What does the organization require?
Example:
Information security responsibilities shall be defined and assigned to appropriate personnel.
Responsibility
Who does what?
Example:
The IT Administrator is responsible for provisioning and disabling user accounts.
Evidence
Show that it is actually happening.
Example:
- Approved access request
- User account creation record
- Termination ticket
- Access review record
Therefore:
Policy = Requirement
Role = Ownership
Evidence = Demonstration
What Does Good A.5.2 Implementation Look Like?
A well-implemented organization should be able to answer:
Who owns information security?
There should be a clearly identified accountable person or management function.
Who manages the ISMS?
The organization should identify the person responsible for coordinating the ISMS.
Who owns critical systems?
Important applications and information assets should have appropriate ownership.
Who manages access?
Access responsibilities should be clearly assigned.
Who responds to security incidents?
There should be a defined incident response responsibility and escalation path.
Who performs internal audits?
Audit responsibilities should be appropriately assigned, considering the need for objectivity and independence.
What happens if a responsible person leaves?
Responsibilities should be reassigned.
Useful Resources & Draft Documents
To help organizations implement ISO 27001 Annex A 5.2, we have prepared practical resources and draft documents.
📄 Draft Roles & Responsibilities Document
Please find the draft document here:
[Insert Draft Roles & Responsibilities Document Link]
You can customize this document based on your organization’s:
- Organizational structure
- ISMS scope
- Number of employees
- Technology environment
- Security responsibilities
- Regulatory requirements
- Business processes
📋 Useful Resources
You may also find these resources helpful:
- ISO 27001 Information Security Policy
- ISO 27001 Roles & Responsibilities Template
- ISO 27001 RACI Matrix
- ISO 27001 Statement of Applicability (SoA) Guide – Understand how applicable controls are documented and justified.
- How to Prepare an ISO 27001 Statement of Applicability – Example
- ISO 27001 Risk Assessment Guide
- ISO 27001 Internal Audit Checklist
- ISO 27001 Implementation Guide for Startups
Important: Templates should be treated as implementation aids, not as a substitute for understanding your organization’s actual risks, responsibilities and ISMS requirements.
Final Takeaway
ISO 27001 Annex A 5.2 is about accountability.
An organization should know:
Who is responsible for information security, what they are responsible for, what authority they have, and how those responsibilities are communicated and maintained.
You do not need a large security department to implement A.5.2.
A startup with 20 or 30 employees can implement the control effectively by assigning security responsibilities to existing competent personnel.
The important thing is not the number of security roles.
The important thing is clear ownership, accountability and evidence.
In short:
A.5.2 = Define it. Assign it. Communicate it. Perform it. Review it.