SOC 2 Access Control Requirements Explained (With Practical Examples)
SOC 2 access control requirements sit at the centre of almost every compliance audit. If your organisation handles customer data in the cloud, who can access that data, how they get in, what they are allowed to do, and how quickly their access is removed when they leave, are the questions your auditor will ask first. Getting access control right is not optional for SOC 2 readiness. It is foundational.
For Australian SaaS companies, technology businesses, and cloud service providers pursuing SOC 2 compliance in Australia, access control is typically where audit preparation begins and where the most common findings occur. Over-privileged administrators, missing access reviews, and no formal process for removing leavers are the three issues CyberSapiens sees most often during readiness assessments.
This guide breaks down what SOC 2 means by access control, walks through the key criteria your environment must satisfy, and shows you exactly how those controls work in real tools like Okta, Azure AD, AWS IAM, and Google Workspace. Whether you are preparing for SOC 2 Type 1 or working through a Type 2 observation period, this is the practical reference your security and compliance team needs.
What this guide covers
- SOC 2 access control in plain language
- CC6.x criteria: what each area requires
- Practical examples: Okta, Azure AD, AWS IAM, Google Workspace
- Joiner-Mover-Leaver (JML) lifecycle for SOC 2
- What auditors look for and what evidence to prepare
- Common access control mistakes and how to fix them
Who should read this
- IT managers and security leads planning SOC 2
- GRC and compliance managers preparing audit evidence
- CTOs and founders of cloud-based SaaS businesses
- Teams using AWS, Azure, Okta, or Google Workspace
- Anyone in the SOC 2 Type 1 or Type 2 observation period
Related CyberSapiens resources
What Does SOC 2 Mean by Access Control?
In SOC 2, access control means making sure that only the right people can access your systems, data, and infrastructure, that they can only do what their role requires, and that their access is removed or adjusted the moment their role changes. It covers the full lifecycle of identity in your environment, from the moment a new employee is onboarded to the moment they leave.
SOC 2 access control requirements are primarily addressed through the CC6.x criteria within the Common Criteria category of the Trust Services Criteria (TSC). These criteria address logical access, authentication, authorisation, removal of access, and the security of credentials and physical assets. Satisfying CC6.x is not about ticking a checklist. It is about demonstrating, with evidence, that your controls operate consistently over time.
What SOC 2 access control covers
Authentication
How users prove who they are before gaining access, including MFA and SSO.
Authorisation
What each user or role is permitted to do once inside, enforced through RBAC and policy.
Least privilege
Users should only have the minimum access needed to do their job, nothing more.
Access reviews
Periodic reviews to confirm that access remains appropriate and remove what is not.
User lifecycle management
Provisioning, modifying, and revoking access as people join, move roles, or leave.
Credential and key management
Protection of passwords, API keys, secrets, and certificates used to access systems.
Common misconceptions about SOC 2 access control
Misconception: “We use strong passwords, so we’re covered.”
Password strength is one small part. Auditors want to see MFA, RBAC, access reviews, and JML processes documented and operating.
Misconception: “Our IT team handles access, so it’s fine.”
SOC 2 requires a formal, documented process with assigned ownership, approval workflows, and audit trails, not just ad hoc IT management.
Misconception: “Access control is only about internal staff.”
SOC 2 access control extends to contractors, vendors, third-party integrations, service accounts, and API access as well.
Misconception: “We only need to set it up once.”
SOC 2 Type 2 requires evidence that access controls operated consistently across the entire audit observation period, typically 6 to 12 months.
THE CRITERIA BEHIND THE CONTROLS
Where does access control sit inside SOC 2?
SOC 2 is built on the AICPA Trust Services Criteria. Access control requirements fall primarily under the CC6 — Logical and Physical Access Controls category, which contains criteria numbered CC6.1 through CC6.8. Each criterion targets a specific control area: restricting access, authenticating users, removing access, managing credentials, and protecting physical infrastructure.
Other criteria also touch access control. CC9 deals with third-party risk including vendor access. CC7 covers monitoring and anomaly detection, which overlaps with detecting inappropriate access. A thorough SOC 2 compliance checklist will map your controls to each relevant criterion before your auditor does.
The Five Core SOC 2 Logical Access Control Areas
SOC 2 logical access controls are not a single requirement. They span five distinct areas, each with its own criteria, evidence expectations, and common failure points. Understanding what each area demands helps your team prioritise readiness work and avoid the findings that most frequently delay or qualify SOC 2 reports.
Authentication
SOC 2 requires that users authenticate before accessing systems, and that authentication mechanisms are strong enough to prevent unauthorised access. Multi-factor authentication (MFA) is now an expected baseline for all administrative and privileged accounts.
What auditors want to see
- MFA enforced on all critical systems and admin accounts
- SSO configuration with MFA at the IdP layer
- Password policy documented and enforced technically
- Evidence of authentication logs and monitoring
Authorisation and RBAC
Access must be granted based on defined roles, not on individual preferences or informal requests. Role-based access control (RBAC) ensures that permissions are tied to job functions and that no individual holds more access than their role requires.
What auditors want to see
- Defined roles matrix with access permissions documented
- Formal access request and approval workflow
- Separation of duties enforced for sensitive functions
- No shared or generic admin accounts in use
Least Privilege
Every user, service account, and integration should have only the minimum access needed to perform its function. Least privilege limits the blast radius of a compromised account or insider threat and is one of the most scrutinised areas in SOC 2 Type 2 audits.
What auditors want to see
- No standing admin access unless justified and time-limited
- Privileged access management (PAM) for admin accounts
- Service accounts scoped to the minimum required permissions
- Regular reviews to identify and remove excess access
Periodic Access Reviews
SOC 2 requires that access is reviewed at defined intervals, and that access which is no longer appropriate is removed promptly. For SOC 2 Type 2, your organisation must show that these reviews actually occurred during the observation period, with documented outcomes and remediation actions.
What auditors want to see
- Access review schedule defined in policy (quarterly is common)
- Completed review records with manager sign-off
- Evidence of access removed or modified following reviews
- Tickets or logs showing remediation actions completed
Joiner-Mover-Leaver (JML)
The Joiner-Mover-Leaver process governs how access is provisioned when someone joins your organisation, adjusted when they change roles, and revoked when they leave. SOC 2 auditors examine JML process evidence closely because it directly demonstrates whether your access control posture holds up in day-to-day operations.
What auditors want to see
- Documented JML policy with defined SLAs for each stage
- HR-to-IT handoff process for joiners and leavers
- Same-day or next-day leaver account deactivation evidence
- Mover access changes tied to role change approvals
Each of these five areas requires both a written policy and technical evidence that the control operated as described. If you are mapping your environment against these requirements for the first time, the SOC 2 compliance checklist from CyberSapiens is a practical starting point for identifying gaps before your readiness assessment.
SOC 2 Access Control Examples: Okta, Azure AD, AWS IAM, and Google Workspace
SOC 2 access control requirements are technology-agnostic. The criteria do not specify which tools to use. What matters is that your chosen tools are configured to enforce the required controls and that you can produce evidence showing they operated correctly. Below are practical examples of how Australian SaaS and cloud businesses implement SOC 2 access control across the most common identity and infrastructure platforms.
Joiner-Mover-Leaver Process for SOC 2: How It Works and What Auditors Check
The Joiner-Mover-Leaver process is how your organisation manages user access across the full employment lifecycle. For SOC 2, it is one of the most heavily scrutinised control areas because it directly demonstrates whether your access control posture holds up in real operations, not just on paper. Auditors will sample JML events from across the observation period and test whether access was provisioned, modified, and removed correctly and within your defined SLAs.
The three stages of the JML process each carry distinct SOC 2 evidence requirements. The flow below shows how a well-designed JML process operates in a cloud-first Australian SaaS environment.
Joiner
NEW HIRE OR CONTRACTOR ONBOARDINGWhen a new employee or contractor joins, access must be provisioned based on their role, not granted ad hoc. A formal request and approval workflow must exist, with a defined SLA from the date of joining to account activation.
Process steps
- HR raises access request in ITSM or HR system
- Manager approves role and access level
- IT provisions account in IdP (Okta / Azure AD)
- User assigned to appropriate RBAC groups
- MFA enrolment completed on day one
- Access confirmation email sent to user and manager
SOC 2 evidence required
- Access request ticket with manager approval
- Account creation log from IdP
- Group membership screenshot at point of provisioning
- MFA enrolment confirmation
- Date of hire vs. date of provisioning to confirm SLA met
Mover
ROLE CHANGE OR INTERNAL TRANSFERWhen someone moves to a new role or team, their access must be updated to reflect their new responsibilities. This means removing access from the old role as well as granting access for the new one. Failing to remove old access is one of the most common least privilege violations found in SOC 2 audits.
Process steps
- HR or manager raises role change request
- New manager approves required access for new role
- IT removes user from old RBAC groups
- IT assigns user to new RBAC groups
- Previous system access revoked within defined SLA
- Change logged and confirmed in ITSM ticket
SOC 2 evidence required
- Role change request with dual approval (old and new manager)
- Before and after group membership screenshots
- Timestamp confirming old access removed within SLA
- ITSM ticket showing completion and closure
Leaver
HIGHEST RISK STAGE — AUDITOR PRIORITYThe leaver stage carries the highest SOC 2 risk because any delay in revoking access leaves a window where a departed employee or contractor could still access production systems or customer data. Auditors treat leaver deprovisioning as a high-priority test and will sample termination events specifically to verify that accounts were disabled promptly, typically on the last day of employment or within 24 hours.
Process steps
- HR notifies IT of termination date in advance
- IdP account suspended on last working day
- All RBAC group memberships removed
- Active sessions and tokens revoked
- API keys, SSH keys, and service credentials rotated
- Data ownership transferred before account deletion
- Account permanently deleted after retention period
SOC 2 evidence required
- Termination date from HR vs. account suspension timestamp
- IdP account status showing disabled or suspended
- Confirmation that no active sessions remained post-termination
- Credential rotation confirmation for shared or API access
- Offboarding checklist signed off by IT and HR
Recommended JML SLAs for SOC 2 Compliance
| JML Stage | Recommended SLA | Why it matters for SOC 2 |
|---|---|---|
| Joiner provisioning | Same day or within 24 hours of start date | Demonstrates controlled, timely access provisioning |
| Mover access update | Within 48 hours of role change effective date | Prevents access accumulation from prior roles |
| Leaver deprovisioning | Same day as last working day | Auditor priority test; delays are high-risk findings |
| Contractor deprovisioning | Same day as contract end date | Contractor access often missed; auditors specifically sample this |
If your JML process relies on manual steps and informal communication between HR and IT, it will not hold up under SOC 2 Type 2 scrutiny. Automating JML through your IdP using SCIM provisioning and an ITSM workflow is the most reliable way to produce consistent evidence across the entire audit period. CyberSapiens helps Australian organisations design and implement JML processes that satisfy SOC 2 auditor expectations as part of the broader SOC 2 compliance in Australia journey.
What Auditors Actually Check for SOC 2 Access Control
Auditors do not just ask whether access control exists. They test whether it is designed well, applied consistently, and supported by evidence across the full audit period. In practice, that means they will sample users, review access approvals, compare joiner and leaver dates, inspect privileged accounts, and confirm that access reviews were completed on schedule.
| What auditors ask for | What to prepare | Why it matters |
|---|---|---|
| User access list for in-scope systems | Export from IdP, AWS, admin consoles, and key apps | Shows who had access during the audit period |
| Access request and approval evidence | Ticket screenshots, manager approvals, timestamps | Proves access was granted intentionally |
| MFA enforcement evidence | Policy screenshots and enrolment reports | Confirms strong authentication is in place |
| Privileged access review | Admin list, review sign-off, remediation evidence | Proves least privilege for high-risk access |
| Leaver termination record | HR termination date and account disable timestamp | Tests whether access was removed on time |
| Access review policy and schedule | Documented review cadence with completed evidence | Shows controls operated throughout the period |
Best evidence formats
- Timestamped screenshots from source systems
- CSV or PDF exports from admin consoles
- Ticketing workflow records with approvals
- Access review sign-off documents
- Audit logs showing changes and removals
Common auditor questions
- Who approved this user’s access?
- Why does this admin still have privileged access?
- Was the access review completed on time?
- Was this leaver’s account disabled the same day?
- Can you show evidence from the audit period?
What usually causes findings
- No access review evidence for part of the period
- Inactive or orphaned admin accounts
- Leaver accounts still active after departure
- Missing approval for elevated access
- Screenshots without timestamps or source context
The strongest SOC 2 access control evidence is simple, consistent, and time-bound. If your team can show who had access, who approved it, what changed, and when the change happened, you are already covering the core of what auditors need to verify.
That is why CyberSapiens recommends building access evidence capture into your normal operational workflow rather than collecting it at the last minute.
Common Access Control Mistakes That Hurt SOC 2 Audits
Most SOC 2 audit findings related to access control are not caused by missing technology. They are caused by process gaps, inconsistent execution, and controls that work in theory but break down in practice. The mistakes below are drawn from real readiness assessments and represent the issues CyberSapiens most commonly identifies when working with Australian SaaS and cloud businesses preparing for SOC 2 Type 1 and Type 2.
Every one of these mistakes is fixable before your audit begins. A structured readiness assessment from CyberSapiens identifies exactly which of these gaps exist in your environment and helps you remediate them before an auditor does. Explore the full SOC 2 compliance checklist or speak to our team about an access control review tailored to your environment.
How CyberSapiens Helps Fix Access Control for SOC 2
Access control is not a one-time configuration exercise. It is an ongoing process tied to your people, technology, and business model. CyberSapiens helps Australian SaaS, fintech, and cloud businesses design, implement, and evidence SOC 2-compliant access control across Okta, Azure AD, AWS IAM, Google Workspace, and Microsoft 365, so you walk into the audit with confidence rather than fear.
Access Control Gap Assessment
We start by mapping your existing IdP, cloud platforms, and in-scope applications against SOC 2 CC6.x and related criteria. Our team identifies over-privileged accounts, missing MFA coverage, weak RBAC, and JML process gaps, then documents them in a clear, prioritised risk list.
Access Control Design and Roadmap
We design a realistic access control operating model for your environment, including role matrices, MFA requirements, RBAC structure, and JML policy. The outcome is an actionable roadmap that your IT and security team can follow to align with SOC 2 expectations without disrupting day-to-day operations.
Implementation and Tuning
We work with your team to configure Okta or Azure AD, AWS IAM, Google Workspace, and Microsoft 365 according to the agreed model. This includes setting up MFA policies, RBAC groups, SCIM provisioning, and PAM for privileged accounts, while documenting every change for future audit evidence.
Access Review and JML Workflow Setup
We help you build a repeatable access review calendar and configure JML workflows in your ITSM or HR system so that joiner, mover, and leaver events are routed to IT automatically. By the time your SOC 2 Type 2 observation period begins, these processes are already operating and producing consistent evidence.
Audit Readiness and Evidence Review
Before your auditor arrives, we review your access control evidence pack to confirm that it covers all key CC6.x areas: user lists, access approvals, MFA, access reviews, and leaver deprovisioning. Our goal is to catch any gaps early and give you a clear, audit‑ready access control narrative.
Related CyberSapiens resources
Frequently Asked Questions: SOC 2 Access Control
What does SOC 2 mean by access control?
SOC 2 access control means making sure that only authorised users can access systems and data, that they can only do what their role allows, and that access is removed promptly when it is no longer needed. It covers authentication, authorisation, least privilege, periodic access reviews, and the Joiner–Mover–Leaver lifecycle.
Which SOC 2 criteria cover access control?
Logical access control requirements sit primarily under the CC6 — Logical and Physical Access Controls criteria (CC6.1 to CC6.8) of the AICPA Trust Services Criteria. Related controls are found in CC9 (vendor access) and CC7 (monitoring and anomaly detection). A complete SOC 2 access control design should map to all these criteria.
Do we need MFA for SOC 2?
Yes. SOC 2 expected practice now requires multi-factor authentication for all users of in-scope systems, and it is mandatory for all privileged or administrative accounts. MFA enforced at the identity provider layer (Okta, Azure AD, etc.) is the cleanest way to meet this requirement across multiple SaaS tools.
What is the least privilege principle in SOC 2?
Least privilege means that each user, service account, or integration has only the minimum permissions required to perform its function, nothing more. Over-privileged accounts and standing admin rights are common findings in SOC 2 audits and are treated as high-risk control gaps.
How often should we run access reviews for SOC 2?
A quarterly access review cycle is standard for SOC 2 Type 2. The key requirement is that reviews occur at defined intervals and that evidence from the full audit period can be produced. If your period is 12 months, at least four documented review events are expected.
What evidence do auditors ask for on access control?
Auditors typically request user access lists, access request and approval tickets, MFA enrolment reports, privileged access review records, leaver termination and account disable dates, and completed access review sign-offs. These documents must cover the full SOC 2 observation period and link access decisions back to documented policies.
Do contractors need the same access controls as employees?
Yes. SOC 2 treats contractor access as in scope where they have access to customer data, production systems, or sensitive assets. Contractors must go through the same Joiner–Mover–Leaver process, be assigned role-based access, and have their access removed on the same day as their contract ends.
How long does it take to fix access control for SOC 2?
The timeframe depends on your current state. If you already use an IdP with MFA and have basic RBAC, most gaps can be closed within 6–10 weeks. If you are starting from scratch with many shared credentials and no formal JML process, 10–14 weeks is more realistic before a SOC 2 Type 2 audit.
This Content Was Reviewed By Our Cyber Security and GRC Lead Auditor
Ketki Tidke
Cyber Security and GRC Lead Auditor
ISO 27001 Lead Auditor
Ketki is a certified ISO 27001 Lead Auditor specialised in Governance, Risk and Compliance, with experience consulting public, private, and government clients. She evaluates threats, risk impacts, and regulatory requirements across multiple industry frameworks, helping organisations evidence controls that satisfy auditors and regulators alike.
