Deliverable 01
Cyber Resilience Act · 24/72h reporting · SRP operational readiness
Can your team move from vulnerability awareness to defensible CRA reporting data in time?
Enki Tech runs a focused technical dry run for manufacturers of products with digital elements. The sprint tests the operational path from detection and product impact to independent deadline control, ownership, reporting data, SRP access and submission readiness, remediation and evidence—before the first real event starts the clock.
The buying problem
The regulation may be documented. The operational handoffs still fail under time pressure.
A scanner, ticketing tool, SBOM, incident policy, legal guidance and reporting portal do not automatically create a working 24/72-hour response path. The sprint tests whether people, data, access, deadline controls and evidence can be mobilized quickly enough when an actively exploited vulnerability or severe product-security incident is discovered.
Regulatory context · reviewed 10 September 2026
Reporting applies from 11 September 2026. Prepare the people, data and handoffs.
Article 14 covers actively exploited vulnerabilities and severe incidents affecting in-scope products. Both require reporting without undue delay, with a 24-hour early-warning limit and a 72-hour notification limit from awareness. The dry run also tests the later final-report path.
ENISA recommends preparing personal EU Login accounts with MFA, and registering on the SRP when a notification is needed. We rehearse offline and review existing access where appropriate. No test notification is submitted to the live platform. Internal evidence collection can be automated; ENISA says the initial SRP release has no submission API.
Fixed-scope sprint
One scenario. One timed workflow. Clear gaps and owners.
The engagement is designed as a bounded technical-readiness exercise, not an open-ended compliance programme.
Deliverable 02
Independent regulatory clock anchored to the actual awareness timestamp
Deliverable 03
Product, version, owner and evidence-source mapping for the selected scenario
Deliverable 04
24-hour early-warning and 72-hour notification data-readiness review
Deliverable 05
SRP readiness plan covering personal EU Login/MFA, representative responsibilities and a documented backup handoff
Deliverable 06
Escalation matrix with primary and backup owners for critical handoffs
Deliverable 07
Evidence map showing what can be retrieved quickly and what remains manual
Deliverable 08
Prioritized remediation backlog focused on operational bottlenecks
Deliverable 09
Readiness score and concise management summary for the tested workflow
Dry-run path
From awareness time to verified technical closure
Every stage is linked to an owner, source system, access dependency, evidence requirement and target response time.
Stage
Decision
What the dry run tests
Evidence
Outcome
T0
Preserve awareness time
Record the earliest relevant awareness timestamp and source. Escalate classification promptly; internal validation must not reset or postpone the reporting clock.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
Clock
Start the independent deadline control
Calculate internal 24-hour and 72-hour deadlines from the awareness timestamp rather than depending on a portal timer or individual memory.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
Impact
Map product and affected versions
Determine whether the selected product or version is affected and identify the business and security context.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
Own
Assign decision and submission authority
Identify the primary owner, backup owner and escalation path across Security, Engineering, Product and Legal/Compliance.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
SRP
Prepare the submission handoff
Review personal EU Login/MFA readiness and representative roles. Rehearse with offline reporting templates; follow current ENISA guidance on when to register.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
24h
Prepare early-warning data
Test whether required technical facts can be assembled inside the first reporting window.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
72h
Complete notification data
Validate the deeper impact, mitigation, status and evidence needed for the main notification workflow.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
Fix
Track remediation
Connect the reporting process to corrective or mitigating action, validation and an owned backlog.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
Close
Track the final report
Use the correct final-report trigger for the scenario and preserve corrective-action, validation and notification evidence.
Named source of truth and retrievable artefact
Pass, constrained or remediation required
Final-report deadlines
Keep the two reporting tracks separate.
The initial 24/72-hour windows do not close the reporting process.
Actively exploited vulnerability
Final report no later than 14 days after a corrective measure becomes available. Record that availability timestamp separately from awareness and deployment.
Severe incident
Final report within one month after the incident notification. Track the notification timestamp as the deadline anchor.
Confirm the scenario and any applicable follow-up requirements with your reporting owner. ENISA SRP FAQ and deadlines.
Delivery and acceptance
A five-working-day sprint once inputs and stakeholders are available.
Day 1: confirm scope and collect inputs. Day 2: map owners, products and evidence. Day 3: run the timed exercise. Day 4: prepare the runbook and action plan. Day 5: review results and agree the retest priorities.
Before starting, provide a product/version list, an example vulnerability or incident record, the current process and named technical and reporting owners. We confirm the schedule and fixed fee after a short fit call.
What completion means
You can see what worked, what failed and who acts next.
You receive the timestamped exercise record, primary and backup responsibility matrix, draft reporting-data templates, evidence index and a prioritized 30/60/90-day action plan. Each tested step is marked demonstrated, constrained or not demonstrated, with an owner for every unresolved gap.
Completion means delivery of this agreed evidence package and readout. It does not mean every gap has been fixed or that the organisation is certified.
Typical scope
A defined exercise with a practical handover
One selected product family or clearly bounded product scope
One primary scenario: actively exploited vulnerability or severe security incident
Security, Engineering/Product and compliance decision-makers represented
Existing vulnerability, incident, inventory and evidence sources reviewed
Independent 24/72-hour deadline tracking and escalation path tested
EU Login/MFA preparation, representative roles and backup handoff reviewed
Short management readout plus technical remediation backlog
Important boundary
Responsibilities agreed before the exercise
Enki Tech tests technical and operational readiness, evidence availability and engineering handoffs. The client retains responsibility for legal interpretation, reportability decisions, regulatory submissions and formal incident command unless separately agreed with appropriately authorized parties.
This scheduled exercise does not include live incident response, 24/7 monitoring, product-code or firmware fixes, certification or a guarantee of regulatory compliance.
Who participates
Bring the people who own the response.
Include a technical owner and the person accountable for reporting decisions, plus backups for critical handoffs.
Product Security / PSIRT
Validate whether vulnerability intelligence, product inventory, ownership and reporting can operate as one timed process.
CISO / Security Engineering
Expose gaps between security detection, incident handling, technical remediation and regulatory evidence.
CTO / Head of Engineering
Clarify engineering handoffs, affected-version mapping and decision ownership before a real event creates deadline pressure.
MSSPs / Integrators
Add a bounded CRA technical-readiness work package without positioning as legal counsel or building a full product-security practice internally.
After the exercise
Turn the findings into an owned improvement plan.
You receive a prioritized backlog with owners and acceptance criteria. Enki Tech can separately scope Microsoft Cloud, identity and reporting-workflow improvements. Product-code and firmware fixes stay with your engineering team or a qualified product-security partner. Recurring governance covers only the controls and review cadence agreed with you.
Test readiness before the first real deadline
Run one scenario and find the bottlenecks while there is still time to fix them.
Share the product scope, current vulnerability/incident process and the teams involved. Enki Tech will confirm whether a bounded CRA Incident Reporting Readiness Sprint is the right first step.