ISMS Access Control Policy
1. Purpose, Scope and Audience
1.1. Purpose
This policy ensures that the right people have access to the right information and resources at the right time.
1.2. Scope
This policy applies to:
All employees and third-party users
All systems and applications covered by the ISO 27001 Information Security Management System (ISMS)
| Physical access to buildings and facilities is governed by the Physical and Environmental Policy. |
2. Principles of Access Control
2.1. Need-to-Know and Least Privilege
Access is granted only when it is necessary for a person’s job. Users receive access only to the information and systems they need to perform their specific tasks and roles. Nothing more.
2.2. Role-Based Access
Access to systems is managed through roles. Each role has specific permissions that match the user’s job function. The right to grant roles is held by:
The Business Owner
The System Owner
The Data Owner
They must formally approve each access request before it is granted.
| The current list of roles and their permissions is not listed in this policy. Instead, it is documented in a separate Access Matrix that is kept up to date regularly. See Section 5 for details. |
3. Processes
3.1. Creating and Removing User Accounts
Every new user must go through a documented onboarding process. Every departing user must go through a documented offboarding process.
What happens:
Accounts are created when users join
Accounts are deactivated when users leave
The timing must be as close as possible to the start or end date
All actions are recorded and documented
| The technical details (which systems, which tools, how they are connected) are described in separate work instructions, not in this policy. |
3.2. Granting Access Rights
All access requests go through a formal approval process:
A request is submitted (by the user, manager, or system administrator)
The appropriate owner (Business Owner, System Owner, or Data Owner) reviews it
The owner approves or rejects the request
If approved, Corporate IT implements the access
The approval and implementation are documented
No access is granted without this formal process.
3.3. Managing Special Rights
Sometimes a person needs access beyond their normal role. Examples include:
Administrative access to a system
Temporary elevated permissions
Access to systems outside their normal department
These are called "Special Rights". Rules for Special Rights:
A business need must be documented and justified
Risk must be assessed (how sensitive is the data? How much damage could a misuse cause?)
The CISO (Information Security Officer) must formally approve it
The CISO must document who approved it, when, and why
The access is limited to the minimum time needed
3.4. Audit Trail for Access Changes
Every change to access rights must be documented and traceable:
Who requested the access?
Who approved it?
When was it approved?
What exactly was changed?
When did the change take effect?
This documentation must be kept for audit purposes.
| The specific tool used to track this (for example, a ticketing system) is described in a separate work instruction. |
3.5. Regular Review of Access Rights
At least once per year, the owners of systems and data must review who has access and why:
The owner looks at all active accounts and their permissions
The owner checks: Is this person still in this role? Do they still need this access?
If access is no longer needed, it is removed immediately
The review is documented
This prevents "access creep" - where people accumulate permissions over time that they no longer need.
3.6. Passwords and Authentication
The requirements for passwords and multi-factor authentication are described in the separate Password Policy. This includes:
Password complexity rules
Password change frequency
Multi-factor authentication where required
4. Responsibilities
4.1. CISO (Information Security Officer)
Approves all Special Rights
Documents approval of Special Rights
Oversees compliance with this policy
Ensures access reviews are performed
4.2. Corporate IT
Implements access requests that have been approved
Implements access changes that have been approved
Removes access when requested or when offboarding
Maintains the technical systems that enforce access control
Works with owners to perform access reviews
4.3. Business Owner, System Owner, Data Owner
Approves or rejects access requests for their area
Reviews access rights regularly (at least once per year)
Removes access that is no longer needed
Informs Corporate IT when access should be changed or removed
4.4. Risk Owner
The Risk Owner is responsible for assessing and accepting the risk associated with granting access rights. For normal, day-to-day access requests, the System Owner or Business Owner can approve.
For Special Rights or access to sensitive systems/data, the Risk Owner (typically the CISO) must also approve, based on a risk assessment.
| This section describes roles and responsibilities. The specific job titles or organizational structure are not listed here. The actual mapping of people to these responsibilities is documented elsewhere in the organization. |
5. Related Documents and References
5.1. Access Matrix
The Access Matrix contains the current, official list of:
All technical roles and groups
What permissions each role has
Who can request access to each role
Who must approve access to each role
The Access Matrix is kept up to date by Corporate IT and the CISO. It is reviewed and updated whenever systems change, but it does NOT require approval from the formal policy review board. This keeps it current and prevents it from becoming outdated.
| The Access Matrix is the living, operational document. This policy contains only the principles. The two must be aligned. |
6. Policy Compliance
6.1. Compliance Measurement
Access reviews are performed at least once per year
All access grants are documented and traceable
All Special Rights are documented
Audit trails show all changes to access
6.2. Exceptions
Exceptions to this policy require written approval from the CISO and the relevant System Owner. All exceptions are documented with a business justification and an expiration date.
7. Document Information
Approval date | 2026-08-31 with vshnwiki.atlassian.net/wiki/x/EwBBMw |
Owner | CISO |
Last Review | 2026-08-31 |