Enki Tech resource · CRA incident readiness

CRA 24/72h Incident Dry-Run Checklist

A compact technical checklist for testing whether an organisation can move from awareness of an actively exploited vulnerability or severe product-security incident to owned decisions, reporting data, remediation and evidence.

View the readiness sprint

How to use it

Run the workflow against one realistic scenario and use a clock

The objective is not to debate legal interpretation during the exercise. The objective is to expose operational delay: missing product mapping, unclear authority, unavailable evidence, fragile handoffs and remediation steps that depend on a single person.

Check
Control point
What to test
Evidence source
Result
01
Awareness time
Record the exact time the organisation becomes aware of the event and the source that established credibility.
Name the authoritative system, document or decision record.
Green / Amber / Red
02
Event classification
Determine whether the scenario is an actively exploited vulnerability, a severe product-security incident or neither.
Name the authoritative system, document or decision record.
Green / Amber / Red
03
Product and version mapping
Identify affected product families, versions, components and markets using the organisation’s source of truth.
Name the authoritative system, document or decision record.
Green / Amber / Red
04
Primary and backup ownership
Name the operational owner, decision authority and backup path if a key person is unavailable.
Name the authoritative system, document or decision record.
Green / Amber / Red
05
24-hour data package
Test whether the minimum technical facts for an early warning can be assembled inside the first reporting window.
Name the authoritative system, document or decision record.
Green / Amber / Red
06
72-hour data package
Validate deeper impact, mitigation status, affected scope and evidence for the main notification workflow.
Name the authoritative system, document or decision record.
Green / Amber / Red
07
Remediation ownership
Connect reporting to corrective or mitigating action, engineering ownership, validation and backlog tracking.
Name the authoritative system, document or decision record.
Green / Amber / Red
08
Final-report path
Define how corrective measures, closure evidence and final technical facts will be assembled after the initial reporting windows.
Name the authoritative system, document or decision record.
Green / Amber / Red
09
Evidence retention
Confirm that key decisions, timestamps, owners, technical findings and remediation evidence can be reconstructed later.
Name the authoritative system, document or decision record.
Green / Amber / Red
10
Timed re-test
Repeat the scenario after improvements and compare retrieval time, handoff quality and evidence completeness.
Name the authoritative system, document or decision record.
Green / Amber / Red

Simple readiness scoring

Score the process—not the team

Green · The owner, source system and evidence are known; the step can be completed within the target time without heroic effort.
Amber · The step is possible but depends on manual correlation, unclear ownership, one key person or slow evidence retrieval.
Red · The organisation cannot reliably complete the step inside the required workflow or cannot produce defensible evidence.

Evidence principle

If evidence requires a two-week audit scramble, it is not 24-hour ready.

The strongest remediation opportunities usually sit between tools and teams: vulnerability intelligence that is not linked to product inventory, tickets without clear authority, evidence that lives in screenshots, or decisions that depend on one senior engineer being available.

Scope boundary

Technical readiness is only one part of CRA compliance

This checklist is an operational engineering aid. It does not provide legal advice, determine reportability on behalf of a manufacturer, submit notifications, or certify compliance. Legal interpretation and regulatory responsibility remain with the manufacturer and its authorised advisers.