Your 24 hours started at a moment somebody has to choose

Both of the first two Article 14 deadlines are measured from the same point.Art. 14⁠(2)⁠ The early warning is due twenty-four hours after it, the notification seventy-two hours after it, and for a severe incident the final report is anchored to a submission that itself hangs off the same origin. One moment sets three dates. It is the single most consequential timestamp anyone at your company will ever type, and the Regulation does not tell you which moment it is.

The short answer

Becoming aware is the point at which the manufacturer knows it has an actively exploited vulnerability or a severe incident in its product. It is a conclusion, not an event that arrives — which means somebody decides it, records it, and can say why. No feed, scanner or scheduled job can set it, because none of them knows whether your product is affected.

The cases that are actually hard

Nobody struggles with "our on-call engineer watched it happen." The difficult ones all have the same shape: information arrived, and it took time to become knowledge.

A researcher emails a proof-of-concept at 23:40 on a Friday, to an address three people can read. A customer opens a support ticket describing behaviour that turns out to be exploitation, and it sits in a queue for two days being treated as a bug. A catalogue adds a component you ship, which tells you something about the component and nothing yet about your product. Your own detection fires, and the engineer who silenced it did not write down why.

In each of those, the honest answer is not the moment the message was sent. It is the moment somebody at your company was in a position to conclude that your product was affected — and the reason that matters is that the gap between the two is the thing you will be asked to explain.

Why nothing automated is allowed to set it

This is a product decision and a fairly aggressive one: in our system, an exploitation signal cannot start a clock. A catalogue listing opens an assessment with four questions — is the component actually shipped rather than a build dependency, is the vulnerable path reachable, is there evidence of exploitation against our product or our users, and is a fix already out. Only a person answering those can move the case to reportable, and only that transition sets the awareness time.

The alternative is worse than it sounds. If ingesting a feed set the clock, then every catalogue addition touching your inventory would create a legal deadline you had not agreed to, most of them for products that are not affected at all. You would meet those deadlines by filing, and you would be filing about vulnerabilities in other people's software. The duty is triggered by exploitation of your product.Art. 14⁠(1)⁠ A machine cannot tell you that, so a machine does not get to say when you knew it.

The part everyone skips: recording the "no"

A decision that something is not reportable has to be as durable as a decision that it is. Same fields, same author, same timestamp, same permanence.

The reason is not symmetry for its own sake. The question asked months later is almost never "was that one call correct" — it is "did you have a process, and did it run." Ten recorded assessments that concluded no, each with a name and a date, answer that question. A single filing with nothing around it does not, and an empty triage log for the weeks before an incident is the worst possible shape for a record to have.

What this looks like in practice

Write down the moment, write down what made it that moment rather than an earlier one, and treat any later change to it as an amendment rather than an edit. If the answer to "when did we know" lives only in a Slack thread, then the answer to "what were your deadlines" lives there too.

The three dates that follow from it are arithmetic, and the timeline page sets out every one of them, including the final report — which is the one that does not run from awareness at all.