How Complete Are Access Removal Records After an Offshore Contractor Exits?

Access removal is one of the few offshore operating events that can be checked almost entirely from records. The question is not whether someone says the account was disabled, but whether the record shows which accounts existed, who owned each one, when removal was requested, when it took effect, and who confirmed the result. This protocol defines a repeatable way to sample exits and score the completeness of that evidence. It does not produce a security certification or a legal opinion, and it does not estimate an industry failure rate. Compare offshore staffing services with the research library when you translate this method into a review plan.

The scope is the access record for a departed contractor or offshore team member during a defined review window. The unit is one person-exit event, not one account. A single exit can involve email, chat, file storage, a ticketing tool, a client portal, and a shared password vault, so the account count is a property of the event rather than the unit itself. Linked events, such as a contractor moving from one client team to another, should be separated from a true exit unless the access was fully removed at the move.

Research question and decision supported

The primary question is whether a reviewer who was not present at the exit can reconstruct the removal from the record. That means the record should show the access inventory, the removal request, the effective time, the confirmation evidence, and any exception. The decision supported is narrow: whether the exit can be closed, or whether an open account or missing confirmation requires follow-up. A second question is whether the same missing fields recur across exits, which would point to a process defect rather than a single lapse.

A complete record does not prove that no other account exists outside the inventory. It proves that the known access was handled and that the evidence can be reviewed. This distinction matters because offshore work often includes client-owned systems that the provider cannot enumerate alone. The protocol therefore treats the inventory source as part of the evidence, not as an assumption. Reviewers should record which inventory was used and whether it was reconciled with the identity provider.

Population and unit of analysis

Define the eligible population as every contractor exit recorded during the window, including voluntary departures, contract endings, and transfers that removed access. Exclude people who never received system access, but keep a count of those exclusions. Include exits that were later reopened because a missed account was found. A reopened case is evidence of an inventory or review problem and should not be dropped from the sample.

The unit is one exit event with a stable case identifier. Each account inside the event receives its own line, with the system name, account type, permission level, removal time, and confirmation source. Do not count an account as a separate exit, because that would let a single person with many accounts dominate the result. Do not merge two exits when a contractor returns within the window, because the return creates a new access grant that needs its own review.

Definitions and measures

Define removal as the point when the account can no longer authenticate or when the access token is revoked, not when a ticket is marked complete. Define confirmation as evidence from the system of record, such as a disabled status, a revocation log, or an administrator report. Define closure as the point when the named reviewer accepts the evidence and records any residual risk. These definitions should be written before sampling so every reviewer applies the same standard.

Measure four things: the presence of an access inventory, the presence of a removal request, the presence of effective-time evidence, and the presence of reviewer confirmation. Report each as a count with its denominator rather than a single composite percentage. A case can have an inventory and a request but no confirmation, which is a different problem from a case with no inventory at all. Keep the missing fields separate so the corrective action matches the actual gap.

Evidence and data dictionary

The data dictionary should include the case identifier, the person's role, the last working day, the systems listed, the inventory source, the request time, the effective time, the confirmation source, the reviewer, the exception reason, and the closure time. Add a field for shared or generic accounts, because those often survive a personal exit. Add a field for client-owned systems that require a separate request to the client administrator. Add a field for the person who supplied each record, because provenance matters when two systems disagree.

Evidence should be captured as a reference or a preserved copy, not as a paraphrase. A ticket comment that says access removed is weaker than a screenshot or export showing the account disabled. If the system cannot produce a durable record, the reviewer should note the limitation and the compensating check used. The dictionary should also distinguish not applicable from missing, because a role with no access to a system should not be scored as a failure.

Sampling and collection

Select exits from a frozen list rather than from a list that changes while the review is running. Use a written rule such as every exit in the window for a small population, or a random sample stratified by role and client for a larger one. Include at least one exit that was flagged as urgent and one that involved a shared account. Record the collection date and the version of each system export.

