Why access control is the most-audited security control
Ask any SOC 2 auditor or ISO 27001 certification body what they look at first, and most will say access control. It underpins almost every other security control: encryption is useless if anyone can access unencrypted data; logging is worthless if you can't tie actions to specific users; incident response is harder when you don't know who had access to what.
Access control failures are also the most common root cause of data breaches. According to the Verizon DBIR, credential abuse and misuse of privileges account for a majority of confirmed breaches. A documented, tested, and enforced Access Control Policy is not a compliance box — it's fundamental security hygiene.
This guide covers what your access control policy needs to include, how it maps to SOC 2 CC6, ISO 27001 Annex A.9, HIPAA §164.312, and PCI DSS Requirements 7 & 8, and how to build one that's actually followed rather than just filed.
The core principles: least privilege, need-to-know, default deny
Every access control policy should start with three foundational principles:
- Least privilege: Users receive the minimum access necessary to perform their job function — nothing more. A support engineer doesn't need production database write access. A marketing manager doesn't need AWS console access.
- Need-to-know: Access to data is restricted to those who require it for a specific, legitimate business purpose. Even within engineering, a developer working on the payments module doesn't necessarily need access to the analytics data store.
- Default deny: All access is denied unless explicitly granted. You build up access from zero rather than cutting it back from everything.
These principles sound obvious, but they're commonly violated at SaaS companies where early engineers get admin access to everything and it never gets revoked as the company scales. Documenting the principles in a policy creates an expectation — and gives your security team the authority to enforce it.
Access control models: RBAC, ABAC, and least privilege hybrid
Most SaaS companies use Role-Based Access Control (RBAC) as their primary model. Access rights are assigned to roles (Developer, Support, Admin, DBA, Read-only Analyst), and users are assigned to roles based on their job function. This makes provisioning, review, and deprovisioning manageable at scale.
Pure RBAC has limitations when access decisions need to incorporate context (location, time, device state, data sensitivity). Attribute-Based Access Control (ABAC) adds this contextual decision-making — typically implemented through Zero Trust policies or fine-grained IAM policies on cloud platforms.
In practice, most mature SaaS companies use a hybrid: RBAC for base access provisioning, supplemented by least-privilege attribute checks for sensitive operations. Your policy should document whichever model you use, because auditors will ask how access decisions are made.
What your access control policy must cover
1. User provisioning and onboarding
Access should not be granted until formally requested and approved. The minimum viable process:
- Access request form/ticket (who is requesting, what access, business justification)
- Approval by line manager and/or system owner
- Provisioning via SSO/IdP and SCIM where possible (not manual account creation in each system)
- Onboarding checklist with Day 1 access requirements defined by role
- New hire receives access confirmation and policy acknowledgement
2. Access modification and role change
When an employee changes roles, their access should be reviewed within 5 business days. Excess access from their previous role should be removed. This is called the principle of least privilege at role transition — and it's one of the most commonly missed controls in SOC 2 audits.
3. Offboarding and access revocation
This is where companies fail most visibly. All access must be revoked on the employee's final day — or earlier for involuntary departures. The revocation checklist should cover:
- SSO/IdP account deactivation (this cascades to all SCIM-integrated apps)
- Any accounts not managed through SSO (check for shadow IT)
- SSH keys removed from all servers and code repositories
- API keys and tokens rotated or revoked
- Cloud console IAM user disabled
- Physical access badge deactivated
- VPN certificate revoked
For contractors and vendors: accounts should be time-limited from the start. Set an expiry date when provisioning. Don't wait for contract end to trigger revocation.
4. Multi-factor authentication (MFA)
MFA should be mandatory at minimum for: all user accounts, remote access and VPN, production system access, cloud console admin roles, and code repositories. SMS OTP is acceptable as a last resort, but TOTP authenticator apps and FIDO2 hardware keys are significantly more phishing-resistant.
Common gaps: some SaaS tools don't enforce MFA even when the setting is enabled — users can bypass via legacy auth methods (app passwords, basic auth). Audit this regularly.
5. Privileged access management (PAM)
Privileged accounts — admin, root, production DBA, cloud console admin — require additional controls beyond standard user accounts:
- Separate privileged accounts (never use your standard user account for admin tasks)
- No shared admin credentials (each administrator has their own uniquely identified account)
- Formal approval workflow for privileged access requests (manager + security team sign-off)
- Session logging for privileged sessions (who accessed what, when, what commands were run)
- Just-in-time (JIT) access where possible — temporarily elevate for specific task, auto-revoke after
- Break-glass emergency accounts: documented, sealed, audit-triggered on use, reviewed post-use
6. Access reviews
Access rights drift over time. Quarterly access reviews — at minimum — catch accounts that should have been revoked. The process:
- Export access rights report from identity management system for each in-scope system
- System owner and line manager review each user's access against their current role
- Inappropriate access removed within 5 business days
- Review documented and retained (SOC 2 auditors will ask for evidence of completed reviews)
Privileged accounts should be reviewed more frequently — monthly for highest-privilege roles.
Compliance mapping: what each framework requires
| Framework | Reference | Requirement |
|---|---|---|
| SOC 2 | CC6.1 | Logical access to systems and data restricted to authorised users |
| SOC 2 | CC6.2 | New user access requires registration and authorisation; access removed when no longer needed |
| SOC 2 | CC6.3 | Access removed when employment ends or access no longer required |
| SOC 2 | CC6.6 | Network controls to restrict access to authorised users and devices |
| SOC 2 | CC6.7 | Information transmitted over public networks protected |
| ISO 27001 | A.9.1.1 | Access control policy documented and implemented |
| ISO 27001 | A.9.2.1–2.6 | User registration, provisioning, privileged access, access review, removal |
| ISO 27001 | A.9.4.2–4.3 | Secure log-on, password management |
| HIPAA | §164.312(a)(1) | Access control: unique user IDs, emergency access, automatic logoff, encryption |
| HIPAA | §164.308(a)(3) | Workforce access management and authorisation procedures |
| PCI DSS | Req 7.1–7.4 | Restrict access to system components based on business need |
| PCI DSS | Req 8.1–8.8 | Unique IDs, MFA, password management, credential security |
| GDPR/UK GDPR | Art. 32 | Access control as technical and organisational measure for appropriate security |
| NIS2 | Art. 21(2)(i) | Human resources security, access control policies, asset management |
Remote access controls
Remote work expanded the attack surface dramatically. Your policy should specify:
- VPN or ZTNA required for all production system access (not just "encouraged")
- Device compliance gates: MDM enrolment, disk encryption, screen lock timeout, OS patching — enforce at network layer, not just policy
- Network segmentation: production, development, and corporate office networks should be separated; crossing boundaries requires authentication
- No production access from public/unsecured WiFi without VPN — this is a common audit finding
- Vendor/third-party remote access: session-specific, time-limited, monitored, no persistent standing access
Common access control gaps (and what auditors catch)
| Gap | Why It Matters | How to Fix |
|---|---|---|
| Shared admin credentials | No individual accountability; can't attribute actions to specific person | Unique accounts for all admin users; break-glass accounts with sealed credentials |
| Former employee accounts active | Classic breach vector; former employees with grudges or credentials sold on dark web | HR-triggered offboarding in IdP within same day; quarterly audit of active accounts vs HR roster |
| MFA not enforced in legacy auth | Users bypass MFA via app passwords or basic auth even when MFA "enabled" | Disable legacy auth protocols; enforce Conditional Access policies |
| Access never reviewed | Accumulation of permissions over time; developers with prod DB access 3 jobs later | Quarterly access review with documented evidence; manager sign-off required |
| API keys in source code | Committed to public GitHub = immediate exposure; rotated only after breach | Secrets scanner in CI/CD; secrets manager (HashiCorp Vault, AWS Secrets Manager) |
| Overprivileged service accounts | Service accounts with admin rights pose lateral movement risk if compromised | Service accounts scoped to minimum required permissions; regular rotation |
Minimum viable access control policy for an early-stage SaaS
If you're pre-SOC 2 and building your first security policy, here's the minimum that satisfies most auditors and is actually achievable:
- Document your RBAC model: Define your roles and what access each gets. 3–5 roles covers most small SaaS teams.
- Require unique accounts: No shared credentials. Every person has their own account in every system.
- Enforce MFA everywhere: Start with Google Workspace / Microsoft 365 SSO + enforce MFA at the IdP level. Use Conditional Access / Group Policy to block legacy auth.
- Implement an offboarding checklist: Works with HR. On last day: disable IdP account, revoke SSH keys, rotate shared credentials where they still exist.
- Do a quarterly access review: It can be a spreadsheet. Export user lists from your key systems, have managers sign off on who should still have access. Document it.
- Separate privileged accounts: Admin accounts should not be used for day-to-day work. Even if you're 10 people.
Related guides and generators
- Access Control Policy Generator
- Information Security Policy Generator
- SOC 2 Gap Assessment Generator
- ISO 27001 Gap Assessment Generator
- IT & BYOD Policy Generator
- SOC 2 Gap Analysis: How to Assess Readiness Before Hiring an Auditor
- ISO 27001 Gap Assessment Guide
- GDPR Art. 32 TOMs for SaaS
⚠️ This guide is for informational purposes only and does not constitute legal advice. Access control requirements vary by framework version and assessor interpretation. Engage qualified security and legal counsel for your specific compliance programme.