On this page
- Name the product owner, technical lead, approver, reporting submitter and deputies.
- Build one evidence baseline before scaling to the portfolio.
- Turn unknowns into owned actions without treating them as resolved requirements.
- Practise reporting with fictional cases and the actual handoff process.
Decide what the internal team can own
The team can collect product facts, maintain inventories, perform security work, investigate findings and organise documentation. It also needs someone with authority to accept conclusions and commit resources. A technical lead should not be left to make a commercial support promise or an uncertain legal classification without the right decision-maker.
The Commission's manufacturer guidance provides the lifecycle context. This guide proposes an internal operating method; it does not replace the applicable conformity-assessment procedure. If you mean self-assessment as a legal route, use the separate self-assessment guide.
Choose one product and establish the boundary
Start with an identifiable offering and release. Describe what customers receive, the intended functions, connected services, manufacturer entity and distribution model. Record any exclusions or assumptions that need review. A company-wide statement such as we only sell SaaS is too imprecise when the business also supplies agents or downloadable clients.
Gather the source or build references, SBOM, architecture, security tests, user instructions and support policy. Mark absent or stale material explicitly. The first pass is a map of the evidence you have, not a declaration that the product is ready for market.
Assign responsibilities before generating a backlog
A manageable process has a named person for each kind of work and an agreed escalation path. The following is a suggested division of responsibility. Adapt it to your size, but retain the distinction between supplying evidence and accepting a conclusion.
| Responsibility | Working output | Escalation |
|---|---|---|
| Product owner | Scope, functions and support facts | Commercial or legal uncertainty |
| Engineering lead | Controls, tests, SBOM and fixes | Missing capacity or unresolved technical risk |
| Security coordinator | Vulnerability triage and incident evidence | Potential reporting trigger |
| Accountable approver | Recorded acceptance or refusal | Required specialist or external assessment |
| Reporting submitter and deputy | Submission, receipt and follow-up | Access failure or approaching deadline |
Separate missing evidence from engineering risk
Review the applicable requirements against the product evidence. For each unresolved item, explain whether the control is absent, the evidence is insufficient, the applicability is uncertain or a human decision is pending. These distinctions prevent a documentation task from being confused with a vulnerability remediation task.
For example, an unsigned support policy needs an accountable commitment. An insecure update channel needs engineering remediation and testing. A test report with no build identifier needs provenance work. All three can block a confident review, but they require different owners and completion evidence.
Build the Article 14 runbook now
Name who receives security reports, who investigates, who decides the reporting outcome, who submits and who communicates with users. Include deputies and out-of-hours contact methods. The operational question is whether the team can act when the primary owner is unavailable, not whether a policy file exists.
Article 14 applies from 11 September 2026. Use ENISA's Single Reporting Platform guidance to verify current registration and reporting instructions. Establish the correct manufacturer representation and channel before a live event. An internal case tracker and a registered submitter solve different parts of the process.
Run a fictional drill with a late data entry
Give the team a scenario involving a supported product, a credible security signal and an awareness time earlier than case creation. Ask them to identify the product versions, preserve the original signal, assess the trigger and calculate the relevant deadlines. Make every record clearly a drill and do not send a test notification through a live authority channel.
Remove the primary submitter from the exercise. Can the deputy find the evidence, access the approved submission process and identify the next required action? Introduce a missing component version or unavailable advisory source and check that uncertainty remains visible. Record the gaps and repeat the part that failed after it is fixed.
Review the process after the next release
Once the first baseline exists, use the next update to test maintenance. Check changed product facts, inventory, security evidence and support assumptions. Preserve earlier conclusions and explain which ones need new review. A monthly meeting may help coordinate work, but a live security signal must follow the runbook without waiting for that meeting.
ConformOps can hold the assessment and evidence chain; Continuous includes reporting cases, the runbook and named release operations. It does not submit reports externally or make final legal decisions. Use the readiness-check guide to inspect whether the process is working, and bring focused unresolved questions to a qualified specialist.
Frequently asked questions
Can we prepare for CRA without a consultant-led project?
You can organise the evidence and recurring work internally if the team has the necessary competence and authority. Seek specialist help for unresolved questions and complete any external procedure required by the applicable conformity route.
What should an in-house readiness assessment produce?
A scoped product record, an evidence baseline, unresolved items with owners, recorded decisions and a reporting runbook that has been exercised.
Should a reporting drill create a real authority notification?
No. Use clearly marked fictional records and the appropriate test or training arrangements, where available. Do not submit a fictional event through a live channel as if it were real.