Findings register
Visible gaps with evidence references, severity and a closure route.
Regulation (EU) 2024/2847 — Cyber Resilience Act
Find your CRA gaps. Plan your next steps.
For manufacturers of digital products: we clarify scope, review existing evidence and structure the next steps.
You get a findings register, a prioritised action plan and structured technical evidence you can review with your team.
First step
Know what you will take forward.
Our engagements turn open compliance questions into concrete working documents. Scope and deliverables are agreed before work begins.
Prioritised action plan
Sequenced actions, owners and review points for the work ahead.
Structured technical evidence
A clear file structure for the documents your product actually needs.
- Describe the product and its current evidence.We start from the product, intended purpose and release process.
- Clarify scope and open questions together.We separate what is known, missing and still needs a decision.
- Set the right review and next steps.You leave with a bounded starting point, not a generic checklist.
Step 01 — Orientation
Four questions decide most of it.
Answer them and the page tells you where you probably stand: out of scope, in scope as a distributor, or in scope as a manufacturer — and how heavy the work is likely to be.
Software, network interfaces and components obtained from other manufacturers are what turn a physical product into a product with digital elements — the subject of the questions below.
- Placed on the market under your own name or brand
- Contains software or connects to a network, a device or a service
- Even where parts come from other manufacturers
Question 1 of 3
This is an orientation, not a classification decision. Category assignment under Annex III depends on the product's intended purpose and is documented in the technical file; we confirm it in writing before any other work starts.
Step 02 — Services
Six services. One clear next step.
Start with the question that matters most. Each service names the problem, the deliverable and the next decision.
- Scope & classification
- Is the product a product with digital elements? Which Annex III or Annex IV category applies? Which conformity assessment route follows from that? Output: a written scope opinion with the regulatory basis.
- Gap analysis
- The core engagement. Every Annex I requirement checked against your current state, each finding with evidence, severity and a closure route. Output: findings register, closure plan, effort estimate.
- Documentation & conformity
- Technical documentation to Annex VII, declaration of conformity to Annex V, CE marking workflow, and a review of the evidence needed for the applicable assessment route.
- Reporting readiness
- Article 14 is already live. We build the detection-to-notification path, the 24-hour and 72-hour runbook, and the evidence trail behind both.
- Vulnerability handling
- Support period definition, coordinated disclosure, SBOM maintenance and the process that keeps both alive after the project ends.
- General consulting
- Where the same evidence base serves other obligations: customer security questionnaires, procurement requirements, management-system alignment, build-vs-buy decisions.
Step 03 — The core engagement
The gap analysis is the product.
Not a slide deck. A register in which every requirement has a state, an owner and a piece of evidence — or an explicit note that the evidence does not exist yet.
How the work runs
-
Evidence intake
Architecture, release process, existing security documentation, SBOM if it exists, vulnerability handling, support commitments.
-
Requirement-by-requirement assessment
Annex I Part I against the product, Part II against the process. Each line gets one of four states: met, partially met, missing, not applicable.
-
Findings register
Every gap written so that an engineer can act on it and an auditor can verify it. Severity, evidence, closure route, effort.
-
Closure plan
Sequenced by what blocks CE marking first, not by what is easiest. With named owners and review dates.
| ID | Requirement | State | Severity |
|---|---|---|---|
| I-04 | Secure default configuration, ability to reset to a secure state | Partly met | High |
| I-07 | Security updates available for the support period | Met | — |
| I-09 | Limitation of attack surface, including external interfaces | Missing | High |
| II-02 | Vulnerability handling process with coordinated disclosure | Missing | Critical |
| II-05 | Software bill of materials, maintained per release | Partly met | Medium |
Findings are written against the regulation's own wording. Where a requirement does not apply to your product, that is recorded too — a documented non-applicability is worth as much as a fix.
The method, in one image
Annex I, requirement by requirement.
This is a gap analysis while it runs: every requirement is assessed, the findings are marked, then they are closed. The 28 checks illustrate a sample register, not the number of legal requirements or a real product.
Step 04 — Already in force
Reporting is not a formality any more.
Since 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents. The clock starts when you become aware — not when the fix ships.
- ≤ 24 h Early warningWithout undue delay, and in any event within 24 hours of becoming aware of an actively exploited vulnerability.
- ≤ 72 h Vulnerability notificationGeneral information about the vulnerability, its severity, impact and any indicators of compromise.
- After Corrective and mitigating measuresAnd, where a severe incident is involved, the information the receiving CSIRT needs to assess the situation.
Timings per Article 14 of Regulation (EU) 2024/2847. Administrative fines for missing the 24-hour deadline do not apply to micro and small enterprises — the reporting duty itself still does.
What has to exist before the first incident
- Who decides, who reports, who speaks to customers — named, with deputies
- A monitored channel for vulnerability reports from outside
- Severity criteria that map to your own product, agreed in advance
- The notification content assembled and kept current, not written under pressure
- An evidence trail for each notification: what you knew, when, and what you did
Plus two long-running obligations: a support period of at least five years unless the product's lifetime is shorter, and a software bill of materials that is maintained — not generated once for an audit.
Step 05 — Classification
Category decides the route.
The same requirement set applies to everyone in scope. What changes with the category is how you have to prove conformity — and who has to look at it.
| Category | Where it is defined | Typical assessment route |
|---|---|---|
| Default products | All products with digital elements not listed in Annex III or IV | Internal control — self-assessment against Annex I, documentation, CE marking |
| Important · Class I | Annex III | Self-assessment against harmonised standards, or third-party assessment where those standards are not applied |
| Important · Class II | Annex III | Third-party conformity assessment |
| Critical | Annex IV | European cybersecurity certification or a full third-party assessment |
Category is assigned on the basis of the product's intended purpose, and can change if the intended purpose changes. It is one of the first things we put in writing, because it drives the timeline, the cost and who signs off.
Step 06 — Deliverables
The documents your team receives.
Depending on the agreed scope, we prepare the documents below for your team to use and maintain. We agree which are included before work starts.
- Scope opinion
Whether the product is in scope, which category applies, and which conformity route follows.Scope & classification - Findings register
Annex I Part I and Part II, line by line, with evidence, severity and state.Evidence & gaps - Remediation plan
Sequenced actions, owners, dependencies and the review points that prove closure.Actions & owners - Technical documentation
Assembled to the structure the regulation requires, with a gap list for what you still have to supply.Technical file - Declaration of conformity
Prepared to the required model structure, ready for signature once the evidence exists.Declaration draft - Reporting runbook
Detection to notification, with the 24-hour and 72-hour paths and pre-drafted content.Incident response - SBOM handling
Format, per-release process and the update loop that keeps it alive.Component inventory
Company
We bridge the gap between engineering and compliance.
We believe effective compliance starts with understanding the engineering itself.
Engineering experience gives us the context. Risk-based thinking gives us the method. Compliance and cybersecurity give us the focus.
Step 07 — Questions
The ones that come up first.
We already ship for years. Does the CRA apply to products already on the market?
Article 14 reporting also covers in-scope products placed on the market before 11 December 2027. Other CRA requirements apply to those products if they undergo a substantial modification from that date (Article 69(2)–(3)).
Is custom software we build for a single client a product with digital elements?
A single-customer contract does not in itself exclude software from the CRA. We check market supply, connectivity and the specific exclusions in Article 2; remote data processing can also be part of a product.
Our product is a machine with embedded control software. Where do we start?
With the intended purpose and the interfaces. Which digital elements are part of the product you place on the market, and which are components obtained from others? That split decides your obligations and your evidence.
What does a harmonised standard give us?
It creates a presumption of conformity for the requirements it covers. Without applicable harmonised standards, the route may change, particularly for Class I products — which is why category and standards availability are checked before documentation starts.
Can you just write the documentation for us?
We write the file, but not the facts. Documentation without real evidence fails the first serious audit — worse than having none. So we make the gap visible, sequence the closures, and build the file to hold up.
How long does an engagement take?
Timing depends on the product scope, available evidence and access to your team. We agree milestones and deliverables before the engagement starts.
Start a conversation
Start with the product, not the paperwork.
In an initial conversation, we review your product, its intended use and your current questions. Together we define what needs closer assessment and agree the scope of the next step.
- What to bring
A product description, the intended purpose, and whoever owns the release process. - What you get back
An agreed scope for the assessment. Written findings and delivery dates are defined in the proposal.
The company is being established. The contact address is not yet available. You can prepare and copy an enquiry here; nothing is sent.
Your enquiry text
The recipient address is still being confirmed. You can copy your details and use your usual contact route.