ISO 27001 and SOC 2 Access Control Requirements: A Practical Guide
Access control is the largest single block of requirements in both ISO 27001 and SOC 2, and it is where most findings land. Not because it is hard, but because it drifts. People join, change roles and leave. Contractors get accounts for a project and keep them for two years. A developer gets production access to debug something urgent in March and still has it in November.
Both frameworks are, underneath the terminology, asking one question: can you demonstrate that the right people have the right access, and that you would know if that stopped being true?
What ISO 27001 requires
ISO 27001:2022 spreads access control across both the organisational and technological control sets in Annex A:
- A.5.15 Access control. Rules for physical and logical access are established and implemented based on business and information security requirements.
- A.5.16 Identity management. The full lifecycle of identities is managed.
- A.5.17 Authentication information. Allocation and management of secrets is controlled, and users are made aware of their obligations.
- A.5.18 Access rights. Access is provisioned, reviewed, modified and removed in line with the access control policy.
- A.8.2 Privileged access rights. Allocation and use of privileged access is restricted and managed.
- A.8.3 Information access restriction. Access to information and application functions is restricted per the policy.
- A.8.5 Secure authentication. Secure authentication technologies and procedures are implemented based on access restrictions.
- A.6.1 Screening and A.6.5 Responsibilities after termination sit alongside these on the people side.
A.5.18 is the one that generates findings, because it contains the word reviewed. Provisioning is easy to evidence because it leaves a ticket. Removal is harder. Periodic review is the control that catches the things removal missed, and it is frequently either not performed or performed without a record.
A.8.2 is the second. Privileged access needs to be restricted, time-bound where practical, and separately accountable. Shared administrator credentials fail this control outright, and they are still common.
What SOC 2 requires
In SOC 2 this lives almost entirely in the CC6 series:
- CC6.1. Logical access security software, infrastructure and architectures are implemented over protected information assets.
- CC6.2. Prior to issuing credentials, users are registered and authorised. Credentials are removed when access is no longer required.
- CC6.3. Access is authorised, modified and removed based on roles, responsibilities and the concept of least privilege.
- CC6.6. Logical access controls address threats from outside the system boundary.
- CC6.7. Transmission, movement and removal of information is restricted to authorised users.
- CC6.8. Controls prevent or detect unauthorised or malicious software.
CC6.2 and CC6.3 are the joiner, mover and leaver criteria. A Type 2 auditor will typically pull a sample of people who joined, changed roles and left during the observation window and trace each one. For leavers they will compare the termination date to the access removal date. A gap of days is a finding. A gap of weeks is a problem.
The overlap, and what to build once
| What you build | ISO 27001 | SOC 2 |
|---|---|---|
| Access control policy with defined roles | A.5.15, A.8.3 | CC6.1, CC6.3 |
| Documented joiner, mover, leaver process | A.5.16, A.5.18, A.6.5 | CC6.2, CC6.3 |
| MFA across all access paths | A.8.5 | CC6.1, CC6.6 |
| Privileged access restriction and logging | A.8.2 | CC6.1, CC6.3 |
| Periodic user access review | A.5.18 | CC6.2, CC6.3 |
| Credential and secret management | A.5.17 | CC6.1 |
Build these six things properly and you have covered the access control requirements of both frameworks with one set of evidence.
What good looks like at small-business scale
You do not need an enterprise identity governance platform to pass either audit. You need a single source of identity, enforced MFA, a repeatable process, and records.
Consolidate identity. If your people sign in to twelve services with twelve separate accounts, you cannot evidence lifecycle management, because there is no lifecycle to manage. Pointing your SaaS applications at one identity provider, usually Microsoft Entra ID or Okta or Google Workspace, turns twelve problems into one. Offboarding becomes one action instead of twelve, which is the real reason to do it.
Enforce MFA with no exceptions you cannot justify. Both frameworks will accept phishing-resistant methods as better, and so should you. The exception list is what auditors look at. Service accounts that cannot do MFA need a compensating control written down, not silence.
Separate privileged access from daily access. Administrators get a normal account for email and a separate account for administration. Where your platform supports just-in-time elevation, such as Entra privileged identity management, use it. It converts standing privilege into a logged, time-bound request, which is both better security and better evidence.
Manage secrets somewhere other than a spreadsheet. A password manager with shared vaults, or a secrets manager for machine credentials. A.5.17 and CC6.1 are both satisfied by this and both embarrassed by its absence.
Run access reviews quarterly and keep the output. Export the user list per system, have the relevant manager confirm or reject each entry, action the rejections, and keep the signed-off list. This is twenty minutes per system per quarter and it is one of the highest-value compliance activities there is, because it finds the access nobody remembered to remove.
Platforms we commonly see in Australian mid-market environments include Microsoft Entra ID, Okta, JumpCloud and Google Workspace for identity, and CyberArk, BeyondTrust or Entra privileged identity management where privileged access needs its own layer. The choice matters much less than whether the process around it is actually run.
What auditors ask to see
- The access control policy, and evidence that the roles in it match the roles in your systems.
- A joiner sample. Request, approval, and provisioning record for a selection of recent starters.
- A leaver sample. Termination date against access removal date, across every in-scope system, not just email.
- A mover sample. Evidence that access was removed when someone changed roles, not only added. This is the one most organisations fail, because adding is remembered and subtracting is not.
- MFA coverage, as a report from the identity provider rather than an assertion, plus the exception list and its justification.
- The privileged user list, with a reason for each entry.
- The last two or three access reviews, with evidence of what changed as a result. A review that never results in a removal looks like a review that was not really performed.
- Password and authentication configuration as shown in the tool.
The failure modes we see most
Offboarding that covers email and nothing else. The person is out of Microsoft 365 the same day and still in the AWS console, the CI system, the CRM and the production database three months later. A written list of every system to deprovision, maintained as part of the onboarding checklist, fixes this.
Role change without removal. Someone moves from support to sales and accumulates both sets of access. Over a few years this produces a handful of people who can do almost anything, which is exactly what least privilege is meant to prevent.
Shared accounts. Usually a legacy admin login or a shared service account that four people use. It breaks accountability, so it breaks the control. Where a shared credential genuinely cannot be eliminated, vault it, log retrieval, and document the compensating control.
Standing production access for developers. Common and understandable, and still a finding. Just-in-time elevation with an approval record is the answer that satisfies both the auditor and the on-call engineer.
Access reviews performed by the wrong person. IT confirming that IT granted the access is not a review. The person who owns the data or the system needs to be the one confirming the list.
Contractors and service accounts with no expiry. Set an end date at creation. Both frameworks care about the lifecycle, and a lifecycle with no end is not one.
Australian considerations
The ASD Essential Eight overlaps heavily here. Restricting administrative privileges and implementing multi-factor authentication are two of the eight mitigation strategies, so work done for ISO 27001 or SOC 2 access control usually advances your Essential Eight maturity at the same time. If you report against both, map them once rather than maintaining two stories.
Under the Notifiable Data Breaches scheme, unauthorised access to personal information can be an eligible data breach in its own right, without any data leaving your environment. Stale access is therefore not only a control weakness, it is latent notification exposure.
APRA-regulated entities should read CPS 234’s requirements on information asset access alongside the above rather than instead of it.
Where to start
If you are early in a certification project, access control is the right place to begin, because it produces the most evidence per hour of effort and because the drift it corrects is usually real security risk rather than paperwork. Consolidate identity, enforce MFA, write the joiner, mover and leaver process, then run one full access review and keep every artefact from it.
Our CERTIFY compliance package includes the access control design, the joiner, mover and leaver documentation and the evidence set for ISO 27001 and SOC 2. If you want to know whether the controls you already have would hold up, get in touch and we will tell you straight.
Siege Cyber’s CERTIFY packages take Australian businesses from gap analysis to certification with a fixed scope and a fixed price, for both ISO 27001 and SOC 2. Get a Fixed-Price Quote.