NIS2-compliant software: what it actually means in 2026

“NIS2-compliant software” is a label that, since 2025, has been appearing with increasing frequency in tender specifications, security questionnaires from regulated clients, and public-sector RFPs. The problem: no mark, no official product certification exists under this name. The NIS2 compliance of a software is an emergent property arising from technical requirements, development processes, and governance. Let’s see what it actually means, because without clarity you risk either overselling (claiming compliance you don’t possess) or not understanding what is really needed when the client asks for it.

TL;DR

• “NIS2-compliant software” is not a product certification. It is the combination of technical requirements implemented in the software + documented development processes + governance of the company that develops it.
• The minimum technical requirements (art. 24 D.Lgs. 138/2024 and ENISA guidelines): strong access control, complete audit logs, encryption, patch management, tested backups, secure development, supply chain security, incident response.
• The de facto reference standard is ISO/IEC 27001, which, while not equivalent to NIS2, covers 70-80% of its technical requirements. ENISA has published specific NIS2 guidelines in 2024-2025 that fill the gap.
• For software sold to NIS2 entities (public administration, healthcare, energy, banks), having ISO/IEC 27001 + a specific NIS2 coverage declaration is the commercial baseline for 2026.
• Italian SME software houses can reach the baseline in 8-14 months with investments of 35-120k euros (consulting + audit + tooling + certification).

What “NIS2-compliant software” does NOT mean

Three common misunderstandings.

It does not mean “we are NIS2-certified by the Ministry”. There is no NIS2 product certification. ACN (National Cybersecurity Agency) verifies the compliance of NIS2 entities (the client companies); it does not issue marks on software.

It does not mean “we have ISO 27001”. ISO 27001 is a useful prerequisite but not sufficient. It covers a good portion of NIS2 management requirements, but some specific requirements (incident reporting within 24-72 hours, ACN registration, personal responsibility of top management, supply chain details) require separate attestation.

It does not mean “we have the firewall and the WAF”. Technical tools are necessary but not enough. NIS2 is a systemic approach: governance + processes + technologies together. Having the WAF without a documented vulnerability management policy does not make you “compliant”.

What it actually means

A software is “NIS2-compliant” when it satisfies three families of conditions:

A. Intrinsic technical requirements: the software itself implements the required technical measures (access control, logs, encryption, etc.).

B. Documented development processes: the software has been developed following a secure development lifecycle, with audit logs of changes, vulnerability management, supply chain security.

C. Vendor governance: the software house that develops it is itself a NIS2 entity (or equivalent), with governance bodies, designated AI/security officer, documented risk management.

Selling “NIS2-compliant software” without covering all three families is imprecise marketing. Serious clients will check it and find out.

The concrete technical requirements of the software

Operational detail of the technical requirements that the software itself must incorporate.

1. Access control and authentication

• Mandatory MFA for administrative access (not optional, not bypassable).
• Password policy compliant with NIST/ENISA 2024-2025 guidelines: minimum length 12 characters, no forced rotation, blacklist of compromised passwords (HaveIBeenPwned API or equivalent).
• Role-Based Access Control (RBAC) with the least privilege principle. No “all users have access to everything”.
• Secure session management: configurable timeouts, re-authentication for critical operations, session revoke in case of password change or suspected compromise.
• Privileged Access Management for admin roles: just-in-time access, specific audit log, documented break-glass procedure.

2. Logging and auditability

• Complete logs of: accesses (success + failure), changes to sensitive data, privileged operations, security configurations.
• Log retention for minimum 12 months, ideally 18-24 months to align with possible post-incident investigations.
• Log tamper-evidence: once written, they must not be modifiable by operators. Use append-only storage or blockchain-style hashing.
• Centralization of logs (SIEM) for correlation and proactive monitoring. Splunk, Elastic SIEM, Wazuh, Microsoft Sentinel are mature options.

3. Encryption

• In transit: TLS 1.3 mandatory for any sensitive data communication. TLS 1.2 acceptable in legacy cases but to be deprecated.
• At rest: AES-256 for sensitive persistent data. Database with transparent data encryption active (PostgreSQL with pgcrypto, SQL Server with TDE, MySQL with keyring).
• Documented key management: HSM or cloud KMS (AWS KMS, Azure Key Vault, GCP KMS) with audit logs. Planned key rotation.
• End-to-end encryption for user-to-user communications when applicable (chat, platform-internal messaging).

4. Vulnerability management and patching

• Automatic dependency scanning in the CI/CD pipeline (Snyk, Dependabot, Renovate, Trivy). CVE check on all dependencies.
• SBOM (Software Bill of Materials) automatically generated for each release. Standard CycloneDX or SPDX format.
• Documented patching SLA: critical vulnerabilities (CVSS >= 9.0) within 72 hours, high (7.0-8.9) within 7 days, medium (4.0-6.9) within 30 days.
• Periodic penetration testing: at least annual, semi-annual above a certain size. Desirable to have a bug bounty program for continuous testing.

