NIS2 — broader scope than you think
The NIS2 Directive (2022/2555), implemented by member states since October 2024, is significantly broader than its 2016 predecessor. It covers 18 sectors and tens of thousands of entities across the EU — not only critical infrastructure operators, but also digital service providers, managed ICT service providers and software vendors.
The key change: NIS2 extends security responsibility to supply chains. An entity covered by the directive must manage security risk not only internally, but also at its suppliers. This means technology companies delivering to NIS2 entities become part of the regulatory ecosystem — even if they are not directly covered by the directive.
Art. 21 — supply chain security
Article 21(2)(d) of the NIS2 Directive imposes the obligation to manage supply chain security, “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.”
In practice, this means NIS2 entities will require software and ICT service suppliers to document their security controls. Not as a formality — but as a condition for establishing and continuing cooperation.
SBOM — from voluntary to required
Software Bill of Materials (SBOM) — a structured list of software components with versions and dependencies — is becoming a key document in the NIS2 context. It allows the entity purchasing software to verify its composition and quickly identify exposure to newly discovered vulnerabilities.
The analogy is simple: just as a food manufacturer is required to list ingredients, software suppliers will need to document what their product is built from. US Executive Order 14028, the Cyber Resilience Act (upcoming EU regulation) and growing Enterprise contractual requirements point in the same direction.
Organizations that don’t have automated SBOM generation as part of their build process will need to create these documents manually — which for complex applications with dozens of transitive dependencies is practically impossible to maintain.
What “supplier risk management” means in practice
A NIS2 entity purchasing external software now has an obligation to assess that supplier’s risk. Assessment mechanisms typically include: security questionnaires, certificate review (ISO 27001, SOC 2), requests for technical documentation, and for critical suppliers — audits.
For a technology company that wants to remain a supplier to Enterprise clients in the EU, this means the need to prepare an “evidence package” — documentation confirming actual implementation of security controls, not just declarations of their existence.
Sanctions and enforcement
NIS2 provides for administrative sanctions of up to EUR 10 million or 2% of global turnover (for essential entities) and EUR 7 million or 1.4% of turnover (for important entities). More significant, however, are the business consequences — exclusion from tenders, loss of contracts, obligation to notify clients of incidents.
How NIS2 affects the CI/CD pipeline
NIS2 supply chain requirements translate into concrete expectations for the software development process. An entity covered by the directive, commissioning a supplier audit, looks for answers to questions that directly concern pipeline configuration.
Code and artifact integrity: Is there a mechanism to verify that the artifact deployed to production is exactly what the pipeline built? Artifact signing (Cosign/Sigstore) provides cryptographic proof of integrity. Without it — the supplier cannot prove the integrity of their product.
Vulnerability management in dependencies: Is the application scanned for known vulnerabilities (CVEs) in external libraries? NIS2 Art. 21(2)(e) requires “practices for handling and disclosing vulnerabilities.” In the pipeline context, this means automated SCA (Software Composition Analysis) scanning at every build — not a one-time report.
Pipeline access control: Who can run workflows and modify deployment configuration? The principle of least privilege applies not only to the production application, but also to the tools that build and deploy it. OIDC instead of static tokens eliminates one of the most common access takeover vectors.
Documentation and audit trail: Every pipeline run should generate artifacts that can be presented to an auditor: build logs, scan results, SBOM, artifact signatures. This is precisely what makes up an Evidence Pack.
Implementation timeline and what it means now
The NIS2 Directive entered into force on January 16, 2023, and member states had until October 17, 2024 to transpose it into national law. Poland is working on a cybersecurity national system act (amendment to the 2018 act), whose final shape is still being determined.
Regardless of the pace of national legislation — NIS2 entities are already applying the directive’s requirements in their relationships with suppliers. Security questionnaires, technical documentation requests and SBOM requirements are appearing in RFPs not because national law demands it — but because the EU directive gives them a basis, and compliance officer pressure is real.
For technology companies in Poland, this means: don’t wait for the act. Prepare your technical documentation and Evidence Pack now — because Enterprise clients are asking today.
Read also: