Prior access should change when replacement custody is verified and the buyer understands what every old identity, key, and integration still controls.
Build the revocation set
List human accounts, organization roles, personal tokens, deploy keys, SSH keys, cloud roles, app-store users, domain contacts, support accounts, database users, dashboards, recovery channels, local devices, and shared credentials associated with the departing party. Include identities that appear in automation even if no person logs in with them directly.
CISA guidance emphasizes offboarding and immediate revocation of personnel access, but safe execution still requires knowing which identities are personal and which power production. Mark each item remove, rotate, reassign, retain temporarily, or investigate. A retained exception needs an owner, reason, compensating control, and expiration rather than an informal promise to clean it up later.
Verify replacement paths first
The incoming owner should demonstrate administrative access, deployment, monitoring, incident communication, billing visibility, and recovery for the agreed estate. Confirm that organization ownership is not concentrated in one unreachable person. GitHub explicitly recommends at least two organization owners because a sole owner can leave projects inaccessible when that person is unavailable.
Review secrets and deploy keys after repository transfer because GitHub states that they remain associated. Rotate or replace them according to the buyer's risk decision, then run the affected workflows. Do not assume that a repository move changes an external cloud credential, payment method, DNS control, package token, webhook owner, or marketplace account.
Record removal and residual exceptions
Capture the provider, identity, prior role, action, actor, time, verification, and ticket or receipt for every disposition. Test the critical path after removals and watch for failed automation. If a rollback requires temporarily restoring access, the buyer should approve that condition and set a new removal point rather than letting the exception become invisible.
Reality Contact, LLC prepares the register and facilitates verification for Release Custody Record. The buyer directs all access changes and decides timing with its security, legal, human-resources, and platform owners. This operational record does not replace an incident response, forensic review, employment process, contract interpretation, or provider-specific security assessment.
Where the service stops
Reality Contact, LLC documents and facilitates a software ownership transfer but does not give legal advice, determine intellectual-property title, warrant the software, certify security or compliance, hold production credentials after the engagement, perform unilateral access revocation, or guarantee a release will be incident-free. The buyer names the authorized incoming owner, secures cooperation from current custodians, approves account and repository changes, performs the shadow release, accepts or rejects exceptions, and directs the relevant providers to revoke or reassign prior access. This operational handoff service does not replace legal, intellectual-property, security, compliance, employment, finance, provider, or incident-response review. The buyer controls every repository, account, credential, release, acceptance, and access decision; private materials wait for secure intake and written deletion terms.
Sources: CISA vendor offboarding guidance for smaller businesses; GitHub explanation of what remains associated after repository transfer.