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

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

When the notification clock starts

GDPR Article 33 requires notification “without undue delay and, where feasible, not later than 72 hours after having become aware” of a personal data breach. The critical question for triage: WHEN does the organisation become “aware”?

The supervisory authority guidance is clear: awareness occurs when the organisation 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.

This has direct implications for triage:

Fast triage accelerates the notification clock but gives MORE time for investigation. If the responder classifies at 15 minutes (alert time + 15 = clock start), the organisation has 71 hours and 45 minutes for investigation and notification preparation. If the responder classifies at 4 hours, the organisation has 68 hours. The investigation time is the same, but the regulatory risk of missing the 72-hour deadline is lower with fast triage.

The triage report IS a legal document. The classification decision, the evidence that supports it, the timestamps of every action — all of this becomes part of the regulatory record. If the supervisory authority asks “when did you become aware and what evidence supported that determination?”, the triage report answers the question. A structured, timestamped triage report demonstrates due diligence. An informal Slack message saying “looks like we got hacked” does not.

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.” NIS2 applies to essential and important entities in the EU. The early warning does not require full analysis — it requires “an indication of whether the significant incident is suspected of being caused by unlawful or malicious acts.” The triage classification (TP + suspected malicious) satisfies this requirement.

Chain-of-custody documentation for triage evidence

Chain of custody documents WHO collected WHAT evidence, WHEN, from WHERE, and HOW it has been stored since collection. For triage (not full forensics), the documentation requirements are:

What to document for every evidence collection action:

Evidence Item: auth.log from SRV-NGE-BRS-DB01
Collected By: Rachel Osei (SOC Analyst, Ridgeline CSOC)
Collected At: 2026-04-06T15:26:00Z
Collected From: /var/log/auth.log (live system, accessed via SSH from SOC workstation 10.1.2.10)
Collection Method: cp /var/log/auth.log /mnt/usb/IR/SRV-NGE-BRS-DB01/auth.log
Integrity Hash: SHA256: a7c3e1b2d4f5e6a7...
Storage Location: USB drive WD-123456789, locked in SOC evidence cabinet

The production triage script from TR4.10 generates this metadata automatically — the collection log, timestamps, and SHA256 hashes are produced as part of the script execution. The responder’s only manual documentation requirement is: the collector’s identity, the storage location, and the chain of transfer (if the USB is handed to the investigation team, both parties sign the transfer).

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 court. The defensibility checklist:

1. Necessity: Was this action necessary for the triage? (Running ps to identify suspicious processes: necessary. Installing Wireshark to capture traffic: potentially excessive for triage.)
2. Proportionality: Was the action proportional to the situation? (Capturing auth.log: proportional. Imaging the entire 2TB disk during triage: disproportionate unless evidence destruction is imminent.)
3. Documentation: Was the action documented with timestamps? (Script output with collection log: documented. Manual commands without recording: undocumented.)
4. Minimisation: Was the data collected limited to what was needed? (Auth.log for SSH analysis: minimal. Copying all of /home for “completeness”: excessive.)
5. Authorisation: Was the responder authorised to access this system and data? (SOC analyst with incident response authority: authorised. Junior analyst without IR delegation: needs escalation.)

Investigation Finding — IF-2026-TR0-LEGAL-001

Artifact: Chain-of-custody template for triage evidence

Source: Operational procedure — not incident-specific.

Findings:

The triage evidence chain-of-custody requires 6 elements per item: (1) evidence description, (2) collector identity, (3) collection timestamp, (4) source location, (5) integrity hash, (6) storage location. The production triage script generates elements 1-5 automatically. Element 6 (storage location) is documented manually when the evidence media is secured.

• Proves: The chain-of-custody documentation demonstrates that evidence was collected in a controlled, repeatable manner with integrity verification. This satisfies GDPR Article 33(3)(d) (“measures taken to address the breach”) and NIS2 Article 23(4)(a) (“assessment of the significance of the incident”).
• Does not prove: That the evidence has not been tampered with after collection (requires ongoing custody tracking, not just initial collection documentation). That the collection was legally authorised (requires reference to the organisation’s incident response policy and the responder’s delegated authority).
• Next step: Ensure the IR policy explicitly delegates triage evidence collection authority to named SOC roles. Update the triage script to include a configurable “Collected By” field that records the analyst’s identity automatically.

Regulatory reference: GDPR Article 33 (supervisory authority notification), GDPR Article 34 (data subject notification), NIS2 Article 23 (significant incident reporting), NIST SP 800-86 (Guide to Integrating Forensic Techniques into IR).

Troubleshooting

“I do not know my organisation’s notification obligations.” Escalate to legal counsel or the DPO (Data Protection Officer). The triage responder is not responsible for determining notification obligations — they are responsible for producing the triage report that enables legal/compliance to make the notification decision. Include a note in the triage report: “This finding may trigger GDPR Article 33 notification — refer to DPO for assessment.”

“The triage script does not produce chain-of-custody documentation.” Adapt the production script from TR4.10: add a collector variable set at the start of execution, include the collector in the metadata JSON, and append a chain-of-custody entry to the collection log. This is a 5-minute script modification that permanently improves evidence defensibility.