TR0.6 Legal, Regulatory, and Chain-of-Custody

When the notification clock starts

Three regulatory frameworks impose breach notification timelines that directly affect triage decisions.

Figure TR0.6 — Regulatory notification timelines. The triage responder's classification decision often starts the clock. A TP classification confirming personal data exposure triggers the GDPR 72-hour timeline from that moment.

GDPR Article 33 requires notification to the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware" of a personal data breach. Supervisory authority guidance is clear: awareness occurs when the organization has a reasonable degree of certainty that a breach has occurred. The triage responder's TP classification — "this is a confirmed incident involving personal data" — is that reasonable certainty.

The 72-hour clock starts at the moment of classification, not at the moment the alert fired, not at the moment the investigation concludes, and not at the moment management is briefed.

The practical implication: fast triage accelerates the notification clock but gives more time for investigation. If the responder classifies at minute 15, the organization has 71 hours and 45 minutes for investigation and notification preparation. If the responder classifies at hour 4, the organization has 68 hours. Article 33(4) explicitly allows providing information "in phases" without undue delay — the initial notification can contain incomplete information, with supplementary notifications as the investigation reveals additional scope.

NIS2 Article 23 introduces a faster initial obligation: an early warning to the national CSIRT within 24 hours of becoming aware of a "significant incident," followed by a formal incident notification within 72 hours, and a final report within one month. NIS2 applies to essential and important entities across the EU — sectors including energy, healthcare, finance, digital services, and manufacturing.

As of early 2026, approximately two-thirds of EU member states have completed transposition into national law, with the remainder in advanced legislative stages. The European Commission proposed targeted amendments in January 2026 to simplify compliance for smaller organizations, signaling that NIS2 is a living framework that will continue to evolve.

The early warning doesn't require full analysis — it requires an indication of whether the incident is suspected to be caused by malicious acts. The triage classification (TP plus suspected malicious) satisfies this requirement. The 72-hour formal notification requires an initial assessment of severity and impact — which the triage report provides. The one-month final report requires root cause analysis and remediation — which is the investigation team's responsibility, not the triage responder's.

DORA (Digital Operational Resilience Act) applies specifically to EU financial sector entities and imposes its own classification and reporting timeline. Where DORA provisions are equivalent to or stricter than NIS2, DORA takes precedence — financial entities subject to DORA don't face duplicate NIS2 reporting obligations for the same incident types.

SEC 8-K filing (for US-listed companies) requires disclosure of material cybersecurity incidents within 4 business days of determining materiality. The materiality determination is a legal judgment, not a triage decision — but the triage report feeds the information that legal counsel uses to assess materiality. The triage responder doesn't need to know whether the incident is material. They need to produce a triage report that enables legal to make that determination.

The triage report as a legal document

The triage report is the first formal record of the organization's awareness and response. If a supervisory authority asks "when did you become aware, and what evidence supported that determination?", the triage report answers the question. A structured, timestamped report with documented evidence references demonstrates due diligence. An informal Slack message saying "looks like we got hacked" does not — and may actually be used as evidence that awareness occurred earlier than the formal notification claims.

