Episode 57 · Module 11 · Monitoring & Incident Response

Access Reviews and Least Privilege Audits

19 May 2026 · 8:01 · Security for Legal SaaS

8:01 8:01

Every legal SaaS platform accumulates permissions like a law firm accumulates filing cabinets — slowly, silently, and with nobody tracking what went in six months ago. A contract developer gets database access for a migration project. An associate joins a matter team and receives case file permissions. Both move on. The access stays. This is permission drift, and it is one of the most common findings in every compliance audit.

Today’s Lesson

Security for Legal SaaS — Episode 57: Access Reviews and Least Privilege Audits

The Accounts Nobody Remembers

SOC 2 Trust Services Criteria CC6.2 requires that service organisations conduct periodic reviews of user access to confirm that permissions remain appropriate.¹ ISO 27001:2022 Annex A 9.2.5 mandates review of user access rights at regular intervals, with privileged access reviewed more frequently.² These are not suggestions — they are control objectives that auditors verify with evidence.

Key concept: An access review (sometimes called a user access review or entitlement review) is a systematic audit of who has access to what, confirming that every active permission is still justified by a current business need. It is a core control in SOC 2, ISO 27001, and most data protection frameworks.

The Principle of Least Privilege — Revisited

We first introduced the principle of least privilege back in Episode 8 when discussing database security: grant only the minimum permissions necessary for a task. In the context of access reviews, least privilege is both the standard you measure against and the goal you work towards.

There are two approaches to implementing least privilege:

Approach	Description	Risk Profile
Start minimal, add on request	Users begin with zero permissions and request access as needed	Lower risk, higher friction. Users may wait for approvals
Start broad, remove over time	Users receive role-based defaults and excess permissions are trimmed during reviews	Higher initial risk, lower friction. Relies on reviews actually happening

The first approach is safer. The second is what most organisations actually do — and it only works if access reviews are rigorous and regular.

What an Access Review Covers

A thorough access review examines every layer of your permission model:

User accounts. Are all active accounts tied to current employees, contractors, or service accounts with a documented purpose? A 2024 investigation by Zluri found that 40% of enterprise SaaS organisations had active accounts belonging to former employees — accounts that represent open doors to sensitive data.³

Role assignments. Does each user's role match their current job function? A junior associate who was temporarily elevated to admin during a system migration should not retain admin privileges three months later.

Privileged accounts. Admin accounts, database access, infrastructure credentials, and API keys with elevated permissions require monthly review, not quarterly. NIST SP 800-53 AC-2 specifically calls for organisations to review accounts for compliance with account management requirements on a defined frequency.⁴

Service accounts and API keys. These are the accounts nobody thinks about. A service account created for a decommissioned integration that still has read access to your entire document store is a breach waiting to happen.

Shared credentials. Any shared passwords, team API keys, or group login accounts. These should be eliminated wherever possible and flagged for immediate remediation when found during a review.

Review Frequency

Account Type	Recommended Frequency	Compliance Basis
Privileged / Admin	Monthly	SOC 2 CC6.2, ISO 27001 A.8.2
Standard user accounts	Quarterly	SOC 2 CC6.2, ISO 27001 A.9.2.5
Service accounts / API keys	Quarterly	NIST SP 800-53 AC-2
Third-party integrations	On change + quarterly	SOC 2 CC6.6
Emergency / break-glass accounts	After every use	SOC 2 CC6.1

AccessOwl's best practice guide recommends that access reviews also be triggered by events — role changes, project completion, department transfers — not just calendar schedules.⁵

Offboarding: The Critical Access Review

The most time-sensitive access review is offboarding. When an employee or contractor departs, every access point must be revoked — not next week, not at the end of the pay cycle, but within hours. For a legal SaaS platform, this includes:

Application accounts — disable login, revoke active sessions
API keys and tokens — rotate or revoke any keys the departing user created or had access to
OAuth grants — revoke delegated access tokens (as we covered in Episode 20)
Shared credentials — rotate any passwords the user knew
Cloud infrastructure access — remove IAM roles, SSH keys, VPN certificates
Device management — remote wipe if the user had company data on personal devices
Code repository access — remove from GitHub/GitLab organisations
Third-party SaaS — remove from Slack, project management tools, document sharing

