Define how to identify, collect and preserve evidence related to security events, so it stays usable for investigations or legal proceedings. Handling evidence properly protects your options later.
What an auditor, or Sekit's evidence engine, asks for.
Incident playbooks, exercises and forensics readiness
The step-by-step guides for the most likely incidents, the tabletop exercises, the post-incident review reports, and how evidence is preserved so an incident can be investigated.
From the Sekit evidence catalog
In practice
Evidence collection usually fails quietly: an admin reboots a compromised server to fix it before anyone thinks to image the disk, and whatever forensic value existed is gone. The practical version of this control is a short, written checklist of what to capture first, memory, logs, disk image, and who is authorized to touch the affected system before an external specialist arrives. Log shipping to storage the endpoint itself cannot alter matters because an attacker with admin rights can otherwise erase the trail. Chain of custody records matter less for small companies until the moment a client or regulator asks who handled the evidence and when.
Common gaps
Nobody has defined what evidence to preserve first during an incident, so systems get rebooted or wiped before an investigation can start.
Logs are stored on the same server they describe, so an attacker with admin access can delete the evidence of their own activity.
There is no chain of custody record for evidence handled during past incidents, leaving no proof of who touched what and when.
Questions your auditor will ask
What is captured first when an incident is suspected?
A written order of volatility guides responders to preserve memory, active connections and logs before anything on the affected system is touched or restarted.
Can logs be altered by someone with access to the affected system?
Logs ship to storage the endpoint cannot write to, so an attacker or admin cannot erase the trail after the fact.
Is there a record of who handled evidence during an investigation?
A chain of custody log records who accessed evidence, when, and why, for every incident investigated.
Where regulation demands it
NIS2 3.5 covers incident response, which depends on evidence being preserved well enough to support the investigation.
NIS2 3.2 requires monitoring and logging, the technical source of evidence this control's preservation and chain-of-custody practice depends on.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.