When Does a Company Know Something?

On Friday 11 September 2026 a form went live. It sits at portal.cra-srp.enisa.europa.eu, you get in with an EU Login account and two-factor authentication, and it exists so that European manufacturers of software and hardware can do something none of them had ever had to do in that shape: tell an authority that a vulnerability in one of their products is being actively exploited by somebody.

One of the fields is worth reading in the language it was written in, because the platform is only available in English for now: “Date/Time when you became aware of the incident/actively exploited vulnerability.”

A twenty-four-hour deadline starts from that field.

There is a detail in the FAQ ENISA updated on 12 September, the day after the launch, that I find more interesting than anything else. The agency explains that in the current release the 72-hour counter shows a due date calculated 48 hours from the submission of the early warning, so a notification can be displayed as overdue before 72 hours have elapsed since the manufacturer became aware. Then it adds that the logic will be corrected in a future release, to compute the deadline from the field holding the date and time of awareness.

Put that way it is a release note. It is also the point at which somebody, inside a ticket, had to decide how you measure a period of time that starts from a collective mental fact. For now the platform counts from when you spoke. It has announced it will count from when you knew.

So take an ordinary night.

At 02:13 a product’s telemetry records an anomalous sequence of requests against an authentication endpoint. At 02:14 the SIEM correlates that sequence with a rule and raises a medium-severity alert, one of the four hundred that week. At 07:55 an engineer on the morning shift opens it. At 09:20, having read the application logs, they conclude that this is probably not a scanner but a working exploit against a third-party library. At 11:40 the security lead gets the write-up. At 14:10, once the sales meeting is over, somebody tells management.

Twelve hours. Nobody hid anything, nobody broke a procedure, nobody behaved unreasonably. Every step, taken on its own, is defensible.

When did the company know?

That is not a rhetorical question and it is not a philosophical one. Since 11 September it is a required field on a form, and a clock with penalties attached starts from that field.

I have already written about this deadline, about a platform born on the same day as the obligation it serves, and about what it means to arrive there unregistered. That piece ended on a line that felt like a closing and now looks like the opening of something else: the clock starts from knowledge, and knowledge is an organisational fact before it is a technical one. This essay starts there, and it is not about the CRA.

Law has worked with knowledge since long before software

The objection goes first, in its strong form, because if it holds there is no essay.

There is nothing remotely new about a rule that starts a deadline from the moment somebody comes to know a fact. It is one of the oldest legislative techniques there is. Limitation periods, forfeiture, appeals, notice of defects: law has measured time from knowledge for centuries, and it does so because the alternative, measuring from the objective event, would punish people who could not have known.

In the digital field the precedent is almost embarrassingly explicit. Article 33 of the GDPR has required, since 2018, that a personal data breach be notified to the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”. Recital 87 adds that it should be ascertained whether all appropriate technological and organisational measures have been implemented to establish immediately whether a breach has taken place. The EDPB’s Guidelines 9/2022, version 2.0 adopted on 28 March 2023, say a controller becomes aware when it has “a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised”.

NIS2 does exactly the same thing with exactly the same numbers. Article 23(4) of Directive (EU) 2022/2555 requires an early warning within 24 hours of becoming aware of a significant incident, and a notification within 72. The CRA, in Article 14 of Regulation (EU) 2024/2847, reproduces the scheme almost word for word: early warning within 24 hours of the manufacturer becoming aware, notification within 72, final report within 14 days of a corrective measure being available for vulnerabilities, and within a month of the notification for severe incidents.

Three instruments, the same trigger, the same numbers. It would be very easy to file the whole thing as one more regulatory timer and move on, and for most of the commentary I have read this week that is precisely what happened.

I want to build this piece against that reading, but not by denying it. By denying its conclusion.

The legislator doesn’t say how you know, and that is exactly why it started watching

The document that changed my mind is not the regulation. It is the Commission’s FAQs on the CRA implementation, first published on 3 December 2025 and updated on 4 September 2026, a week before the platform opened. Section 5 covers reporting obligations, and the first entry in that section, 5.1, asks how a manufacturer can become aware of an actively exploited vulnerability or a severe incident.

