The first step is to activate the incident response process and preserve evidence. Quickly confirm which systems were accessed, which records may have been removed, and whether the account still has any active permissions. Then contain the exposure, notify legal and compliance teams, and document the timeline so the organization can respond consistently and defensibly.
What to do before you touch the evidence trail
The right first move is to treat the situation as a potential security incident, not just a personnel dispute. Activate the incident response process, preserve logs and mailboxes, and freeze routine changes to the affected account and systems so the team can establish what happened without destroying evidence or widening the loss.
That initial response should also define scope quickly: which repositories, endpoints, cloud services, or collaboration tools the former employee could reach, what data classes were exposed, and whether credentials, sessions, or sharing links still remain valid. If the facts are unclear, a narrow containment step is safer than waiting for perfect confirmation.
FIRST standards and incident response coordination guidance supports this approach because the early priority in any incident is to preserve evidence, stabilize the environment, and coordinate response roles before attribution or root-cause conclusions harden.
How to confirm whether client data actually left the environment
Start with a source-of-truth review of access and activity. Check authentication logs, file access history, email forwarding rules, downloads, cloud sync events, and external sharing activity, then compare those records against the former employee’s last known working window, role, and access entitlements. The goal is to separate routine post-employment cleanup from actual data removal or exfiltration.
Pay attention to whether the person used shared accounts, delegated access, unmanaged devices, or synced data to personal storage. In many cases the decisive question is not only what was copied, but whether the account or session still had a path to the same client data after employment ended. If access was not revoked promptly, the exposure can continue after the employment relationship has ended.
NIST Cybersecurity Framework 2.0 is useful here because it links asset identification, access control, detection, response, and recovery into a single investigation path rather than treating the event as a one-off cleanup task.
Why legal, compliance, and containment must move together
Once the basic facts are forming, containment and notification decisions should be made together. If client records may be involved, legal and compliance teams need to determine whether the event triggers contractual notice duties, privacy obligations, regulator-facing timelines, or customer communication requirements. At the same time, technical containment must stop further access, preserve evidence, and avoid actions that would complicate later proof.
The practical mistake is to delay containment while waiting for a complete legal view, or to rush remediation without documenting who had access, what was changed, and when. The defensible sequence is to restrict the exposure, preserve the audit trail, then assess obligations and downstream communications using the same incident timeline.
NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with this situation because access control, audit logging, incident handling, and configuration controls all matter when determining what was reachable and whether the response was sufficient.
Risk and Threat Considerations
The main risk is not only unauthorized disclosure, but also uncertainty about scope. If the former employee still had active permissions, cached sessions, forwarding rules, synced files, or copied credentials, the organisation may face continuing exposure long after the departure date. That makes the first hours of investigation critical for both containment and defensibility.
Failure mechanism: Residual access, poor offboarding, or inadequate logging lets the organisation miss either the initial removal of client data or later reuse of the same access path. That can turn a contained employment issue into broader data exposure, notice obligations, and loss of evidentiary confidence.
Impact: The business may underestimate the scope of compromise, miss a reporting deadline, overstate or understate the affected records, or preserve too little evidence to explain its conclusion. In practice, the quality of the first response often determines whether the organisation can prove what happened.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Defines incident roles and decision ownership for suspected data theft after offboarding. |
| DE.CM-01 — Monitoring for Anomalous and Suspicious Activity | Supports checking logs, downloads, sharing, and session activity to confirm exposure scope. | |
| RS.MA-01 — Incident Management Plan Implementation | Applies because the question asks what to do first when a suspected incident is identified. | |
| Recommendation — Assign incident ownership and decision authority before investigating the former employee's access. Review access and activity telemetry to identify suspicious access to client data. Activate the incident response plan immediately and preserve evidence before remediation. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Needed to analyze logs and determine which systems and records were accessed. |
| IR-4 — Incident Handling | Directly governs initial response, containment, and investigation steps for suspected exfiltration. | |
| AC-2 — Account Management | Relevant because former employee access must be reviewed and revoked quickly. | |
| Recommendation — Correlate audit records to establish what was accessed and when. Contain the incident and preserve evidence under the incident-handling process. Disable or review accounts and entitlements linked to the former employee. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Incident readiness and response planning are central to the first-step decision. |
| A.5.28 — Collection of evidence | The question explicitly requires preserving evidence in a suspected data theft event. | |
| A.5.18 — Access rights | Former employee access must be verified and removed as part of containment. | |
| Recommendation — Use the incident response process defined in the ISMS to coordinate the initial response. Preserve evidence before making disruptive changes to accounts or systems. Review and revoke remaining access rights tied to the departed employee. | ||
Practitioner Guidance
What to prioritise: First secure the evidence trail, then revoke or verify every remaining access path tied to the former employee. If the account can still authenticate anywhere, treat that as an active exposure until proven otherwise.
What to verify: Confirm last access time, data touched, forwarding or sync behavior, shared links, and any privileged or delegated permissions that survived termination. The investigation is stronger when those checks are time-stamped and reconciled to HR offboarding records.
Practitioner takeaway: The first decision is not whether the data was definitely stolen, it is whether the organisation can still trust the access path and evidence trail well enough to make a defensible conclusion.
Related resources from NHI Mgmt Group
- What should organisations review first when they suspect privilege creep in IT operations?
- What should teams do first when they suspect client-side code can be reverse-engineered?
- What should organisations do first when they suspect a malicious package could be executed in CI/CD?
- What should organisations do first if they suspect attackers are using legitimate credentials to bypass endpoint controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
