Software & SaaS | Modelled case study
Stand up CRA Article 14 reporting with signed incident evidence
How do we meet the CRA's actively-exploited-vulnerability and severe-incident reporting duties without leaking customer data in the process?
Reviewed as of 2026-10-26 · primary scenario
The modelled organisation
A recognisable problem reaches the operating agenda
This composite scenario follows the Product Security Officer · Head of Engineering · Legal functions. It is grounded in the cited problem context but does not identify a real customer.
Operating environment
A software provider ships frequent releases through source, build, package, deployment, dependency, and customer-assurance systems.
What is at stake
Customers and regulators need to distinguish an authorized release and evidenced control from a claim assembled after an incident.
Situation
CRA Article 14 reporting applies from September 2026 through the ENISA Single Reporting Platform, and manufacturers must report inside strict windows while protecting evidence and customer data.
Event that forces action
CRA Article 14 enforcement from 11 September 2026, or a notified-body conformity-assessment schedule.
Concrete system boundary
Systems this case study puts in scope
The model is specific about the operational surfaces that must be discovered, changed, or independently checked.
product inventory and CBOM records
vulnerability and incident intake
signed evidence submission path
customer notification workflows
Modelled case study walkthrough
How this organisation would use QNSI
The walkthrough connects the real-world problem to a bounded QNSI contribution and an independently reviewable result.
Recognise the operating condition
CRA Article 14 reporting applies from September 2026 through the ENISA Single Reporting Platform, and manufacturers must report inside strict windows while protecting evidence and customer data.
Frame the decision the owners must make
How do we meet the CRA's actively-exploited-vulnerability and severe-incident reporting duties without leaking customer data in the process?
Apply QNSI to the controlled boundary
Scope affected products from inventory and CBOM records, encrypt and sign incident evidence, and govern the disclosure workflow with policy-controlled access.
Leave the team with a concrete result
A CRA-aligned reporting runbook with signed incident evidence, product-scope records and an authorised SRP submission path.
Prove the result in the organisation's environment
Legal owns notification wording and timelines; engineering verifies the evidence pack excludes customer-confidential material.
What useful success looks like
A decision artifact plus proof from the real environment
The model stops at a target result. It becomes an actual case study only when a customer produces and independently validates this evidence in production.
Decision artifact
A CRA-aligned reporting runbook with signed incident evidence, product-scope records and an authorised SRP submission path.
Independent validation boundary
Legal owns notification wording and timelines; engineering verifies the evidence pack excludes customer-confidential material.
Real-world problem grounding
Primary sources behind the model
These sources establish the external requirement, failure mode, or risk context used to model this case. They do not endorse HEOSSI or prove that QNSI completed the scenario.
Customer evidence status
This is modelled, not a customer claim
The organisation is a composite and the result is a target state. This page does not prove a deployment, customer outcome, certification, legal conclusion, regulator endorsement, or completed control.