Access that ends when it should.
CC6.2 is the SOC 2 criterion about the lifecycle of logical access. New users are registered and authorized before they receive access, and that access is removed or modified when someone leaves, changes roles, or no longer needs it. It is the criterion behind the questions an auditor asks about access: who can get an account, how was the grant approved, and is anyone who departed still active? In a SaaS product the answers usually live in code: the SSO integration, the invite flow, the sync jobs that create and deactivate accounts.
The shapes the same control failure takes.
CC6.2 weakens when the lifecycle stops working, and it rarely stops loudly: a removal case is dropped in a refactor, a sync job is paused, an invite flow skips a step. The recurring shapes:
An account outlives its departure
The deactivation that should fire when someone is removed in the identity provider or HR system never reaches the application: the event case is dropped, the webhook is unregistered, or the sync job that suspends leavers is paused and never resumed.
A role change only ever adds
Moving teams or getting promoted is supposed to change access, not only grow it. The sync grants what the new role needs but never touches what the old one had, so the modification half of a role change never arrives and the old access quietly rides along.
Access lands before it is authorized
A self-serve or invite path hands out an active account the moment someone signs up, where the documented process says access is requested and approved first, so the approval exists on paper but not in the flow.
The removal is partial
The account is deactivated but its existing sessions, tokens, or API keys stay valid, so the access is not actually gone: a person marked as departed can still reach the system with what they already hold.
Temporary access never expires
A contractor's account or a break-glass login ships with no expiry and no owner who revisits it, so the removal CC6.2 expects when access is no longer appropriate never has a trigger.
An SSO migration that drops the removed-user case.
The SSO integration is being migrated to a new identity provider, and the event mapper is rewritten for the new payloads. In the rewrite, the removed-from-org case is dropped and left for a follow-up, so the events the provider still sends reach the switch, match nothing, and do nothing. People removed in the provider keep an active account with standing access, and nothing in the application notices.
switch (event.type) { case "user.updated": await syncProfile(event.data); break;- case "user.removed_from_org":- await users.deactivate(event.data.id);- break;}This deletes the case that deactivates a user when the identity provider says they left. CC6.2 expects access to be removed when it is no longer appropriate, and a departure is exactly that trigger: after this merge, people the provider removes keep an active account until someone notices by hand. Map the removal event (deactivate the user, and treat open sessions as in scope) before the new provider is trusted for events, rather than landing it after the cutover.
Offboarding is sampled against the leaver list.
In a SOC 2 examination, CC6.2 gets one of the most concrete tests in the audit: the auditor takes the list of people who left, from HR or the identity provider, and checks how many still have active accounts, and how quickly access was removed after each departure. Provisioning is sampled the same way in reverse: how a new grant was requested, who approved it, and whether the flow works the way the process document says. An SSO migration that quietly stops delivering removals is invisible to policy documents and produces the kind of exception this test finds, one departed user at a time. The change that breaks it is a diff, which is where it can be caught before the sample.
A review, not your access lifecycle.
heygrc flags changes that break the grant-and-remove flow and cites the criterion so the fix happens in the pull request. It does not connect your identity provider, run your offboarding, or decide who should have access. It catches the moment the lifecycle stops working, at the diff.