1. Purpose

The Access Control Matrix (ACM) defines which roles are permitted to access organizational systems, applications, information, cloud environments, and business processes.

It helps the organization:

• Apply least privilege.
• Prevent unauthorized access.
• Define role-based access.
• Identify excessive permissions.
• Support segregation of duties.
• Standardize access approvals.
• Support joiner/mover/leaver processes.
• Conduct periodic access reviews.
• Provide audit evidence.

Core Principle

Role → Required Access → Approved Permission → Controlled Use → Periodic Review → Revoke When No Longer Required

---

2. Scope

The Access Control Matrix may cover:

• Employees
• Contractors
• Consultants
• Interns
• Third-party users
• Privileged administrators
• Business applications
• SaaS platforms
• Cloud environments
• Databases
• Source-code repositories
• Security tools
• Corporate systems
• Customer systems
• Physical/remote access where applicable

---

3. What Is an Access Control Matrix?

An Access Control Matrix maps:

WHO → CAN ACCESS WHAT → AT WHAT LEVEL

For example:

Role	System	Access
Developer	Source Code Repository	Read/Write
Developer	Production AWS	Limited / Approved
Customer Support	Support Platform	Read/Write
HR	HR System	Full Business Administration
Finance	Accounting System	Finance Administration
Security	Security Platform	Security Administration

The matrix should reflect actual organizational roles and systems.

---

4. Access Levels

Use standardized access levels where practical.

Level	Meaning
No Access	Access is not permitted
Read	View information only
Create	Create records/information
Write	Create or modify information
Approve	Approve transactions/requests
Delete	Delete information
Admin	Configure/manage the system
Privileged Admin	High-risk administrative access
Temporary	Access for a defined period

Not every application needs every access level.

---

5. Example Role-Based Access Matrix

The following is an example for a SaaS startup.

System / Resource	CEO	CTO	Engineering	Security/ISMS	IT Admin	HR	Finance	Support	Procurement
Corporate Email	Admin/Use	Admin/Use	Use	Admin/Use	Admin	Use	Use	Use	Use
HR System	Read	No	No	No	No	Admin	No	No	No
Finance System	Approve	Read	No	No	No	No	Admin	No	Read
CRM	Read	Read	No	No	No	No	Read	Read/Write	Read/Write
Customer Support	Read	Read	No	Read	Admin	No	No	Read/Write	No
Source Code Repository	Read	Admin	Read/Write	Read	No	No	No	No	No
AWS Production	Limited	Admin	Limited	Security	Admin	No	No	No	No
AWS Development	Read	Admin	Read/Write	Read	Admin	No	No	No	No
Security Platform	Read	Read	Limited	Admin	Admin	No	No	No	No
Vulnerability Platform	Read	Read	Remediate	Admin	Admin	No	No	No	No
Vendor Management	Approve	Read	No	Read	No	No	Read	No	Admin
Document Repository	Read/Write	Read/Write	Read/Write	Read/Write	Admin	Read/Write	Read/Write	Read/Write	Read/Write

Note: This is an example. Actual permissions should be based on business responsibilities, risk, system functionality, and the organization’s approved access model.

---

6. Detailed Access Control Matrix

For audit purposes, maintain a more granular matrix.

ID	Role	System	Environment	Resource	Permission	Data Classification	Privileged?	Approval Required	Review Frequency	Status
ACM-001	Developer	GitHub	Production	Source Code	Read/Write	Confidential	No	Engineering Lead	Quarterly	Active
ACM-002	Developer	AWS	Production	Application Logs	Read	Confidential	No	CTO	Quarterly	Active
ACM-003	Security	AWS	Production	Security Services	Admin	Restricted	Yes	CTO	Monthly/Quarterly	Active
ACM-004	Support	Support Platform	Production	Customer Tickets	Read/Write	Confidential	No	Support Manager	Quarterly	Active
ACM-005	HR	HR Platform	Production	Employee Records	Admin	Confidential	Yes	HR Head	Quarterly	Active
ACM-006	Finance	Finance System	Production	Financial Records	Admin	Confidential	Yes	Finance Head	Quarterly	Active
ACM-007	Auditor	Audit Repository	Temporary	Audit Evidence	Read	Confidential	No	Security Lead	Per Engagement	Temporary

---

7. AWS Cloud Access Matrix

For AWS environments, access should be defined at role/resource level rather than simply giving broad account access.

Role	AWS Environment	IAM Role	Access	MFA	Production	Review
Developer	Development	DeveloperRole	Read/Write	Required	No	Quarterly
Developer	Production	ProductionReadOnly	Read	Required	Limited	Quarterly
DevOps	Development	DevOpsRole	Admin	Required	No	Quarterly
DevOps	Production	ProductionAdmin	Admin	Required	Yes	Monthly/Quarterly
Security	Production	SecurityAuditRole	Security Read	Required	Yes	Quarterly
Security	Production	SecurityAdmin	Security Admin	Required	Yes	Monthly/Quarterly
Support	Production	SupportReadOnly	Limited Read	Required	Limited	Quarterly
External Auditor	Audit Account/Repository	AuditorRole	Read Only	Required	No	Per Engagement

