Wednesday, 15:50. A security researcher emails the company's general info address. The email contains a proof-of-concept and log files showing evidence of active exploitation. The staff member managing that inbox does not recognise it as a security disclosure. It gets filed under general customer queries.

Wednesday, 17:10. A second version of the same report arrives through a reseller. It is forwarded to the regional sales manager, who forwards it again to the CISO with the message "can you take a quick look before the weekend?" The CISO is already on the way to the airport for a long weekend.

Thursday (public holiday), 11:30. Working remotely from a holiday address, a developer confirms the vulnerability is present in two product lines already deployed with customers. The exploitation evidence holds up.

At this point, the question is no longer technical but a matter of business decisions you can prepare for:

• Who decides whether this meets the Article 14 threshold?
• Who holds access to the SRP account?
• Who drafts the Early Warning, and who signs off on it, on a public holiday, with most of the team unreachable?

If awareness is later determined to have started Wednesday afternoon, the 24-hour window has already closed before anyone with the authority to act has even read the report.

Why this keeps happening

A technical lead who has lived through this kind of scenario put it simply: technical confirmation is rarely the bottleneck. Most engineering teams can validate a vulnerability within a few hours.

What separates organisations is whether they decided, in advance, three things:

• Who owns the notification decision under Article 14?
• How that person can be reached outside office hours?
• What minimum information does an Early Warning need to contain?

Organisations that have rehearsed this once handle it calmly. Organisations encountering it for the first time lose the window to internal routing, not to technical uncertainty. We already have a few rehearsal scenarios, contact us if you are interested.

Three structural takeaways

1. Intake design matters. A report landing in a general support inbox needs a clearly signposted channel that routes it directly to people who recognise it as a CRA-relevant security disclosure, not a customer complaint.

2. Awareness is an organisational fact, not an individual one. A credible report sitting unread in a queue is itself a compliance risk. The process must be designed to minimise the time between first contact and a decision by someone with actual authority.

3. The notification decision needs a named owner and a designated deputy. Both must be able to act regardless of time zone, weekend, or public holiday. Exploited vulnerabilities do not check the corporate calendar before they surface.