NIS2 and the Cyber Resilience Act: what software vendors need to prove

This article classifies the requirements from a technical perspective and does not constitute legal advice. Please have a lawyer clarify whether and to what extent the regulations apply to your company.

Two European regulations currently occupy software vendors at the same time, and they are often thrown into one pot. But they ask different questions.

NIS2 asks about your operations

The NIS2 directive targets the cybersecurity of organizations in certain sectors. Those affected must take risk management measures and report certain incidents. Management is personally liable for implementation – that is the point that has drawn the attention.

Relevant for technical practice are above all:

• Risk analysis and security concepts for your own information systems.
• Handling of security incidents, including reporting channels and deadlines.
• Supply chain security, i.e. the assessment of your service providers and components.
• Procedures to assess the effectiveness of the measures taken.

The last point is the one for which a penetration test is the obvious evidence. "We have taken measures" is a claim. "We have the effectiveness reviewed externally on a regular basis and here are the reports" is evidence.

A second, often overlooked point: NIS2 has an effect beyond the directly affected companies. Whoever supplies an affected company has its requirements passed on through the contract. Many software vendors are therefore effectively affected without falling under the directive themselves.

The Cyber Resilience Act asks about your product

The CRA starts at a different point: not with the operation of the organization, but with products with digital elements placed on the EU market. Among other things it requires:

• Security by design and by default – products must be in a secure state on delivery.
• Vulnerability handling over the support period, including provision of security updates.
• A software bill of materials (SBOM) covering the components included.
• Reporting obligations for actively exploited vulnerabilities.
• Technical documentation that demonstrates conformity.

This is about proving that a product meets the state of the art. A test report on the product itself – application test, code review – is the fitting document for that.

What a report must deliver to qualify as evidence

Not every report is suitable for this purpose. From an auditor's point of view it needs at least:

Component	Why
Scope description	Defines what the statement applies to – and what it does not
Period and testers	Assigns the report to a point in time and to a responsibility
Methodology with standard reference	Makes coverage traceable (for example OWASP ASVS)
CVSS rating	Uniform, externally recognized scale
Reproduction steps	Proves that testing actually took place
Retest evidence	Shows that findings were fixed – often the decisive part

The last point is regularly underestimated. An auditor is less interested in the list of problems found than in what became of them. A report without a retest documents a deficiency. A report with a retest documents a working process.

A workable rhythm

For most software vendors a simple pattern has proven itself:

1. Continuously: automated dependency checks in the pipeline, SBOM generation at build time.
2. Quarterly: a light test run after larger releases.
3. Annually: a full application test with report and retest.
4. Ad hoc: before larger architecture changes or before a customer audit.

This creates a gapless chain of evidence without blowing the annual budget. And it answers the question that is actually asked in an audit: not "have you tested?", but "how do you continuously ensure that your product stays secure?".