Collect the evidence in the same order for every case: inventory, request, effective time, confirmation, and closure. This order makes missing steps visible early. If a field is unavailable, record the reason and the person who was asked. Do not replace an unavailable record with a plausible assumption. A small sample with honest gaps is more useful than a large sample filled with reconstructed guesses.

Reviewer independence and agreement

Two reviewers should score the same subset of cases before discussing them. Compare their judgments on each field, not only on the overall closure decision. A disagreement about whether a screenshot proves removal may reveal an unclear definition. A disagreement about the inventory may reveal that one reviewer used a different source. Record the first-pass judgments and then discuss the evidence.

Agreement is not accuracy. Two reviewers can agree that a case is complete when both relied on the same weak ticket comment. Follow the agreement check with a source-quality check that asks whether the evidence is independent of the person who performed the removal. Where possible, use a system log or an administrator report rather than a self-reported completion note.

What the evidence can support

The record can support a decision to close an exit, reopen a case, or change the removal process. It can show which systems are consistently covered and which are consistently missed. It can also show whether confirmation is happening within the expected window or only at the end of a monthly cleanup. These are operational findings that a manager can act on without claiming a security guarantee.

The record cannot prove that no unknown account exists. It cannot show whether a client administrator removed access in a system the provider cannot see, unless the client provides confirmation. It also cannot establish legal compliance on its own. The protocol is a review aid, and its conclusions should be limited to the evidence collected and the population defined.

Limitations and error

The main limitation is inventory quality. If the starting list is incomplete, a perfect removal record can still miss an account. Another limitation is timing, because a system export taken after the review may not reflect the state at the exit. Record the export time and avoid treating a later clean export as proof of timely removal. A third limitation is shared accounts, which may be disabled for one person but still used by a team.

Reviewer error is also possible. A reviewer may accept a ticket status without checking the system log, or may mark a field missing when it exists in another system. Use a short calibration set and a clear evidence hierarchy to reduce this risk. Report the limitations beside the result rather than in a separate appendix that nobody reads.

Sensitivity and alternatives

Rerun the count with a stricter definition of confirmation that requires a system log rather than a ticket note. If the completeness rate changes materially, report both results. Rerun with shared accounts excluded to see whether they are driving the gap. Rerun with a different closure rule, such as requiring client confirmation for client-owned systems, to test how much the result depends on the standard.

Consider plausible alternatives before assigning cause. A missing confirmation may reflect a system that cannot produce a durable log, not a careless reviewer. A late removal may reflect a client approval step outside the provider's control. Name those alternatives and the evidence that would distinguish them. Do not choose the explanation that makes the process look best or worst without checking.

Privacy, access, and retention

Use the minimum data needed to review the exit. Replace names with case identifiers in the working sample and keep the crosswalk in a restricted location. Do not copy client records, credentials, or personal data into the review file when a system reference is enough. Apply the same access rules to the review evidence that apply to the underlying systems, and remove the sample when the review is closed.

Retention should be defined before collection. Keep the final findings and the evidence references for the period required by the client agreement or the applicable policy, then dispose of the working copies. Log who accessed the review file and why. A review that creates a new pile of unmanaged sensitive data is not a control improvement.

Reporting template

Report the review window, the eligible exit count, the sampled count, and every exclusion. Present the results by field and by system, with the denominator beside each count. Include a short list of cases that need follow-up, the owner, and the due date. Separate confirmed gaps from unavailable evidence, and state the limitations in the same summary.

Close with three decisions: whether the sampled exits can be closed, which process change will address the most common gap, and when the next review will run. Name the person accountable for each decision. The report should be short enough for a manager to read and specific enough for an administrator to act on. That short list is the handoff to the next review, not a substitute for the evidence itself.

Sources

1. NIST SP 800-53 security and privacy controls
2. NIST Cybersecurity Framework 2.0
3. CISA Cybersecurity Performance Goals
4. CISA Zero Trust Maturity Model
5. NIST Privacy Framework
6. Philippine National Privacy Commission
7. FTC data security guidance
8. HHS HIPAA privacy and security resources
9. OWASP application security resources
10. ISO 9001 quality management principles