Every element in the triage report serves a dual purpose: operational (guiding the investigation team) and legal (demonstrating the organization's response was timely, proportionate, and documented). The classification timestamp starts the notification clock. The evidence references demonstrate the basis for the classification — satisfying GDPR Article 33(3)(a) which requires describing the "nature of the personal data breach." The containment actions demonstrate the "measures taken to address the breach" required by Article 33(3)(d).

The scope assessment — which environments are affected, what data is at risk, how many data subjects are potentially impacted — demonstrates the "likely consequences" required by Article 33(3)(c).

The triage responder should not write the regulatory notification itself. But they should write the triage report knowing that it will be the primary source document for the notification. Clear language, precise timestamps, documented evidence references, and explicit scope boundaries make the DPO's job of drafting the notification significantly easier — and produce a more defensible regulatory record.

Chain-of-custody documentation

Chain of custody documents who collected what evidence, when, from where, and how it has been stored since collection. Without this documentation, evidence may be challenged as unreliable or inadmissible in regulatory proceedings, legal disputes, or criminal investigations. For triage — not full forensics — the documentation requirements are manageable: 6 elements per evidence item collected.

The six elements: (1) evidence description — what the item is and why it was collected, (2) collector identity — the person who performed the collection, (3) collection timestamp in UTC — when the collection occurred, (4) source location — the system, path, or log table the evidence came from, (5) integrity hash — SHA256 computed immediately after collection to prove the evidence hasn't been modified, and (6) storage location — where the evidence is physically or logically stored after collection.

The integrity hash is the critical element. A SHA256 hash computed at collection time and recorded in the custody log proves that the evidence file the investigation team examines is identical to the file the triage responder collected. If the hash matches, the evidence is intact. If it doesn't, the evidence has been modified — accidentally or deliberately — and its reliability is compromised. The hash takes 2 seconds to compute and eliminates an entire category of legal challenge.

#!/bin/bash
# Triage evidence collection with chain-of-custody metadata
# Generates: evidence files + custody_log.json
COLLECTOR="Rachel Osei (SOC Analyst, NE CSOC)"
INCIDENT="INC-NE-2026-0227"
TARGET="SRV-NGE-BRS-DB01"
OUT="/mnt/evidence/${INCIDENT}/${TARGET}"
mkdir -p "$OUT"
# Function: collect file with custody metadata
collect() {
    local src="$1" desc="$2"
    local fname=$(basename "$src")
    cp "$src" "$OUT/$fname"
    local hash=$(sha256sum "$OUT/$fname" | awk '{print $1}')
    echo "{\"item\":\"$desc\",\"source\":\"$src\"," \
         "\"collector\":\"$COLLECTOR\"," \
         "\"timestamp\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"," \
         "\"sha256\":\"$hash\"," \
         "\"stored\":\"$OUT/$fname\"}" >> "$OUT/custody_log.json"
}
# Collect evidence items
collect "/var/log/auth.log" "SSH authentication log"
collect "/var/log/syslog" "System log"
ps auxwwf > "$OUT/processes.txt"
collect "$OUT/processes.txt" "Running process snapshot"
ss -tnp > "$OUT/connections.txt"
collect "$OUT/connections.txt" "Network connection snapshot"
echo "Evidence collected: $(wc -l < $OUT/custody_log.json) items"
echo "Custody log: $OUT/custody_log.json"

The script produces a custody_log.json with one entry per evidence item — description, source path, collector identity, UTC timestamp, SHA256 hash, and storage location. The production triage scripts in TR4 and TR9 generate this metadata automatically. The responder's only manual documentation requirement after running the script is recording the physical storage location if evidence is transferred to removable media, and signing the transfer if the media is handed to the investigation team.

Defensible actions during triage

Every triage action should be legally defensible — meaning it can be explained and justified to a regulatory authority, legal counsel, or a court. Five criteria determine defensibility.

Necessity. Was this action necessary for the triage? Running ps to identify suspicious processes is necessary. Installing Wireshark to capture traffic may be excessive for initial triage — that's an investigation-phase action.

Proportionality. Was the action proportional to the situation? Capturing auth.log for SSH analysis is proportional. Imaging the entire 2 TB disk during triage is disproportionate unless evidence destruction is imminent and no other preservation option exists.

Documentation. Was the action documented with timestamps? Script output with a custody log is documented. Manual commands typed without recording are undocumented — and undocumented actions are difficult to defend in a regulatory inquiry.

Minimization. Was the data collected limited to what was needed? Auth.log for SSH session analysis is minimal. Copying all of /home for "completeness" is excessive and may violate data minimization principles under GDPR Article 5(1)(c).

Authorization. Was the responder authorized to access this system and collect this data? A SOC analyst with delegated incident response authority under the organization's IR policy is authorized. A junior analyst without IR delegation needs escalation before collecting evidence — not because the collection is wrong, but because the authorization chain must be documented. The IR policy should explicitly name the roles authorized to perform triage evidence collection: SOC Analyst, Senior SOC Analyst, IR Analyst, SOC Lead.

If your organization's IR policy doesn't include this delegation, flag it to your SOC lead — the 5-minute policy update that adds "SOC Analysts are authorized to collect volatile evidence during triage under the supervision of the SOC Lead" permanently resolves the authorization question for every future incident.

The critical principle for the first responder: you cannot go back and recollect evidence you contaminated. A memory dump without a hash is indefensible in legal proceedings. A log exported without recording the timestamp and method is unreliable as evidence. An endpoint rebooted before capturing volatile evidence has lost data permanently. Document everything as if it will be read in a courtroom — because it might be.

When no formal evidence handling procedure exists

Many organizations — particularly those without a dedicated IR function — have no formal evidence handling procedure. The SOC analyst triaging the alert has no chain-of-custody template, no evidence storage protocol, and no documented authorization for evidence collection. This is common, and it should not prevent evidence collection.

Collect immediately with ad-hoc documentation. Evidence is volatile, and delay means permanent loss. The custody log script above provides the documentation structure. A USB drive with the evidence files and the custody_log.json, stored in a locked cabinet with a note recording who placed it there and when, is legally stronger than a perfectly procedural collection that started 30 minutes late because the analyst was waiting for authorization.

After the incident, use the ad-hoc collection as the basis for building the formal procedure. The triage script, the custody log format, the storage location, and the authorization delegation all become part of the IR policy. At NE, the current evidence handling procedure was built entirely from lessons learned during the first three incidents — each one revealed a gap, and the gap was closed before the next incident. The procedure didn't exist on day one. It was built iteratively from operational experience.