The exact permissions should be defined using the organization’s AWS IAM roles and security architecture.

---

8. Application Access Matrix

For each application, define the available roles.

Example: Customer Support Platform

Role	View Tickets	Create Ticket	Update Ticket	Export Data	Delete Ticket	Admin
Support Agent	✓	✓	✓	Restricted	No	No
Support Manager	✓	✓	✓	✓	Restricted	No
Security	✓	No	No	Restricted	No	No
IT Admin	As Required	As Required	As Required	Restricted	Restricted	✓
HR	No	No	No	No	No	No

This level of detail helps prevent broad or unnecessary permissions.

---

9. Database Access Matrix

Database access should be separately controlled because databases may contain sensitive or customer information.

Role	Database	Environment	Access	Data	Direct Query	Write	Admin
Developer	Customer DB	Development	Read/Write	Test Data	Yes	Yes	No
Developer	Customer DB	Production	Read Limited	Customer Data	Restricted	No	No
DBA	Customer DB	Production	Admin	Customer Data	Yes	Yes	Yes
Security	Customer DB	Production	Audit/Read	Security Data	Limited	No	No
Support	Customer DB	Production	Application-mediated	Customer Data	No	No	No

Production database access should be more restrictive than development access.

---

10. Source Code Access Matrix

Role	Repository	View	Commit	Merge	Branch Admin	Repository Admin
Developer	Assigned Project	✓	✓	Controlled	No	No
Engineering Lead	Assigned Project	✓	✓	✓	Limited	No
CTO	All Projects	✓	✓	✓	✓	Limited
Security	Required Projects	✓	No	No	No	No
External Consultant	Approved Project	✓	As Approved	No	No	No

Branch protection and code-review requirements should be implemented where appropriate.

---

11. Privileged Access Matrix

Maintain a separate view for high-risk access.

Role	Privileged System	Privilege	Business Need	MFA	Logging	Review
CTO	AWS	Administrator	Cloud administration	Required	Required	Periodic
Security Lead	Security Platform	Administrator	Security operations	Required	Required	Periodic
IT Admin	Identity Platform	Administrator	Identity management	Required	Required	Periodic
DBA	Production DB	Administrator	Database administration	Required	Required	Periodic
DevOps	Production Infrastructure	Administrator	Deployment/operations	Required	Required	Periodic

Privileged access should be limited to named individuals and should not normally be provided through shared administrator accounts.

---

12. Temporary Access Matrix

Temporary access should include an expiry date.

User	System	Access	Purpose	Start	End	Approver	Status
External Auditor	Audit Repository	Read	SOC 2 Audit	01-Oct	15-Oct	Security Lead	Active
Consultant	AWS	Read Only	VAPT	05-Oct	12-Oct	CTO	Active
Developer	Production Logs	Read	Incident Investigation	10-Oct	11-Oct	Security Lead	Closed

Temporary access should be removed when the defined period ends.

---

13. Third-Party Access Matrix

Third Party	System	Access	Data	Purpose	Start	Expiry	Owner
Security Consultant	VAPT Platform	Testing	Technical	Security Assessment	Date	Date	Security
External Auditor	Audit Repository	Read	Audit Evidence	Certification Audit	Date	Date	ISMS
Cloud Consultant	AWS	Limited Admin	Technical	Cloud Project	Date	Date	CTO

Third-party access should use individual named accounts wherever practical.

---

14. Segregation of Duties

The Access Control Matrix should identify conflicting combinations.

Example

Activity	Role A	Role B	Same Person Allowed?
Create Supplier	Procurement	—	Yes
Approve Supplier	Procurement Manager	—	Controlled
Create Payment	Finance	—	Yes
Approve Payment	Finance Manager	—	Controlled
Deploy Code	Developer	—	Yes
Approve Production Release	Engineering Lead	—	Controlled
Perform Internal Audit	Internal Auditor	—	Independent

The matrix should be reviewed against the organization’s Segregation of Duties Policy.

---

15. Joiner Access

When a new employee joins:

Role Identified → Standard Role Access → Manager Approval → Provision → Verify → Record

Use role-based access rather than manually assigning unrelated permissions.

Example

A new customer support employee receives the approved Support Agent access package.

---

16. Mover Access

When an employee changes role:

New Role → Compare Existing Access → Remove Unnecessary Access → Add New Access → Verify

Example

An employee moves:

Engineering → Customer Support

Remove:

• Source-code write access
• AWS development access
• CI/CD access
• Engineering SaaS tools

Add:

• Customer support platform
• Approved CRM access
• Support collaboration tools

---

17. Leaver Access

When employment or engagement ends:

Identify Access → Revoke → Verify → Record

Review:

• Email
• SSO
• VPN
• SaaS
• AWS/cloud
• Source code
• Databases
• Security systems
• API keys
• SSH keys
• Tokens
• Physical access

---

18. Access Review

The matrix should be compared with actual system permissions during periodic access reviews.

Review Process

Access Matrix

↓

Actual User Access

↓

Compare

↓

Identify Excess/Incorrect Access

↓

Owner Review

↓

Remove/Modify

↓

