Software conforme NIS2: cosa significa concretamente nel 2026

“Software conforme NIS2” è un’etichetta che dal 2025 compare con frequenza crescente in capitolati di gara, security questionnaire di clienti regolamentati, RFP della PA. Il problema: nessun marchio, nessuna certificazione ufficiale di prodotto esiste con questo nome. La conformità NIS2 di un software è una proprietà emergente derivante da requisiti tecnici, processi di sviluppo e governance. Vediamo concretamente cosa significa, perché senza chiarezza si rischia o di sovravendere (sostenendo conformità che non si possiede) o di non capire cosa serve davvero quando il cliente la richiede.

TL;DR

• “Software conforme NIS2” non è una certificazione di prodotto. È la combinazione di requisiti tecnici implementati nel software + processi di sviluppo documentati + governance della società che lo sviluppa.
• I requisiti tecnici minimi (art. 24 D.Lgs. 138/2024 e linee guida ENISA): controllo accessi forte, audit log completi, cifratura, patch management, backup testati, secure development, supply chain security, incident response.
• Lo standard di riferimento de facto è ISO/IEC 27001, che pur non essendo equivalente a NIS2 ne copre il 70-80% dei requisiti tecnici. ENISA ha pubblicato linee guida specifiche NIS2 nel 2024-2025 che integrano il gap.
• Per software venduto a soggetti NIS2 (PA, sanità, energia, banche), avere ISO/IEC 27001 + dichiarazione di copertura NIS2 specifica è la baseline commerciale del 2026.
• Le PMI software house italiane possono raggiungere la baseline in 8-14 mesi con investimenti di 35-120k euro (consulenza + audit + tooling + certificazione).

Cosa NON significa “software conforme NIS2”

Tre fraintendimenti diffusi.

Non significa “siamo certificati NIS2 dal Ministero”. Non esiste certificazione di prodotto NIS2. ACN (Agenzia Cybersicurezza Nazionale) verifica la conformità dei soggetti NIS2 (le aziende clienti), non emette marchi sui software.

Non significa “abbiamo ISO 27001”. ISO 27001 è un prerequisito utile ma non sufficiente. Copre buona parte dei requisiti NIS2 di gestione, ma alcuni requisiti specifici (incident reporting in 24-72 ore, registrazione ACN, responsabilità personale dei vertici, dettagli su supply chain) richiedono attestazione separata.

Non significa “abbiamo il firewall e il WAF”. Strumenti tecnici sono necessari ma non bastano. NIS2 è un approccio sistemico: governance + processi + tecnologie insieme. Avere il WAF senza la policy documentata di gestione vulnerabilità non rende “conformi”.

Cosa significa effettivamente

Un software è “conforme NIS2” quando soddisfa tre famiglie di condizioni:

A. Requisiti tecnici intrinseci: il software stesso implementa le misure tecniche richieste (controllo accessi, log, cifratura, ecc.).

B. Processi di sviluppo documentati: il software è stato sviluppato seguendo secure development lifecycle, con audit log delle modifiche, gestione delle vulnerabilità, supply chain security.

C. Governance del fornitore: la software house che lo sviluppa è essa stessa soggetto NIS2 (o equivalente), con organi di governance, AI/security officer designato, risk management documentato.

Vendere “software conforme NIS2” senza coprire tutte e tre le famiglie è marketing impreciso. I clienti seri lo verificano e lo trovano.

I requisiti tecnici concreti del software

Dettaglio operativo dei requisiti tecnici che il software stesso deve incorporare.

1. Controllo accessi e autenticazione

• MFA obbligatoria per accessi amministrativi (non opzionale, non bypassabile).
• Politica password conforme a linee guida NIST/ENISA 2024-2025: lunghezza minima 12 caratteri, no rotazione forzata, blacklist password compromesse (HaveIBeenPwned API o equivalente).
• Role-Based Access Control (RBAC) con principio del minimo privilegio. Niente “tutti gli utenti hanno accesso a tutto”.
• Session management sicuro: timeout configurabili, re-authentication per operazioni critiche, revoke delle sessioni in caso di cambio password o compromissione sospetta.
• Privileged Access Management per ruoli admin: just-in-time access, audit log specifico, break-glass procedure documentate.

2. Logging e auditability

• Log completi di: accessi (successo + fallimento), modifiche su dati sensibili, operazioni privilegiate, configurazioni di sicurezza.
• Retention dei log per minimo 12 mesi, idealmente 18-24 mesi per allinearsi a possibili indagini post-incident.
• Tamper-evidence dei log: una volta scritti non devono essere modificabili da operatori. Usare append-only storage o blockchain-style hashing.
• Centralizzazione dei log (SIEM) per correlazione e monitoring proattivo. Splunk, Elastic SIEM, Wazuh, Microsoft Sentinel sono opzioni mature.

3. Cifratura

• In transito: TLS 1.3 obbligatorio per qualsiasi comunicazione di dati sensibili. TLS 1.2 accettabile in casi legacy ma da deprecare.
• A riposo: AES-256 per dati persistenti sensibili. Database con transparent data encryption attiva (PostgreSQL con pgcrypto, SQL Server con TDE, MySQL con keyring).
• Key management documentato: HSM o KMS cloud (AWS KMS, Azure Key Vault, GCP KMS) con audit log. Rotazione delle chiavi pianificata.
• End-to-end encryption per comunicazioni utente-utente quando applicabile (chat, messaging interni a piattaforma).

4. Gestione vulnerabilità e patch

• Dependency scanning automatico nel CI/CD pipeline (Snyk, Dependabot, Renovate, Trivy). Verifica CVE su tutte le dipendenze.
• SBOM (Software Bill of Materials) generato automaticamente per ogni release. Formato CycloneDX o SPDX standard.
• SLA di patching documentato: vulnerabilità critiche (CVSS ≥ 9.0) entro 72 ore, alte (7.0-8.9) entro 7 giorni, medie (4.0-6.9) entro 30 giorni.
• Penetration testing periodico: almeno annuale, sopra una certa dimensione semestrale. Auspicabile bug bounty program per testing continuo.

5. Backup e disaster recovery

• Backup automatici giornalieri minimo, transactional consistency garantita.
• Test di restore mensile o trimestrale: non basta avere il backup, va testato che si possa ripristinare in tempi noti.
• RTO/RPO documentati e testati: per quanto tempo possiamo stare offline (RTO)? Quanti dati possiamo perdere al massimo (RPO)?
• Backup off-site / off-cloud: copia ridondante in regione geografica diversa o provider diverso (per prevenzione ransomware che cifra anche backup co-located).

6. Incident detection e response

• Monitoring proattivo 24/7: SIEM con alerting su pattern anomali. SOC interno o esterno (MSSP) per aziende sopra una certa dimensione.
• Incident response plan documentato e testato: chi fa cosa entro quanti minuti, come si attiva l’escalation, come si notifica il cliente.
• Procedura di notifica NIS2 integrata: in caso di incidente significativo, il workflow attiva la segnalazione ad ACN entro 24h (preliminare) e 72h (intermedia).

7. Secure development lifecycle

• Code review obbligatoria su tutti i merge in main. Non più un option: almeno 1 reviewer diverso dall’autore.
• Static Application Security Testing (SAST) automatico: SonarQube, Semgrep, CodeQL.
• Dynamic Application Security Testing (DAST) per applicazioni web: OWASP ZAP, Burp Suite Pro.
• Threat modeling per nuove feature significative: identificazione esplicita dei vettori d’attacco prima dello sviluppo (STRIDE, PASTA framework).
• Secrets management: niente credenziali hardcoded. Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault.

8. Supply chain security

• Verifica integrità delle dipendenze: package signing, checksum verification.
• Approval process per nuove dipendenze: ogni nuova libreria open-source aggiunta passa una review minima (popolarità, manutenzione, licenza, vulnerabilità note).
• Mirror interno o registry privato per dipendenze critiche: evita di dipendere dalla disponibilità di npm/PyPI pubblici per il deploy.
• Vendor security questionnaire per fornitori di terze parti: i SaaS che vi servono devono dimostrare anche loro un livello di sicurezza.

9. Privacy by design

GDPR articolo 25 (Privacy by Design and by Default) si integra con NIS2:

• Data minimization: raccogliere solo i dati necessari per il servizio.
• Pseudonymization per dati personali quando il caso d’uso lo permette.
• Consent management: gestione esplicita dei consensi GDPR con audit log.
• Right to erasure implementato tecnicamente: cancellazione completa dei dati su richiesta, inclusi backup.

