On this page
Research context
## Question and scope This protocol asks whether access granted to an outsourced contributor was removed after the engagement ended, and how long the removal took. It covers repository access, cloud roles, support tools, package registries, deployment systems, and credentials that can act on the client's behalf. The study examines the access record and the offboarding evidence; it does not evaluate the person's conduct or the quality of their work. Set the scope to one engagement type and one observation window. An individual contractor, a supplier team, and a staff-augmentation seat have different account models, so mixing them without strata can hide a systemic gap. Record the systems in scope, the identity provider, and the person responsible for each system. If a system is outside the team's control, mark it as dependent rather than pretending the audit covered it.
## Population and unit The unit is one offboarded person-system relationship, not one person and not one ticket. A contributor with repository access, a cloud role, and a support seat produces three units, each with its own removal evidence. This granularity prevents a single closed ticket from making every access path look complete. Link the units with a stable engagement identifier while keeping the system-specific status separate. Define the effective end time from the contract, the manager's instruction, or the supplier's notification, whichever the policy uses. Record the date the access was actually removed and the date the removal was verified. If the person never had access to a system, record not applicable rather than a pass. A blank cell should not be treated as evidence that access was absent.
## Access inventory Build the inventory from authoritative sources: the identity provider's group membership, the repository's collaborator list, cloud role assignments, the support platform's agent list, package registry owners, and deployment system users. Do not rely only on the onboarding ticket, because access may have been granted later through a group or an integration. Check personal accounts, shared service accounts, personal access tokens, SSH keys, deploy keys, and OAuth applications that can act without an interactive login. For each system, record the account identifier, the access level, how it was granted, and the authoritative source used to verify removal. A group membership removal is not the same as deleting a direct collaborator; the audit should check both. A token owned by the person but used by a pipeline is still a credential that needs an owner and a rotation decision. Keep the inventory in an approved system with restricted access. Do not copy secrets or full token values into the audit record. A hash, a token identifier, and the revocation time are enough to support the finding without creating a new exposure.
Practical application
## Offboarding record A useful offboarding record names the person, the engagement, the effective end time, the systems covered, the person who performed each removal, and the verification method. It should also name the backup owner for each system so a single unavailable administrator does not leave access in place. If the supplier is responsible for removing access, the client still needs a verification step and a named client owner for the residual risk. Separate the request from the evidence. A ticket that says access was removed is a claim; a screenshot of the collaborator list after removal, a role assignment export, or an identity provider log is evidence. For systems that cannot produce an export, record a manual check with the reviewer and the time. The record should let a later auditor repeat the check, not just read that someone else did it. Include the handover of client-owned artifacts: repositories, documents, design files, package ownership, and any credentials shared during the engagement. Access removal is incomplete if the former contributor remains the owner of a package, a domain, or an integration that the client depends on. That ownership is a separate finding with a separate remediation path.
## Measurement and analysis Measure removal time from the effective end of access to the verified removal timestamp. Report the median and the distribution by system, along with the count still open at the audit date. A single average can hide a long tail in one critical system, so show the systems with the slowest removal and the reason. If the policy allows a grace period, state it and measure against that rule rather than against zero. Report residual access by system, access level, and whether the account was interactive or non-interactive. A former contributor with read access to a public repository is a different risk from one with an active deploy key or an organization owner role. Do not collapse those into one count. If a token was rotated rather than deleted, record the rotation and the new owner. Compare engagements only when the account model and the offboarding process are similar. A difference in removal time may reflect the system's tooling, the supplier's cooperation, or the client's verification practice. Inspect the cases behind the difference before proposing a cause. The purpose is to find the system that needs a better removal path, not to rank people.
Operating controls
## Limitations An audit can verify only the systems in its inventory. Access through a personal cloud account, a locally stored token, or a vendor portal outside the identity provider may be invisible. A clean repository export does not prove that a copied credential is unusable. The study should state which systems were not observable and what evidence would be needed to close that gap. The effective end time may be ambiguous when a contract ends on a weekend, a notice period is disputed, or a supplier reassigns the person to another client. Record the interpretation and apply it consistently. If the removal was performed before the formal end time, that is not necessarily a failure; note the reason and the authorization. Public control frameworks describe access management and offboarding practices, not a local benchmark. The result is a description of this engagement sample. It should trigger remediation and a follow-up check, not a claim that the organization is secure or insecure in general.
## Review and next action Prioritize residual access that can change code, deploy software, read customer data, or administer identity. Assign an owner and a deadline for each. For a systemic gap, choose one change: add the system to the offboarding checklist, automate group removal, require a client verification step, or rotate shared credentials when a contributor leaves. Test the change on the next offboarding rather than waiting for the next annual audit. Repeat the protocol on a small sample after the change. Report the time to removal, the residual count, and the systems that still lack evidence. Close the review when the owner accepts the remaining risk and the next verification date is on the calendar. Keep the audit record with the engagement so a future reviewer can see what was checked and what was not.
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
How much review evidence does an outsourced pull request need?