Start free trial

By Yair Knijn · March 17, 2025

The leaver whose VPN still works six weeks later, until the SOC 2 auditor pulls the timestamps

The MSP owner-operator writes a clean offboarding policy, gets it signed, drops it in the evidence folder, and treats the control as done. The policy says access is revoked on the last day. Nobody checks whether it actually happened on the last day, every time, for every leaver.

Then the SOC 2 Type II auditor arrives, pulls the HR termination list for the period, samples three names, and asks one question for each: show me the timestamp the access died and prove it was after termination, not six weeks later. That is where the policy and the reality stop matching.

CC6.1 and CC6.2: what the auditor actually samples and asks for

CC6.1 and CC6.2 are tested on operating effectiveness across the whole period, not on whether a document exists. The auditor takes the population of terminated users, selects a sample, and for each one expects three artifacts to line up: an HR termination record with a date, a revocation ticket showing IT was asked to remove access, and system evidence that the account is actually dead, the absent user list, or a Last Login that predates the termination date.

Deprovisioning is the single most common source of SOC 2 exceptions. The common bar is removal within three business days; firms chasing a stronger report target a 24-hour SLA. The sample size scales with your population, often 5 to 25 names. One name where the timestamps do not line up is enough.

Why revoking SSO is not deprovisioning: the standalone-app blind spot

You disable the user in Entra or Okta, the SSO session dies, and it feels finished. It is not. Every tool that authenticates outside the IdP keeps its own door open: the firewall with local VPN accounts, the RMM and PSA with native logins, the backup console, the standalone billing portal, the shared service account the leaver knew the password to.

The auditor does not care that SSO was revoked in minutes if the leaver's standalone VPN credential still accepted a login six weeks later. That login lands in the firewall logs, dated after termination, and it reads as exactly what it is: access that should have been gone and was not. The IdP toggle is one line item in deprovisioning, not the whole control.

Design deficiency vs operating-effectiveness exception, and which one ends the deal

A design deficiency means the control was never built to work, no defined revocation process at all. That is bad, but it is honest, and a buyer's security team can read it as a gap with a roadmap. An operating-effectiveness exception is worse in a specific way: the control exists, the policy is signed, and it still failed in practice on a sampled user. It says your process does not run reliably, which is the exact thing a prospect's vendor review is checking.

One exception can flip a clean opinion to qualified. The prospect's procurement and security teams read the report, find the dangling leaver, and the deal that was waiting on your SOC 2 stalls. You do not get to explain it in the report; the timestamps already did.

Making the leaver ticket the timestamped evidence the auditor wants

The fix is to stop treating offboarding as a memory exercise and make it a ticket that generates its own proof. When HR marks a termination, a leaver ticket opens with a hard clock, and it does not close until every system is checked off with a timestamp.

That is the part OpsDesk handles inside a customer workspace: an offboarding ticket with a revocation checklist, an SLA clock per task, and an audit trail that hands the auditor a timestamp instead of an apology. When the sample lands on your leaver, the evidence is already filed. See how the lifecycle view turns a termination into closed, timestamped proof.