Verify

↓

Record Evidence

---

19. Access Review Record

User	Role	System	Matrix Access	Actual Access	Difference	Action	Owner	Date	Status
User A	Developer	AWS	Read	Admin	Excess	Remove Admin	CTO	Date	Closed
User B	Support	CRM	Read/Write	Read/Write	None	None	Support	Date	Confirmed
User C	Former Contractor	GitHub	No Access	Read	Excess	Revoke	Engineering	Date	Closed

This provides useful evidence that the matrix is actually being used rather than being a static document.

---

20. Access Exceptions

If a user requires access outside the standard matrix:

Exception ID	User	System	Requested Access	Reason	Risk	Compensating Control	Approver	Expiry	Status
EX-001	Developer	Production DB	Temporary Read	Incident investigation	Medium	MFA + logging	CTO/Security	Date	Closed

Exceptions should be:

• Business justified
• Risk assessed
• Approved
• Time-bound where practical
• Reviewed
• Removed when no longer required

---

21. Access Matrix Maintenance

The matrix should be updated when there are changes to:

• Organizational roles
• Applications
• Cloud environments
• Business processes
• Information classification
• Security risks
• Regulatory requirements
• Customer requirements
• Access models
• System functionality

Update Flow

Change Identified → Impact Assessment → Update Matrix → Owner Approval → Implement → Verify → Record

---

22. Access Matrix Ownership

Responsibility	Role
Overall Access Model	Security/ISMS
Business Role Definition	Business Owner
Application Permissions	Application/System Owner
Cloud Permissions	Cloud/IT Owner
User Provisioning	IT/System Administrator
Access Approval	Manager/System Owner
Privileged Access	System Owner/Security
Periodic Review	System/Data Owner
Matrix Maintenance	Security/ISMS + System Owners
Independent Verification	Internal Audit

The exact allocation should reflect the organization’s structure.

---

23. Access Control Matrix – Master Template

Use this as the organization’s master matrix.

ID	Role	User/Group	System	Environment	Resource	Access Level	Data Classification	Privileged	Business Purpose	Approval Authority	MFA	Logging	Start Date	Expiry	Review Frequency	Status
ACM-001
ACM-002
ACM-003

---

24. Audit Evidence

An auditor may request:

• Approved Access Control Matrix
• User Access Requests
• Access approvals
• IAM configuration
• Application role configuration
• Privileged access list
• Access review records
• User provisioning evidence
• Access revocation evidence
• Temporary access records
• Third-party access records
• Exceptions
• SoD reviews
• AWS IAM evidence
• SSO/MFA evidence
• Access logs
• Corrective actions

Audit Trail

The organization should be able to demonstrate:

Role → Access Requirement → Request → Approval → Provisioning → Actual Access → Review → Revocation

---

25. Common Mistakes

❌ Matrix exists but actual permissions are different

The matrix must reflect the intended access model and be reconciled with actual permissions.

❌ Everyone receives administrator access

This violates the principle of least privilege.

❌ Temporary access has no expiry

Temporary access should have a defined end date where practical.

❌ Old access remains after role changes

Mover processes must remove unnecessary access.

❌ Shared accounts

Individual accountability should be maintained.

❌ No distinction between production and development

Production access normally requires greater control.

❌ Matrix never gets reviewed

The matrix should change as the organization, systems, roles, and risks change.

---

26. Startup-Friendly Implementation

A startup does not need hundreds of complex access rules on day one.

Start with:

Tier 1 – Critical Systems

• AWS production
• Source-code repository
• Identity provider
• Customer database
• Security platforms
• Backup systems

Tier 2 – Business Systems

• CRM
• HR
• Finance
• Customer support
• Collaboration
• Procurement

Tier 3 – Standard Applications

• General SaaS tools
• Internal applications
• Low-risk business tools

Define standard roles first, then add exceptions only where required.

---

27. Relationship with Other ISMS Documents

The Access Control Matrix connects:

Information & Asset Inventory

↓

Asset Ownership

↓

Information Classification

↓

Risk Assessment

↓

Access Control Matrix

↓

User Access Request

↓

Access Provisioning

↓

Access Review

↓

Access Revocation

↓

Audit Evidence

It also connects with:

• Access Control Policy
• Privileged Access Management
• Segregation of Duties Policy
• Employee Offboarding Checklist
• Contractor Offboarding Checklist
• Cloud Asset Inventory
• SaaS Application Register
• Data Inventory
• Information Classification Policy
• Incident Management Procedure
• Risk Register

---

28. ISO 27001 Connection

The Access Control Matrix supports the organization’s implementation of applicable information security controls relating to:

• Identity management
• Authentication
• Access rights
• Privileged access
• Information access restriction
• Segregation of duties
• User access lifecycle
• Secure access to systems and applications

The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA).

---

29. Final Audit Trail

A well-maintained Access Control Matrix should answer:

Who can access what?

Why do they need it?

What level of access do they have?

Who approved it?

Is the access still required?

Does actual access match approved access?

When should it be removed?

Final Principle

Define access by role, grant only what is required, approve sensitive access, verify actual permissions, review regularly, and remove access when the business need ends.