Real-world failure: The Colonial Pipeline ransomware attack (2021) exploited a dormant VPN account that had never been deactivated after the employee left. No MFA, no access review, no offboarding checklist. One forgotten account caused a shutdown of nearly half the fuel supply to the US East Coast.⁶

Automating Access Reviews

Manual access reviews — downloading a spreadsheet of users, emailing managers, chasing responses — do not scale. Modern platforms automate the process:

Automated detection flags stale accounts (no login in 90 days), over-provisioned roles (permissions never exercised), and orphaned service accounts (created by departed users). Tools like Zluri, Vanta, and Drata integrate with your identity provider and SaaS applications to surface these automatically.³

Manager certification workflows send each manager a list of their direct reports' permissions and require explicit approval or revocation — with an audit trail showing who approved what and when.

Just-in-time access replaces permanent elevated permissions with temporary grants. A developer who needs production database access for a debugging session gets it for two hours, with automatic revocation. This eliminates the permission drift that makes access reviews necessary in the first place.

Evidence for Auditors

Access reviews are only as valuable as the evidence they produce. SOC 2 and ISO 27001 auditors expect:

Documented policy — who reviews, how often, what triggers a review, and what happens to findings
Review records — timestamped evidence showing reviews were conducted on schedule
Remediation evidence — proof that findings (stale accounts, over-provisioned access) were resolved within a defined timeframe
Exception documentation — if any user retains access that violates least privilege, a documented business justification with a review date

Without this evidence trail, you have not conducted an access review in any meaningful compliance sense — you have just looked at a list.

What's Next

Episode 58 covers Insider Threats and Employee Access — what happens when the attacker already has legitimate credentials, and how to detect access patterns that are technically authorised but behaviourally anomalous.

Sources & Further Reading

Sources & references

ISMS.online, Enforcing SOC 2 Access Controls Effectively — SOC 2 CC6.2 access review requirements.
ISMS.online, ISO 27001 Annex A.9: Access Control — periodic review of user access rights.
Zluri, User Access Review Policy: What to Document for PCI DSS, HIPAA, ISO 27001, SOC 2, & SOX — access review policy requirements and stale account statistics.
NIST, SP 800-53 AC-2: Account Management — review accounts for compliance with account management requirements.
AccessOwl, User Access Reviews: Best Practices for Successful Audits — event-driven and scheduled review cadence.
Wikipedia, Colonial Pipeline Ransomware Attack — dormant VPN account exploited due to no access review.
Konfirmity, SOC 2 Role-Based Access Control — RBAC and least privilege enforcement.
Neumetric, ISO 27001 Access Control Requirements for Enforcing Least Privilege — Annex A access control deep dive.
HighTable, ISO 27001:2022 Annex A 8.2 Privileged Access Rights — privileged access review requirements.
AccessOwl, Access Controls for SOC 2 & ISO 27001 — cross-framework access control comparison.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 57 — access reviews and least privilege audits. Alice, this is one of those topics that sounds like paperwork, but I suspect there's more to it than that.

Alice: There is. Think of it this way. Every time you give someone access to a system — a login, an API key, permission to read case files — that's a door you've opened. Access reviews are the process of walking through the building every few months and checking which doors are still supposed to be open. Because what happens in practice is that people join projects, get access, the project ends, they move on, and nobody closes the door behind them.

Dan: Mm. So it's not about whether you gave access correctly at the start — it's about whether that access still makes sense six months later.

Alice: Exactly. This is what compliance frameworks call "permission drift." You start with the right permissions, but over time they accumulate. A developer gets database access for a one-week migration. A paralegal joins a sensitive matter team temporarily. The work finishes, but the permissions stay. And the longer they stay, the more invisible they become — nobody remembers granting them, and nobody thinks to revoke them.

Dan: Right. And this isn't just a hygiene issue — there's a compliance angle.

Alice: <sigh> There's a significant compliance angle. SOC 2 — which is the security audit framework we'll cover in depth in Episode 60 — requires periodic user access reviews under its Trust Services Criteria. ISO 27001, the international information security standard, has a specific control for reviewing access rights at defined intervals. If an auditor asks "show me evidence that you reviewed who has access to what in the last quarter" and you can't produce it, that's a finding. A material one.