Standard di riferimento (cosa cita davvero un capitolato di gara)

I capitolati di gara italiani 2025-2026 citano tipicamente:

Obbligatorio o quasi:

• ISO/IEC 27001 (Information Security Management System): la baseline riconosciuta.
• ISO/IEC 27002: linee guida specifiche dei controlli.
• D.Lgs. 138/2024 (NIS2 italiana).

Spesso citati:

• ENISA Threat Landscape report annuali.
• ENISA Guidelines on Security Measures under NIS2 (pubblicate progressivamente 2024-2025).
• NIST Cybersecurity Framework (riferimento USA ma con uptake europeo).
• OWASP Top 10 e OWASP ASVS per applicazioni web.
• CIS Benchmarks per configurazioni di sistema.

Settoriali specifici:

• PCI DSS se si gestiscono pagamenti.
• HL7 / FHIR se si opera in sanità.
• AgID Linee Guida per fornitori della PA.
• TISAX se si opera in automotive.

Per la maggior parte delle software house italiane, ISO/IEC 27001 + ENISA NIS2 Guidelines sono la baseline corretta. Le altre vengono aggiunte selettivamente per settore.

Architetture software NIS2-ready: i pattern

Tre pattern architetturali che facilitano la conformità per design.

Pattern 1: Zero trust architecture

Niente “rete interna fidata”. Ogni richiesta verso un servizio è autenticata e autorizzata, anche fra microservizi interni. Implementazione: mTLS fra servizi, service mesh (Istio, Linkerd), identity provider centralizzato (Keycloak, Auth0, Cognito) per servizi e utenti.

Pattern 2: Event sourcing per audit log

Per applicazioni dove l’audit log è critico (sanità, finanza, PA), event sourcing rende intrinseca la tracciabilità: ogni modifica è un evento immutabile salvato. Lo stato corrente si ricostruisce dalla sequenza eventi. Audit è automatico, non un add-on.

Pattern 3: Segregation of concerns

Separazione netta fra layer:

• Domain layer con la logica business
• Authorization layer che applica RBAC e policy
• Audit layer che logga ogni operazione significativa
• Encryption layer che cifra i dati sensibili al boundary

Questo design rende esplicite le responsabilità e facilita l’audit di conformità.

Errori che vediamo nelle PMI software house

1. “Faremo ISO 27001 dopo il prossimo cliente grosso”. La certificazione richiede 8-14 mesi. Se aspettate il cliente che la chiede, ci arrivate quando l’opportunità è già persa. Iniziare prima è strategico anche senza richiesta esplicita.

2. Compliance come Excel di buoni propositi. Il documento “Politica di sicurezza” steso dal consulente in 2 settimane e archiviato non è compliance. È documentazione che in caso di audit fa peggiore figura dell’assenza di documentazione (mostra che si è investito ma non implementato).

3. Tool sprawl senza integrazione. Comprare 8 tool di security diversi (SIEM, WAF, SAST, DAST, DLP, ecc.) senza integrarli porta a complessità ingestibile e log non correlati. Meglio meno tool ben integrati che molti scollegati.

4. Dipendenza da consulenti esterni per la compliance operativa. La compliance va internalizzata nei processi del team di sviluppo. Affidarla esclusivamente a consulenti esterni significa che la compliance “esiste solo quando il consulente è in azienda”.

5. Sottovalutazione della formazione. NIS2 richiede formazione cybersecurity per tutto il personale. Senza investimento serio (4-8 ore/anno per ogni dipendente, distribuito), la “cultura della sicurezza” che le linee guida ENISA richiedono semplicemente non esiste.

Cosa dimostrare in caso di audit (ACN o cliente)

In caso di audit per verificare conformità NIS2 del vostro software o della vostra organizzazione, l’auditor chiederà evidenze concrete, non documenti generici. Le evidenze più richieste:

1. Documentazione policy firmata e datata (politiche di sicurezza, accesso, incident response).
2. Risk assessment aggiornato con metodologia documentata.
3. Audit log del software stesso (campioni recenti, retention dimostrata).
4. Test di restore backup documentati negli ultimi 12 mesi.
5. Penetration test report recente (ultimi 12-24 mesi).
6. Incident response plan + evidenza di esercitazione (tabletop) testata.
7. Log di formazione del personale (presenze, contenuti, test di apprendimento).
8. SBOM delle dipendenze + log di patching delle vulnerabilità.
9. Contratti fornitori con clausole di sicurezza appropriate.
10. Verbali CdA sulle deliberazioni di security policy (responsabilità dei vertici).

