Preparing Internal Detection, Escalation, and Decision-Making Processes

Article 14 is often discussed as a regulatory question. Operationally, it is an internal-process question. The official platform, the routing to ENISA, and the structured forms are the easy part once you understand them. The hard part is everything that happens inside your own organisation between the first faint signal that a product is being attacked and the moment a named person decides to file an early warning.

That internal stretch is where the 24-hour deadline is actually won or lost. A manufacturer with flawless knowledge of the reporting platform will still miss the window if a researcher's email sat unread for two days, or if the engineer who spotted the exploit traffic had no idea who to tell, or if nobody felt they had the authority to declare a reportable event without a director's sign-off.

This post is a practical guide to building that internal machinery. It is the fifth in our CRA reporting series, following the posts on when reporting becomes mandatory, what must be reported, where reports go, and the timelines that apply. For a single-page overview of the whole reporting regime, see our guide to which CRA reporting obligations apply, when they start, and how to be ready.

Detection: where awareness comes from

The clock starts at awareness, so the first job is to ensure awareness forms reliably and fast. Exploitation signals arrive through several channels, and a gap in any one of them is a blind spot.

• The coordinated disclosure channel. Under Article 13 you must operate a contact point for vulnerability reports. For many manufacturers this is the single most likely source of first warning that a product is being exploited, because researchers and customers report there. It must be monitored continuously, not checked when someone remembers.
• Customer and support reports. A customer describing strange behaviour, unexpected outbound traffic, or a breach traced to your product is reporting exploitation, even if they do not use that word. Support staff need to recognise these signals and route them, not close them as ordinary tickets.
• Internal telemetry and monitoring. Where your products or your own infrastructure emit security telemetry, alerts that indicate exploitation or a build-pipeline compromise are detection sources. They are only useful if someone triages them promptly.
• Threat intelligence and external feeds. Public exploitation reporting, vendor advisories about shared components, and threat-intel services can tell you a vulnerability in your product is being exploited before your own systems do.
• Coordinators and authorities. Sometimes a national CSIRT or a coordinator will contact you about exploitation of your product. That contact is awareness.

The common failure is not the absence of these channels. It is that they feed into different inboxes, queues, and teams, with no convergence point. Detection works when every channel funnels into one triage process that someone owns.

Triage: turning a signal into a classification

Once a signal arrives, someone has to decide what it is. Triage is the step that converts a raw report into one of three outcomes: routine vulnerability to be handled, potential Article 14 event to be escalated, or not a security issue.

Effective triage under the CRA needs a few things in place.

First, a defined severity method. Most manufacturers use CVSS as the backbone, but the Article 14 trigger is active exploitation, not score, so triage must explicitly assess exploitation evidence as a separate axis. A modest-severity bug under active exploitation is reportable. A critical bug with no exploitation is not. The triage form should force both questions. We worked through this distinction in detail in exploitable versus exploited reporting obligations.

Second, an acknowledgement commitment. Good practice, and the spirit of Article 13, is to acknowledge inbound reports within a defined window, commonly 48 hours or sooner. Acknowledgement does more than show courtesy. It keeps a researcher engaged rather than going public out of frustration.

Third, a defined service level for triage itself. A report that takes a week to triage defeats a 24-hour reporting clock. The triage SLA has to be short enough that escalation can still happen inside the window.

Escalation: a path that runs at 2am

Detection and triage are routine. Escalation is the part that has to work under the worst conditions: out of hours, when the obvious person is on leave, when the signal is ambiguous and the stakes are high.

A workable escalation path has these properties.

• A single, known route. Everyone who could receive a first signal, support, engineering, the disclosure inbox owner, knows the one way to escalate a suspected exploitation event. Not three possible routes. One.
• Always-on coverage. There is a defined on-call responsibility for security events, with a named primary and a backup, so escalation never depends on one individual being reachable. The 24-hour clock does not pause for weekends.
• A low threshold to escalate. Staff are told explicitly to escalate on suspicion, not on proof. The cost of escalating a false alarm is minutes of a responder's time. The cost of not escalating a real event is a missed legal deadline. The asymmetry should be built into the culture.
• A documented runbook. The on-call responder follows a written procedure: confirm the signal, timestamp awareness, classify, and if it is a potential Article 14 event, invoke the decision-maker. A runbook is what lets a competent responder act correctly at 2am without improvising. We discuss building this capability from nothing in our PSIRT-from-scratch guide.

