1. Purpose
The Access Rights Register is a controlled record of the access permissions assigned to users, contractors, third parties, privileged users, service identities, and other authorized identities across organizational systems and information resources.
The register provides visibility into:
- Who has access
- What they can access
- What level of access they have
- Why the access is required
- Who approved it
- When it was granted
- When it should expire
- Whether it is privileged
- When it was last reviewed
- Whether the access remains appropriate
Core Principle
Identify → Request → Approve → Grant → Record → Review → Modify → Revoke
2. Scope
The register may cover access to:
- Corporate identity/SSO
- Email and collaboration systems
- SaaS applications
- AWS/Azure/GCP
- Servers
- Databases
- Source-code repositories
- CI/CD platforms
- VPN
- Security platforms
- Customer systems
- File-sharing platforms
- Business applications
- Network resources
- Physical systems where access rights are relevant
It should include, as applicable:
- Employees
- Contractors
- Consultants
- Interns
- Temporary workers
- Third-party personnel
- Privileged users
- Service/application identities
- Emergency identities
3. What Is an Access Right?
An access right represents an authorized permission assigned to an identity.
Examples include:
- Read
- Create
- Modify
- Delete
- Execute
- Approve
- Export
- Administrator
- Database administrator
- Cloud administrator
- Security administrator
- Repository administrator
- Production access
An access right should be specific enough to determine what the identity can actually do.
4. Access Rights Register – Master Fields
| Field | Description |
|---|---|
| Access Right ID | Unique identifier |
| Identity ID | Link to Identity Register |
| User/Identity Name | Person or identity |
| Identity Type | Employee / Contractor / Third Party / Service |
| Department/Organization | User’s organization |
| Job Role | Current role |
| Manager/Sponsor | Responsible person |
| System/Application | Resource being accessed |
| Environment | Production / Development / Test |
| Cloud Account/Subscription | Where applicable |
| Resource | Specific resource |
| Access Role | Assigned role |
| Permission Level | Read / Write / Admin etc. |
| Privileged Access | Yes / No |
| Business Purpose | Reason for access |
| Information Accessed | Type of information |
| Information Classification | Public / Internal / Confidential / Restricted |
| Access Type | Permanent / Temporary / Emergency |
| Start Date | Access effective date |
| Expiry Date | Where applicable |
| Access Approver | Person approving access |
| System Owner | Owner of resource |
| Data Owner | Where applicable |
| Access Request ID | Link to request |
| Related Risk ID | Where applicable |
| Authentication Method | SSO / MFA / other |
| Last Review Date | Most recent review |
| Next Review Date | Planned review |
| Review Result | Approved / Modified / Revoked |
| Status | Active / Expired / Revoked |
| Evidence Reference | Supporting evidence |
| Remarks | Additional information |
5. Sample Access Rights Register
| Access ID | User | System | Environment | Role | Access | Privileged | Purpose | Status |
|---|---|---|---|---|---|---|---|---|
| AR-001 | Employee-001 | GitHub | Production Repo | Developer | Read/Write | No | Software development | Active |
| AR-002 | Employee-002 | AWS | Production | DevOps Admin | Admin | Yes | Infrastructure management | Active |
| AR-003 | Employee-003 | Jira | All | User | Create/Modify | No | Project management | Active |
| AR-004 | Vendor-001 | Audit Repository | Production | Auditor | Read Only | No | External audit | Temporary |
| AR-005 | Employee-004 | RDS | Production | DBA | Admin | Yes | Database administration | Active |
| AR-006 | Service-App-001 | AWS | Production | Application Role | Application Access | No | SaaS application | Active |
6. Access Right Identification
Each access right should be uniquely identifiable.
Example:
AR-2026-001
The ID should remain associated with the access record throughout its lifecycle where practical.
Do not create duplicate records for the same access simply because the access is reviewed.
Instead, maintain the history of significant changes.
7. Identity Linkage
Each access right should link to an identity.
The identity may be:
- Employee
- Contractor
- Consultant
- Third party
- Service account
- Application identity
- Cloud role
- Emergency identity
The Access Rights Register should not replace the Identity Register.
Identity Register
Who/what is the identity?
Access Rights Register
What can the identity access?
8. System and Application
Record the specific system or application.
Examples:
- Microsoft 365
- GitHub
- Jira
- Salesforce
- AWS
- Azure
- GCP
- Production database
- VPN
- Security platform
- Customer portal
Where possible, identify the specific account, tenant, repository, database, application, or environment rather than using generic descriptions.
9. Environment
Identify the environment where the access applies.
Examples:
- Production
- Development
- Test
- Staging
- Disaster Recovery
Production access should normally receive additional scrutiny based on risk.
A user having development access does not automatically mean they should have production access.
10. Access Role
Record the actual role assigned.
Examples:
- Standard User
- Developer
- Support Agent
- Finance User
- Security Analyst
- DevOps Engineer
- Database Administrator
- Cloud Administrator
- Security Administrator
- Repository Administrator
- Auditor
Avoid vague entries such as “System Access” where more precise information is available.
11. Permission Level
Record the effective level of permission.
Examples:
| Permission | Description |
|---|---|
| Read | View information |
| Create | Create information |
| Modify | Change information |
| Delete | Delete information |
| Execute | Run approved functions |
| Approve | Approve transactions/activities |
| Export | Extract information |
| Admin | Administrative control |
| Privileged | Elevated permissions |
Where a system uses detailed permissions, record the applicable role or permission set.
12. Business Purpose
Every significant access right should have a legitimate business purpose.
Examples:
Software development
Customer support
Production infrastructure administration
Security monitoring
Financial reporting
External audit
Database administration
Avoid statements such as:
“Required by employee.”
The purpose should explain why the access is necessary.
13. Information Classification
Identify the information accessible through the permission.
Example classification:
- Public
- Internal
- Confidential
- Restricted
The organization should define and maintain its own classification scheme.
Higher-risk information should receive appropriate access restrictions.
14. Privileged Access
Identify privileged access separately.
Examples:
- AWS Administrator
- Database Administrator
- Identity Administrator
- Security Administrator
- Network Administrator
- Repository Administrator
- CI/CD Administrator
- Backup Administrator
For privileged access, link the record to the Privileged Access Register where applicable.
Additional information may include:
- Business justification
- Privileged role
- Approval
- MFA
- Monitoring
- Review frequency
- Expiry
- Emergency access requirements
15. Permanent and Temporary Access
Record whether the access is:
- Permanent
- Temporary
- Emergency
Temporary access should have a defined expiry date.
Example:
| Access | Type | Start | Expiry |
|---|---|---|---|
| External Auditor | Temporary | 01-Oct-2026 | 15-Oct-2026 |
| AWS Administrator | Permanent | 01-Jan-2026 | N/A |
| Emergency Admin | Emergency | As required | Immediate/review |
Permanent access does not mean it should remain forever. It should still be periodically reviewed.
16. Access Approval
Record who approved the access.
Depending on the system and risk, approval may come from:
- Manager
- System owner
- Application owner
- Data owner
- Business owner
- Security/ISMS
- Privileged access approver
Link the access right to the original User Access Request ID where possible.
17. Access Request Linkage
Each access right should be traceable back to the request that initiated it.
Example:
Access Right: AR-2026-018
↓
Access Request: UAR-2026-041
↓
Approval: Engineering Manager
↓
System: AWS Development
↓
Role: Developer
This creates a useful audit trail.
18. Access Start and Expiry
Record:
- Access start date
- Expiry date where applicable
Expiry should be mandatory for:
- Temporary access
- Contractor access where appropriate
- Third-party access
- Project-specific access
- Emergency access
- Time-limited privileged access
Expired access should be automatically removed where technically possible.
19. Authentication Information
The Access Rights Register may record the authentication mechanism used.
Examples:
- SSO
- MFA
- Security key
- Passkey
- Certificate
- Workload identity
- Cloud role
However, actual authentication secrets must never be recorded.
Do not store:
- Passwords
- API keys
- Access tokens
- Refresh tokens
- MFA seeds
- Recovery codes
- Private keys
- SSH private keys
20. AWS Access Rights Example
For an AWS SaaS environment:
| Field | Example |
|---|---|
| Identity | Employee-002 |
| System | AWS |
| Account | Production |
| Environment | Production |
| Role | DevOps Production Role |
| Permissions | Limited infrastructure administration |
| Privileged | Yes |
| Authentication | SSO + MFA |
| Purpose | Production infrastructure management |
| Approver | CTO |
| System Owner | CTO |
| Review | Quarterly |
| Status | Active |
Where AWS IAM Identity Center or another centralized identity mechanism is used, the register should capture the effective role/account assignment rather than storing credentials.
21. Service and Application Access
The register may also contain non-human identities where access rights need to be tracked.
Examples:
- Application role
- AWS workload identity
- CI/CD identity
- Service account
- Backup service
- Monitoring service
For these identities record:
- Owner
- Business purpose
- System
- Permissions
- Environment
- Authentication mechanism
- Privilege level
- Review date
- Status
Actual credentials should be managed through the Secrets Management process.
22. Third-Party Access Rights
For external users, record:
- Organization
- Individual
- Internal sponsor
- System
- Access level
- Business purpose
- Information accessed
- Contract/SOW
- NDA where applicable
- Start date
- Expiry date
- Approval
- Review
- Status
Example:
External Auditor → Audit Repository → Read Only → Confidential Audit Evidence → 14-day expiry
23. Access Rights for Restricted Information
Access to Restricted information should be specifically controlled.
Examples:
- Production credentials
- Encryption keys
- Highly sensitive security information
- Critical vulnerability information
- Security incident investigation information
- Highly sensitive customer information
The register should make it possible to identify who has access to such information.
24. Access Review
Access Rights should be periodically reviewed according to risk and organizational requirements.
The review should determine:
- Is the identity still valid?
- Is the access still required?
- Is the business purpose still valid?
- Is the permission appropriate?
- Is the access level excessive?
- Is privileged access still justified?
- Has the user’s role changed?
- Has the project ended?
- Has the contractor relationship ended?
- Has the access expired?
- Is there a SoD conflict?
- Does the access match the classification of information?
Review Process
Collect → Reconcile → Validate → Assess → Correct → Verify → Record
25. Access Reconciliation
The register should be compared with actual access in relevant systems.
Potential sources include:
- Identity Provider
- SSO
- AWS IAM/Identity Center
- Azure
- GCP
- SaaS applications
- GitHub
- VPN
- Databases
- Security platforms
- HR records
- Contractor records
The purpose is to identify differences such as:
- Access exists but is not registered
- Register shows access that no longer exists
- User has excessive permissions
- User has old role permissions
- Former employee remains active
- Contractor access has expired
- Privileged access is not documented
26. Access Modification
When access changes:
- Identify the existing access right.
- Determine why the change is required.
- Obtain approval where required.
- Remove unnecessary permissions.
- Add approved permissions.
- Verify actual access.
- Update the register.
- Retain evidence.
Avoid simply adding new permissions without reviewing existing access.
27. Access Revocation
When access is no longer required:
- Remove the permission.
- Disable the account if appropriate.
- Remove privileged roles.
- Revoke cloud access.
- Remove SaaS access.
- Remove repository access.
- Revoke VPN access.
- Address tokens/keys where applicable.
- Verify removal.
- Update status to Revoked.
- Record revocation evidence.
28. Access History
Where practical, maintain a change history.
| Date | Access Right | Change | Previous State | New State | Changed By | Reason |
|---|---|---|---|---|---|---|
| AR-001 | Role Change | Developer | DevOps | Role change | ||
| AR-002 | Revocation | Active | Revoked | Employee exit |
The register should provide sufficient history to demonstrate how significant access changes occurred.
29. Access Exceptions
Where access cannot follow the standard process, record:
- Exception ID
- Access right
- Reason
- Risk
- Compensating control
- Approver
- Expiry/review date
- Status
Exceptions should be reviewed periodically.
30. Access Status
Recommended status values:
- Requested
- Pending Approval
- Approved
- Provisioning
- Active
- Temporary
- Expired
- Suspended
- Revoked
- Rejected
The organization may adapt these statuses to its workflow.
31. Access Rights Register Review
The register itself should be reviewed periodically for completeness and accuracy.
Check:
- Duplicate records
- Missing owners
- Missing approvals
- Missing expiry dates
- Unknown identities
- Unknown access
- Incorrect permissions
- Stale records
- Revoked access still marked active
- Missing privileged access
- Missing third-party access
- Missing review dates
32. Responsibilities
System Owners
- Define appropriate access.
- Approve access where required.
- Review access periodically.
- Ensure excessive access is corrected.
Managers
- Confirm business need.
- Approve employee access.
- Notify role changes and departures.
Data Owners
- Approve access to sensitive information.
IT/IAM
- Provision and revoke access.
- Maintain technical records.
- Support reconciliation.
Security/ISMS
- Define access-control requirements.
- Review high-risk access.
- Support access reviews and audits.
Users
- Use access only for authorized purposes.
- Protect credentials.
- Report unauthorized access.
Internal Audit
- Independently assess whether access-management controls operate effectively.
33. Evidence
Supporting evidence may include:
- User Access Request Forms
- Approval records
- IAM/SSO records
- Application access reports
- AWS IAM Identity Center assignments
- Access Control Matrix
- Privileged Access Register
- Access Review Reports
- JML records
- Access Revocation records
- Change tickets
- System logs
- Exception approvals
- Contractor/third-party records
Actual credentials should never be stored in the register or audit evidence.
34. Minimum Register for a Startup
A startup can begin with a controlled spreadsheet or GRC platform containing:
| Identity | System | Role | Access Level | Purpose | Privileged | Approver | Start | Expiry | Last Review | Status |
|---|
As the organization grows, the register can be integrated with IAM, SSO, cloud platforms, SaaS applications, and automated access-review workflows.
35. Recommended Access Rights Register Structure
For larger environments, maintain separate views or tabs:
1. Master Access Rights Register
All active and historical access rights.
2. Privileged Access
Administrative and elevated permissions.
3. Temporary Access
Time-limited access.
4. Third-Party Access
External personnel.
5. Service/Application Access
Non-human identities.
6. Access Change Log
Changes to access rights.
7. Access Review Log
Periodic review results.
This keeps the master register manageable while preserving detailed evidence.
36. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Identity Register | Identifies users and identities |
| Access Rights Register | Records what each identity can access |
| User Access Request Form | Requests access |
| User Access Management Procedure | Defines lifecycle |
| Access Control Matrix | Defines expected role-based permissions |
| Privileged Access Register | Records elevated access |
| Authentication Information Register | Records authentication mechanisms |
| JML Procedure | Manages joiner/mover/leaver changes |
| Contractor Account Procedure | Manages contractor identities |
| Third-Party Access Procedure | Controls external access |
| Access Review Report | Periodically validates access |
| Access Revocation Checklist | Supports access removal |
| Segregation of Duties Policy | Addresses conflicting access |
| Asset/Data Inventory | Identifies resources and information |
| Risk Register | Records access-related risks |
| Incident Management | Handles unauthorized access events |
37. Identity vs Access vs Authentication
These three records should remain conceptually separate:
| Record | Main Question |
|---|---|
| Identity Register | Who or what is the identity? |
| Authentication Information Register | How is the identity authenticated? |
| Access Rights Register | What can the identity access? |
For example:
Employee-002
→ Identity Register: employee identity
→ Authentication Register: SSO + MFA
→ Access Rights Register: AWS Production DevOps Role
→ Privileged Access Register: production privileged role
This separation makes access governance easier to maintain and audit.
38. Quick Audit Checklist
An auditor should be able to select an identity and determine:
- ☐ Identity exists in the Identity Register
- ☐ Access is recorded
- ☐ Business purpose is documented
- ☐ Appropriate system/resource identified
- ☐ Access level is defined
- ☐ Information classification considered
- ☐ Approval exists
- ☐ Actual system access matches the register
- ☐ Privileged access is identified
- ☐ Temporary access has an expiry
- ☐ Access has been periodically reviewed
- ☐ Excess access has been corrected
- ☐ Leaver access has been revoked
- ☐ Third-party access is controlled
- ☐ Service identities have owners
- ☐ Evidence is available
39. ISO 27001 Connection
The Access Rights Register supports the organization’s implementation of identity management, access rights, authentication, privileged access, access restriction, and related information-security controls.
The organization should determine the exact applicable controls through its risk assessment and Statement of Applicability (SoA) rather than treating the register as evidence that every access-related control is automatically applicable.
The register is primarily an operational record and audit trail supporting the organization’s access-management process.
40. Final Audit Trail
For every important access right, the organization should be able to answer:
Who has the access?
What system or information can they access?
What permissions do they have?
Why do they need it?
Who approved it?
When was it granted?
Is it privileged or temporary?
When was it last reviewed?
Is the access still required?
When was it removed if no longer required?
Can the organization demonstrate the evidence?
Final Principle
Know who has access, know exactly what they can access, know why they need it, record who approved it, review it periodically, and remove it when the business need ends.