The answer opens by saying the CRA does not specify it. “The CRA does not specify how a manufacturer is to become aware”, it only imposes the duty to notify once knowledge exists. Then the Commission does something it was not obliged to do: it lists the channels. A customer or a partner reporting unusual activity. A threat intelligence report. Security researchers or cybersecurity firms publishing an analysis of a zero-day used in targeted attacks. A governmental agency that detected the exploitation with its own monitoring systems. An ethical hacker. And then, at the end of the list, the phrase I care about: a manufacturer may also become aware “via internal monitoring, scanning activities or telemetry”. Its own telemetry system, or a honeypot, indicating the exploitation of a previously unknown flaw. Its own security team watching dark web forums and finding evidence that somebody has successfully exploited the product.

In that list, the sensor is no longer only a technical instrument. It is one of the ways a legal person comes to know something.

A qualification is needed here, because the temptation to overread the text is strong and giving in would be dishonest. Immediately after the list, the Commission writes that none of this implies the manufacturer is required to carry out those activities or monitor those channels in order to comply with the reporting obligations. There is no duty to see in Article 14. And I am not arguing that any alert automatically starts the clock: the text does not say so, the Commission does not say so, and the working notion of awareness will take years of interpretation to settle.

That sentence, though, carries a footnote, the tenth, and the footnote says the rest. “Nonetheless”, Annex I, Part II does require the manufacturer to have, among other things, a single point of contact where vulnerabilities can be reported, to put in place and enforce a coordinated vulnerability disclosure policy, and to take measures to facilitate the sharing of information about potential vulnerabilities.

Translated: the reporting obligation does not require you to look, but the regulation it sits inside requires you to be reachable. It is not a duty to see. It is a duty to have a door, keep it open, and tell everyone where it is.

There is a second clue inside the same regulation that I don’t think anyone has pressed on hard enough. Article 14 says “becomes aware”, actual knowledge. Article 13(21), same subject, same text, uses a different formula: manufacturers “who know or have reason to believe” that the product is not in conformity must immediately take corrective measures. Know, or have reason to believe. That is the standard of imputed knowledge, the one law assigns to those who ought to have known.

The European legislator knows the difference between the two formulas perfectly well and used them a few lines apart. It did not extend imputed knowledge to the reporting duty, and that choice is deliberate. But it wrote a regulation in which the standard of what you know and the standard of what you have reason to believe live within a page of each other. Anyone who thinks the ambiguity around awareness is an oversight has not read closely enough.

So the thesis is not that Europe has ordered companies to know. It is subtler and, I think, more important. Piece by piece, European digital law is making legally relevant the architecture through which an organisation comes to know something. It does not mandate monitoring. It creates a very strong incentive to be able to describe how a signal becomes knowledge.

Epistemic architecture

I use epistemic architecture to mean the set of mechanisms through which an organisation gathers signals from the world, assigns them meaning, decides when the evidence is sufficient, and turns that judgment into a fact it can act on. There is nothing esoteric about the term and nothing new about the thing. It exists in every company, including the ones that have never named it.

A SOC is an epistemic architecture. An incident management process is one. An escalation chain is one. The unwritten rule by which a certain class of alert gets muted on Friday afternoon is one. So is the decision not to integrate a source, not to renew a feed, not to read a mailbox: a negative epistemic architecture, implicit, almost never deliberate, and working perfectly well.

In software we have built an extremely sophisticated vocabulary for discussing the observability of machines. Structured logs, metrics, distributed traces, cardinality, percentiles, SLO-based alerting. I can know within seconds that an endpoint’s ninety-ninth percentile latency is up 15% on last week, and I can tell you which downstream service it comes from.

We are far worse at describing the observability of the organisation that owns those systems.

When an alert was seen, and by whom. Who, at that moment, had what it took to interpret it. Which evidence was missing, and who had it. When doubt became reasonable certainty. Who had the authority to declare it, and whether that person was reachable.

These read like administrative questions right up to the moment a rule starts a twenty-four-hour deadline from one of them. Since Friday, in Europe, one of them is a required field with a date and a time inside it.

The paradox of regulated observability

Here comes the objection I take most seriously in this whole piece, and I give it all the room it deserves because it is true.

An organisation that sees better apparently puts itself in a worse regulatory position.

If I have excellent telemetry on the product in production, if I buy threat intelligence, if I scan dependencies continuously, if I have people on call at three in the morning and an escalation chain that works, I will find incidents sooner. And finding them sooner starts the clock sooner. My colleague who has none of this knows nothing, and no clock appears to start.

