Do we need SSO for customers too, or just internal staff?

The access control criteria are about your system and the people who operate it, so internal staff is where the requirement bites. An auditor is asking how your engineers, support team, and contractors authenticate into production, your cloud console, your database, and your internal admin tooling — not how your end users log in. Customer-facing SSO is a commercial requirement rather than a compliance one: enterprise buyers ask for SAML or OIDC support because they want to manage your app inside their own identity provider, and that request usually arrives in the same procurement conversation as the SOC 2 report, which is why the two get conflated. Build internal SSO first, because that is what the examination tests. Build customer SSO when a deal needs it. If customer accounts in your product can hold administrative privileges over other customers' data — a support-style role sold to a client, for instance — then those accounts sit inside your control boundary too, and the same expectations apply.

Is role-based access control enough, or do auditors want attribute-based access control?

Roles are enough for the large majority of companies, and no criterion names a specific access-control model. The Trust Services Criteria describe an outcome — access is granted, modified, and removed based on authorization, and is restricted to what is appropriate — and RBAC is simply the most common way to reach it. What gets scrutinized is not the model's sophistication but whether it is real: are roles tied to job function, is every grant traceable to an approval, is enforcement consistent across every entry point, and can you show the current mapping on request. A simple role model that is genuinely enforced beats a fine-grained attribute system that half the codebase bypasses. Attribute-based rules earn their place when the decision genuinely depends on context that a role cannot express — data residency, per-record ownership, time-bounded emergency access, customer-tenant boundaries — and in practice most teams end up with roles for the coarse decisions and a handful of attribute checks layered on top.

How often do access reviews need to happen?

There is no universal frequency written into SOC 2. The period comes from your own written policy, and the auditor tests whether you follow the policy you wrote. Quarterly is the most commonly chosen cadence for teams with meaningful production access, and some organizations run annually for low-risk systems and more frequently for the highest-privilege ones; the right answer depends on your risk profile, your headcount churn, and what your auditor considers reasonable for your environment — confirm the cadence with them rather than inheriting a number from a blog post. What matters more than the interval is that reviews are event-driven as well as periodic. A quarterly review is a backstop; the primary control is that access changes when the job changes, on the day it changes. If your only mechanism is the quarterly sweep, then someone who left a team in week two holds inappropriate access for eleven weeks, and the review that finally catches it is evidence of the gap as much as of the control.

RBAC and SSO requirements for SOC 2: what auditors actually check

Access control is two questions, not one — how someone proves who they are, and what they are allowed to do once they have. What auditors look for in each, the RBAC mistakes that fail examinations, and why SSO is an offboarding control before it is a convenience.

Two halves of the same question

Access control shows up in a SOC 2 examination as one theme with two mechanisms, and teams that treat them as separate projects tend to get an uncomfortable question in the walkthrough.

The theme is that only the right people should have the right access, and nothing more. The two mechanisms answer that from opposite ends. Single sign-on governs how someone proves they are who they claim to be — the front door, the moment identity is established, the point at which multi-factor requirements and device checks apply. Role-based access control governs what that now-authenticated person is permitted to do — which systems, which records, which destructive operations.

Neither is sufficient alone, and the failure modes are mirror images. Perfect RBAC behind scattered local passwords means your carefully modeled roles are attached to identities you cannot centrally disable; the person who left last month still has a working login to three systems, and the roles are dutifully granting them exactly the access they had on their last day. Perfect SSO with no real authorization model means everyone who walks through a well-guarded door can do anything inside; you have excellent evidence of who logged in and no answer to what they were allowed to touch.

An auditor asks about both because the objective is only met when both hold. The practical version of the question: for a named employee, how did they authenticate, what could they reach, who approved it, and what happens the day they leave?

What "good enough" RBAC looks like

There is no certification for an access model. What gets tested is whether four properties are simultaneously true, and whether you can demonstrate each of them without a scramble.

Roles map to job function, not to individuals. A role called support-tier-2 is a statement about a job: these are the permissions that job requires. A role called dave-permissions is a statement about a person, and it means the model has collapsed into ad-hoc grants wearing a costume. The test an auditor applies is whether they can look at your role list and understand the organization from it. If the role names describe responsibilities — support, on-call engineer, billing admin, read-only analyst — the model is doing its job. If they describe individuals, exceptions, or historical accidents, it is not.

