What does access removal lag look like after an assignment ends?

Question and scope

This review asks how to measure the lag between the end of an assistant's assignment and the removal of that assistant's access. The unit is an account or credential tied to the assignment, not the person in general. The scope includes email, file storage, task tools, client systems, and any shared credential the assistant used. The result is an evidence standard for offboarding, not an estimate for a specific provider.

Removal lag matters because an active account can outlive the business reason for it. A former assistant may retain access to client data, internal notes, or billing records. The risk grows when the account is shared or when the client owns the system. A measured lag turns a vague assurance into a fact the buyer can review.

The review treats a disabled login and a revoked session as separate events. A password change may leave an active session usable, and a disabled account may still appear in a client's shared folder permissions. The evidence standard should cover both the authentication path and the residual sharing path. Otherwise the measured lag can look better than the real exposure.

The review should state whether it covers the provider's own tools, the client's tools, or both. A provider can control its email and task board but may only request removal in a client's accounting system. Combining the two without a label hides where the delay occurs. Report them as separate populations with separate owners.

The review should also record who can remove access when the usual owner is unavailable. A named owner without a backup is a single point of failure, especially at the end of a month or during a holiday. Test the backup path on one account before the next exit. The lag measurement is only meaningful if the process works when the primary owner is away.

Defining removal and lag

Removal means the account can no longer authenticate, not that a ticket was opened or a manager sent a request. For shared credentials, removal means the credential was changed and the former assistant cannot retrieve the new value. For client systems, removal means the client's own user list no longer shows the account. Record the exact evidence for each definition.

Lag is the time between the assignment end and the confirmed removal. Use the later of the last working day and the formal notice date as the start, and state which one you used. Use the timestamp from the system or the client confirmation as the end. A lag calculated from a ticket closure date measures process, not access.

Record whether the assignment ended voluntarily, involuntarily, or through a client request. Each path has a different notification chain and a different risk of delay. An involuntary exit may require a faster removal than a planned handover. The start date and the path belong beside the lag measurement.

Evidence needed for each account

Collect the system name, account identifier, permission level, owner, and removal timestamp for every account. Add a screenshot or export showing the account is disabled or absent. For shared credentials, record the rotation date and the person who confirmed the new value. For client systems, keep the client's written confirmation.

Note the accounts that could not be verified and why, such as a tool with no audit log or a client that would not share its user list. Treat an unverified account as open rather than closed. The report should show both the verified removals and the gaps. A clean summary that hides the gaps is not evidence.

Check the mailbox rules, calendar delegates, and file-sharing links that are not part of the user account. These artifacts can preserve access after the login is disabled. Add them to the evidence list with the same timestamp standard. A removal review that stops at the user list misses the most common residual path.

Check the account's last activity date as well as the removal date. An account that was never used after the assignment end is a lower risk than one with activity during the gap. The activity log also shows whether the removal actually stopped access. Use it as supporting evidence, not as a substitute for the disabled status.

Sampling the offboarding record

Select completed assignments across several clients and start dates, including at least one involuntary exit. Include assignments that ended during a busy period, because those are the ones most likely to slip. Sample the accounts from the access register rather than from memory. Record the assignment end date and the evidence source for each.

Ask the assistant's manager and the client contact separately, since each may hold a different part of the record. Compare their answers with the system evidence. Where the answers conflict, keep both and mark the account unverified. The sample should be small enough to verify each account properly.

Ask the client to confirm removal in the client's own tool, even when the provider reports a successful offboarding. The client owns the user list and can see an account the provider cannot. Keep the confirmation short and specific: system, account, date, and the person who verified it. A general statement that access was removed is not enough.

Why provider claims are not enough

A provider may state that access is removed on the last day without producing a system timestamp. That statement is a policy, not evidence of the specific account. NIST SP 800-53's account management controls describe authorizing, monitoring, and removing accounts, and the same standard applies to a provider's own process. Ask for the record that shows the control operated.

Client-owned systems add another layer, because the provider may not control the user list. The client should confirm removal in its own tool, not rely on the provider's ticket. A joint confirmation with a date is stronger than either party's assurance. The review should distinguish provider-controlled and client-controlled accounts.

A provider's clean offboarding report can also hide an account that was never in the register. Compare the report with the client's user list and the assistant's actual tool history. An account outside the register is a scope gap, not a zero-lag success. Record it as unverified until someone proves it is gone.

Limits of a retrospective review

A retrospective sample cannot show what would have happened if removal had been faster. It can show whether the recorded removal matched the policy and the assignment end. It cannot prove that no one used the account during the gap. Treat the finding as a control test rather than a breach investigation.

Records may be incomplete, especially for tools that overwrite user status without history. A missing log is a limitation, not proof of a long lag. State the evidence standard and the number of unverified accounts. Avoid reporting a single average when most accounts are unverified.

Separate a policy failure from a record failure. A provider may have removed the account on time but failed to keep the timestamp, or kept a timestamp for an account that was never disabled. The two failures need different remediation. Report them separately so the fix matches the cause.

Reporting and remediation

Report the verified lag, the unverified accounts, and the systems that lack an audit trail. Recommend one control change, such as a removal checklist with a system timestamp or a client confirmation step. Assign an owner and a date for the change. Keep the remediation with the evidence so the next review can test it.

Recheck a small sample after the change and compare the lag and the verification rate. If the lag improves but verification does not, the process may be closing tickets rather than accounts. Fix the evidence before celebrating the speed. The purpose is confidence that access ends when the work ends.

Keep the remediation small enough to finish before the next offboarding. A new policy document is harder to test than a required timestamp field on the existing checklist. Choose one control, assign one owner, and set one date. Then verify the control on a real exit rather than on a training example.