Incident Evidence Checklist

The first fifteen minutes

1. Start an incident log and keep it. Record each action, who did it and the time, in a single timezone, stating which.
2. Name one incident lead so that decisions are not made by whoever is nearest.
3. Use a channel the attacker cannot read. If email or chat may be compromised, use a phone call or another route.
4. Do not announce conclusions. Record facts and mark guesses as guesses.

Contain without destroying

• Isolate affected machines from the network by unplugging the cable, using a quarantine VLAN or using your endpoint tool's isolate function.
• Do not power them off if you can avoid it. Memory holds running processes, network connections and sometimes encryption keys, and is lost at shutdown.
• If you have to power off, record that you did, when, and why.
• Do not log in to suspect machines with privileged accounts. You may hand the attacker your credentials.

Capture what disappears first

RFC 3227 sets out the order of volatility: capture the most short-lived evidence first. In practice:

1. Memory, using a trusted tool run from read-only media.
2. Running processes, network connections and logged-in users.
3. Temporary file systems.
4. Disk contents, as a forensic image.
5. Logs held remotely, and monitoring data.
6. Configuration and network topology.

Preserve logs before they roll off

• Export firewall, VPN, identity provider, email gateway and endpoint logs.
• Export cloud audit logs: AWS CloudTrail, Microsoft Entra sign-in and audit logs, and the Google Cloud audit logs.
• Export web server, application and database logs.
• Extend retention now. Many systems overwrite quietly after a short window, and an investigation can start weeks after the intrusion.
• Note the clock offset of each source against a reliable time, so events from different systems can be ordered.

Disks, snapshots and cloud

• Image affected disks with a write blocker, and work from the copy, never the original.
• In the cloud, snapshot the volumes of affected instances, keep the instance metadata, and store the snapshots in a separate account the attacker cannot reach.
• Preserve the affected mailboxes, tenant audit logs and the list of OAuth applications and API keys in use.

Chain of custody

Evidence you cannot account for is weak evidence, and in a dispute it may be inadmissible. For every item record:

• What it is, and which system it came from.
• Who collected it, when and how.
• The SHA-256 hash at the time of collection.
• Where it is stored.
• Every transfer: who handed it to whom, and when.

What not to do

• Do not wipe or reimage a machine before imaging it.
• Do not run a cleaning tool on the only copy.
• Do not restore from backup before you know how the attacker got in, or you will restore the way in with it.
• Do not delete attacker accounts or files without recording them first.
• Do not pay a ransom or contact the attacker without senior and legal sign-off.

Who needs to be told, and by when

Several clocks may start at once. This is a prompt to check each, not a statement of your obligations.

• CERT-In. Its directions of 28 April 2022 under section 70B(6) of the IT Act require certain cyber incidents to be reported within six hours of noticing them.
• The Data Protection Board and affected people, if personal data is involved (DPDP Act, section 8(6)).
• Your sector regulator. RBI, SEBI, IRDAI and others each have their own timelines.
• Customers, where contracts require it.
• Your cyber insurer. Many policies make notice a condition of cover, so read yours.
• Law enforcement, where a crime has been committed.

What to hand to the investigators

• A timeline of what you know, with sources.
• A list of affected systems, accounts and data.
• Network diagrams and an asset list.
• Log exports and disk images, with hashes and custody records.
• Dated photographs of any ransom note, rather than a copy of the text.
• Email headers of any phishing message.
• Your incident log: everything done, by whom, and when.

References

• RFC 3227, Guidelines for Evidence Collection and Archiving
• NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide
• CERT-In, directions under section 70B(6) of the IT Act, 28 April 2022
• The Digital Personal Data Protection Act, 2023

This is general guidance for engineers and managers, not legal advice. Obligations depend on your sector, your contracts and the rules in force on the day, so confirm the current position with your counsel and the regulator before relying on it.