Senza queste evidenze, l’auditor conclude per non-conformità sostanziale, anche in presenza di sistemi tecnici corretti.

FAQ

Quanto costa rendere un software esistente NIS2-conforme?

Per una software house italiana media (20-80 persone) con software in produzione da anni:

• Setup iniziale (consulenza + audit gap + tooling + cert ISO 27001): 35-120k euro distribuiti su 8-14 mesi.
• Costi ricorrenti annui: 8-25k euro (audit sorveglianza ISO, manutenzione tooling, formazione).
• Effort interno: 0.3-0.8 FTE dedicato alla compliance.

I numeri crescono se partite da zero (nessuna policy, nessun tooling). Scendono se avete già una postura di sicurezza decente.

ISO 27001 basta per “essere NIS2-compliant”?

Copre il 70-80% dei requisiti. Per il restante 20-30% serve documentazione integrativa: registrazione ACN, incident response 24-72h conforme, formazione obbligatoria specifica, designazione formale del responsabile sicurezza con poteri operativi. Aziende già ISO 27001 raggiungono la baseline NIS2 in 4-6 mesi.

Si possono usare cloud US (AWS, Azure, GCP) restando NIS2-compliant?

Sì, con caveat. I tre hyperscaler hanno servizi specifici per ottenere conformità (compreso data residency in regioni UE). Il punto critico è il trasferimento extra-UE dei dati personali: GDPR (con le clausole standard, Privacy Shield non più valido) si applica e va valutato dal DPO. Per dati ex art. 9 (sanitari, ecc.) la scelta cloud diventa più restrittiva: spesso si va su cloud sovrano italiano (TIM Cloud, OVH, Aruba) o self-hosted.

Il software open-source può essere “NIS2-compliant”?

L’open-source in sé non è né compliant né non-compliant: dipende dall’integrazione. Una software house che integra open-source nel proprio prodotto è responsabile della supply chain security (SBOM, vulnerability monitoring, etc.). Non potete scaricare le responsabilità ai maintainer open-source. PostgreSQL open-source può tranquillamente essere parte di uno stack NIS2-compliant; va monitorato come qualsiasi altra dipendenza.

Quanto durano le certificazioni ISO 27001?

Tre anni con audit di sorveglianza annuali. Audit di sorveglianza più leggero dell’audit iniziale ma comunque sostanziale. Dopo 3 anni serve ricertificazione completa.

Come si bilancia compliance e velocità di sviluppo?

L’errore tipico è vedere la compliance come freno. Compliance ben fatta accelera lo sviluppo nel medio periodo (test automatizzati di security, dependency scanning, code review): le best practice sono anche pratiche di qualità. Nel breve, sì, aggiunge overhead, ma è investimento.

Che differenza c’è fra NIS2 e CRA (Cyber Resilience Act)?

Il CRA (Regolamento UE 2024/2847) è complementare a NIS2: riguarda i prodotti software/hardware con componenti digitali in commercio nell’UE. Si applica a chi vende prodotti, non solo a chi opera in settori critici come NIS2. Entrato in vigore parziale a fine 2024, applicazione piena nel 2027. Per software house che vendono prodotti software in UE, CRA + NIS2 vanno gestiti insieme.

Conclusione

Sviluppare software conforme NIS2 nel 2026 è un esercizio di rigore tecnico, processi documentati e governance esecutiva. Non c’è una silver bullet né una certificazione magica: ci sono pratiche concrete che, applicate insieme e in modo dimostrabile, costruiscono la conformità. Le software house italiane che si muovono nel 2026 si differenziano sul mercato regolamentato; quelle che aspettano si trovano escluse dalle gare.

Se state lavorando alla conformità del vostro software (o della vostra software house) e volete un assessment strutturato del gap da chiudere, parliamone. Possiamo fare un gap analysis in 4-6 settimane con piano operativo.

Per approfondire: la pagina pilastro software custom security-aware, la pagina dedicata al software conforme NIS2, e gli articoli correlati NIS2 per software house italiane per il quadro normativo aziendale, e AI Act da agosto 2026 per chi opera anche su AI.