In one line: the better you are at knowing, the sooner you become responsible for what you know.

That is the paradox of regulated observability, and it is not a seminar exercise. Badly built regulation produces exactly this perverse incentive, and the incentive never shows up in explicit form. No board minutes a resolution saying “we would rather not know”. It shows up in deferrals: the project to pipe application logs into the SIEM that slips quarter after quarter, the threat intelligence feed that doesn’t get renewed because it generates too many false positives, the night rota that stays informal, the criteria for opening an incident written so demandingly that they push the moment somebody can say it really happened hours into the future. Every one of those decisions has a reasonable technical or budgetary justification. The sum is organisational blindness, built by accumulation rather than by choice.

Anyone who has worked in compliance long enough knows this is how organisations actually defend themselves. Not by lying. By structuring themselves so they never reach the point where the truth becomes a declarable fact.

So the question is whether the strategy works.

The GDPR, which has an eight-year head start here, has already answered no, and the answer is harder than it is usually quoted. Recital 87 does not say the controller must notify when it knows. It says it should be ascertained whether appropriate technical and organisational measures have been implemented to establish immediately whether a breach has taken place. The object of the assessment is not the notification. It is the capacity to notice. The EDPB, at paragraph 37 of the guidelines, writes that the controller should therefore have internal processes in place to be able to detect and address a breach, and adds that when a breach is detected it is important that it be reported upwards to the appropriate level of management, so it can be addressed and, if required, notified. Paragraph 126 closes the loop: where notification is delayed, the controller must be able to provide reasons for that delay, and documentation relating to it helps demonstrate that the delay was justified and not excessive.

You cannot give the reason for a delay without a chronology. And you cannot have a chronology of an event your systems never recorded.

Under the CRA this principle is going to take a more structural shape, and the date to watch is not last Friday. It is 11 December 2027, when the regulation becomes fully applicable and with it Annex I, Part II, which lists the vulnerability handling requirements. Manufacturers will have to identify and document the vulnerabilities and components in their products, drawing up a machine-readable SBOM covering at the very least the top-level dependencies. They will have to apply effective and regular security tests and reviews. They will have to put in place a coordinated disclosure policy and provide a contact address for reports. And Article 13(7) requires them to systematically document the relevant cybersecurity aspects of their products, including vulnerabilities they become aware of and any relevant information provided by third parties.

Lined up, those obligations do not tell manufacturers they must know everything. They tell them they must hold a current inventory of what they built, a declared channel through which reports arrive, a process that picks those reports up, and a written trace of what they knew and from whom. I have argued elsewhere that European compliance fails for lack of inventory far more than for lack of rules. Here the point widens: the inventory is no longer only about components. It is about the paths by which news of those components reaches somebody who can decide.

So the legislator is not really offering a choice between knowing and not knowing. It has started to regulate the capacity to know, which is a different and far more invasive thing.

Before behaviour there is knowledge

This is the step that makes the essay not about the CRA.

For decades compliance has been told as a two-term relation, between behaviour and rule. A rule sets out what you must do, the organisation does it, and then proves it did. The whole apparatus of audit, certification and documentary evidence comes out of that scheme.

A third term is emerging in the digital field, and it sits before the other two.

You cannot remediate a vulnerability you never identified. You cannot notify an incident nobody classified as one. You cannot assess a risk if the information needed to assess it stayed inside the log of a system nobody watches, or inside the private session of a tool one person uses. The rule says what to do, but the very possibility of applying it depends on a fact the rule does not describe: that the organisation came to know.

The quality of compliance therefore becomes a function of the quality of the organisation’s cognitive apparatus. Not of its good faith, not of its legal budget, not of how many policies it has approved.

That explains, incidentally, why so many compliance programmes produce paper rather than security. They describe required behaviours with great precision and never describe the paths by which the organisation discovers it has to perform them.

When does an agent know

So far the problem is as old as organisations. Here is what makes it urgent.

In that list, the Commission cites internal monitoring, scanning and telemetry as channels through which a manufacturer comes to know about a problem. It is written with signal-generating systems in mind: a honeypot that lights up, a rule that fires, a counter that crosses a threshold. The signal then goes to a person, and the person understands.

We are moving fast into a world where those systems no longer merely signal.

