1. Purpose
The purpose of this Access Control Policy is to ensure that access to information, applications, systems, networks, and technology resources is authorized, appropriate, controlled, and regularly reviewed.
The organization shall provide users with only the access required to perform their assigned responsibilities and shall protect accounts and authentication information from unauthorized use.
This policy supports the organization’s Information Security Management System (ISMS) and is intended to reduce risks associated with unauthorized access, privilege misuse, credential compromise, and inappropriate access to information.
2. Scope
This policy applies to:
- Employees
- Contractors
- Temporary workers
- Consultants
- Administrators
- Third-party users
- Applications and systems
- Cloud infrastructure
- Corporate devices
- Networks
- Databases
- Source-code repositories
- SaaS applications
- Business and customer information
It applies to both logical and, where relevant, physical access to organizational resources.
3. Access Control Principles
The organization shall manage access based on the following principles.
3.1 Least Privilege
Users shall receive only the access necessary to perform their authorized responsibilities.
For example, a software developer who does not require production administration should not have unrestricted production administrator privileges.
3.2 Need to Know
Access to sensitive information shall be provided only where there is a legitimate business requirement.
3.3 Role-Based Access
Where practical, access shall be assigned according to defined job roles and responsibilities.
3.4 Separation of Duties
Conflicting responsibilities shall be separated where required to reduce the risk of unauthorized activity or fraud.
For example, where practical:
The person requesting a high-risk access change should not be the sole person approving that change.
3.5 Individual Accountability
Users should have individually identifiable accounts wherever practical.
Shared accounts should be avoided unless there is a documented business or technical requirement and appropriate compensating controls are implemented.
4. User Access Management
User access shall follow a controlled lifecycle:
Request → Approval → Provisioning → Use → Review → Modification → Removal
Access shall be granted based on:
- Job responsibilities
- Business requirements
- System sensitivity
- Risk
- Management approval
- Applicable contractual or regulatory requirements
Access requests should identify:
- User
- System/application
- Requested access
- Business justification
- Approver
- Access level
- Date granted
- Review requirements
5. User Provisioning
Before granting access to a system or application, the organization shall determine:
- Whether the user requires access.
- What level of access is required.
- Who is authorized to approve the access.
- Whether additional security requirements apply.
- Whether the access should expire automatically.
Access should be provisioned using approved organizational procedures and technology wherever practical.
Example
For a SaaS startup:
New developer → HR confirms employment → Manager requests access → System owner approves → IT provisions GitHub/AWS/Jira access → Evidence retained
6. Privileged Access
Privileged access shall receive additional controls because compromise of privileged accounts can have a significant impact on the organization.
Examples include:
- AWS Administrator
- Cloud infrastructure administrator
- Database administrator
- Domain administrator
- Security administrator
- Production deployment administrator
Privileged access should:
- Be limited to authorized personnel
- Require appropriate approval
- Use strong authentication
- Use MFA where supported
- Be separately identifiable
- Be reviewed periodically
- Be logged and monitored where practical
Where practical, administrative accounts should be separate from normal user accounts.
For example:
Normal account: user@company.com
Administrative account: admin-user@company.com
This reduces the likelihood that compromise of a normal account automatically provides privileged access.
7. Authentication Requirements
Authentication mechanisms shall be appropriate to the sensitivity and risk of the system.
Where supported and appropriate, the organization should use:
- Multi-factor authentication (MFA)
- Strong passwords/passphrases
- Single sign-on (SSO)
- Centralized identity management
- Password managers
- Hardware security keys for high-risk accounts
MFA should be prioritized for:
- Privileged accounts
- Cloud administration
- Corporate identity systems
- Production environments
- Remote access
- Systems containing sensitive information
Authentication credentials shall not be shared with other users.
8. Password Management
Where passwords are used, users shall:
- Use strong and unique passwords
- Avoid reusing corporate passwords across unrelated services
- Not share passwords
- Not store passwords insecurely
- Use an approved password manager where provided
- Report suspected credential compromise
The organization should use technical controls such as password policies and centralized identity management where appropriate.
Passwords should not be stored in source code, configuration files, tickets, spreadsheets, or other locations where unauthorized users could obtain them.
9. Access to Production Systems
Production access shall be restricted to authorized personnel with a legitimate business requirement.
Production access should be:
- Approved
- Limited
- Individually attributable
- Protected by strong authentication
- Logged where practical
- Periodically reviewed
Developers should not automatically receive unrestricted production access simply because they require access to development environments.
Where practical, production access should be granted through controlled roles or temporary access mechanisms.
10. Access Reviews
User access shall be reviewed periodically based on the organization’s risk and defined review frequency.
Higher-risk access should generally be reviewed more frequently.
The review should consider:
- Current employment status
- Current job responsibilities
- Required access
- Privileged access
- Inactive accounts
- Excessive permissions
- Conflicting access
- Third-party access
Example
A quarterly privileged-access review may include:
| User | System | Role | Business Need | Approved | Action |
|---|---|---|---|---|---|
| User A | AWS | Admin | Yes | CTO | Retain |
| User B | GitHub | Maintainer | Yes | Eng. Lead | Retain |
| User C | AWS | Admin | No | CTO | Remove |
Evidence of completed reviews shall be retained.
11. Joiner, Mover and Leaver Process
Access shall be managed throughout the employee lifecycle.
Joiner
When a new employee joins:
HR notification → Manager approval → Required systems identified → Access provisioned → MFA enabled → Security awareness
Mover
When an employee changes role:
Role change → Existing access reviewed → Unnecessary access removed → New access approved → Updated access provisioned
Leaver
When an employee leaves:
Termination notification → Access identified → Access disabled/removed → Credentials/tokens revoked → Assets recovered → Evidence retained
Access removal should be performed within a timeframe appropriate to the organization’s risk and employment termination circumstances.
For involuntary or high-risk terminations, access may need to be disabled immediately.
12. Third-Party Access
Third-party users shall receive access only when there is a legitimate business requirement.
Third-party access should:
- Be approved
- Be limited to required resources
- Be individually identifiable where practical
- Use appropriate authentication
- Have defined validity periods where appropriate
- Be reviewed
- Be removed when no longer required
Vendor accounts should not remain active indefinitely simply because a supplier may need access again in the future.
13. Application and System Access
Application owners shall define appropriate access levels for their systems.
Typical access levels may include:
- Viewer
- User
- Contributor
- Manager
- Administrator
Access should correspond to job responsibilities.
For example:
A customer-support employee may need to view customer records but may not require permission to modify system configuration.
14. Cloud Access Control
For cloud environments such as AWS, Azure, or Google Cloud, access shall be managed using appropriate identity and access management mechanisms.
Controls may include:
- Individual accounts
- IAM roles
- MFA
- Least privilege
- Separate administrative roles
- Restricted production access
- Logging
- Access reviews
- Temporary credentials
- Service accounts
- Key rotation where appropriate
Long-lived access keys should be avoided where a more secure authentication mechanism is available.
15. Service Accounts and API Credentials
Service accounts, API keys, tokens, and machine identities shall be managed securely.
The organization should:
- Assign ownership
- Restrict permissions
- Store secrets securely
- Avoid hard-coding credentials
- Rotate credentials where appropriate
- Revoke unused credentials
- Monitor privileged service accounts
Secrets should not be committed to public or private source-code repositories.
16. Remote Access
Remote access to organizational systems shall use approved mechanisms and appropriate security controls.
Depending on the risk, controls may include:
- MFA
- Device security
- VPN
- SSO
- Conditional access
- Endpoint protection
- Session monitoring
- Restricted administrative access
Remote administrative access to critical systems should receive additional protection.
17. Physical Access
Where physical access is relevant to the ISMS, access to offices, server rooms, data centers, and other restricted areas shall be controlled based on business requirements.
Controls may include:
- Access cards
- Locks
- Visitor controls
- Security guards
- CCTV
- Visitor logs
- Restricted-area authorization
Cloud-hosted infrastructure may reduce the organization’s direct physical access responsibilities, but relevant cloud-provider and data-center controls should still be considered.
18. Access Logging and Monitoring
Access to critical systems should be logged and monitored based on risk.
Logs may include:
- Successful authentication
- Failed authentication
- Privileged activity
- Account creation
- Account modification
- Account deletion
- Permission changes
- Administrative actions
Examples of evidence for an AWS-based environment include:
- AWS CloudTrail
- IAM activity
- Identity-provider logs
- Security monitoring alerts
Logs should be protected against unauthorized alteration and retained according to organizational and legal requirements.
19. Inactive Accounts
Inactive or unnecessary accounts shall be identified and disabled or removed within an appropriate timeframe.
Examples include:
- Former employees
- Former contractors
- Dormant vendor accounts
- Test accounts
- Unused administrative accounts
- Temporary project accounts
Periodic account reviews should help identify such accounts.
20. Access Exceptions
Any exception to this policy shall:
- Have a documented business justification.
- Be assessed for information security risk.
- Be approved by an authorized person.
- Include compensating controls where appropriate.
- Have an expiry or review date where practical.
Exceptions should not become permanent alternatives to implementing appropriate controls.
21. Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Provide direction and resources |
| ISMS/Security Manager | Maintain access-control requirements and monitor compliance |
| IT/Cloud Team | Provision, modify, review, and remove technical access |
| System Owner | Approve and review access to owned systems |
| HR | Notify relevant teams of joiners, movers, and leavers |
| Managers | Confirm business need for employee access |
| Employees | Protect credentials and use access appropriately |
| Contractors/Suppliers | Follow access requirements and contractual obligations |
| Internal Auditor | Independently assess whether access controls are implemented and effective |
22. Evidence and Records
The following may be used as evidence of access-control operation:
- Access requests
- Approval records
- IAM configurations
- MFA configuration
- User-access lists
- Privileged-access lists
- Access-review records
- Joiner/mover/leaver records
- Termination tickets
- SSO reports
- Cloud audit logs
- Authentication logs
- Privileged activity logs
- Access exception records
- Service-account inventory
- API-key/credential reviews
The organization should retain evidence according to its documented retention requirements.
23. Example: AWS SaaS Startup
Consider a 30-person SaaS company operating on AWS.
A practical access model could be:
| Role | AWS Access |
|---|---|
| CTO | Controlled administrative access |
| Cloud Engineer | Infrastructure administration |
| Developer | Development + limited production access |
| Security Lead | Security monitoring/audit access |
| Support | No AWS administrative access |
| HR | No production access |
| External Consultant | Temporary, approved access |
The organization could implement:
SSO + MFA → Role-Based Access → Least Privilege → Privileged Access Review → CloudTrail Logging → Periodic Review
This provides a practical control environment without creating unnecessary manual administration.
24. Access Control: Policy vs Evidence
A policy states what the organization requires.
The actual system configuration and operational records demonstrate whether the requirement is being followed.
For example:
Policy requirement
Privileged access must be restricted to authorized personnel.
Implementation
AWS IAM roles and identity-provider groups restrict privileged permissions.
Evidence
- IAM role configuration
- User/role membership
- Approval records
- MFA status
- Quarterly access review
- CloudTrail activity
This distinction is important during an ISO 27001 audit.
25. ISO 27001 Connection
Access control is supported by multiple areas of ISO/IEC 27001:2022, including controls relating to:
- Access control
- Identity management
- Authentication information
- Access rights
- Privileged access
- Information access restriction
- Secure authentication
- Source-code access
- User endpoint security
- Logging and monitoring
The exact controls applicable to an organization should be determined through its risk assessment and Statement of Applicability, rather than treating Annex A as a universal checklist.
26. Policy Review
This policy shall be reviewed periodically and whenever significant changes occur, including:
- Major technology changes
- New cloud platforms
- Organizational restructuring
- New regulatory requirements
- Significant security incidents
- Changes to the ISMS scope
- Changes to access architecture
The review should confirm that the policy remains appropriate to the organization’s business and security risks.
Quick Startup Checklist
Before considering access control operational, ask:
- Does every user have an identifiable account?
- Is access based on business need?
- Is least privilege implemented?
- Is MFA enabled for important systems?
- Is privileged access restricted?
- Are production permissions controlled?
- Are joiner/mover/leaver processes defined?
- Are former employees’ accounts removed promptly?
- Are third-party accounts controlled?
- Are service accounts identified and managed?
- Are access rights reviewed periodically?
- Are important access activities logged?
- Are exceptions documented and approved?
- Can the organization demonstrate evidence of these controls?
Final Principle
An effective ISO 27001 Access Control Policy should not simply state:
“Access shall be controlled.”
It should establish a practical lifecycle:
Request → Approve → Provision → Authenticate → Use → Monitor → Review → Modify → Remove
The objective is to ensure that the right person has the right access, to the right resource, for the right reason, for the right amount of time.