The final invoice settles the commercial relationship. It does not close the vendor’s accounts, revoke its service principals, expire its API keys, or remove its cloud tenancy. Those persist until someone specifically ends them, and the record of what exists is held by the party leaving.
Six stages, and the question at each
An orphaned credential remains usable without an accountable owner or a justified current purpose. Tracking it means recording identifiers and secure-store references — never secret values — with the issuing administrator and the application owner identified before anything is changed.
Issue. Owner, purpose, audience, resource scope, and an expiry or review trigger. Can the identity obtain broader or longer-lived access than intended?
Operate. Usage evidence, monitored exceptions, and a dependency map. Does an inactive interval contain disaster recovery or seasonal work?
Rotate. The new credential validated in the required workflows, and the old one’s disposition recorded. Were retries, scheduled jobs, or copied secrets missed?
Transfer. Recipient-controlled issuance and recovery, plus any approved continuing vendor access. Is the recipient merely borrowing the departing party’s identity?
Revoke. Grants, existing sessions, authority to issue new sessions, trust paths, and propagation all checked. Can an existing session, a resource-based grant, or another identity still reach the asset?
Close. Timestamped tests, retained exceptions, and a responsible owner. Has removal been demonstrated within a defined scope?
Revocation is not one action
The assumption that disabling a credential ends the access is where closeouts fail.
Temporary-session permissions are evaluated on each request, policy changes take time to propagate, and effective restriction has to account for resource-based grants and the type of session in use. So a disabled key can coexist with a live session, and a removed identity can coexist with a resource policy that grants access by other means.
The practical closeout question is whether previously issued sessions or resource grants remain usable after the key is disabled. Closure stays pending until those paths are checked — and until the retained functions that were supposed to keep working are confirmed to still work. Negative access tests are scoped to authorised test resources.
Temporary credentials are preferred where the integration supports them, and long-lived exceptions exist. Those need their necessity documented alongside the protective controls, rather than being treated as failures to be eliminated.
There is no established rotation interval here. Replacement timing follows applicable policy, assessed risk, and events such as compromise or departure, and planned continuity changes are separate from urgent incident containment.
The inventory has holes, by construction
Shadow infrastructure is infrastructure a prototype uses that the responsible institution has not adequately registered or brought under control. An asset known to one developer and to no institutional record is exactly this.
Five reconciliation inputs, each with a stated blind spot. Cloud exports miss unauthorised accounts and unsupported resource types. Identity and deployment records miss running resources left behind by removed code or inactive jobs. Procurement and billing records miss free services and personal payment routes. Network and application configuration depends on access and traffic visibility. And team or vendor confirmation is attributed testimony rather than observation.
That last one matters at closeout: a customer’s cloud export cannot attest to a vendor’s internal estate, so the vendor’s own environment enters the enquiry as a question rather than an export.
A team whose cloud export lacks a callback endpoint referenced in a workflow has not proven the endpoint does not exist. The vendor confirming it belongs to a separate account, with scoped access evidence, adds a dependency and a disposition owner to the register. Neither declaring the export complete nor deleting the endpoint because it was absent is the right move.
Unexplained assets are triaged rather than removed: establish the owner, dependencies, exposure, and approved disposition, then verify that remediation actually changed the exposure. Continuity, retention, and incident-evidence needs are assessed before quarantine or deletion.
Data closeout runs alongside
Access removal and data deletion are separate obligations reaching the same closeout.
Under GDPR, the controller chooses deletion or return after processing services end, including deletion of existing copies, unless law requires storage. Under HIPAA cloud guidance, return or destruction is required at termination where feasible, and where infeasible the protections continue with uses limited to the purposes making it infeasible.
Neither is satisfied by an assertion. The evidence has to cover the stores that actually exist — provider and subprocessor copies, support systems, and backups — which is why the discovery work and the deletion work are the same work.
The rule
What stays fixed is that the closeout is demonstrated within a defined scope, with the scope stated. What changes is which paths remain, and the party best placed to enumerate them is the one with the least remaining reason to.
That is the argument for doing it while the engagement is live. A register maintained during operation makes closeout a verification. A register assembled at closeout makes it an investigation, conducted by people whose contract has ended.
Not to be confused with
An incident playbook. The lifecycle table is for planned continuity changes. Containment after a suspected compromise is a different procedure with different urgency.
Completeness. No method establishes that every asset was found. The register records the inventory boundary, the observation time, and the environments that remained outside inspection.