What is ISO 27001 Annex A 5.15 – Access Control?
ISO 27001 Annex A 5.15 – Access Control establishes the principles and rules for controlling access to information and other associated assets.
In simple terms:
People should have access to the information and systems they need to perform their job — and nothing more than necessary.
Access control is one of the most important foundations of information security.
An organization should determine:
- Who can access information?
- What can they access?
- Why do they need access?
- How is access approved?
- How is access granted?
- How is access reviewed?
- When should access be removed or changed?
Access control applies to:
- Applications
- Databases
- Cloud platforms
- Servers
- Laptops
- Networks
- Source-code repositories
- Customer systems
- Business applications
- Documents
- Physical areas
- Administrative interfaces
- Security tools
- Production environments
Simple Explanation
A.5.15 ensures that access to company information and systems is controlled according to business and security requirements.
Why is A.5.15 Important?
Unauthorized access is one of the most common ways organizations experience security incidents.
Consider a SaaS company where:
- A former employee still has access to GitHub.
- A developer has production access without needing it.
- All employees can access customer records.
- A shared administrator account is used by several people.
- An external contractor still has access after the project ends.
These situations increase the risk of:
- Data leakage
- Unauthorized modification
- Data theft
- Fraud
- Account compromise
- Insider threats
- Security incidents
- Compliance violations
Simple Principle
Give people the access they need, restrict access they do not need, and remove access when the need ends.
What Does A.5.15 Require?
The organization should establish rules for access control based on:
- Business requirements
- Information security requirements
- Risk
- Information classification
- Legal requirements
- Regulatory requirements
- Contractual obligations
Access should be managed throughout its lifecycle.
This includes:
Request → Approve → Grant → Use → Review → Modify → Revoke
A.5.15 is a policy and principle-level control.
Other controls provide more specific mechanisms for implementing it.
For example:
- A.5.16 – Identity Management
- A.5.17 – Authentication Information
- A.5.18 – Access Rights
- A.8.2 – Privileged Access Rights
- A.8.3 – Information Access Restriction
Core Principles of Access Control
1. Least Privilege
Users should receive only the access necessary for their responsibilities.
For example:
A marketing employee may need access to:
- Marketing tools
- Website CMS
- Analytics
They generally do not need:
- Production database access
- Root server access
- Security administration
- Payroll systems
2. Need-to-Know
Access should be based on legitimate business need.
For example:
The Finance team may need access to financial records.
The Engineering team may not need access to employee salary information.
3. Need-to-Use
Access should be provided when required for the user’s role or responsibilities.
A user should not automatically receive access simply because they are an employee.
4. Role-Based Access
Access can be assigned based on job responsibilities.
Example:
| Role | Typical Access |
|---|---|
| Developer | Development environment, source code |
| Finance | Accounting system |
| HR | HR system |
| Sales | CRM |
| Security | Security tools |
| System Administrator | Infrastructure administration |
This is commonly referred to as Role-Based Access Control (RBAC).
5. Separation of Duties
Where appropriate, critical activities should not be controlled entirely by one individual.
For example:
One employee requests a payment.
Another employee approves it.
Similarly:
One person may develop software.
Another person may approve production deployment.
Separation of duties reduces the risk of unauthorized or fraudulent activity.
6. Privileged Access Control
Administrative access should receive stronger controls.
Examples:
- Root accounts
- Domain administrators
- Cloud administrators
- Database administrators
- Security administrators
Privileged accounts should be:
- Limited
- Authorized
- Monitored
- Reviewed
- Protected with strong authentication
7. Default Deny
Where appropriate, access should be denied unless it has been explicitly authorized.
Instead of:
Everyone has access unless removed.
Use:
No access unless required and approved.
This is particularly important for sensitive systems.
Access Control Lifecycle
A practical access lifecycle is:
1. Request
User or manager requests access.
↓
2. Review
The business owner determines whether access is required.
↓
3. Approval
Appropriate authority approves the request.
↓
4. Provision
IT or system administrator grants access.
↓
5. Use
User accesses the system according to their role.
↓
6. Review
Access is periodically reviewed.
↓
7. Modify
Access changes when responsibilities change.
↓
8. Revoke
Access is removed when no longer required.
Activities Required to Implement A.5.15
Step 1: Identify Important Systems
Create an inventory of systems requiring access control.
Examples:
- Microsoft 365
- Google Workspace
- AWS
- Azure
- GitHub
- GitLab
- Jira
- CRM
- ERP
- HR platform
- Accounting system
- Production database
- VPN
- Security tools
Step 2: Identify Users and Roles
Determine who needs access.
Examples:
- Employees
- Contractors
- Interns
- Consultants
- Vendors
- Service accounts
- Administrators
- Temporary workers
Step 3: Define Access Requirements
For each system, determine:
- Who needs access?
- What level of access?
- Why do they need it?
- Who approves it?
- How long should access remain?
- Is privileged access involved?
Step 4: Define Access Levels
For example:
| Access Level | Description |
|---|---|
| Read | View information |
| Write | Create or modify information |
| Approve | Approve transactions or changes |
| Admin | Manage system configuration |
| Super Admin | Full administrative control |
The exact levels should depend on the system.
Step 5: Define Approval Requirements
Not all access should be approved by the same person.
For example:
Standard application access
Manager approval.
Financial system
Manager + Finance owner.
Production access
Manager + System/Application owner + Security approval where appropriate.
Privileged access
Additional authorization and stronger controls.
Step 6: Implement Authentication
Access control depends on reliable user identification.
Controls may include:
- Unique user IDs
- Strong passwords
- MFA
- SSO
- Conditional access
- Hardware security keys
- Certificate-based authentication
These mechanisms are closely related to A.5.16 and A.5.17.
Step 7: Control Privileged Access
Administrative access should be separately controlled.
Examples:
Instead of giving every developer:
Production Administrator
consider:
Developer → Development Access
and provide production access only when there is a documented operational requirement.
Step 8: Manage Remote Access
Remote workers may access systems from outside the corporate office.
Controls may include:
- MFA
- VPN where appropriate
- Device security
- Conditional access
- Approved devices
- Session controls
- Monitoring
Step 9: Manage Third-Party Access
External parties may include:
- Consultants
- Auditors
- Vendors
- Contractors
- Managed service providers
Their access should be:
- Authorized
- Limited
- Time-bound where possible
- Monitored appropriately
- Removed when no longer required
Step 10: Review Access
Access should be reviewed periodically and when circumstances change.
Triggers include:
- Employee transfer
- Promotion
- Role change
- Project completion
- Contract termination
- Employee exit
- Security incident
- Significant organizational change
Startup Example
Consider a SaaS startup with:
- 50 employees
- 10 developers
- 5 customer-support employees
- 5 sales employees
- 3 finance employees
- 2 HR employees
- External security consultant
The company uses:
- GitHub
- AWS
- Google Workspace
- CRM
- Accounting system
Access model
Developers
→ GitHub
→ Development AWS environment
Production
→ Restricted to authorized personnel
Finance
→ Accounting system
Sales
→ CRM
HR
→ HR system
Security consultant
→ Limited, time-bound security access
Employee exit
HR informs IT.
↓
IT identifies all accounts.
↓
Access is disabled.
↓
Sessions/tokens are revoked where appropriate.
↓
Privileged access is removed.
↓
Evidence is retained.
This connects A.5.15 with A.6.5 – Responsibilities After Termination or Change of Employment and A.5.16 – Identity Management.
Example Access Control Matrix
| System | Developer | Finance | HR | Sales | Security Admin |
|---|---|---|---|---|---|
| GitHub | Write | No Access | No Access | No Access | Admin where required |
| AWS Dev | Access | No Access | No Access | No Access | Admin |
| AWS Production | Limited/Approved | No Access | No Access | No Access | Restricted Admin |
| CRM | Limited | No Access | No Access | Write | Admin |
| Accounting | No Access | Write | No Access | Read where required | Limited |
| HR System | No Access | Limited | Write | No Access | Admin where required |
This matrix should reflect the organization’s actual business requirements rather than being copied blindly.
Example Access Request
Access Request
Employee: Rahul Sharma
Department: Engineering
System: AWS Production
Requested Access: Read-only
Business Justification: Production troubleshooting
Duration: 7 days
Manager Approval: Approved
System Owner Approval: Approved
Security Approval: Required/Completed where applicable
Access Expiry: 30 September 2026
This creates a clear audit trail.
Startup-Focused Quick Summary
A startup can start with six basic rules:
Rule 1
Every user should have a unique account.
Rule 2
Access should be based on job responsibilities.
Rule 3
Use least privilege.
Rule 4
Use MFA for important and privileged systems.
Rule 5
Review access periodically.
Rule 6
Immediately remove access when employment or business need ends.
Simple Startup Model
Right Person → Right System → Right Access → Right Time
Example Access Review Register
| User | System | Current Access | Business Need | Reviewer | Decision | Date |
|---|---|---|---|---|---|---|
| User A | GitHub | Developer | Required | Engineering Manager | Retain | 2026-09-01 |
| User B | AWS | Admin | Required | CTO | Retain | 2026-09-01 |
| User C | CRM | User | Required | Sales Manager | Retain | 2026-09-01 |
| User D | Finance | User | No longer required | Finance Manager | Remove | 2026-09-01 |
Audit Evidence for A.5.15
An auditor may ask:
“How does your organization control access to information and systems?”
Useful evidence includes:
Policies
- Access Control Policy
- Information Security Policy
- Password Policy
- Privileged Access Policy
Procedures
- User Access Request Procedure
- Access Approval Procedure
- Access Review Procedure
- Joiner-Mover-Leaver Procedure
Registers
- User Access Register
- Access Matrix
- Privileged Account Register
- Application Inventory
Technical Evidence
- IAM configuration
- SSO configuration
- MFA configuration
- RBAC configuration
- Active Directory / Entra ID configuration
- Cloud IAM configuration
- GitHub access settings
- VPN configuration
Operational Evidence
- Access requests
- Approval records
- Access reviews
- Termination records
- Role-change records
- Privileged-access logs
A.5.15 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Is there an approved access-control policy? | Access Control Policy |
| Are access-control principles defined? | Policy |
| Is least privilege applied? | Access matrix |
| Is need-to-know considered? | Access records |
| Are access requests formally approved? | Access requests |
| Are users uniquely identified? | IAM records |
| Are privileged accounts controlled? | Privileged account register |
| Is MFA implemented for important systems? | MFA configuration |
| Are third-party users controlled? | Vendor access records |
| Is remote access controlled? | VPN/conditional access configuration |
| Are access rights periodically reviewed? | Access review records |
| Are terminated users removed promptly? | Offboarding evidence |
| Are role changes reflected in access? | Mover records |
| Are excessive permissions identified and removed? | Access review evidence |
| Are access exceptions documented? | Exception register |
Common Mistakes in A.5.15
1. Giving Everyone Administrator Access
This is one of the most common startup mistakes.
It may be convenient during early growth, but it creates unnecessary risk.
2. Shared Accounts
Examples:
admin@company.comsupport@company.comserveradmin
used by multiple people without individual accountability.
Where possible, users should have unique accounts.
3. No Formal Approval
IT gives access based on a verbal request without documented authorization.
An auditor may ask:
“Who approved this access and why?”
The organization should be able to demonstrate the answer.
4. No Periodic Access Review
Access is granted once and never reviewed.
Employees change roles, projects end, and responsibilities evolve.
5. Former Employees Still Have Access
This creates a serious access-management weakness.
Offboarding should include access revocation.
6. Contractors Are Forgotten
Contractors often have access to:
- GitHub
- AWS
- Jira
- Customer systems
- Shared drives
Their access should have a defined owner, duration, and removal process.
7. Permanent Privileged Access
Users may retain administrator rights even though they only needed them temporarily.
Where practical, privileged access should be limited and time-bound.
8. No Separation of Duties
One person can:
- Create
- Approve
- Execute
- Modify
- Delete
a sensitive transaction without independent review.
This can increase fraud and error risk.
9. Access Matrix Exists but Does Not Match Reality
A spreadsheet says:
Developer = No Production Access
but several developers actually have production administrator permissions.
Auditors may identify the difference through system evidence.
10. Treating Access Control as Only an IT Problem
Access control involves:
- HR
- Managers
- System owners
- Security
- IT
- Employees
- Contractors
- Vendors
It is an organizational process, not just a technical configuration.
Practical Startup Implementation Model
A simple startup implementation can follow:
Identify → Request → Approve → Grant → Review → Modify → Revoke
Identify
Determine systems and information requiring protection.
↓
Request
User requests access based on business need.
↓
Approve
Appropriate owner approves.
↓
Grant
IT/system administrator provides appropriate permissions.
↓
Review
Access is periodically reviewed.
↓
Modify
Access changes when responsibilities change.
↓
Revoke
Access is removed when no longer required.
Policy vs. Process vs. Evidence
| Component | Example |
|---|---|
| Policy | Defines access-control principles |
| Access Rules | Least privilege, need-to-know, separation of duties |
| Procedure | Explains how access is requested and approved |
| Access Matrix | Shows who can access which systems |
| Technical Controls | IAM, RBAC, MFA, SSO |
| Access Review | Periodic review of user permissions |
| Training | User responsibilities regarding access |
| Evidence | Requests, approvals, configurations, reviews, revocations |
Relationship with Other ISO 27001 Controls
A.5.9 – Inventory of Information and Other Associated Assets
You need to know which assets exist before determining who should access them.
A.5.12 – Classification of Information
Information sensitivity helps determine appropriate access restrictions.
A.5.13 – Labelling of Information
Labels communicate information classification and handling requirements.
A.5.15 – Access Control
Establishes the overall principles and rules for controlling access.
A.5.16 – Identity Management
Controls the lifecycle of user identities.
A.5.17 – Authentication Information
Protects information used to authenticate users.
A.5.18 – Access Rights
Focuses specifically on provisioning, reviewing, modifying, and removing access rights.
A.6.5 – Responsibilities After Termination or Change of Employment
Ensures access-related responsibilities are addressed when employment changes.
A.8.2 – Privileged Access Rights
Provides additional controls for administrative and privileged access.
A.8.3 – Information Access Restriction
Supports restriction of access to information based on defined requirements.
Useful Resources
Recommended Documents
- [Insert Draft Document Link – Access Control Policy]
- [Insert Draft Document Link – User Access Request Form]
- [Insert Draft Document Link – Access Control Matrix]
- [Insert Draft Document Link – User Access Review Checklist]
- [Insert Draft Document Link – Privileged Access Register]
- [Insert Draft Document Link – Joiner-Mover-Leaver Procedure]
- [Insert Draft Document Link – Third-Party Access Procedure]
- [Insert Draft Document Link – Access Review Report]
Final Takeaway
ISO 27001 Annex A 5.15 establishes the organization’s overall approach to controlling access to information and associated assets.
The objective is not simply:
“Give users access.”
It is:
“Give the right person the right level of access to the right information or system for the right business reason.”
A practical access-control lifecycle is:
Request → Approve → Grant → Use → Review → Modify → Revoke
For startups, the most important foundations are:
- Unique user accounts
- Least privilege
- Need-to-know
- Appropriate approvals
- MFA
- Controlled privileged access
- Periodic access reviews
- Strong joiner/mover/leaver processes
- Timely removal of unnecessary access
The key audit question is:
Can the organization demonstrate who has access, why they have it, who approved it, whether it is still required, and what happens when that access is no longer needed?
If the organization can demonstrate that lifecycle consistently, A.5.15 becomes a practical access-governance control rather than just an access-control policy sitting on a shelf.