The corollary is least privilege, which is easier to state than to hold. Roles accrete permissions, because adding one is a small favor and removing one risks breaking someone's day. The review is where accumulated favors get unwound.

Granting and revoking access is a documented process, not a Slack message. Auditors care less about the tooling than about whether there is a repeatable path: a request, an approval by someone with the authority to approve it, a record of the grant, and a mirror-image path for removal. This does not need a ticketing platform. It needs to exist in writing, be followed consistently, and leave a trail. A short checklist in your onboarding doc, executed every time, is a real control. An informal culture of asking the CTO, with no record, is not — even when the CTO's judgment is impeccable, because the control cannot be tested and cannot survive the CTO being on holiday.

Access reviews actually happen, and someone actually reviews. This is where a surprising number of otherwise well-run teams stumble. The control is not that access exists in a defined state; it is that a person with the context to judge periodically looks at who has what and confirms it is still correct — and sometimes concludes that it is not, and removes something. A review that has never resulted in a revocation is one an auditor will probe, because it suggests a rubber stamp rather than an examination. Reviews should cover production systems, the cloud console, the database, internal admin tooling, source control, and third-party services holding customer data. The reviewer should be someone who knows what each person's job requires — usually their engineering lead, not a central administrator reading a list of names they do not recognize.

Evidence can be produced on demand. Everything above is invisible unless it leaves artifacts: a current export of users and their roles; a definition of each role and the permissions it carries; the record of a completed review with a date, a reviewer, and the outcome including any changes made; and, for a sampled individual, the trail from request through approval to grant, and through departure to revocation. The audit log carries most of this — permission changes are among the highest-value entries it holds, covered in detail in SOC 2 audit logging for developers. If your log records role grants and revocations with actor, subject, timestamp, and outcome, much of your access-control evidence is already assembled.

The RBAC mistakes that fail audits

Three patterns account for most of the findings, and all three are the kind of thing that feels fine right up until someone asks about it directly.

The shared admin account. One admin login, the credentials in a password manager, four engineers who use it. Convenient, common in small teams, and it defeats the entire control. Every action taken through it is attributable to a group, not a person, so your audit log cannot answer the question it exists to answer, offboarding requires a password rotation and a trust exercise, and multi-factor enrollment is either shared or absent. Auditors look for this specifically because it is a single fact that invalidates several controls at once. The same applies to shared service credentials used interactively by humans, and to a root or owner account left in daily use rather than sealed away for break-glass. Individual accounts with individually granted roles are the baseline, and the fix is rarely difficult — it is a migration nobody prioritized.

Roles that exist in code but are not enforced everywhere. The model is defined, the middleware checks it on the main API, and then there is a background job runner that operates with full privileges, an internal admin panel written in a hurry that checks only whether you are logged in, a set of database credentials several engineers hold directly, or a support tool that can impersonate any user without a permission gate. The model is real in one place and decorative in the others. This is dangerous because it survives a superficial review — the code contains a role system, the documentation describes it accurately, and the gap only appears when someone traces every path that can reach customer data. The internal admin tool is by far the most frequent offender: built early, powerful by design, used by trusted people, and exactly the surface that should have the strictest checks and the most complete logging.

Grants with no matching revocation path. Access is added when someone joins or takes on a new responsibility, and it is never removed when the responsibility ends. Departures usually get handled, at least partially; internal transfers almost never do. A person who moves from support to engineering keeps their support-era access to customer records indefinitely, and after two years of a growing team, the accumulated set of people who can reach production data no longer resembles anyone's intent. The structural fix is to treat revocation as part of every change, not as a separate cleanup activity: the offboarding checklist has a mirror, the role change is a swap rather than an addition, and the periodic review exists to catch what the process missed rather than to be the process.

A fourth, quieter one: contractors, vendors, and integrations. Access granted to a fractional engineer for a three-month project, an API key issued to a partner, a third-party tool given broad OAuth scopes on your source control. These are created outside the employee onboarding flow and are therefore missed by an offboarding flow scoped to employees. They belong in the same inventory and the same review.

Why SSO matters beyond convenience

