Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which incident-management artifacts should you preserve?
Updated
Preserve the detection record, the decision timeline with timestamps, the severity and reportability decisions with who made them, internal and external communications, containment and remediation actions, and the post-incident review. Preserve them before you triage, not after.
Incident-evidence map, last verified 10 September 2026 against NIST SP 800-61 as guidance, the AICPA Trust Services Criteria CC7.3 through CC7.5, ISO/IEC 27001:2022 Annex A 5.24 to 5.28, and the reporting ladders in Regulation (EU) 2024/2847 Article 14, Directive (EU) 2022/2555, Regulation (EU) 2022/2554, and GDPR Articles 33 and 34. This page is not legal advice, does not determine YOUR obligations, does not decide whether any incident is reportable, does not start a clock, and does not file anything with any authority or auditor.
What this page is, and what it is not
Audience: a security lead or engineering manager who wants the incident programme to be provable after the fact, and who needs the evidence that a regulatory report depends on to still exist when the report is drafted.
This page is not legal advice. It does not determine YOUR obligations, does not decide whether a given event is a reportable incident or a personal-data breach, does not start any clock, and does not file with any authority or auditor. Reportability turns on facts, product scope, sector, jurisdiction, and the affected data — all of which are questions for counsel and your regulator-facing owner. Last verified 10 September 2026.
Two things make incident evidence different from every other category in this cluster. First, it is perishable: container logs roll, ephemeral hosts are replaced, and a well-meaning engineer who rebuilds the affected instance to restore service destroys the only record of how the intrusion happened. Second, the clocks that matter run from awareness, not from resolution — so the record of when you became aware, and who knew what at that moment, is itself primary evidence.
- Preserve first, investigate second. Snapshot volumes and export logs before you rebuild, patch, or rotate.
- Timestamp everything in one timezone, and say which. Reconstructing a 24-hour deadline from mixed local timestamps is where timelines fall apart.
- Record the decision not to report as carefully as the decision to report. An unrecorded no is indistinguishable from never having considered it.
- The near miss and the low-severity event are also evidence. A programme whose record contains only major incidents looks like a programme that detects nothing.
Incident-lifecycle-to-evidence map
First column is the lifecycle stage, second the artifact, third the control intent it satisfies, fourth the failure that most often destroys or degrades it. Last verified 10 September 2026. Not legal advice.
| Lifecycle stage | Evidence artifact | Control intent it satisfies | Common failure |
|---|---|---|---|
| Preparation | The incident-response plan and its version history, the on-call roster for the period, role assignments, and the record of the last plan test or tabletop exercise | A plan exists, is current, and has been exercised. AICPA TSC CC7.3 and CC7.4; ISO/IEC 27001:2022 Annex A 5.24; NIST SP 800-61 preparation phase as guidance. | A plan written once and never tested, or a roster that no longer names people who still work there. |
| Detection | The alert or report that started it, with its raw source: monitoring alert, scanner finding, customer report, third-party notification, or researcher disclosure | Detection is real and traceable to a source. AICPA TSC CC7.2 and CC7.3; Annex A 5.25 and 8.16. | The alert is described in the write-up but the underlying record has aged out, so the detection time cannot be corroborated. |
| Awareness | The record of when a responsible person first knew, who they were, and what they knew — usually the first paging record, ticket creation, or channel message, with timezone | The clock start is documented. Directly relevant to CRA Article 14, NIS2, DORA and GDPR Article 33 timing; AICPA TSC CC7.3. | Awareness reconstructed after the fact from memory, which is the single most contested fact in a late-report enquiry. |
| Triage and severity classification | The severity assigned, the criteria used, who assigned it, when, and any later re-classification with its reason | Severity is assigned consistently against defined criteria, not by mood. AICPA TSC CC7.3 and CC7.4; Annex A 5.25. | Severity downgraded silently, so the record shows a low-severity event that consumed two weeks of engineering time. |
| Evidence preservation | Disk and volume snapshots, memory captures where taken, exported log ranges with their hashes, and the preservation log recording what was captured, by whom, when, and where it is stored | Volatile evidence survives the response. Annex A 5.28 collection of evidence; NIST SP 800-61 and SP 800-86 as guidance. | The affected host was terminated and replaced to restore service, taking the only copy of the local logs with it. |
| Containment and eradication | The actions taken with timestamps and actors: credentials rotated, access revoked, hosts isolated, rules changed, patches applied — plus the change records for each | Response actions were deliberate and authorised. AICPA TSC CC7.4; Annex A 5.26. | Emergency actions taken outside the change process with no retrospective record, so containment and unauthorised change look identical in the log. |
| Impact assessment | The determination of what was accessed, exfiltrated, altered, or made unavailable, the evidence it rests on, and explicitly what could not be determined | Impact was assessed on evidence, and the limits of that assessment are stated. Underpins GDPR Article 33 and 34 analysis; AICPA TSC CC7.4. | An impact statement with more confidence than the logs support. Recording what you could not determine is stronger than implying you determined it. |
| Reportability decision | The written decision on each applicable regime, the reasoning, the named decision-maker, the timestamp, and where advice was taken, the fact that it was | Reporting duties were considered deliberately. Relevant to CRA Article 14, NIS2, DORA and GDPR Article 33; Annex A 5.5 contact with authorities. | No record at all, which is the finding. The decision may well have been right; the absence of a record is what is indefensible. |
| External notification | Submitted notification text, submission receipts or reference numbers, submission timestamps, and every subsequent update or final report | Notifications were made and are reconstructable. CRA Article 14; NIS2 reporting; DORA reporting; GDPR Articles 33 and 34. | A draft kept and the submitted version lost, or a portal receipt never captured. |
| Internal and customer communications | Status-page history, customer notices sent, internal updates, and any regulator or partner correspondence | Stakeholders were informed as the plan requires. AICPA TSC CC2.2 and CC7.4; Annex A 5.24. | Communications live only in chat threads and email inboxes that nobody exports before retention expires. |
| Recovery and verification | Evidence service was restored, the restoration was verified, and residual risk was assessed | Recovery was confirmed rather than assumed. AICPA TSC A1.2 and CC7.5; Annex A 5.26 and 8.13. | Declared resolved when the alert stopped, with no verification record. |
| Post-incident review | The written review: timeline, contributing causes, actions with owners and dates, and the evidence those actions were completed | Lessons produce change. AICPA TSC CC7.5; Annex A 5.27 learning from information security incidents. | Reviews written but action items never closed. The open-forever action list is a finding on its own. |
| Programme-level record | The incident register for the period: every incident and near miss with dates, severity, reportability outcome, and closure | The population is complete, so the control can be tested rather than sampled from the incidents you chose to show. AICPA TSC CC7.3 and CC7.5. | Only significant incidents recorded, so the register implies the year was quieter than it was. |
Reporting clocks that the evidence has to support
This is a pointer, not a determination. The dates and windows below were verified on 10 September 2026 against the instruments named; several EU regimes phase in obligations over time and are amended, so re-verify against the primary sources before relying on any window. Whether any of these regimes reaches your organisation, and whether a given event is reportable under it, is a question for counsel — this page does not decide it, and it does not start any clock.
| Regime | Reporting shape as written | What the evidence has to support | What it does not mean |
|---|---|---|---|
| Regulation (EU) 2024/2847 (Cyber Resilience Act) Article 14 | For actively exploited vulnerabilities and severe incidents affecting product security, a laddered notification: an early warning within 24 hours, a notification within 72 hours, and a final report — with the CRA's own timing for the final report depending on which limb applies. | A defensible awareness timestamp, the exploitation or severity evidence behind the classification, and the submitted early warning, notification, and final report with receipts. | Does not mean every vulnerability or incident is reportable, and does not decide whether your product falls in scope. Manufacturer obligations under the CRA phase in; verify the applicable dates. |
| Directive (EU) 2022/2555 (NIS2) | For essential and important entities, an early warning within 24 hours of awareness of a significant incident, an incident notification within 72 hours, and a final report within one month, as transposed by each Member State. | Awareness timing, the significance assessment, cross-border impact where relevant, and each submission with its national-authority receipt. | Does not apply to every company, and the operative rules are the national transpositions, which differ. Sector and size criteria decide scope, not this table. |
| Regulation (EU) 2022/2554 (DORA) | For in-scope financial entities, initial, intermediate, and final reporting of major information and communication technology related incidents, with the windows set by the Regulation and its implementing and delegated acts. | Classification against the major-incident criteria, the timestamps, and the submissions in the prescribed template with receipts. | Does not apply outside the financial entities and designated critical third-party providers the Regulation names. |
| GDPR Articles 33 and 34 | Notification of a personal-data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless it is unlikely to result in a risk; communication to data subjects where the risk is high. | The awareness record, the risk assessment for individuals, the notification or the recorded reasoning for not notifying, and the internal breach register Article 33(5) requires for all breaches. | Not every security incident is a personal-data breach, and the 72-hour figure is not a grace period. The Article 33(5) internal record applies even where no notification is made. |
| Contractual and customer notification terms | Whatever your customer agreements and data processing agreements say — frequently shorter than any statutory window, sometimes 24 hours or less. | The contract term itself, the notice sent, and the timestamp. | Not a statutory obligation, and often the tightest clock you actually have. Read your own agreements; they are not on this page. |
Preserving evidence without breaking the response
The tension is real: restoring service quickly is the point of incident response, and preservation slows it down. The resolution is to make preservation a cheap, early, standing step rather than a decision made under pressure. These are ShipReady Metrics recommendations and common industry best practice, not legal requirements, and they are not a forensic methodology — where forensic defensibility matters, engage people who do that work.
- Snapshot before you rebuild. A volume snapshot takes seconds and can be examined later; a terminated instance cannot.
- Export the log range immediately, including the window before detection. Cloud and platform log retention is measured in days by default, and the relevant window is often already close to expiring.
- Keep a preservation log: what was captured, by whom, when, where it is stored, and its hash. That is a timestamped record of custody. It is not a forensic chain of custody, and calling it one is the kind of claim that collapses under examination.
- Put preserved evidence somewhere the incident cannot reach — a separate account or project, with write-once storage where available and access restricted to the response team.
- Freeze the automatic deletion that would otherwise apply to affected records, and record that you did.
- Preserve the human record too: the incident channel export, the call recordings or notes, and the decision messages. These carry the awareness and severity facts.
- Do not edit preserved artifacts. Keep analysis in separate documents that reference the originals.
- Where a legal hold may apply, ask counsel before deleting anything related to the incident, including in the ordinary course of retention.
Which kind of authority each statement carries
Incident work attracts more confident assertion than any other compliance topic. Label the source. Last verified 10 September 2026.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| GDPR Articles 33 and 34 notification duties, and the Article 33(5) internal record of all personal-data breaches. | Legal requirement, where the Regulation applies to your processing. | Does not make every incident notifiable, and does not tell you whether a specific event is a personal-data breach. That assessment is a legal one. |
| CRA Article 14, NIS2 reporting as transposed, and DORA incident reporting. | Legal requirement for entities and products in scope, with phased application and, for NIS2, national transposition. | Does not mean these reach your organisation. Scope depends on product category, sector, size, and Member State law. |
| NIST SP 800-61 incident handling and SP 800-86 forensic techniques. | Regulatory and technical guidance — widely respected, and the source most auditors' expectations derive from. | Not binding on a private company by itself. Cite it as the basis for your process, not as a law. |
| AICPA TSC CC7.3, CC7.4, CC7.5 and ISO/IEC 27001:2022 Annex A 5.24 to 5.28. | Attestation and certification criteria, applying because you sought a report or certification. | Do not prescribe severity levels, tooling, or a specific timeline. Your own documented plan is what you are tested against. |
| Snapshot before rebuild, export logs immediately, keep a preservation log, and store preserved evidence outside the affected environment. | ShipReady Metrics recommendation, and common industry best practice. | Not a legal requirement and not a forensic methodology. It preserves options; it does not by itself make evidence forensically defensible. |
| Record the reportability decision even when the answer is no. | ShipReady Metrics recommendation, consistent with the GDPR Article 33(5) internal-record duty where that applies. | Does not substitute for taking advice. It records that the question was asked and by whom. |
Checklist
Run this against your last incident, not against your plan. Not a determination that any regime applies to you. Last verified 10 September 2026. Not legal advice.
- Can we state, from a record rather than memory, when a responsible person first became aware — and in which timezone?
- Did we snapshot affected systems and export the relevant log range before we rebuilt or patched anything?
- Is there a preservation log naming what was captured, by whom, when, and where it is stored?
- Is preserved evidence stored outside the environment that was affected, with restricted access?
- Is the severity decision recorded with the criteria and the person who made it, including any re-classification?
- Is there a written reportability decision for each regime we consider applicable, with reasoning and a named decision-maker — including where the answer was no?
- Do we hold submitted notification text, receipts, reference numbers, and every subsequent update, not just drafts?
- Did we export the incident channel, customer notices, and status-page history before retention expired?
- Does the impact assessment state what we could not determine, as well as what we could?
- Is the post-incident review written, with action items that have owners, dates, and closure evidence?
- Does the incident register for the period include near misses and low-severity events, so the population is complete?
- Has the plan been tested in the period, with the test recorded?
- Do our contractual notification windows appear anywhere in the runbook, given they are often shorter than statutory ones?
What to do now
Ordered so that the perishable evidence is protected first. None of these steps is a legal determination, none starts a clock, and none files anything.
- Add preserve-first as step one of the runbook: snapshot, export the log range, and record the capture, before triage decisions are made.
- Create the preservation destination now — a separate account or project with restricted access and immutability where your platform offers it. Building it during an incident is too late.
- Extend platform log retention where the default is measured in days, and confirm the length covers both your audit period and any plausible reporting window.
- Add explicit awareness capture: the first responder records the time they knew and what they knew, with the timezone, as a field rather than as prose.
- Add the reportability decision as a required field with a named decision-maker, so the no is recorded too.
- Export the human record — incident channel, notices, status-page history — at the point of closure, as a closure task.
- Reconcile your customer and data processing agreement notification windows into the runbook, since they are frequently the tightest clock.
- Test the plan once in the period and keep the exercise record; an untested plan is a common finding.
- Re-verify the CRA, NIS2, DORA and GDPR windows above against the primary sources annually and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not run your incident response, does not detect incidents in your production environment, does not preserve forensic evidence, does not notify any authority, and does not decide whether an event is reportable.
CRA reporting tracks the 24-hour, 72-hour and 14-day ladder from recorded awareness, for findings your organisation has classified as CRA-in-scope, and can produce a draft for a named reviewer. It does not start a clock — the clock runs from the facts, and recorded awareness is your record of them. A named human still submits, and the product does not file with any authority.
The cyber risk register holds risks and their treatment. Delivery Health computes DORA delivery posture — including time to restore — from connected sources such as GitHub Actions runs. That is delivery posture, not an incident-response runbook and not an incident register.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Incident artifacts arrive as manual rows. That produces a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, not a regulator filing pack, and not an auditor's opinion. The obligation map lists frameworks your organisation marked in-scope; that mark is not a legal opinion that a framework applies.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
Regulation (EU) 2024/2847 (Cyber Resilience Act) Article 14, Directive (EU) 2022/2555 (NIS2), Regulation (EU) 2022/2554 (DORA), and Regulation (EU) 2016/679 (GDPR) Articles 33 and 34 are legal instruments, applying by scope and, for NIS2, through national transposition. NIST SP 800-61 and SP 800-86 are guidance. AICPA Trust Services Criteria CC2.2, CC7.2 to CC7.5 and A1.2 are attestation criteria; ISO/IEC 27001:2022 Annex A 5.5, 5.24 to 5.28, 8.13 and 8.16 are certification requirements. ENISA publishes reporting guidance for several of these regimes. Not a complete list, and not legal advice.
The breach-reporting cluster carries the deadline ladders in detail, the incident-response cluster covers preserving evidence during a live response, and the log-retention page in this cluster covers how long the underlying records need to survive.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of incident activity to evidence, with each source labelled by the kind of authority it carries. Whether the CRA, NIS2, DORA, GDPR, or any contractual notification term reaches your organisation, and whether a specific event is reportable, are questions for counsel and your regulator-facing owner. This page does not determine YOUR obligations, does not start a clock, and does not file anything.
When does the clock start?
Under the instruments on this page, generally from awareness rather than from resolution — GDPR Article 33 runs from becoming aware, and the CRA and NIS2 ladders run from awareness of the qualifying event. That is exactly why the awareness record is primary evidence. What counts as awareness in a specific case is a legal question, and nothing in this product or on this page starts a clock; the facts do.
What do we preserve if we have to rebuild the host to restore service?
Snapshot the volumes and, where you can, capture memory before terminating anything, then export the platform log range covering both before and after detection. A snapshot costs seconds and preserves the option to investigate later. Record the capture in a preservation log with hashes. That is a timestamped custody record, not a forensic chain of custody.
Do we need to record incidents we decided not to report?
Keep the record either way. Where GDPR applies, Article 33(5) requires an internal record of all personal-data breaches regardless of whether you notified. More generally, an unrecorded decision not to report is indistinguishable from never having considered the question, which is the harder position to defend. Record the reasoning and the named decision-maker.
Does ShipReady Metrics report incidents for us?
No. CRA reporting tracks the 24-hour, 72-hour and 14-day ladder from recorded awareness for findings your organisation classified as CRA-in-scope, and produces a draft for a named reviewer. A named human submits. It does not start a clock, does not detect incidents in your production environment, does not preserve forensic evidence, and does not file with any authority.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.