SOC2 for Builders, Part 3: Access Control and Least Privilege by Default
Most access incidents aren’t sophisticated attacks. They come from overly broad permissions that never got tightened. The fix is boring: keep roles short, permissions explicit, and tests that prove who can do what.
SOC2 for Builders series
- Part 1: Treat It Like a Product Requirement
- Part 2: Data Classification and Logging Hygiene
- Part 3: Access Control and Least Privilege by Default (this post)
- Part 4: Change Control, CI, and Deploy Evidence
- Part 5: Incident Response, Backups, and Restore Proof
Default deny is the real starting point
If the system doesn’t know who you’re, it shouldn’t let you do anything. That sounds obvious, but it’s the first thing people soften under schedule pressure.
Least privilege in practice
We follow a few rules that are easy to explain to a team:
- Roles map to concrete actions, not vague titles.
- Service accounts get a narrow scope and one purpose.
- Admin access is time-bound and logged.
- Anything that touches production has an audit trail.
Keep permissions readable
If your permissions model requires a wiki page to understand it, it will rot. We keep the role list short, the permissions explicit, and tests that prove the right people can do the right things.
Break-glass, but make it loud
You’ll need emergency access. That’s fine. The rule is that emergency access is time-limited and logged with a reason. If it isn’t logged, it didn’t happen.
Evidence is mostly metadata
You don’t need screenshots. You need:
- A list of roles and permissions in code.
- A way to show who has access and when it was used.
- A record of changes to access policies.
Keep those in the normal workflow and access control becomes audit-ready by default.
Next up
Part 4 covers change control, CI, and deploy evidence. This is where the audit trail becomes automatic.
Related reading
- SOC2 for Builders, Part 1: Treat It Like a Product Requirement
- SOC2 for Builders, Part 2: Data Classification and Logging Hygiene