If you want to guess where your SOC 2 will produce an exception before anyone has tested anything, guess offboarding. Not because the control is hard to describe — “access is removed within one business day of termination” is one sentence — but because it depends on two teams talking to each other on a day when one of them is having an awkward conversation and the other is not in the room.
Onboarding fails less often, and when it does, it fails differently. Onboarding exceptions are usually about missing approval: someone got access, and nobody can show who authorised it. Offboarding exceptions are almost always about timing and completeness: access was removed, but eleven days later, or removed from the identity provider and not from the two systems that sit outside it.
Why the joiner–mover–leaver controls fail more than most
Most SOC 2 controls run on a schedule you set. A quarterly access review happens when you decide it happens. A vulnerability scan runs weekly because you configured it to. If you miss one, you usually notice.
Joiner, mover and leaver controls are different. They are triggered by events you do not schedule, and the trigger lives in HR rather than in IT. Someone resigns, is let go, changes teams, or a contract ends. The control only fires if that event reaches the person who can revoke access, promptly, in a form they act on.
That handoff is the control. Everything else — the ticket, the checklist, the SSO configuration — is machinery around it. When auditors test a sample of terminations and find one that took nine days, the root cause is nearly always that the notification arrived late, went to a shared inbox, or went to someone on leave.
Where the auditor gets the population
This is the part teams underestimate. Before testing anything, the auditor needs a complete population of everyone who joined and everyone who left during the period. That list has to come from a source independent of the process being tested — normally the HR system or payroll, not the IT ticket queue.
The reason is straightforward. If the population comes from the offboarding ticket queue, then anyone who was never ticketed is invisible, and the test cannot detect the exact failure it exists to detect. So expect to be asked for an HR-generated roster of joiners and leavers with dates, exported in front of the auditor or with evidence of how it was produced.
Then expect a reconciliation. The auditor takes leavers from HR and looks for corresponding revocations in your systems. Discrepancies in either direction matter:
- A leaver in HR with no revocation record, or a revocation dated well after the termination date
- An active account belonging to someone who left months ago
- A revocation for someone who does not appear on the HR roster at all, which usually means contractors are tracked somewhere else entirely
If your HR roster and your account inventory cannot be reconciled, that is the finding, regardless of how good the process looks on paper.
Onboarding: the failures are about authorisation, not speed
Nobody is late onboarding people. New hires escalate loudly when they cannot log in. So the onboarding control rarely fails on timing.
It fails on three other things.
No record of who approved the access. The auditor’s question is not “did this person get an account” but “who decided they should have this level of access, and did they have the standing to decide it?” A Slack message saying “set her up like the rest of the team” is a real approval in practice, but it is weak evidence and it does not say what “like the rest of the team” means.
Access granted beyond the role. New engineer gets production database access on day one because that is what the setup script does. The control says access is granted based on job role; the evidence shows a standard bundle applied to everyone. Those two statements are not the same, and the auditor will notice which one your policy claims.
Prerequisites not actually enforced. Many onboarding controls bundle in background checks, signed acceptable use policies and security awareness training. If your control says access is granted after the policy is signed, and the sample shows three people with accounts created a week before they signed anything, that is an exception even though the security risk is modest. The control failed as written.
Offboarding: the failure is almost always timing
Most offboarding controls state a deadline — same day, one business day, 24 hours, 72 hours. The auditor tests against your stated deadline, not against a general standard of reasonableness. This is worth sitting with, because it means a tighter commitment is a tighter test.
Common patterns that produce exceptions:
Friday and holiday terminations. Someone leaves at 5pm Friday, the ticket is worked Monday morning. If your control says one business day you are fine; if it says 24 hours you are not.
Involuntary terminations handled out of band. These are the ones where access genuinely gets cut fast, but by someone acting directly rather than through the normal workflow, so no ticket exists. The control worked and the evidence does not.
Systems outside the identity provider. SSO disablement is treated as complete offboarding. Meanwhile the person retains a local account in a monitoring tool, a database credential, a shared password vault entry, an external SaaS admin console, or access to a code repository under a personal account. The auditor’s system list comes from your own system description, and they will check the ones you named.
Departures that are not terminations. Contract expiry, an intern finishing, a vendor engineer rotating off. If HR does not record these events, they never reach the queue.
If you can only fix one thing, tighten evidence of the revocation timestamp on each in-scope system, and make your stated deadline one you can actually meet on a bad week. Changing the policy from 24 hours to one business day is not weakening your security posture; it is describing it accurately.
The mover case that nobody owns
Transfers are the quietest failure. Someone moves from support to engineering, or from engineering to management. They get the new access immediately, because they need it to do the job. The old access is nobody’s action item.
Over two or three years this produces the accumulation auditors describe as privilege creep — the long-tenured employee who can touch everything. It usually surfaces during the periodic access review rather than in transfer testing, and it lands harder there because the reviewer approves the access rather than questioning it, which turns a provisioning problem into a review-quality problem.
Two practical fixes. Make the transfer trigger a removal step, not just an addition step, with the previous manager confirming what should be revoked. And when a role changes materially, consider rebuilding entitlements from the role baseline rather than adding to what exists.
Contractors, shared accounts and the long tail
Contractors are the single most common gap in the population, because they are frequently not in the HR system at all. If your engagement is with an agency, the individuals may rotate without anyone at your company being told. Decide who owns the contractor roster, keep end dates on it, and treat that roster as part of the population you hand the auditor.
Service accounts and shared credentials need a different answer, not the same one. They cannot be offboarded by person, so the control is usually ownership plus rotation: every service account has a named human owner, and credentials shared with a departing employee get rotated when they leave. If you claim rotation on departure, be ready to evidence it for at least a sample of leavers who held privileged access.
What to do next
Run the reconciliation yourself before anyone else does. Export every termination from HR for the last three months, and for each one pull the revocation timestamp from each system named in your system description. Count how many exceeded your stated deadline and how many systems you could not produce a timestamp for at all.
That number tells you two things: whether you have a process problem or a logging problem, and whether the deadline written in your policy is the one you actually operate to. Fixing either before fieldwork is far cheaper than explaining it in a management response.
Assurion performs SOC 2 examinations as a licensed CPA firm, and this reconciliation is one of the first things we ask for — it is a fair test to run on yourself first.