Short answer: IT forensics examines which technically observable traces exist for an incident, how reliable they are and which cause hypotheses are supported or contradicted by the available evidence.

Reconstruct IT incidents technically instead of assigning blame prematurely

For security incidents, data loss, unexpected system changes or disputed IT events, a single log entry is rarely sufficient for a reliable conclusion. Relevant traces can arise at different levels: operating system, application, cloud service, network, repository, deployment, database or backup.

The examination connects this evidence by time and version. Observed finding, technical interpretation, cause hypothesis and statement boundary are documented separately. Missing logs or retention gaps are not replaced by assumptions.

Typical reasons for an assignment

cyber or security incident with an unclear technical sequence
data loss, unexpected system change or unexplained system state
dispute about the time, provenance or technical cause of a change
review of existing incident, forensic or log analyses
technical evidence preservation for insurers, companies, courts or law firms

Typical technical questions

Which digital traces are technically meaningful for the specific incident?
Can timestamps, log events, file or system changes be connected reliably into a chronology?
Which cause hypotheses fit the observed traces and which counter-hypotheses must be tested?
Which gaps, detection limits or later changes restrict the strength of the conclusions?

Examination scope: The scope is limited in advance to systems, time period, data sources and concrete technical questions. Original systems and traces should not be changed unnecessarily. Where copies, images or exports are created, the acquisition method, time, tool state and integrity evidence should be documented where appropriate. Reconstruction can extend only as far as suitable traces remain available and accessible.

From incident to a bounded technical reconstruction

1 Scope & preservation Delimit incident, systems, period and relevant data sources; document changes after the event.

2 Integrity & evidence chain Connect artefacts, copies, hash values, provenance and processing steps as traceably as possible.

3 Timeline & hypotheses Correlate logs, metadata, states and events; test cause and counter-hypotheses against the evidence.

4 Finding & boundary Separate technical finding, interpretation range, data gaps and unsupported conclusions.

A missing log entry does not automatically prove that an event did not occur. Logging configuration, retention, time synchronisation and collection limits are part of the assessment.

The individual steps are adapted to the incident; new evidence can require returning to earlier hypotheses or system states.

Typical examination material

System, application, cloud, security and audit logs including documented retention
Files, metadata, hash values, backups, snapshots, forensic images or exported system states including documented acquisition method
Repository, commit, build, release and deployment information
Configurations, permissions, network and interface information where within scope
Tickets, incident records and technical timelines as context — kept separate from the underlying technical evidence

What you receive

Evidence overview: which sources were examined and what evidentiary value and limitations they have
Technical chronology: time-based attribution of relevant events and system states where supportable
Hypothesis testing: technical cause and counter-hypotheses with supporting and contradictory findings
Finding report: traceable technical conclusions with explicitly stated gaps and statement boundaries

Statement boundary: IT forensics does not determine legal guilt or liability and does not automatically identify an attacker. It also does not replace a 24/7 incident-response service. Statements apply only to the examined systems, periods and preserved traces.

Related services

IT Security Assessment Software Assessment IT Project Assessment Analysis & Assessment

Relevant knowledge

Reconstruct a security incident

Separate incident, system state, traces and alternative explanations.

Evaluate log data

Classify log sources, time references, gaps and correlations reliably.

Timestamps and metadata

Do not equate timestamps with event time or cause without examination.

Integrity and evidence chain

Treat hash values, provenance and processing steps as separate evidence questions.

Preserve web state

Document volatile web and deployment states reproducibly.

Git history and provenance

Reconstruct development states and provenance of technical artefacts.

Frequently asked questions

Is IT forensics the same as incident response?

No. Incident response primarily aims to contain and recover from an active incident. The IT forensics described here focuses on traceable technical reconstruction and evidence assessment. The two can complement each other.

Can an incident be examined without complete logs?

Yes, if other suitable traces exist. The strength of the conclusions decreases with evidence gaps. Missing evidence is documented as a limitation rather than replaced by assumptions.

Do hash values alone prove provenance or identify a responsible person?

No. A hash can support equality or integrity of a specific data object. Provenance, authorship or causation require additional evidence.

Delimit the IT incident technically

Useful starting information includes a short description of the event, the relevant period, affected systems and an overview of available logs, backups, images or other technical artefacts. Changes after the incident should remain traceable where possible.

Send enquiry