An agent can read a CVE published ten minutes ago, check whether the affected dependency appears in the product’s SBOM, open the repository, check whether the vulnerable function is actually reachable from the code we ship, correlate it with the last seventy-two hours of production telemetry, and open an issue with a conclusion written in plain language: this vulnerability appears to be exploited on this version of the product, and here is the evidence.

This is not a frontier scenario. It is an afternoon’s work with the tools we have now.

When does the organisation know?

When the agent produces the conclusion? When a human reads it? When somebody approves it? When the issue moves from triage to confirmed? When it reaches the mailbox the company has publicly declared to be its security channel, which is to say the single point of contact Annex I requires it to have?

I don’t have the legal answer and I distrust anyone giving one confidently today. I leave it open because it genuinely is, and because there will be no case law on it for years.

What I will say is that AI does not create the problem. It makes it impossible to postpone. We have always treated automated systems as instruments through which people acquire knowledge: the sensor detects, the human knows. With agents we are starting to build systems that gather evidence, form inferences, assess their own confidence and decide on their own that something deserves attention. The line between “the machine detected” and “the organisation knows” is going to get blurrier, and it is going to get blurrier quickly.

From which follows a consequence about internal AI governance that I think is underrated.

Governing an agent will not only mean setting out what it may do. It will mean setting out which facts it is authorised to turn into organisational knowledge.

An agent that finds a vulnerability and leaves the result inside a developer’s private session is one thing. The same agent, same model, same prompt, wired into the company pipeline so that it opens a security incident with a timestamp, is another. Technically they are the same system. Institutionally they are two different entities, because the second one can start a deadline and the first one cannot.

I wrote some time ago that authority arrives before intelligence, and that an agent is interesting not because it does things on its own but because somebody granted it the right to do them. This is the same idea applied to knowing instead of doing. The right to declare, inside an organisation, that something is true, is a delegation like any other, and until yesterday we never wrote it down anywhere because only people had it.

There is an upside too, and it should be said. If the marginal cost of investigating a signal collapses, the number of events an organisation can afford to understand goes up. We will not just get more machine-written code. We may get organisations far more sensitive to their own environment, able to take seriously signals that today get closed unread because reading them costs forty minutes of a good engineer.

That is a good thing. And it produces an almost counterintuitive shift for people who do my job: the problem will no longer be building tools clever enough to see risks. It will be designing the process by which what they see acquires an organisational status.

An institution’s nervous system

The metaphor I use when I have to explain this to a client is anatomical, and it has the merit of breaking the “we need more monitoring” reflex straight away.

A company is not a brain. It is a distributed organism. It has peripheral receptors, transmission paths with different latencies, centres where signals are integrated, and mechanisms by which a stimulus becomes a reflex, a pain, or a conscious decision.

Bad governance, in this picture, is not only having too few receptors. It can be a nervous system that feels perfectly well and transmits slowly, reaching the centre once the damage is done. Or one that generates so many signals it can no longer tell pain from noise, which is the clinical condition of quite a few SOCs I have seen.

If a SOC takes ten thousand irrelevant alerts a week, the organisation is not better informed. It just has more noise, and on top of that it has built a perfectly defensible reason for not looking at the ten thousand and first.

Epistemic quality is not the same as the quantity of available data. It is the ability to turn evidence into beliefs reliable enough to justify acting. Those are two different things, and you cannot buy the second one.

Knowing enough to act

The EDPB’s reference to a reasonable degree of certainty is useful precisely because it recognises this and says it in one line. Legally relevant knowledge is not the same as absolute certainty. The same guidelines note that a short period of initial investigation is legitimate and that during it the controller cannot be regarded as aware, but they add that the investigation should begin as soon as possible and establish, with a reasonable degree of certainty, whether a breach has taken place. The detail comes afterwards.

This puts a finger on something cultural that, to my mind, weighs more than the rule.

A great many organisations have built their decision processes on an implicit premise of certainty. Before you take a problem upwards you must be sure. Before you open an incident you must have confirmation. Before you involve legal or management you must know exactly what happened, because turning up with a wrong hypothesis costs credibility, and credibility is the currency careers are paid in.

The reporting regimes Europe has built over the past eight years are designed precisely to work before that certainty exists. It is why the CRA and NIS2 separate the early warning from the later notification: the first twenty-four hours are, by construction, hours of incomplete information, and the content required in the early warning reflects it. For a severe incident the CRA asks, within 24 hours, at least whether the incident is suspected of being caused by unlawful or malicious acts. At least whether it is suspected. Not what happened.

