On this page
Research context
Access closure is usually reported as a completed checklist. This protocol treats it as an evidence question: for a declared offboarding event, which grants existed, which were removed, and what source system record proves the removal? A checklist can be completed while a token, a vendor seat, or a shared credential remains active, and the difference only appears when someone queries the system instead of reading the form.
The unit of observation is one grant held by one identity on one system. A grant is a role binding, a repository permission, a database account, a vendor seat, a token, a key, or a shared credential the identity could use. The identity is the person or service account being offboarded. Counting identities rather than grants hides the fact that one person can hold many paths into the estate.
The grant universe must be built from multiple sources. Start with the identity provider, then repository and cloud role bindings, then the application database, then the vendor inventory, then secret stores and CI configuration. No single console holds the complete picture, and the audit should record which sources were available and which were not.
Indirect grants are the most common gap. A personal access token in a laptop keychain, an SSH key in an agent, a deploy key on a repository, and a saved session on a mobile device all survive an account disable. The audit should name these paths even when it cannot inspect the device, and it should record the owner who can confirm the device state.
The offboarding event has a stop signal. Record who sent it, when, and through which channel. The clock starts at the signal, not at the ticket creation that may follow hours later, and the audit should report both if they differ. A closure that looks fast against the ticket and slow against the signal is a routing problem worth naming.
Closure has three states: removed, not held, and unresolved. A grant marked not held needs a source query that returned zero rows, not a recollection that the person never used the tool. A grant marked unresolved needs an owner, a reason, and a date. Treating unresolved as removed is the failure mode this protocol is designed to detect, and it should be counted explicitly in the readout.
Verification belongs to someone other than the person who removed the access. The verifier runs a query in the source system and records the query text, the timestamp, and the result. An admin summary screen is not sufficient because it can hide role bindings and tokens, and it may show a deleted user while an active key issued by that user remains valid.
Practical application
Timing is descriptive rather than punitive. Report minutes from the stop signal to the first removal, to the last verified removal, and to the closure of the identity record. Separate the waits caused by vendor support, owner approval, and tooling downtime. The interesting number is usually the gap between the last removal and the verification, because that is where a hidden grant surfaces.
Shared accounts need their own rule. If a credential is shared, removing one person does not remove access. The audit records the shared account, the rotation event, and the owner of the next rotation. A shared password that was not rotated is an open finding even when the person no longer uses it, and it will remain open until the credential changes.
Tokens and keys need a search by issuer. Look for tokens created by the departing identity, deploy keys added to repositories, CI variables changed in the period, and cloud access keys. A token list is more reliable than a hunch about which tools were used, and it should include tokens that were created for a temporary project and never revoked.
Vendor seats are often outside single sign on. Where no administrative interface exists, the evidence is a seat list export plus a screenshot with a date, and the audit should mark the verification as manual rather than pretending it is automated. The manual finding needs a named owner and a recheck date, because a seat can be reassigned without a new audit.
Sampling is acceptable for large estates if the sampling rule is declared, because an undeclared convenience sample tends to select the systems that are easiest to query rather than the ones that carry the most risk. Stratify by system criticality and grant type, include every production and customer data grant, and sample the rest with a fixed method. Report the sample size and the population, and do not describe a small sample as a full audit of the estate.
Independence check: have a second auditor pick three closed grants and verify them from the source system. If any is still active, the whole closure set is suspect and the audit should return to the population rather than patching one row. One false closure is evidence about the checking process, not an isolated error. Include the source query and the date on every sampled row so a later auditor can repeat the check without asking the original team which export was used or which filter was applied.
Access after the stop signal is the most important finding. Query the audit log for activity by the identity after the signal. A single successful call is evidence that at least one path remained open, and it should be traced to a grant. The trace is more useful than the log line alone, because it names the control that failed and the system that owns it.
Operating controls
Exceptions require an expiry and an owner. A temporary vendor seat for knowledge transfer is reasonable, but it must have a date and a person who will remove it. The audit reports exceptions by age band, and an exception past its date should be treated as unresolved access rather than a documented decision.
Report the population and the denominators. Grants inventoried, grants verified removed, grants not held, unresolved grants, and exceptions. A closure rate without the population and the unresolved count is not auditable, and a percentage that excludes vendor seats should say so in the same line as the number.
The method has limits. It can verify records, not intent. A removed grant does not prove the credential was never copied, and a vendor without an audit interface cannot provide strong evidence. Those limits belong next to the conclusion rather than in a footnote, because a reader will otherwise treat a closure rate as a security guarantee. A closure rate is only meaningful when the reader can see which systems were in scope and which were not reached.
Security of the audit itself matters. The register contains system names, roles, and sometimes token identifiers. Use least-privilege access, redact identifiers in published excerpts, and set a retention date that matches the company policy. A register that is convenient to share is also convenient to leak, and it maps the estate for anyone who obtains it. The register should name that owner before the next quarter, not after the next incident.
Refresh the protocol when the identity provider, a major vendor, or the repository hosting changes. A new system added to the estate is a new population, and an audit that omits it will report a closure rate that is too high. The practical output is one repair: a rotation for a shared credential, an owner for a vendor seat, a query added to the closure script, or an expiry default for exceptions.
The method reports no local closure times, seat counts, or benchmark figures are reported here. The sources describe access control frameworks and privacy practice; they do not measure this estate or certify any offboarding process. Acceptance is a reviewer who can choose three grants and confirm from the source system that each is gone, and who can find an owner and a date for every exception that remains.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
Secret Exposure Response Completeness Study
Dependency Vulnerability Triage: Reliability of a Declared Queue