Dan: Mm-hmm. So what does an access review actually look like in practice? Is someone just scrolling through a list of usernames?

Alice: That's what it looks like at companies that fail audits. A proper access review is structured. You go through every layer. First, user accounts — are all active accounts tied to current people? You'd be surprised how often you find accounts for contractors who left months ago still sitting there, fully active. One study found that forty percent of enterprise SaaS organisations had active accounts belonging to former employees.

Dan: Hmm. Forty percent. That's not a rounding error.

Alice: It's not. Second, you check role assignments. Does each person's access match their current job? Someone who was temporarily given admin access during an emergency should not still be an admin three months later. Third — and this is the one everyone forgets — service accounts and API keys. These are automated accounts that systems use to talk to each other. They're created by a developer for a specific integration, the developer leaves, the integration gets replaced, but the API key is still active and still has access to your document store.

Dan: Yeah. Those are the ones that show up in breach reports, aren't they?

Alice: They are. The Colonial Pipeline attack in 2021 — we've referenced it before — exploited a dormant VPN account. The employee had left. The account was never deactivated. No MFA on it, no access review had flagged it. One forgotten account shut down nearly half the fuel supply to the US East Coast.

Dan: Mm. So how often should these reviews happen?

Alice: It depends on the account type. Privileged accounts — your admins, your database access, your infrastructure credentials — those should be reviewed monthly. Standard user accounts, quarterly is the accepted baseline. Service accounts and API keys, quarterly. And any emergency access or break-glass account should be reviewed after every single use. But here's the key point — reviews should also happen on events, not just on calendars. When someone changes roles, when a project ends, when a contractor's engagement finishes. Those are the moments when permissions become stale.

Dan: Right. Now, you mentioned offboarding. That feels like the most high-stakes version of this.

Alice: It is. When someone leaves — an employee, a contractor, a temporary consultant — every access point needs to be revoked within hours. Not next week. Not at the end of the billing cycle. Hours. That means application accounts disabled, active sessions killed, API keys revoked, OAuth tokens cancelled, shared credentials rotated, cloud access removed, code repository access stripped, and third-party tools — Slack, document sharing, project boards — all cleaned up. If you're building a legal SaaS platform, you need an offboarding checklist that covers every system, and you need to run it the same day the person departs.

Dan: Mm. That's a lot of places to check. Can you automate any of this?

Alice: You can and you should. Manual reviews — downloading a spreadsheet, emailing managers, chasing people for confirmations — that doesn't scale past about twenty users. Modern identity platforms can automatically flag stale accounts, detect permissions that were granted but never used, and surface orphaned service accounts. They can also send managers a list of their team's permissions and require explicit approval or revocation, with a full audit trail. The most advanced approach is something called just-in-time access — instead of giving a developer permanent production database access, you give them a temporary grant that expires automatically in two hours. That eliminates the drift problem entirely.

Dan: Yeah, that makes a lot of sense. Instead of cleaning up after the fact, you prevent the buildup in the first place.

Alice: Exactly. And the last piece that matters — especially for anyone preparing for a SOC 2 or ISO 27001 audit — is evidence. Conducting a review means nothing if you can't prove you did it. Auditors want to see your documented policy, timestamped records showing reviews happened on schedule, evidence that findings were remediated, and documented justifications for any exceptions. If a user retains access that seems broader than their role requires, there needs to be a written business reason and a date for the next review. Without that evidence trail, as far as the auditor is concerned, the review never happened.

Dan: Mm-hmm. So the review itself is a control, but the documentation of the review is the proof that the control works.

Alice: That's exactly right. And for legal SaaS specifically — where your platform holds case files, client communications, litigation strategy — the consequences of a dormant account being exploited aren't just a data breach. They're a potential breach of legal professional privilege. The stakes are higher than most SaaS categories, and the access review process needs to reflect that.

Dan: Next episode — insider threats and employee access. What happens when the person with legitimate credentials decides to use them in ways you didn't intend.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.