Law is asking for something many companies find culturally very hard: being able to say, in writing, to an authority, that you know enough to act and not enough to know everything.

It is a form of epistemic maturity, and it is rare.

In my experience the breaking point is almost never technical. On one complex project I worked on, with a chain of responsibility spread across several suppliers, the problem was never missing data: the data was all there, with its timestamps, and had been for months. The problem was that the same anomaly changed its nature depending on who was looking at it. To the developer it was a bug for the backlog. To the person running operations it was a recurring alert with a runbook. To the security lead it was a possible incident, but “possible” was not enough to open one. To management it did not exist until a formal communication arrived, and the formal communication required that somebody had already called the thing an incident.

Reality did not change as it crossed those boundaries. What changed was the status the organisation assigned to it, and the time spent between one boundary and the next was the actual risk. I have no names to give and none are needed: anybody who has worked in an organisation of more than twenty people has already recognised the scene.

The objections that deserve an answer

Two, and the second worries me far more than the first.

The first is that I am reading too much into a word. Awareness is an ordinary piece of legislative technique, the European legislator never set out to build a theory of organisational knowledge, and attributing philosophical intentions to it is the standard vice of people who comment on rules without drafting them.

The objection is sound and I accept it in full. Which is why there is no need to attribute any intention at all. It is enough to observe the organisational effects produced by different instruments that systematically use the same trigger, overlap on the same entities, and each demand a dated declaration. A European software company will end up with three clocks that start from knowledge and one organisation that has to start them. At that point the question of how you know stops being philosophical and becomes a design problem, regardless of what Brussels had in mind.

The second objection is more serious. Over-formalising knowledge can produce defensive organisations, in which every piece of information is classified, logged, routed to legal and treated as evidence, with the effect of degrading the very capacity to react. Anyone who has watched what defensive medicine became knows this is not a theoretical risk. And an engineer who knows their comment on a ticket might be read by an authority in three years will write worse comments, not better ones.

That objection is true too, and I have no answer that dissolves it. I only have a distinction, which I use as a criterion when I have to design these processes.

The goal is not to bureaucratise knowing. It is to reduce ambiguity at the few junctions where ambiguity prevents a timely decision. There are only a handful and they can be counted: who has the authority to declare an incident open, within what time an unassessed signal must be looked at by somebody anyway, which mailbox is the official channel and who reads it at night, what happens when the person who has to decide does not answer. Four or five junctions. Everything else can and should stay informal, because an organisation in which every conversation is an act stops thinking.

The difference between the two is the difference between a nervous system and a plaster cast.

Who turns a possibility into a fact

On Friday, Europe did not simply open a reporting portal.

It made visible something that will accompany technology regulation more and more. A company that builds digital products has to be able to observe itself. It has to know which eyes it owns, which signals it treats as reliable, where the uncertainty it can tolerate ends, and who, at what moment, turns a possibility into a fact the organisation is prepared to answer for.

For years we read digital accountability as the ability to explain what we did. The next level is the ability to explain when we knew enough to do it.

The nature of the evidence changes with it. The final incident report is no longer enough, the well-written one with the timeline reconstructed after the fact and the lessons learned. What becomes relevant is the real timestamps, the escalations, the tickets, the decision logs, the provenance of the information, the initial classification and the changes of assessment. Not because Brussels likes logs. Because without that chain it is impossible to reconstruct an organisation’s epistemic history, and an organisation that cannot reconstruct it cannot defend itself either.

The point is not to show that you reacted. It is to show that you never needed to pretend not to know.

The opposite of compliance is not only breaking a rule. It can be building an organisation incapable of knowing when it is breaking one.

Institutions, like people, are not responsible only for what they know. Under certain conditions they become responsible for the way they chose to know. A father who does not ask, a doctor who does not read the test, a company that does not wire up the log: law and ordinary morality have always known that ignorance can be a construction, and that building it is already a decision.

Technology is simply making that old intuition much more concrete, and much easier to date.

The author

Andrea MargiovanniEU compliance

I work alongside teams designing systems under AI Act, CRA, NIS2, GDPR. The rule is not a checklist: it is an architectural constraint, and it has to be on board at design time, not after.

See the guide →