Origin
In early September Pranay, one of our founders, spent 2 days with the IT lead at a 300-person fintech. They were 2 weeks from fieldwork on their first SOC 2 Type II, covering March to August, and wanted someone to read their offboarding evidence the way the auditor would.
The IT lead wasn't worried about offboarding. 23 people had left during the window, and every one of them had been deactivated in Okta. He'd checked. The access was gone.
So we did what the auditor would do. We took the HR termination report, picked the first leaver on it, an analyst whose last day was 14 March, and tried to show the date her access was removed.
We couldn't, and for 13 of the 23 nobody else in the building could either.
A Type II samples leavers from the HR list and asks, for each one, when access came off, against the window your own policy promises. That's a question about the past. Most of the identity stack is built to answer questions about now: who's active, which groups they're in, which apps they're assigned. Okta, Entra and Google answer those accurately whenever you ask.
Where the past does get recorded, it's thrown away on a schedule. Okta keeps its System Log for 90 days. Entra keeps audit logs for 30 days on P1 and P2. Google Workspace keeps admin log events for 6 months. For a window running March to August, with fieldwork in September, the deactivation events for everyone who left before June had expired before anyone looked. The logs did what they're documented to do.
Evidence is whatever the work leaves behind while it happens. You can't go back and gather it for an audit, and most teams only find that out in the weeks before fieldwork.
The present has a gap of its own. The usual fallback is an export of Okta users, to prove the leavers are at least gone now. Okta's list-users call "omits users that have a status of DEPROVISIONED" unless you filter for them. The obvious export shows who is here, and the auditor's sample is made entirely of people who aren't. The file the fintech had already put in its evidence folder had none of its 23 leavers in it.
Compliance automation platforms tend to inherit the same view. They snapshot the active-user list every day from the day they're connected, which is rarely the first day of the audit window.
Some of it can be rebuilt. Every Okta user object carries statusChanged, the last time the user's status changed, and for a deactivated user who hasn't been touched since, that's the deactivation. It only keeps the last change, so it's weaker evidence than a log event, and the write-up should say so. It gave the fintech a usable date for 12 of its 13 early leavers. The 13th had been deleted from Okta in a cleanup, and a deleted user has no fields left to read.
The usual reading of all this is that the offboarding was fine and the paperwork is broken. That gets the order wrong. For a Type II, a removal with no date attached is, as far as the test goes, a removal that didn't happen. The auditor doesn't have to give you the benefit of the doubt, and a good one won't.
How much evidence the work leaves depends almost entirely on how the work was done. A removal through an identity provider leaves a log event, for as long as the provider keeps it. A removal done by hand in an app with local logins, or in an AWS account with IAM users from before SSO, leaves a user list that can prove the account is gone today and never when. Those end up as exceptions, and the best a team can do is find them before the auditor does. The fintech went into fieldwork with 5 on a list it had written itself.
One part no tooling fixes. HR often keys a termination days after the person's last day, and no IT team can beat a clock that starts before they're told. Start the clock when IT is notified and keep that timestamp. The auditor can still record the HR delay as its own exception. It just stops showing up as IT removing access late.
The fix is to move the record closer to the moment of the work. Pull the identity provider's log every month into storage you keep for 13 months, or stream it. Write a timestamp for every removal outside it, from the app's own audit log where there is one and a ticket where there isn't. Save the filtered export with the query showing, so the auditor can run it again.
That's how we build Iden. A termination in the HRIS removes access across every connected app, through SCIM, an API or by operating the app's admin console, and each removal is written down with its time and method as it happens. Where a step still needs a person, the best any tool can record is who marked it done and when. That's weaker evidence, and an auditor is right to treat it that way.
We'd take one leaver from the start of your audit window and try to prove, with you, when their access ended in every app they had. No deck. Just the product.