CC6.2 is where first SOC 2 audits go sideways

A founder hires an auditor, passes the policy review, and gets to the sample. The auditor asks for the list of people who left during the audit period and picks three. For each one, the question is the same: show me when every account was removed.

That request is CC6.2 in the AICPA's 2017 Trust Services Criteria. The criterion covers registering and authorizing users before access is granted, and for users whose access the company administers, removing credentials when access is no longer authorized. CC6.3 adds the review and removal of access when roles change. Offboarding is the part that breaks.

Why it fails at a ten-person company#

The person who left had access in more places than anyone wrote down.

• Google Workspace or Microsoft 365. The primary account, plus mail forwarding, shared drives, and any OAuth tokens the user granted to third-party apps.
• GitHub. Organization membership, outside collaborator status on individual repositories, personal access tokens, and SSH keys. Removing a person from the organization is a separate action from suspending their company email; GitHub documents it in removing a member from your organization.
• AWS and GCP. IAM users with console passwords or access keys, roles assumed through a federated identity, and service accounts the person created.
• SaaS tools. Slack, the error tracker, the analytics tool, the password manager, each with its own user list and, often, local passwords that bypass single sign-on.

HR knows the termination date. The HR system, the payroll system, and the identity provider each hold a record of the person, and none of them tells GitHub. In a company of ten, the offboarding process is a founder remembering which tools the person used. In a company of forty, it is a checklist in a ticket that someone closes after finishing the three items they remembered.

What an auditor samples#

For a Type 1 report, the auditor looks at whether the control is designed and in place on a date. For a Type 2 report, the auditor tests operation across the whole observation period. Type 2 is where offboarding gets exposed, because every termination in the window is in the population.

The auditor takes a sample from the HR termination list and requests, per person:

1. The termination date from HR.
2. The date and evidence of account removal for each in-scope system.
3. The time between the two, measured against the deadline in your written policy.

Expect three kinds of failure. The account was removed, but later than the policy deadline. An account in one system was never removed, and surfaced when the auditor compared the termination list to the user list exported from that system. Or the evidence exists only as a ticket marked done, with nothing showing the state of the systems.

The second failure matters most. The auditor can export the GitHub member list on the day of testing and compare it to the HR list. A former employee still in the organization is a finding regardless of what the checklist says.

What evidence holds up#

A closed ticket says someone believed they finished. A screenshot of the Workspace admin console shows one system at one moment, with no record of the others.

Evidence that survives an auditor's questions reads back from each system after the change:

• The identity provider shows the user as suspended or deactivated, with a timestamp.
• The GitHub organization member list, exported after removal, does not include the user.
• The AWS IAM credential report shows no active password or access keys for the user, and AWS documents the removal steps the report should reflect.
• Each SaaS user list, exported after removal, does not include the user.

Each item is a record the system produced about itself, dated, and tied to the person and the termination. Put together, they answer the auditor's question without asking the auditor to trust the checklist.

Make termination revoke access#

Manual offboarding fails on the Friday afternoon when two people leave. Three changes remove the dependence on memory.

Make the identity provider the source of access. Put GitHub, Slack, and the major SaaS tools behind single sign-on from Google Workspace, Microsoft 365, or Okta, and turn off local passwords. Suspending one account then cuts off every app behind it. Anything outside single sign-on stays on a short list you check by hand.

Connect HR to the identity provider. Rippling and Gusto hold the termination date. Where the HR system can drive the identity provider, a termination in HR suspends the account on the effective date without a person in the loop. Where it cannot, a named person owns the handoff and the policy states the deadline.

Write the deadline down. The control tests against your own policy, so the policy needs a number: same business day, 24 hours, or whatever you can meet every time. A deadline you miss twice is worse than a longer one you meet.

Where Deixic fits#

Deixic reads the termination from the HR system and finds the person's remaining access across the connected systems: the Workspace account, GitHub membership, IAM users and keys, and SaaS accounts. It removes the access within your written policy, waits for a named approver where your policy requires one, and reads each system back afterward. The read-back, the approver and reason, and the before and after state attach to the test and are kept in a signed, hash-linked receipt. The auditor's sample then comes from one record per person, and your own coding agents can read the same record over MCP.

Whatever tooling you use, run the auditor's test yourself before the audit. Take your last three departures, export the member list from every system, and compare. The gaps you find are the findings you would otherwise receive.