SSO is usually sold internally as a comfort — one login, fewer passwords. That framing undersells it, and it is not the reason it appears in an audit.

The real argument is offboarding. Without centralized authentication, removing someone's access means going system by system: the cloud console, the source control host, the error tracker, the database admin interface, the internal dashboard, the CI provider, three SaaS tools someone signed up for with a company card. Each is a separate action, each can be forgotten, and no single place shows whether the job is complete. The honest answer to "how do you know their access was fully removed" becomes a list of steps someone believes they performed. With an identity provider in the middle, disabling one account closes the door on every connected application at once, and the provider itself is the evidence: a timestamped record showing the account disabled and the sessions terminated. One action, one artifact, one answer.

The second argument is MFA enforcement in one place. Configured per application, multi-factor is a policy you hope each tool implements and each person enables, and verifying it means checking every tool's settings and every user's status. Configured at the identity provider, it is a condition of authentication itself, applied uniformly to everything behind it, with a report showing enrollment coverage. That report is the evidence, and it is far more convincing than a screenshot from each of nine services.

The third is consistent identity across systems, which is what makes access review possible at all. When every tool has its own user list keyed on whatever email someone typed, assembling "everything this person can reach" is manual reconciliation. When identity is centralized, the directory is the spine the review hangs off, and provisioning flows outward from group membership instead of being repeated by hand.

SSO does not replace RBAC. It centralizes the who, and roles still decide the what inside each system. But it makes the roles governable, because now there is one authoritative answer to who exists.

Practical notes for a small engineering team

Use an identity provider; do not build this. There are several established options in this category — the workspace suite you already pay for, a dedicated enterprise identity platform, your cloud vendor's directory service — and for the purposes of an audit they satisfy the same control. The important properties are that it can be the single source of identity for your tools, that it enforces MFA centrally, that it supports SAML or OIDC so your applications can delegate authentication to it, and that disabling an account there promptly ends access everywhere. Choosing between them is an operational decision about cost, existing footprint, and which of your tools integrate cleanly. Building your own is the wrong call at any size: session handling, token lifecycle, MFA, and recovery flows are a large surface with severe failure modes and no differentiation for your product.

Connect the systems that matter most, first. Full coverage takes time; the highest-value connections are the ones holding production access and customer data. Cloud console, source control, database access, error and log tooling, internal admin panels. A tool holding no sensitive data and no production reach can wait. Keep a written inventory of what is connected and what is not, because "everything except these three, for these reasons" is a defensible position and "we think most things" is not.

Do not forget non-human access. Service accounts, CI credentials, deploy keys, and API tokens do not authenticate through the identity provider, and they sit outside the model unless you deliberately put them in it. They need owners, scoped permissions, a rotation practice, and inclusion in the review. An unowned token with broad privileges and no expiry is trivially fixable and embarrassing to be told about.

Plan the break-glass path deliberately. Centralizing authentication centralizes the failure. There has to be a documented way to reach critical systems when the identity provider is unavailable — typically a small number of sealed emergency accounts with strong credentials, offline recovery codes, and alerting on their use. Auditors do not object to break-glass access; they object to break-glass access that is undocumented, unmonitored, or indistinguishable from ordinary use. Make its use loud.

Wire it into the log. Authentication events from the identity provider and authorization changes in your application are two halves of the same evidence trail. Role grants and revocations, permission changes, impersonation, and privileged administrative actions should all land in the audit log with actor, subject, and outcome. Done properly, the access review stops being an archaeology project and becomes a query.

The shape of it, done

Every person has their own identity in one provider, with MFA enforced there. Their permissions come from roles tied to their job, granted through a process that leaves a record and revoked through the same process in reverse. Every path that can reach customer data enforces those roles, including the internal tools. Someone with real context reviews the whole picture on a cadence you wrote down and can defend, and that review has occasionally removed something. And all of it is visible in a log the application cannot rewrite.

That is a set of controls worth having independent of any examination — it is the difference between knowing who can reach your customers' data and assuming you do. It is also markedly cheaper to build early than to retrofit, which is the broader argument for designing compliance-ready architecture from the start rather than reverse-engineering it under a deal deadline. If you are still deciding which examination to pursue and when the evidence needs to start accumulating, that timing question is covered in SOC 2 Type 1 vs. Type 2.