Digital evidence after a cyber incident: business lessons from Europol's new report

The first instinct after a cyber incident is to fix it: disconnect the device, delete the message, reset the account or rebuild the system. Some of those actions may be urgent, but each changes the environment. Without a plan to preserve relevant data, an organisation can erase the information needed to establish what happened, who was affected and whether access persists.

On 16 October, Europol published Digital forensics: gap analysis, prepared with the European Commission. Its primary subject is law-enforcement capability across EU Member States. It identifies pressure from the growing volume and variety of evidence, expensive or rapidly ageing tools, inconsistent formats and validation methods, and shortages of specialist expertise.

Breachroad’s conclusion: this is not a corporate incident-response manual, but its principles carry an important organisational lesson. Logs, devices, messages and cloud records are useful only when their source, collection method, handling history and reproducibility are understood.

Why the digital trail is becoming harder to collect

Relevant information rarely lives on one computer. An incident may leave traces on an employee’s phone, a mail platform, an identity provider, a SaaS application, cloud infrastructure, backups, network devices and a supplier’s management portal.

Europol highlights challenges involving cloud services, the Internet of Things and connected vehicles. Encryption and custom technologies add difficulty to access and interpretation. Incompatible formats and validation practices make it harder to combine findings and work across borders.

The corporate problem begins in a similar place, although its legal purpose differs. If logs are retained for seven days and the intrusion is detected two weeks later, expertise cannot recreate missing records. If a SaaS vendor exposes detailed audit data only on another subscription tier, the team may discover the limitation during the breach. If every analyst exports data in a different format, building the timeline takes longer.

Preservation does not mean leaving an attack active

Do not postpone isolation of a system under active attack merely to obtain a perfect memory image. Protecting people, funds and production may take priority. The objective is a deliberate sequence, not inaction.

For example, after detecting an account takeover, a team may revoke sessions and block sign-in. Before making the change, if circumstances allow, it exports current identity logs, active sessions, MFA methods, mailbox rules and change history. If the danger is immediate, the team blocks first but records the exact time, operator and reason.

That distinction matters. Response changes the environment, but a documented change can still form part of a credible timeline.

The first hour: a minimum evidence package

Scope depends on the incident, but organisations can prepare a consistent baseline:

1. record the report time, time zone and alert source;
2. assign an incident identifier and owner;
3. preserve the original message, file or alert rather than only a screenshot;
4. record the account, device and connection state before changes;
5. export relevant mail, identity, EDR, cloud, proxy and application logs;
6. log every action, including who did what, when and why;
7. keep originals separate from working copies;
8. agree access, retention and disclosure rules with legal and privacy teams.

A file hash can help show that a copy has not changed, but a hash alone does not create trustworthy evidence. Collection context, time, source, tooling and access control also matter.

Actions to avoid by default

An employee should not delete a suspicious message before reporting it, send the file through a personal messenger or open it on additional devices. An administrator should not clear logs or immediately rebuild a system without preserving state, unless safety requires the faster action.

Sensitive material should not be pasted into an arbitrary AI service for a “quick analysis”. Doing so may breach privacy rules, confidentiality obligations or incident-handling terms. Even an approved tool should receive only the material authorised for that purpose.

AI can assist, but its result must be verifiable

Europol sees potential for AI to analyse large datasets, automate tasks and produce investigative leads. It also stresses transparency, traceability, documentation, reproducibility and manual verification. Original evidence and a clear chain of custody must remain intact.

In a corporate investigation, this means a model-generated summary is a lead, not the source record. Retain the input logs, tool or model version, data scope, prompt, analysis time and reviewing person. A critical conclusion should be confirmable without trusting the AI response alone.

What to prepare before the next incident

The work completed before an alert saves the most time:

• a map of systems and data owners;
• verified log retention for critical services;
• tested export procedures for Microsoft 365, Google Workspace, cloud and EDR;
• a protected evidence repository with access controls;
• a supplier list and known log-delivery times;
• coordination rules for IT, legal, HR, communications and leadership;
• criteria for bringing in external forensic support or law enforcement;
• an exercise in which participants actually export data rather than only discuss slides.

A small organisation does not need its own forensic laboratory. At minimum, it should know which records disappear fastest, who can retrieve them and where they can be preserved safely.

Report findings and business recommendations

The gaps in tooling, interoperability, training and resources, along with requirements for transparent AI use, come from the Europol report and the European Commission summary. These publications address law-enforcement needs; the announcement does not itself impose a new corporate obligation.

The corporate evidence package, response sequence and AI-handling rules above are Breachroad recommendations derived from those principles. Start with an incident response plan, then test roles, decisions and data collection through an incident-readiness tabletop exercise.