How can organisations support forensic investigation of suspected data exfiltration?

Why This Matters for Security Teams

Suspected exfiltration is rarely a single file copy event. More often, it is a sequence of access, staging, compression, transfer, and cleanup that spans human and non-human identities. If evidence is not preserved quickly, teams lose the ability to prove what happened, who or what initiated it, and whether the activity was authorised. That matters for containment, legal defensibility, HR review, and post-incident lessons learned. The NIST Cybersecurity Framework 2.0 treats investigation support as part of broader detection and response discipline, not an afterthought.

For NHI-heavy environments, the identity behind an action can be more important than the device used to perform it. Service accounts, API keys, CI/CD tokens, and agent credentials may never sit on a user endpoint at all, which means conventional endpoint forensics can miss the decisive evidence. NHIMG research shows the scale of that problem: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs — Key Research and Survey Results. In practice, many security teams discover the missing trail only after logs have rolled, tokens have expired, or an attacker has already removed the easiest evidence.

How It Works in Practice

Effective forensic support starts with preserving the evidence path, not just the suspected payload. That means capturing hashes, timestamps, request IDs, identity claims, and the surrounding audit context in a way that can be replayed later. For NHI activity, the most useful artifacts are often authentication logs, token issuance records, vault access logs, API gateway logs, and workload identity traces. Where a copy of the file or object is needed, it should be preserved in a read-only state with chain-of-custody notes. Where a hash is enough, preserve the hash plus the system that calculated it.

A practical workflow usually includes:

• Freeze relevant logs before retention windows expire, especially cloud control-plane, SaaS, IAM, and vault telemetry.
• Record the exact identity context, including service account name, workload identity, session ID, and privilege level.
• Preserve timestamps in a consistent time source so legal and security teams can correlate events across systems.
• Link the suspected action to the access path, such as a CI/CD job, API call, or agent execution trace.
• Quarantine or revoke credentials only after enough evidence is retained to explain the sequence of events.

This is where identity governance and response overlap. If the suspected exfiltration involved a compromised NHI, the evidence should show whether access came from a long-lived secret, an over-privileged role, or a short-lived session that was abused. That is why the Sisense breach and the Schneider Electric credentials breach are so instructive: credential compromise is not just an access problem, it is also a reconstruction problem. Security teams need enough telemetry to show what was used, when, and for what purpose. These controls tend to break down when logs are distributed across cloud, SaaS, and CI/CD systems because the identity chain becomes fragmented before investigators can correlate it.

Common Variations and Edge Cases

Tighter evidence preservation often increases operational overhead, requiring organisations to balance forensic readiness against storage, privacy, and response speed. Best practice is evolving for cloud-native and agentic environments, where there is no universal standard for every telemetry source yet. Current guidance suggests prioritising the systems most likely to hold identity truth: IAM events, secrets managers, workload identity providers, and orchestration logs.

Edge cases matter. If exfiltration is suspected through an AI agent or other autonomous workflow, the evidence set should include tool-use history, prompts or task inputs where policy allows, and any JIT credential issuance that enabled the action. If the activity occurred through a transient container or serverless function, endpoint imaging may be irrelevant, and the decisive evidence may exist only in short-lived logs. If the organisation relies on RBAC alone, investigators may struggle because static permissions do not explain the runtime intent behind the access. For that reason, forensic readiness is strongest when paired with NIST Cybersecurity Framework 2.0 style detection and response discipline, plus workload identity records that show who or what actually acted. The current consensus is that identity-aware evidence collection should be built into incident response, but the exact retention model still varies by platform and jurisdiction.

Related resources from NHI Mgmt Group

• How should teams respond when a secret is found in a support ticket?
• What did the incidents in ServiceNow reveal about support operations?
• When should organisations prioritise relay and coercion controls?
• Why do non-human identities increase data leakage risk?