What NIS2 is, in one paragraph
The NIS2 Directive (EU 2022/2555) extends EU cybersecurity obligations to roughly 160,000 organisations across 18 sectors — energy, transport, banking, health, digital infrastructure, manufacturing of critical products, and more — sorted into "essential" and "important" entities based on sector and size (broadly: 250+ staff or €50M+ turnover in Annex I sectors for essential status; 50–249 staff or €10–50M turnover for important status, with some sub-threshold exceptions for DNS providers, TLD registries and similar). Each Member State transposes it into national law, so exact enforcement timelines and supervisory authorities vary by country — this page describes the directive itself, not any one national implementation.
Article 21(2): the 10 measure categories
Article 21(2) requires entities to implement measures covering at least these ten categories — quoted directly from the directive text:
| § | Measure |
|---|---|
| (a) | Policies on risk analysis and information system security |
| (b) | Incident handling |
| (c) | Business continuity, such as backup management and disaster recovery, and crisis management |
| (d) | Supply chain security, including security-related aspects concerning relationships with direct suppliers or service providers |
| (e) | Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure |
| (f) | Policies and procedures to assess the effectiveness of cybersecurity risk-management measures |
| (g) | Basic cyber hygiene practices and cybersecurity training |
| (h) | Policies and procedures regarding the use of cryptography and, where appropriate, encryption |
| (i) | Human resources security, access control policies and asset management |
| (j) | Multi-factor or continuous authentication, secured voice/video/text communications and secured emergency communication systems |
Highlighted rows are the two categories a source-code scan can genuinely produce evidence for. The other eight are organisational, procedural or infrastructure measures — no static analysis tool touches them.
Where StaticCodeAudit actually fits
(e) Vulnerability handling and disclosure
A SARIF 2.1.0 export is exactly the kind of structured, machine-readable vulnerability record this category calls for: a scan run against a given commit, with every finding's rule, severity, file and line — evidence that vulnerability handling happened at a specific point in the development lifecycle, not just a claim that it does.
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-high(d) Supply chain security
A CycloneDX 1.5 SBOM lists every dependency a codebase pulls in — name, version, Package URL. Combined with the SARIF findings from the same scan, it is the kind of artefact a procurement reviewer or auditor can act on when assessing "the overall quality of products and cybersecurity practices" of a supplier, one of the sub-considerations NIS2 attaches to this category.
./staticcodeaudit-linux-x86_64 /path/to/project --sbomA secondary point worth making explicit
Article 21(2)(d) also asks entities to weigh the cybersecurity practices of their own suppliers — including whether those suppliers' tools introduce new data flows. An offline scanner that never uploads source code anywhere doesn't add a new SaaS dependency to a codebase's own supply-chain risk footprint, unlike a cloud-based SAST vendor a security team would then also need to assess.
What this doesn't cover — the honest list
Eight of the ten categories are outside what a source-code scanner can produce evidence for, and no amount of scanning changes that:
- (a) Risk analysis and security policies — an organisational process, not a code artefact.
- (b) Incident handling — requires a response process and team, not a scan.
- (c) Business continuity and disaster recovery — infrastructure and process, unrelated to source code.
- (f) Effectiveness-assessment policies — a governance activity.
- (g) Cyber hygiene training — a people activity.
- (h) Cryptography policy — a written policy; a scan can flag a weak algorithm in code (contributing to ASVS chapter V11) but cannot write or approve the policy itself.
- (i) HR security and access control policy — organisational, not code-level.
- (j) MFA and secured communications — an infrastructure/deployment decision, not a source-code property.
Frequently asked questions
Does using StaticCodeAudit make my organisation NIS2 compliant?
No single tool does. NIS2 compliance is an organisational obligation covering all ten Article 21(2) categories, most of which are policy and process, not software. StaticCodeAudit produces evidence usable for two of them — (d) and (e) — as part of a broader compliance programme, not a substitute for one.
Am I even in scope for NIS2?
Scope depends on your sector (one of 18 listed in the directive's Annex I or II) and size (roughly 50+ staff or €10M+ turnover, with exact thresholds and a few sub-threshold exceptions). This is a legal determination for your organisation's counsel or compliance officer to make, not something a scanner output can answer.
Does the SARIF/SBOM output reference NIS2 directly?
No — the exports are standard formats (OASIS SARIF 2.1.0, OWASP CycloneDX 1.5) with no NIS2-specific fields. The connection to Article 21(2) is in how the evidence is used by your compliance process, not something encoded in the file itself.
How does this relate to the ISO 27001 and ASVS matrices on the standards page?
NIS2 does not mandate a specific technical standard, but Member States and supervisory authorities commonly reference ISO/IEC 27001 and similar frameworks as evidence of "state of the art" measures. The compliance matrices generated by every scan (ISO 27001 Annex A, ASVS, NIST CSF) can serve as supporting material in that broader conversation, on the same honest terms: partial, code-visible coverage only.
See the real evidence a scan produces
Open the live demo report — no install, no signup — and look at the SARIF/SBOM exports and compliance matrices directly.
Open the live report Read more on the regulated industries page