The main operational risk in Article 14 is not only missing a security event. It is allowing a credible event to remain inside technical teams while the reporting clock is already running. A good workflow creates fast escalation without requiring complete forensic certainty before regulatory reporting begins.
Start With a Single Security Intake Path
Potential Article 14 events can arrive through many channels: vulnerability researchers, customer support, threat intelligence, security monitoring, managed service providers, engineering teams, public disclosure or internal incident response. The manufacturer needs a way to route credible product-security signals into a common assessment process. This does not require one technical system for every source, but it does require a clear path from detection to the team responsible for deciding whether CRA reporting may be triggered.
- Map all major vulnerability and incident intake channels.
- Define which team receives potential CRA-relevant signals.
- Create urgent escalation criteria.
- Avoid leaving product-security evidence inside ordinary support queues.
Capture the Manufacturer-Awareness Timestamp
Article 14's 24-hour and 72-hour stages are tied to the manufacturer becoming aware of the qualifying event. Internal workflows should therefore capture the relevant awareness timestamp as soon as the reporting trigger is established. The organisation should distinguish raw technical detection from the point at which available information establishes awareness of an actively exploited vulnerability or severe incident. The evidence supporting that determination should be recorded so the deadline calculation is traceable.
- Record the relevant awareness time.
- Record the evidence available at that point.
- Calculate the 24-hour deadline immediately.
- Calculate the 72-hour deadline immediately.
- Do not wait for completed forensics before starting deadline management.
Run Two Separate Article 14 Trigger Tests
The workflow should assess actively exploited vulnerabilities and severe incidents separately. For an actively exploited vulnerability, the team asks whether reliable evidence shows malicious exploitation of a vulnerability without the system owner's permission. For a severe incident, the team applies the Article 14(5) effects and malicious-code criteria. The same security event can raise both questions. A generic internal severity rating such as critical or P1 does not replace either legal test.
- Assess the actively exploited vulnerability trigger.
- Assess the severe-incident trigger.
- Document each conclusion separately.
- Do not rely only on internal incident severity labels.
Assign a Small Regulatory Decision Group
A 24-hour reporting requirement is difficult to meet if every decision must move through a long sequential approval chain. A practical model uses a small group with access to product-security evidence, legal or compliance interpretation and authority to initiate the SRP process. Engineering, executive management and customer teams can be involved as needed without making every person a formal gate. The workflow should identify who can make the Article 14 trigger determination and who can authorise submission outside normal business hours.
- Name the technical decision owner.
- Name the legal or compliance decision owner.
- Name the SRP submission owner.
- Define after-hours authority.
- Keep the approval chain short enough for a 24-hour obligation.
Open the Regulatory Case Immediately
Once an event is considered potentially reportable, open an Article 14 case record. It can contain the affected product and versions, awareness time, trigger analysis, coordinating-CSIRT routing, assigned representative, current investigation status, Article 14 deadlines, mitigation, user communication and links to SRP submissions. The record should begin before all facts are known. Its purpose is to keep the developing technical and regulatory evidence in one controlled chronology.
- Create a unique internal case ID.
- Record affected products and versions.
- Record the Article 14 trigger analysis.
- Record the coordinating CSIRT.
- Record the Assigned Representative.
- Track every reporting deadline.
Prepare the 24-Hour Warning and Investigation in Parallel
The early warning is not the end of the technical investigation and should not wait for that investigation to finish. The regulatory owner can prepare the information required for the 24-hour stage while incident responders continue collecting logs, identifying affected versions, containing compromise and assessing exploitation. This parallel model is essential because Article 14 deliberately expects information to mature between the early warning, 72-hour notification and final report.
- Prepare the early warning without waiting for final root cause.
- Continue technical investigation in parallel.
- Continue containment and mitigation in parallel.
- Begin preparing the 72-hour evidence package during the first day.
Treat User Communication as a Separate Workstream
Article 14(8) requires the manufacturer, after becoming aware of an actively exploited vulnerability or severe incident, to inform impacted users and, where appropriate, all users of the vulnerability or incident. Where necessary, users must also be informed of risk-mitigation and corrective measures they can deploy. The workflow should therefore include a user-communication owner rather than assuming the SRP notification itself satisfies this separate obligation. Security, support, legal and product teams may need to coordinate the timing and technical accuracy of those communications.
- Identify impacted users.
- Assess whether all users should be informed.
- Prepare relevant mitigation or corrective instructions.
- Coordinate technical accuracy with the product-security team.
- Track when user communication was issued.
Use the 72-Hour Stage to Mature the Regulatory Record
After the early warning, the workflow should move directly into the 72-hour notification workstream. For an actively exploited vulnerability, this means developing the product, exploit, vulnerability and mitigation information required by Article 14. For a severe incident, it means developing general incident information and the initial assessment. The case owner should clearly distinguish confirmed facts, preliminary assessments and unresolved questions. If information changes later, ENISA's current SRP workflow allows an open notification to be updated before Final Report submission.
- Continue updating affected-product information.
- Develop exploitation or incident evidence.
- Develop mitigation information.
- Separate confirmed facts from preliminary conclusions.
- Use the SRP update function when material information changes.
Track the Correct Final-Report Clock
The final-report deadline depends on the reporting type. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after submission of the 72-hour incident notification. The escalation workflow should therefore create the correct final deadline when the relevant triggering event occurs rather than using one generic closure date for every Article 14 case.
- AEV: track availability of the corrective or mitigating measure.
- AEV: calculate the 14-day final-report deadline.
- Severe incident: record the 72-hour notification submission time.
- Severe incident: calculate the one-month final-report deadline.
Keep the Case Open Until Regulatory and User Actions Are Complete
Technical containment is not necessarily regulatory closure. The Article 14 case should remain open until the required reporting stages have been completed, material updates have been submitted, applicable user communication has been handled and the final report has been filed. A short post-case review can then identify delays in awareness escalation, missing product records, SRP access problems, unclear ownership or communication gaps. Those lessons should feed back into the next tabletop exercise and workflow revision.
- Do not close the case at technical containment alone.
- Confirm all required SRP stages are complete.
- Confirm user communication has been addressed.
- Confirm the final report has been submitted.
- Review the workflow after the event.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.