5. Backup and disaster recovery

• Automatic backups at least daily, with guaranteed transactional consistency.
• Monthly or quarterly restore testing: it’s not enough to have the backup, you need to test that it can be restored within known times.
• Documented and tested RTO/RPO: how long can we be offline (RTO)? How much data can we lose at most (RPO)?
• Off-site / off-cloud backup: redundant copy in a different geographical region or different provider (to prevent ransomware that also encrypts co-located backups).

6. Incident detection and response

• 24/7 proactive monitoring: SIEM with alerting on anomalous patterns. Internal or external SOC (MSSP) for companies above a certain size.
• Documented and tested incident response plan: who does what within how many minutes, how escalation is triggered, how the client is notified.
• Integrated NIS2 notification procedure: in case of a significant incident, the workflow triggers the report to ACN within 24h (preliminary) and 72h (intermediate).

7. Secure development lifecycle

• Mandatory code review on all merges to main. No longer an option: at least 1 reviewer other than the author.
• Automatic Static Application Security Testing (SAST): SonarQube, Semgrep, CodeQL.
• Dynamic Application Security Testing (DAST) for web applications: OWASP ZAP, Burp Suite Pro.
• Threat modeling for significant new features: explicit identification of attack vectors before development (STRIDE, PASTA framework).
• Secrets management: no hardcoded credentials. Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault.

8. Supply chain security

• Integrity verification of dependencies: package signing, checksum verification.
• Approval process for new dependencies: every new open-source library added goes through a minimum review (popularity, maintenance, license, known vulnerabilities).
• Internal mirror or private registry for critical dependencies: avoids depending on the availability of public npm/PyPI for deployment.
• Vendor security questionnaire for third-party providers: the SaaS you use must also demonstrate a level of security.

9. Privacy by design

GDPR article 25 (Privacy by Design and by Default) integrates with NIS2:

• Data minimization: collect only the data necessary for the service.
• Pseudonymization for personal data when the use case allows it.
• Consent management: explicit management of GDPR consents with audit logs.
• Right to erasure implemented technically: complete deletion of data upon request, including backups.

Reference standards (what tender specifications actually cite)

Italian tender specifications 2025-2026 typically cite:

Mandatory or close to it:

• ISO/IEC 27001 (Information Security Management System): the recognized baseline.
• ISO/IEC 27002: specific controls guidelines.
• D.Lgs. 138/2024 (Italian NIS2).

Often cited:

• Annual ENISA Threat Landscape reports.
• ENISA Guidelines on Security Measures under NIS2 (progressively published 2024-2025).
• NIST Cybersecurity Framework (US reference but with European uptake).
• OWASP Top 10 and OWASP ASVS for web applications.
• CIS Benchmarks for system configurations.

Sector-specific:

• PCI DSS if you handle payments.
• HL7 / FHIR if you operate in healthcare.
• AgID Guidelines for public administration suppliers.
• TISAX if you operate in automotive.

For most Italian software houses, ISO/IEC 27001 + ENISA NIS2 Guidelines are the correct baseline. The others are added selectively by sector.

NIS2-ready software architectures: the patterns

Three architectural patterns that facilitate compliance by design.

Pattern 1: Zero trust architecture

No “trusted internal network”. Every request to a service is authenticated and authorized, even between internal microservices. Implementation: mTLS between services, service mesh (Istio, Linkerd), centralized identity provider (Keycloak, Auth0, Cognito) for services and users.

Pattern 2: Event sourcing for audit logs

For applications where the audit log is critical (healthcare, finance, public administration), event sourcing makes traceability intrinsic: every change is an immutable event saved. The current state is reconstructed from the sequence of events. Auditing is automatic, not an add-on.

Pattern 3: Segregation of concerns

Clear separation between layers:

• Domain layer with the business logic
• Authorization layer that applies RBAC and policies
• Audit layer that logs every significant operation
• Encryption layer that encrypts sensitive data at the boundary

This design makes responsibilities explicit and facilitates compliance auditing.

Mistakes we see in SME software houses

1. “We’ll do ISO 27001 after the next big client”. Certification takes 8-14 months. If you wait for the client who asks for it, you get there when the opportunity is already lost. Starting earlier is strategic even without explicit request.

2. Compliance as an Excel of good intentions. The “Security Policy” document drafted by the consultant in 2 weeks and filed away is not compliance. It’s documentation that, in case of audit, makes a worse impression than the absence of documentation (it shows you invested but didn’t implement).