Decision authority: who can pull the trigger

This is the most underprepared element in most organisations, and the one that most often causes a missed deadline.

Filing an early warning within 24 hours requires a decision: this event is reportable, file it now. If that decision can only be made by a senior executive or requires legal sign-off, you have built a bottleneck directly into the path of a legal deadline. Executives are not always reachable in 24 hours. Legal review of a public statement can take longer than the window allows.

The resolution is to separate the early warning from the public disclosure. The early warning is preliminary, goes only to authorities, and is explicitly allowed to be incomplete. It does not carry the same risk profile as a public advisory or a press statement. So pre-authorise it.

Concretely, name a role, the PSIRT lead, the head of product security, or an equivalent, and grant that role standing authority to declare an Article 14 event and submit the early warning without further approval. Document this authority in advance. Senior leadership and legal can still own the public disclosure strategy and the detailed reports. What they should not own is the go decision on the 24-hour early warning, because their availability is the thing most likely to make you late.

This single decision, pre-authorising the early warning, is the highest-leverage preparation in the entire programme. We made the same point about the 24-hour window specifically in our analysis of the 24-hour notification obligation.

A reference flow

Putting it together, a prepared organisation runs a flow like this:

1. A signal arrives through any detection channel and is funnelled to the single triage queue.
2. The report is acknowledged within the committed window, and awareness is timestamped.
3. Triage classifies it, assessing severity and active-exploitation evidence as separate questions.
4. If it is a potential Article 14 event, the on-call responder follows the runbook and invokes the decision-maker.
5. The pre-authorised decision-maker confirms it is reportable and files the early warning inside 24 hours.
6. The team assembles the 72-hour detailed notification while remediation proceeds in parallel.
7. Every step is timestamped and recorded.

The whole flow should be rehearsed, not merely documented. A tabletop exercise that walks a simulated exploited-vulnerability report through the path will expose the gaps, an unmonitored inbox, an on-call rota with holes, an unclear decision authority, while the stakes are zero.

Common gaps to check for

When auditing your own readiness, these are the failure points that appear most often:

• The disclosure inbox is monitored during business hours only.
• Support has no instruction to recognise and escalate exploitation reports.
• Escalation depends on one named individual with no backup.
• No one has explicit authority to file the early warning without executive approval.
• Platform credentials and the national CSIRT contact are not verified or are held by one person.
• Report templates do not exist, so each stage is drafted from scratch under pressure.
• Awareness is never timestamped, so the organisation cannot evidence when the clock started.

Each of these is cheap to fix in advance and expensive to discover during a live incident.

How CVD Portal operationalises this

CVD Portal is, in effect, this internal process delivered as software. The branded disclosure portal gives you the monitored Article 13 intake channel. Inbound reports land in a single triage queue with acknowledgement tracking against your committed window. The triage workflow assesses CVSS severity and flags potential active exploitation as a distinct signal. Awareness is timestamped on receipt, the deadline clocks run from there, and pre-populated early-warning and notification drafts remove the from-scratch drafting bottleneck. Role-based access lets you encode who holds the authority to act. The result is that the people on call have a single place to work and a clear path to a filed report.

The bottom line

The CRA reporting deadlines are met or missed inside your own organisation. Reliable detection across every channel, fast triage that separates severity from exploitation, an escalation path that runs at 2am, and a pre-authorised decision-maker for the early warning are what turn a vague late-night signal into a filed report on time. Build and rehearse that machinery before September 2026, because the 24-hour clock is not the moment to design it.

The final post in the series steps back from the single incident to the whole programme: linking vulnerability reporting to broader product and risk management.