Market surveillance authorities and enterprise buyers ask the same question, and it is not whether you are compliant. It is what you can produce, and how fast.
The short answer
"Are we compliant?" is not a question anyone will ever ask you.
A market surveillance authority asks what you concluded, why, and when. An enterprise buyer asks what you can produce and how quickly. Neither accepts a declaration, because a declaration is an opinion about yourself.
"We are compliant" an assertion. Unverifiable. Worth nothing.
"Here is the assessment,
dated, with its reasoning" a fact. Checkable. Worth everything.The gap between the two is not effort. It is whether the work left a trace.
---
What is actually asked, by whom
A market surveillance authority
Under the CRA, authorities may require the technical documentation and the EU declaration of conformity, and these must be kept available for ten years after the product is placed on the market, or for the support period, whichever is longer.
What they ask is narrower and harder than "are you compliant":
- *How did you classify this product, and on what reasoning?*
- *Show the risk assessment that led to these measures.*
- *Show the vulnerability handling process, running, with dates.*
- *When did you become aware of this vulnerability, and when did you report it?*
Every one of those questions has a date in it. That is the part a compliance programme without records cannot answer, regardless of how good the underlying engineering is.
A NIS2-regulated buyer
Article 21(2)(d) makes them answerable for their suppliers' security, so they push the question down. And essential entities are supervised ex ante — an audit can arrive because of what they are, not because something happened.
They ask for artefacts, not policies. A policy states an intention. An artefact shows the intention was executed.
The one that costs the most: Article 21(2)(f)
NIS2 requires policies and procedures to assess the effectiveness of the measures themselves.
This is the question almost every programme fails, because it cannot be answered by producing a document. It requires a review with a date, a scope, and a result — including results that were not good. An annual assertion that the policy exists is not an assessment of whether it works.
---
The four things worth having, ranked by what they cost
1. A dated classification with its reasoning. Free. It is a page. It answers the first question every authority asks, and its absence cannot be repaired retroactively with any credibility.
2. A published vulnerability contact and disclosure policy. Free, and verifiable from outside — which is precisely why it carries weight. Anyone can check it in ten seconds, including a buyer who has not contacted you yet.
3. An SBOM you can regenerate. Cheap if generated in CI, expensive if produced by hand. Answers *what is in the product* and, through its archive, *which shipped versions are affected*.
4. An effectiveness review, dated. The one nobody has. It is also the one that distinguishes a programme that runs from a programme that was written.
None of the four requires a certification, a notified body, or a budget line. All four are verifiable by someone outside your organisation.
---
Why "audit-ready" is a speed measurement, not a state
The 24-hour early warning under CRA Article 14 and NIS2 Article 23 is not really a reporting deadline. It is a test of whether you can find something out about yourself in a day.
can you determine, within hours, whether a reported vulnerability
affects a version you have shipped?
with an SBOM archive -> a query
without one -> a project, run under a deadlineThe same is true of procurement. A buyer who asks for three artefacts and receives them the same day has learned something about you that no certification communicates.
---
The mistake that costs the most
Preparing the answer instead of keeping the record.
Teams build an "audit pack" ahead of an expected review. It is assembled from memory, dated the day it was written, and describes decisions taken months earlier.
An authority can tell the difference immediately, because the dates do not line up with the product history. A fundamental rights impact assessment written after deployment, a classification reasoned after the launch, an effectiveness review dated the week of the audit — each of these is worse than nothing, because it shows the process did not exist when it mattered.
The record is not a by-product of the work. On this kind of obligation, it is the work.
---
Five things to do this quarter
- 1Write down your classification and date it. Every regulation that reaches you starts here.
- 2Publish the vulnerability contact and disclosure policy. It is free and externally verifiable.
- 3Move SBOM generation into CI, and archive one per shipped version.
- 4Run one effectiveness review and record the result — including what did not work.
- 5Name who can notify an authority, and give them the authority to do it without convening a committee. The 24-hour clock is a decision-rights problem before it is a technical one.
---
See what you could produce today — free, no account
- [Free readiness assessment](/assess) — which obligations reach you, and which artefacts are missing across CRA, NIS2, DORA, the AI Act and RED
- [Compliance responsibility mapper](/resources/responsibility-mapper) — a RACI by role, so each artefact has a named owner
- [Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover
---
Further reading
→ Audit-ready evidence for the CRA → What counts as evidence → What an auditor checks → CRA Article 14 incident reporting → NIS2 incident reporting timelines → One evidence set across five EU regulations
---
*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Retention periods, documentation requirements and supervisory powers differ between instruments and, for NIS2, between national transpositions. Verify against the applicable texts and consult your competent authority or a qualified adviser.*