3. Tool sprawl without integration. Buying 8 different security tools (SIEM, WAF, SAST, DAST, DLP, etc.) without integrating them leads to unmanageable complexity and uncorrelated logs. Better fewer well-integrated tools than many disconnected ones.

4. Dependence on external consultants for operational compliance. Compliance must be internalized into the development team’s processes. Entrusting it exclusively to external consultants means that compliance “exists only when the consultant is in the company”.

5. Underestimating training. NIS2 requires cybersecurity training for all personnel. Without serious investment (4-8 hours/year for each employee, distributed), the “security culture” that ENISA guidelines require simply does not exist.

What to demonstrate in case of audit (ACN or client)

In case of an audit to verify NIS2 compliance of your software or your organization, the auditor will ask for concrete evidence, not generic documents. The most requested evidence:

1. Policy documentation signed and dated (security policies, access, incident response).
2. Risk assessment updated with documented methodology.
3. Audit logs of the software itself (recent samples, demonstrated retention).
4. Documented backup restore tests within the last 12 months.
5. Recent penetration test report (last 12-24 months).
6. Incident response plan + evidence of a tested exercise (tabletop).
7. Personnel training logs (attendance, content, learning tests).
8. SBOM of dependencies + patching log of vulnerabilities.
9. Vendor contracts with appropriate security clauses.
10. Board meeting minutes on security policy deliberations (top management responsibility).

Without this evidence, the auditor concludes for substantial non-compliance, even in the presence of technically correct systems.

FAQ

How much does it cost to make an existing software NIS2-compliant?

For an average Italian software house (20-80 people) with software in production for years:

• Initial setup (consulting + gap audit + tooling + ISO 27001 cert): 35-120k euros spread over 8-14 months.
• Recurring annual costs: 8-25k euros (ISO surveillance audit, tooling maintenance, training).
• Internal effort: 0.3-0.8 FTE dedicated to compliance.

The numbers grow if you start from zero (no policy, no tooling). They go down if you already have a decent security posture.

Is ISO 27001 enough to “be NIS2-compliant”?

It covers 70-80% of the requirements. For the remaining 20-30%, you need supplementary documentation: ACN registration, NIS2-compliant 24-72h incident response, specific mandatory training, formal designation of the security officer with operational powers. Companies already ISO 27001 reach the NIS2 baseline in 4-6 months.

Can you use US clouds (AWS, Azure, GCP) and remain NIS2-compliant?

Yes, with caveats. The three hyperscalers have specific services to achieve compliance (including data residency in EU regions). The critical point is the extra-EU transfer of personal data: GDPR (with standard clauses, Privacy Shield no longer valid) applies and must be evaluated by the DPO. For data under art. 9 (health data, etc.) the cloud choice becomes more restrictive: often you go to Italian sovereign cloud (TIM Cloud, OVH, Aruba) or self-hosted.

Can open-source software be “NIS2-compliant”?

Open-source in itself is neither compliant nor non-compliant: it depends on the integration. A software house that integrates open-source into its own product is responsible for the supply chain security (SBOM, vulnerability monitoring, etc.). You cannot offload responsibilities onto open-source maintainers. Open-source PostgreSQL can perfectly well be part of a NIS2-compliant stack; it must be monitored like any other dependency.

How long do ISO 27001 certifications last?

Three years with annual surveillance audits. Surveillance audits are lighter than the initial audit but still substantial. After 3 years, complete recertification is needed.

How do you balance compliance and development speed?

The typical mistake is to see compliance as a brake. Well-done compliance accelerates development in the medium term (automated security tests, dependency scanning, code review): best practices are also quality practices. In the short term, yes, it adds overhead, but it’s an investment.

What’s the difference between NIS2 and CRA (Cyber Resilience Act)?

The CRA (EU Regulation 2024/2847) is complementary to NIS2: it concerns software/hardware products with digital components on the EU market. It applies to those who sell products, not just to those who operate in critical sectors like NIS2. It came into partial force at the end of 2024, with full application in 2027. For software houses that sell software products in the EU, CRA + NIS2 must be managed together.

Conclusion

Developing NIS2-compliant software in 2026 is an exercise in technical rigor, documented processes, and executive governance. There is no silver bullet or magic certification: there are concrete practices that, applied together and in a demonstrable way, build compliance. Italian software houses that move in 2026 differentiate themselves on the regulated market; those that wait find themselves excluded from tenders.

If you are working on the compliance of your software (or your software house) and want a structured assessment of the gap to close, let’s talk. We can do a gap analysis in 4-6 weeks with an operational plan.

To dig deeper: the pillar page security-aware custom software, the page dedicated to NIS2-compliant software, and the related articles NIS2 for Italian software houses for the corporate regulatory framework, and AI Act in force from August 2026 for those operating on AI as well.