What is ISO 27001 Annex A 5.18 – Access Rights?
ISO 27001 Annex A 5.18 focuses on ensuring that access rights to information and associated assets are provisioned, reviewed, modified, and removed according to business and security requirements.
In simple terms, an organization should make sure that:
- People get only the access they need.
- Access is approved before it is granted.
- Access changes when a person’s role changes.
- Access is periodically reviewed.
- Access is removed when it is no longer required.
- Privileged access receives appropriate additional control.
Simple Explanation
Give people the access they need to do their job—and remove or change that access when their job or need changes.
Why is A.5.18 Important?
Access that is appropriate today may become inappropriate tomorrow.
For example:
A developer moves from the development team to the finance team.
If the developer continues to have:
- Production access
- GitHub administrator privileges
- AWS administrator access
- Database access
then the organization may have unnecessary access remaining after the role change.
Similarly, when an employee leaves the company, access to:
- Cloud platforms
- Source code
- VPN
- CRM
- Financial systems
- Customer data
should not remain active.
A.5.18 helps organizations reduce risks such as:
- Unauthorized access
- Excessive privileges
- Former employee access
- Inappropriate access after role changes
- Privilege accumulation
- Orphaned accounts
- Unauthorized access to sensitive information
- Lack of accountability
Simple Principle
Access should follow business need—not historical privilege.
What Does A.5.18 Require?
The organization should establish a process for managing access rights throughout their lifecycle.
This generally includes:
Request → Approve → Grant → Review → Modify → Remove
Access rights should be based on:
- Job responsibilities
- Business requirements
- Information sensitivity
- Risk
- Least-privilege principles
- Need-to-know requirements
- Contractual or regulatory requirements
The process should cover both normal user access and privileged access.
Access Rights vs Identity vs Authentication
These controls are closely connected.
| Concept | Question | Example |
|---|---|---|
| A.5.16 Identity Management | Who is this identity? | John Smith |
| A.5.17 Authentication Information | How is the identity authenticated? | Password + MFA |
| A.5.18 Access Rights | What is the identity allowed to access? | AWS production read access |
| A.8.2 Privileged Access Rights | How are highly privileged rights controlled? | AWS Administrator |
Example
John is an employee.
Identity: John has an individual company account.
Authentication: John uses SSO + MFA.
Access Rights: John can access Jira, GitHub repositories for his team, and specific AWS resources.
The three controls address different parts of the access lifecycle.
What Types of Access Rights Should Be Managed?
A company should consider access to:
Business Applications
- CRM
- ERP
- HR systems
- Finance applications
- Ticketing systems
- Collaboration platforms
Infrastructure
- AWS
- Azure
- Google Cloud
- Servers
- Databases
- VPN
- Network devices
Development Systems
- GitHub
- GitLab
- CI/CD
- Container registries
- Production environments
- Cloud consoles
Information
- Customer data
- Employee information
- Financial records
- Source code
- Security documentation
- Confidential business information
Physical or Facility Access
Where applicable:
- Office access
- Server rooms
- Data centers
- Restricted areas
Activities Required to Implement A.5.18
Step 1: Identify Systems Requiring Access Management
Start by identifying important systems.
For example:
| System | Data/Function | Criticality | Access Managed? |
|---|---|---|---|
| Google Workspace | Corporate information | High | Yes |
| GitHub | Source code | High | Yes |
| AWS | Infrastructure | Critical | Yes |
| Jira | Project information | Medium | Yes |
| Salesforce | Customer information | High | Yes |
| Payroll | Employee/financial information | High | Yes |
A startup does not necessarily need to document every low-risk application initially.
Prioritize systems that contain sensitive information or can materially affect the business.
Step 2: Define Access Roles
Create appropriate access roles.
For example:
Engineering
- Developer
- Senior Developer
- Engineering Manager
- DevOps Administrator
Finance
- Finance User
- Finance Manager
- Finance Administrator
HR
- HR User
- HR Manager
IT
- IT Support
- IT Administrator
Role-based access can make access management easier and more consistent.
Step 3: Define Access Requirements
For each role, determine what access is required.
Example:
| Role | System | Access |
|---|---|---|
| Developer | GitHub | Team repository |
| Developer | AWS | Development environment |
| Developer | Production | Limited/approved |
| Finance | Accounting | Finance module |
| HR | HRIS | Employee records |
| IT Admin | Google Workspace | Administrative |
| Sales | CRM | Customer records |
The objective is not to give everyone the maximum available access.
Step 4: Establish an Access Request Process
Access should normally be requested and approved through a defined process.
Example:
Employee requests access
↓
Manager approves
↓
System owner/security approves where required
↓
IT/IAM grants access
↓
Access is recorded
↓
Access is periodically reviewed
The exact approval chain can depend on the sensitivity of the system.
Step 5: Apply Least Privilege
Users should receive only the level of access necessary for their responsibilities.
For example:
A developer who needs to view production logs does not automatically need:
- Production database write access
- AWS Administrator
- Billing Administrator
- IAM Administrator
Access should be appropriately limited.
Step 6: Manage Role Changes
This is one of the most important practical areas.
Suppose:
Developer → Engineering Manager
The organization should evaluate whether the person’s existing access remains appropriate.
Some access may be:
Retained
Some may be:
Added
Some may be:
Removed
Example
| Access | Previous Role | New Role | Action |
|---|---|---|---|
| Development GitHub | Yes | Yes | Retain |
| Production read | Yes | Yes | Retain |
| Finance system | No | No | None |
| Team administration | No | Yes | Add |
| Temporary project access | Yes | No | Remove |
Step 7: Remove Access When Employment Ends
When an employee leaves, access should be removed or disabled according to the organization’s offboarding process.
Consider:
- SSO
- VPN
- GitHub
- AWS
- Azure
- Google Workspace
- SaaS applications
- CRM
- HR systems
- Privileged accounts
- Physical access
The timing should be appropriate to the circumstances and organizational risk.
Step 8: Manage Temporary Access
Temporary access should have:
- Defined purpose
- Approver
- Start date
- End date where practical
- Appropriate permissions
- Review or removal mechanism
Example:
A consultant requires production access for three days.
Instead of creating permanent access:
Consultant access
→ Approved
→ Limited permissions
→ Valid for defined period
→ Automatically or manually removed
Step 9: Review Access Rights Periodically
Organizations should periodically review whether access remains appropriate.
A review may ask:
- Does this person still need access?
- Does their role still justify it?
- Is the level of access appropriate?
- Are there inactive accounts?
- Are there excessive privileges?
- Are former employees still present?
- Are contractors still engaged?
- Are temporary accounts still active?
The frequency should be determined based on risk and organizational requirements.
Step 10: Review Privileged Access
Administrative access should receive additional attention.
Examples:
- AWS Administrator
- Google Workspace Super Admin
- GitHub Organization Owner
- Database Administrator
- Firewall Administrator
The organization should know:
- Who has privileged access?
- Why do they need it?
- Who approved it?
- Is it still required?
- When was it last reviewed?
Startup Example
Imagine a 60-person SaaS startup.
The company uses:
- Google Workspace
- GitHub
- AWS
- Jira
- Salesforce
- Slack
A developer has:
- GitHub access
- AWS development access
- Jira access
- Slack access
The developer later becomes an Engineering Manager.
The company reviews the existing access.
Existing access
GitHub → Retain
AWS Development → Retain
Jira → Retain
Slack → Retain
Additional access
Team administration → Add
Security dashboard → Add
Access no longer required
Temporary project administrator access → Remove
The access review is documented.
This demonstrates that access rights are actively managed rather than simply accumulated over time.
Access Rights Register
A startup can maintain an access register for important systems.
| User | Role | System | Access Level | Owner | Approval | Last Review | Status |
|---|---|---|---|---|---|---|---|
| User A | Developer | GitHub | Developer | Engineering | Manager | 2026-09 | Active |
| User B | DevOps | AWS | Admin | CTO | CTO | 2026-09 | Active |
| User C | Finance | Accounting | Finance User | Finance | CFO | 2026-09 | Active |
| User D | Sales | CRM | Standard | Sales Manager | Manager | 2026-09 | Active |
For larger environments, access-review information may be maintained directly in IAM or GRC platforms.
Access Review Example
A quarterly access review could look like:
| User | System | Access | Required? | Action | Reviewer |
|---|---|---|---|---|---|
| User A | AWS | Developer | Yes | Retain | Engineering Manager |
| User B | GitHub | Admin | No | Reduce | CTO |
| User C | CRM | Sales | Yes | Retain | Sales Manager |
| User D | Jira | Project Admin | No | Remove | Project Owner |
The important point is not simply conducting the review.
The organization should demonstrate that identified inappropriate access is actually corrected.
Audit Evidence
An auditor may request evidence showing that access rights are properly managed.
Policy Evidence
- Access Control Policy
- Information Security Policy
- User Access Management Policy
- Privileged Access Policy
Process Evidence
- User access request procedure
- Access approval workflow
- Joiner/mover/leaver procedure
- Access review procedure
- Offboarding procedure
- Temporary access procedure
Technical Evidence
Depending on the environment:
- IAM configuration
- SSO configuration
- Role-based access configuration
- Group membership
- AWS IAM reports
- GitHub organization access
- Microsoft Entra ID / Google Workspace access reports
- Database permissions
- VPN access lists
Operational Evidence
- Access request tickets
- Approval records
- Access review records
- Access removal records
- Employee offboarding records
- Privileged access review
- Contractor access review
ISO 27001 A.5.18 Audit Checklist
Access Provisioning
- Is there a documented process for granting access?
- Is access approved before it is granted?
- Is access based on business requirements?
- Are access rights assigned according to roles?
- Is least privilege considered?
Access Modification
- Is access reviewed when employees change roles?
- Are unnecessary privileges removed?
- Are temporary permissions removed?
- Are contractor permissions reviewed when contracts change?
Access Removal
- Is access removed when employment ends?
- Are SaaS accounts disabled?
- Are cloud accounts disabled?
- Are VPN credentials removed?
- Are privileged accounts addressed?
- Is physical access removed where applicable?
Periodic Review
- Are access rights periodically reviewed?
- Are privileged accounts reviewed?
- Are inactive accounts identified?
- Are contractor accounts reviewed?
- Are temporary accounts identified?
- Are inappropriate permissions corrected?
Evidence
- Can the organization demonstrate who approved access?
- Can it demonstrate when access was granted?
- Can it demonstrate when access was removed?
- Can it demonstrate periodic access reviews?
- Can it demonstrate corrective actions from those reviews?
Common Mistakes
1. Giving Everyone Administrator Access
This is common in small startups because it is convenient.
However, convenience can create significant security exposure.
2. Access Never Changes After Promotion
An employee changes roles but keeps all previous permissions.
This can result in privilege accumulation.
3. Former Employees Still Have Access
This can happen when companies manually manage dozens of SaaS applications.
Centralized identity management and SSO can help reduce this risk.
4. Contractors Are Forgotten
Contractors may receive access for a project and remain active after the engagement ends.
Temporary access and defined end dates can help.
5. No Access Reviews
A company may have a policy saying:
“Access is reviewed periodically.”
But there is no evidence that anyone actually performs the review.
For ISO 27001, evidence of operation is important.
6. Access Review Without Remediation
Another common problem is completing a spreadsheet review but not removing inappropriate access.
A useful access review should result in action where necessary.
7. Shared Accounts
Shared accounts make it difficult to determine who performed an action.
Individual identities should be used wherever practical.
8. No System Owner
If nobody owns an application, nobody may be accountable for deciding who should have access.
Critical applications should have clearly identified owners.
Practical Startup Implementation Model
A startup can implement A.5.18 using:
Request
Employee requests access.
↓
Approve
Appropriate manager/system owner approves.
↓
Grant
IT/IAM grants appropriate access.
↓
Record
Access is recorded.
↓
Review
Access is periodically reviewed.
↓
Change
Permissions are modified when roles change.
↓
Remove
Access is revoked when no longer required.
Simple Model
Request → Approve → Grant → Review → Change → Remove
Policy vs Process vs Evidence
| Component | Example |
|---|---|
| Policy | Access shall be granted based on business need |
| Standard | Privileged access requires additional approval |
| Procedure | User access request process |
| Procedure | Joiner/mover/leaver process |
| Procedure | Quarterly access review |
| Technical Control | IAM/SSO |
| Technical Control | Role-based access |
| Evidence | Access request |
| Evidence | Approval record |
| Evidence | Access review |
| Evidence | Access removal ticket |
The strongest audit trail connects:
Requirement → Approval → Technical Access → Review → Remediation
Relationship With Other ISO 27001 Controls
| Control | Relationship |
|---|---|
| A.5.15 Access Control | Establishes the organization’s overall access-control principles |
| A.5.16 Identity Management | Manages identities throughout their lifecycle |
| A.5.17 Authentication Information | Protects authentication information |
| A.5.18 Access Rights | Manages the granting, reviewing, modifying, and removal of access |
| A.6.5 Responsibilities After Termination or Change of Employment | Addresses responsibilities and access after employment changes |
| A.8.2 Privileged Access Rights | Provides additional controls for privileged access |
| A.8.3 Information Access Restriction | Restricts access to information according to defined requirements |
| A.8.5 Secure Authentication | Supports secure authentication mechanisms |
Useful Documents for A.5.18
- Access Control Policy
[Insert Draft Document Link] - User Access Request Form
[Insert Draft Document Link] - User Access Management Procedure
[Insert Draft Document Link] - Joiner-Mover-Leaver Procedure
[Insert Draft Document Link] - Access Rights Register
[Insert Draft Document Link] - Periodic Access Review Template
[Insert Draft Document Link] - Privileged Access Review Template
[Insert Draft Document Link] - Contractor Access Review Checklist
[Insert Draft Document Link]
Final Takeaway
ISO 27001 Annex A 5.18 is about ensuring that access rights remain appropriate throughout their lifecycle.
It is not enough to grant access correctly once.
The organization needs to consider what happens when:
- A person joins
- A person changes roles
- A project ends
- A contractor’s engagement changes
- A privilege is no longer required
- An employee leaves
- A system changes
- A security risk changes
The practical objective is simple:
Give the right access, to the right person, for the right reason—and remove or modify it when that reason no longer exists.
A simple auditor-focused model:
Request → Approve → Grant → Monitor → Review → Modify → Remove
A startup does not need a complicated access-management program to begin. It needs clear ownership, appropriate approvals, least-privilege access, periodic reviews, and evidence that inappropriate access is actually corrected.