ISO 27001 A.5.18: granting and removing access, explained for startups

A.5.18 Access rights

Access is reviewed regularly and removed when it is no longer needed. What proves it: a recent access review of your key systems, with the changes it produced.

A certification auditor samples access reviews and joiner, mover and leaver records. A file that usually does the job: a quarterly access review listing each account, the reviewer's decision and the removals made.

How to put it in place

Each step leaves a record, and the record is what the auditor samples rather than the step itself. Inside Polara, the control card for A.5.18 walks you through it in this order.

1. Export the user lists from your key systems.
2. Have each system owner confirm or remove every account.
3. Sign and date the review and repeat it every quarter.

The free ISO 27001 readiness assessment asks 3 questions that evidence it:

• How is access to company systems granted?
• How often do you review who has access to your systems, including admin access?
• When someone leaves, how quickly is their access removed?

Policies, connectors and the SOC 2 overlap

In the ISO 27001 policy pack, the Access Control Policy covers A.5.18. An auditor reads the policy for the rule, then samples the records to see the rule was followed.

Connected systems that pull evidence for it:

• Amazon Web Services, IAM users: who has access, with each user's multi-factor authentication status and last login.
• Amazon Web Services, IAM groups: groups and their member assignments.
• GitHub, Organization members: all members of the organization with their access type.
• GitHub, Repository collaborators: per-repository collaborator access, including outside collaborators.
• Google Cloud, IAM members: project-level IAM policy bindings, showing which roles are granted to which members.
• Google Workspace, Directory users: all users in the Workspace domain with admin, suspended and 2-Step Verification enrollment status.
• Okta, Users and last sign-in: Okta users with their status and last sign-in time.
• Okta, Deprovisioned users: users deprovisioned in the collection window, with the date their status changed.
• Microsoft Entra ID, Users and last sign-in: directory users with their enabled status, user type and last sign-in.
• Linear, Workspace members: Workspace members with their active, admin and guest status.
• Jira, Site users: users on the Jira site with their active status and account type.
• Slack, Workspace members: Workspace members, admins, guests and deactivated accounts.

The same evidence counts toward SOC 2. The Trust Services criteria that cover this ground: CC6.2, user provisioning and CC6.3, least privilege.

Organizational controls

A.5.18 is one of the 37 organizational controls in Annex A. How the company runs security: policies, roles, suppliers, incidents, continuity and legal duties. Most of these are written decisions and the records that show you follow them.

Nearby controls in the same theme:

• A.5.15, access control rules
• A.5.16, identities and accounts
• A.5.17, passwords and secrets
• A.5.19, supplier security
• A.5.20, security in supplier contracts
• A.5.21, technology supply chain

Before it: A.5.17, passwords and secrets. After it: A.5.19, supplier security. Every control, by theme, is on the Annex A controls page.