NIS2 and the Cyber Resilience Act: effectiveness has to be proven

Over the past few months, two European sets of rules have significantly tightened what is expected of IT security in mid-sized companies. They are often mentioned in the same breath, yet they address different parties and give rise to different tasks. What they share is a characteristic that is easy to overlook: taking protective measures is not enough. You have to be able to prove that they work.

Two sets of rules, two audiences

NIS2 is a directive, Directive (EU) 2022/2555. It addresses organisations and governs how a company secures its own IT, reports incidents and keeps an eye on its supply chain. It was transposed into German law by the NIS2 Implementation Act, which was promulgated on 5 December 2025 and came into force on 6 December 2025. The substantive obligations have since sat in the BSI Act.

The Cyber Resilience Act is a regulation, Regulation (EU) 2024/2847. It applies directly, without a national implementing act, and addresses manufacturers: anyone placing a product with digital elements on the EU market. It does not govern how a company protects itself, but which security properties a product must have and how long the manufacturer remains answerable for them. The Cyber Resilience Act applies in stages. The provisions on the notification of conformity assessment bodies have applied since 11 June 2026. The reporting obligations under Article 14 apply from 11 September 2026. The main remaining CRA obligations apply from 11 December 2027.

Anyone who develops software and operates it themselves is caught by both, in two different roles. That is the case most often underestimated in practice.

How many companies are affected

The figure that best describes the scale comes from the BSI itself: around 4,500 organisations were subject to the regulation up to now; in future it will be some 29,500 entities, roughly a sixfold increase. The jump arises because NIS2 widens the sectors covered and introduces size thresholds that catch many mid-sized companies which have never regarded themselves as critical infrastructure.

What applies from when

NIS2: assessing effectiveness is an obligation in its own right

The core of the NIS2 transposition sits in Section 30 of the BSI Act. Entities in scope must take appropriate technical and organisational measures and document them. The Act lists ten areas that have to be covered, among them risk analysis, handling security incidents, business continuity, supply chain security, cryptography, access control and multi-factor authentication.

Two of those ten areas bear directly on quality assurance. One concerns security in the acquisition, development and maintenance of information technology systems, including the handling of vulnerabilities. The other requires policies and procedures to assess the effectiveness of the risk management measures taken.

The second point is the genuine change. Implementing a measure and demonstrating that a measure is effective are two different tasks, and the second calls for procedures defined in advance. The BSI is specific here and names four building blocks: measurable indicators with defined thresholds, internal and external audits, regular reports to the management body, and an improvement process that draws consequences from the results. To classify the level reached, the BSI points to its own maturity model with five levels, from "planned" to "continuously improved".

The pattern is familiar from test management: indicator, threshold, planned check, documented result and follow-up action. It is the same control loop, applied to security measures rather than to functionality.

The obligations with hard deadlines

NIS2 also sets clear reporting and registration deadlines. Registration with the BSI must take place no later than three months after the point at which an entity first, or once again, falls within scope. For a significant security incident, a three-stage reporting chain applies: an early initial report within 24 hours, a more detailed report within 72 hours and a final report no later than one month after the 72-hour notification.

Responsibility for implementation and oversight also rests expressly with the management body. It cannot be delegated to the IT department, and it comes with training obligations.

Cyber Resilience Act: testing is explicit

The CRA obliges manufacturers to build cybersecurity into design and development from the outset, following the principles of "secure by design" and "secure by default". The specific requirements are set out in Annex I, which is in two parts: Part I describes properties the product must have, Part II the handling of vulnerabilities across the entire support period.

Part II contains the requirement that makes this a test-management task: manufacturers must carry out effective and regular tests and reviews of the security of the product. Not once for approval, but on an ongoing basis. Added to that is the obligation to identify the components contained in the product and to maintain them in a software bill of materials, in a commonly used and machine-readable format. The BSI aptly describes it as the ingredients list of the software: which libraries and other constituents are in there. It does not have to be published, but it does have to be maintained.

Reporting runs through ENISA's single reporting platform. For actively exploited vulnerabilities and severe incidents, an early warning must first be submitted within 24 hours, followed by a full notification within 72 hours. For actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For severe incidents, the final report is due within one month of the 72-hour notification. Across the declared support period the manufacturer owes free security updates, and that period runs for at least five years unless the expected lifetime of the product is shorter.

Security updates are releases too

This is precisely where the task arises that most project plans leave out. At least five years of obligatory security updates means years of changes to a live product, at customers who are using it. Every one of those updates is a release. Every one of them can break something that worked before.

A manufacturer that has to close vulnerabilities quickly and has no dependable body of regression tests faces an uncomfortable choice: ship fast and risk knock-on defects at the customer, or test thoroughly and leave the vulnerability open for longer. Both are expensive. The way out is not more people, but a regression suite prioritised on a risk basis: you do not test everything with every patch, only what lies on the change path and is business-critical. That prioritisation has to be settled in advance, not worked out on the night of the emergency patch.

For organisations in scope of NIS2, the operational challenge is different. Even an organisation that merely buys and operates software has to install security updates, and promptly. The only way to know that an update does not disrupt your own operations is to test it. An acceptance test for third-party software is not a luxury; it is what makes fast patching possible in the first place.

What test management contributes, and what it does not

The boundary matters here. Test management is not a substitute for an information security management system, certification consultancy or penetration testing. Anyone wanting to build an ISMS, run a supply chain analysis or have a security architecture reviewed needs the appropriate specialists for that.

What test management does contribute is the part where both sets of rules have the same need, namely structured evidence:

• A risk picture that assesses requirements and changes by likelihood and impact and derives the test depth from that. It provides the rationale for why some things are tested deeply and others only lightly.
• An auditable test plan with defined entry and exit criteria. Without criteria set in advance there is no statement about effectiveness, only a feeling.
• A requirements traceability matrix showing which requirement is covered by which test. In an audit it is the document that answers the question "how do you know?" in a single sentence.
• A risk-based regression strategy for the support period. It determines whether a security update can be delivered in days or in weeks.
• A documented release approval record for each release, stating the result, the open points and the named residual risks.

These controls are not specific to NIS2 or the CRA. An organisation that already steers quality on the basis of data does not have to build a second world for these rules, only extend its existing chain of evidence to security matters.

Who does what

Qelivia's role is deliberately limited: we plan, manage and document the testing. We produce the risk picture, the test plan, the authoring standard and the release approval record, and we take on review and sign-off of the test case inventory. Your team runs the tests themselves, in your tool or in a test environment we provide. The reason is the same as on any other engagement: the detailed system and domain knowledge sits with you, and no outsider can credibly replace it.

Equally clearly: a test plan is not a conformity assessment under the CRA and not a supervisory report under NIS2. It replaces neither the legal review nor the notified body where one is required. What it delivers is the technical basis on which both can rest in the first place.

Conclusion

NIS2 and the Cyber Resilience Act are two different sets of rules with a shared question. NIS2 asks an organisation: are your measures effective, and how do you know? The CRA asks a manufacturer: is your product secure, and will it still be across the whole support period? Both questions can only be answered with evidence that arises during the work, not afterwards. Put the chain of evidence in place now and the proof comes later as a by-product. Wait, and you have to reconstruct it; with test results that is precisely what cannot be done.

Note: This article reflects the position as at 25 August 2026 and summarises publicly available sources from the BSI and the EU institutions. This article is not legal advice. Whether, and in which role, your organisation is affected by NIS2 or by the Cyber Resilience Act should be reviewed by a lawyer.