Regolamentazione europea: CRA, NIS2 e oltre

22 Gennaio 2026

Indice dei contenuti

Parole chiave consigliate (usate e in grassetto nell’articolo)
Campo di applicazione e soggetti coinvolti
Obblighi chiave: reporting incidenti, secure-by-design, SBOM, certificazione
Impatti per le imprese italiane: dalla gap analysis alla compliance misurabile
Checklist essenziale per il Cyber Resilience Act (prodotti digitali)
Template di reporting incidenti (NIS2) – esempi pronti da usare
Esempi pratici per secure-by-design e SBOM (CRA)
Best practice: integrare sicurezza, privacy e compliance
Snippet utili: script e modelli per accelerare l’adeguamento
Prospettive: AI Act, GPAI, guidance e codici di pratica

Il quadro europeo della cyber security è entrato in una fase di maturità: la Direttiva NIS2, il Cyber Resilience Act (CRA), il Cyber Security Act e l’AI Act stanno ridisegnando responsabilità, processi e controlli lungo tutto il ciclo di vita del prodotto digitale, del servizio e dei dati.

Per le organizzazioni italiane dalle PMI ai grandi gruppi, fino agli operatori dei servizi essenziali non si tratta solo di “mettere a posto la compliance”, ma di tradurre obblighi in processi misurabili, architetture sicure-by-design, monitoraggio continuo e governance orchestrata tra CISO, team compliance e linee di business.

In questo articolo operativo (e molto approfondito) trovi:

Una panoramica normativa con campo di applicazione, soggetti e obblighi (es. reporting incidenti, secure-by-design, SBOM, certificazione).
Gli impatti per le imprese italiane con gap analysis, roadmap di adeguamento, KPI e sanzioni.
Un esempio operativo: checklist per CRA, template report incidenti (NIS2), esempi di policy e snippet di codice utili.
Il ruolo del CISO e del team compliance: governance, responsabilità, audit interno.
Le prospettive future: interazione con AI Act, Cyber Security Act, certificazione europea e schemi ENISA.

Timeline chiave (aggiornate): il Cyber Resilience Act è entrato in vigore il 10 dicembre 2024; le principali obbligazioni applicano dall’11 dicembre 2027. La Direttiva NIS2 (UE 2022/2555) è già in vigore e in Italia è attuata con D.Lgs. 138/2024; introduce scadenze stringenti per il reporting degli incidenti (allerta entro 24 ore, notifica entro 72 ore e report finale entro un mese). L’AI Act è entrato in vigore il 1° agosto 2024 con applicazioni scaglionate fino al 2 agosto 2027 (inclusi obblighi per GPAI dal 2 agosto 2025).

Panoramica normativa europea: dal prodotto al servizio, fino all’AI

La legislazione UE ha costruito un “tessuto” coerente:

Direttiva NIS2
Amplia platea e obblighi rispetto a NIS1; impone gestione del rischio, reporting incidenti strutturato, misure tecniche e organizzative, supervisione e sanzioni. Per l’Italia, il D.Lgs. 138/2024 ha definito ruoli, Autorità (in primis ACN), processi e ambiti settoriali. Tempi del reporting: early warning entro 24 ore, notifica entro 72 ore, report finale entro un mese (e aggiornamenti intermedi se l’incidente è in corso).
Cyber Resilience Act (CRA)
Introduce requisiti di secure-by-design per prodotti con elementi digitali (software e hardware), gestione vulnerabilità lungo tutto il ciclo di vita, SBOM e obblighi di segnalazione. Applicazione piena dall’11 dicembre 2027: i produttori devono già oggi pianificare processi, toolchain e contratti.
Cyber Security Act
Rafforza ENISA e istituisce il quadro europeo di certificazione (schemi volontari con livelli di assicurazione basic, substantial, high) per prodotti, servizi e processi ICT: tassello chiave per dimostrare compliance e fiducia sul mercato.
AI Act
Approccio risk-based; vieta usi ad rischio inaccettabile, regolamenta i sistemi ad alto rischio con requisiti stringenti (dalla qualità dei dati alla valutazione di conformità), introduce obblighi specifici per GPAI e trasparenza (anche su deepfake/chatbot). Timeline applicativa scaglionata fino al 2027.

Questi strumenti non vivono isolati: NIS2 si concentra su governance del rischio e resilienza dei servizi, CRA sulla sicurezza intrinseca del prodotto (compreso software standalone), Cyber Security Act abilita certificazione e fiducia, AI Act regola i sistemi di intelligenza artificiale con livelli di rischio, inclusi i modelli GPAI.

Campo di applicazione e soggetti coinvolti

NIS2

La NIS2 si applica a una vasta gamma di entità “essenziali” e “importanti” in settori critici (energia, trasporti, bancario, sanitario, infrastrutture digitali, pubblica amministrazione, ecc.) e in numerosi servizi digitali. L’adesione non dipende solo dal settore ma anche da dimensioni e impatto. In Italia, l’ACN è Autorità competente NIS e punto di contatto unico.

Obblighi principali: gestione del rischio, reporting incidenti, business continuity, audit interno e cooperazione con le autorità. L’inosservanza comporta sanzioni significative.

Cyber Resilience Act

Il Cyber Resilience Act si applica a prodotti con elementi digitali immessi sul mercato UE: include software, hardware, componenti e prodotti connessi. I fabbricanti (e, secondo i casi, importatori e distributori) devono garantire secure-by-design, gestione delle vulnerabilità (incluso processo di coordinated vulnerability disclosure), SBOM, tracciabilità aggiornamenti e segnalazioni. Applicazione piena: 11 dicembre 2027.

Cyber Security Act

Riguarda l’architettura di certificazione paneuropea coordinata da ENISA. Non è un obbligo generalizzato, ma sempre più gare e supply chain richiedono schemi riconosciuti (es. EUCC basato su Common Criteria). Livelli di assicurazione: basic, substantial, high.

AI Act

Si applica a fornitori e utilizzatori di sistemi di AI nell’UE. Obblighi mirati per sistemi ad alto rischio (es. impiego in infrastrutture critiche, sanità, occupazione), regole di trasparenza per sistemi a rischio limitato (chatbot, deepfake), obblighi specifici per GPAI. Timeline: divieti e alfabetizzazione AI dal 2 febbraio 2025, obblighi GPAI dal 2 agosto 2025, piena applicazione al 2 agosto 2026 (con estensioni fino al 2027 per alcune categorie).

Obblighi chiave: reporting incidenti, secure-by-design, SBOM, certificazione

Reporting incidenti (NIS2)

Early warning entro 24 ore da quando si viene a conoscenza dell’incidente significativo (indicando se si sospettano atti illeciti o impatti transfrontalieri).
Incident notification entro 72 ore con valutazione iniziale, indicatori, impatti su servizi e utenti, misure intraprese.
Report finale entro 1 mese, con analisi causa radice e azioni correttive.
Aggiornamenti intermedi (progress report) se l’incidente è ancora in corso.

Secure-by-design e gestione vulnerabilità (CRA)

Requisiti di secure-by-design e secure-by-default nei prodotti con elementi digitali;
Processo documentato di gestione vulnerabilità (monitoraggio, patching, comunicazione clienti);
Disponibilità di SBOM;
Gestione dell’end-of-support con trasparenza su rischi residui. Applicazione piena dal 2027.

Certificazione (Cyber Security Act)

Possibilità di dimostrare compliance e maturità tramite schemi EU (es. EUCC – Common Criteria – e futuri per cloud/servizi).
Livelli di assicurazione graduati (basic/substantial/high). Crescente richiesta nelle supply chain e nelle gare PA.

AI Act

Classificazione per rischio: divieti (es. social scoring), requisiti severi per sistemi ad alto rischio (data governance, logging, trasparenza, human oversight, cyber security), obblighi per GPAI (trasparenza, documentazione).

Impatti per le imprese italiane: dalla gap analysis alla compliance misurabile

Per rispettare NIS2 e arrivare pronti a CRA, occorre una roadmap integrata. Gli impatti più concreti:

Governance
Eesponsabilità formali (Board, CISO, team compliance), politiche, ruoli e audit interno periodico.
Processi
Gestione vulnerabilità, patch management, incident response, change management, supplier risk.
Tecnologia
Asset inventory continuo, EDR/XDR, SIEM/SOAR, telemetria, gestione SBOM, pipeline DevSecOps.
Persone
Formazione, piani di consapevolezza, esercitazioni tabletop, KPI e OKR di sicurezza.
Contratti
Clausole su sicurezza e reporting incidenti per la supply chain, SLA di patching, obblighi di notifica, penali.
Documentazione
Politiche, procedure, template report incidenti, registri, evidenze di controllo.

Esempio di Gap Analysis (rapida ma efficace)

Ambito
Sistemi e servizi critici (perimetro NIS2), portafoglio prodotti software/hardware (perimetro CRA).
Controlli
Mappa requisiti NIS2/CRA vs controlli attuali (framework NIST/ISO 27001/ISA/IEC 62443 dove rilevante).
Maturity scoring
0–5 per ciascun requisito (politiche, processo, tecnologia, evidenze).
Prioritizzazione
Rischio e costi (quick wins in 90 giorni; iniziative strutturali in 6–18 mesi).
Roadmap
Milestones, owner, budget, KPI (es. % sistemi con SBOM, tempo medio patching CVSS≥7, MTTD/MTTR incidenti, copertura logging).

Checklist essenziale per il Cyber Resilience Act (prodotti digitali)

Inventario prodotti con elementi digitali e versioni; mappa componenti e dipendenze (open source incluse) → SBOM.
Secure-by-design
Minimi di sicurezza predefiniti, hardening, configurazioni secure-by-default, limitazione superfici d’attacco.
Threat modeling e analisi rischi per release; requisiti di sicurezza nei criteri di accettazione.
Pipeline DevSecOps
SAST/DAST/SCA (incluso controllo licenze), firma artefatti, supply chain di build riproducibile.
Gestione vulnerabilità
Intake (CVD), triage, remediation SLA, comunicazione clienti, tracking CVE.
Documentazione tecnica
Sicurezza, test, piani di aggiornamento, fine supporto; istruzioni per l’utente su configurazioni sicure.
Monitoring in-field
Telemetria (privacy-by-design), raccolta crash/vuln, canale di aggiornamento sicuro.
Contratti
Clausole con fornitori/componenti, diritti di audit, gestione fine vita.
Evidenze
Report di test, attestazioni, audit trail; preparazione alla vigilanza.
Piano di transizione fino al 2027
Priorità per famiglia di prodotti, budget, staffing e certificazione dove utile.

Template di reporting incidenti (NIS2) – esempi pronti da usare

Di seguito un template minimal (estendibile) per allinearsi a early warning (24h), incident notification (72h) e final report (30 giorni). Adattalo alle linee guida dell’ACN/CSIRT competente.

1) Early Warning (entro 24h)

incident_id: "NIS2-2025-000123"

phase: "early_warning_24h"

detection_timestamp: "2025-11-04T07:15:00Z"

report_timestamp: "2025-11-04T14:00:00Z"

reporter:

  entity: "Acme SpA"

  sector: "Healthcare"

  contact: "ciso@acme.example"

summary:

  suspected_illicit_act: true

  cross_border_impact: "unknown"

  affected_services: ["EHR portal", "API gateway"]

  preliminary_iocs: ["1.2.3.4", "malware: possible cobalt strike"]

initial_actions:

  - "isolated affected subnets"

  - "blocked outbound C2 domains"

requested_guidance: true

2) Incident Notification (entro 72h)

incident_id: "NIS2-2025-000123"

phase: "incident_notification_72h"

impact:

  service_disruption: "partial"

  users_affected: 24000

  data_compromise: "under_investigation"

technical_details:

  attack_vector: "phishing -> credential theft -> lateral movement"

  iocs:

    ips: ["1.2.3.4","5.6.7.8"]

    hashes: ["sha256:..."]

  mitre_techniques: ["T1566", "T1078", "T1021"]

mitigation:

  containment: ["account reset","network segmentation","EDR quarantine"]

  eradication: ["malware removal","kerberos reset"]

coordination:

  csirt_contacted: "yes"

  law_enforcement: "no"

  suppliers_involved: ["IdP vendor", "MFA provider"]

3) Final Report (entro 30 giorni)

incident_id: "NIS2-2025-000123"

phase: "final_report_30d"

root_cause: "legacy vpn exposed; missing mfa exception policy"

timeline:

  - "2025-11-01 10:12Z initial phishing"

  - "2025-11-02 08:05Z lateral movement"

  - "2025-11-03 17:45Z detection by EDR"

  - "2025-11-04 07:15Z incident declared"

lessons_learned:

  - "enforce conditional access for all identities"

  - "deprecate legacy vpn by Q1"

  - "tuning SIEM detection for abnormal OAuth grants"

kpi:

  mttd_hours: 33

  mttr_hours: 60

follow_up_actions:

  - "tabletop exercise"

  - "supplier security review"

  - "audit interno su identity governance"

Le strutture e le tempistiche sono coerenti con NIS2 (24h/72h/30gg) e prassi europee. Verifica sempre eventuali specificità del tuo settore e dell’Autorità competente.

Esempi pratici per secure-by-design e SBOM (CRA)

Pipeline DevSecOps con SBOM automatico

Esempio di integrazione SBOM nel ciclo di build (adatta a GitLab/GitHub Actions/Jenkins):

# Genera SBOM in formato CycloneDX

cyclonedx-bom -o sbom.json

# Verifica vulnerabilità note (SCA)

grype dir:. --output json > vuln-report.json

# Firma artefatti (es. Sigstore cosign)

cosign sign --key cosign.key registry.example.com/app:1.2.3

# Policy gate (pseudocomando): rifiuta build se CVSS≥7 non mitigati

./policy-gate --sbom sbom.json --vulns vuln-report.json --cvss-threshold 7.0

File di policy di sicurezza del prodotto (estratto)

product_security_policy:

  secure_defaults: true

  hardening_baseline: "CIS Level 1"

  crypto_minimums:

    tls: "1.2+"

    algorithms: ["AES-GCM","CHACHA20-POLY1305"]

    key_rotation_days: 90

  vulnerability_management:

    intake: "security@example.com"

    cvd: "https://example.com/.well-known/security.txt"

    triage_sla_days:

      critical: 7

      high: 15

      medium: 30

  sbom:

    format: "CycloneDX"

    published_to_customers: true

  update_lifecycle:

    eol_notice_months: 12

    channel: "signed OTA"

Questa impostazione supporta compliance CRA: secure-by-design, gestione vulnerabilità, SBOM, ciclo di patching e comunicazione trasparente.

Roadmap di adeguamento: 90 giorni → 12 mesi → 24+ mesi

Fase 1 – 90 giorni (Quick Wins)

Nomina formale di CISO/team compliance, definizione governance e RACI.
Gap analysis NIS2/CRA vs controlli attuali; mappa asset critici e servizi essenziali.
Stabilire processo di reporting incidenti (24/72/30) e creare template + runbook.
Avviare generazione SBOM per i principali prodotti e definire baseline secure-by-design.
Attivare telemetria minima (EDR, logging centralizzato) e canali di coordinated vulnerability disclosure.

Fase 2 – 6-12 mesi (Strutturazione)

Implementare pipeline DevSecOps con SAST/DAST/SCA e policy gate.
Formalizzare audit interno, tabletop incident response, KPI (MTTD/MTTR, patch SLA).
Aggiornare contratti supply chain: sanzioni e obblighi di reporting incidenti.
Preparare dossier tecnico per certificazione (dove utile) secondo Cyber Security Act/ENISA.

Fase 3 – 12-24+ mesi (Maturità e certificazione)

Estendere SBOM a tutti i prodotti, integrare gestione vulnerabilità con priorità rischio.
Eseguire audit interno periodici, readiness assessment per vigilanza.
Allineare sistemi AI agli obblighi AI Act (classificazione alto rischio, governance dati, human oversight).
Valutare schemi EU (es. EUCC) per rafforzare posizione di mercato.

Ruolo del CISO e del team compliance: orchestrare tecnologia, legale e business

CISO
Definisce strategia, risk appetite, architetture secure-by-design, telemetria, gestione vulnerabilità, incident response e audit interno.
Team compliance
Interpreta la norma, redige policy, coordina reporting incidenti, conserva evidenze.
IT/Dev
Integra controlli in pipeline, produce SBOM, implementa patching.
Procurement/Legale
Aggiorna contratti, inserisce requisiti e sanzioni; governa la supply chain.
Board
Supervisiona e finanzia la roadmap, valuta KPI e rischi.

Best practice: integrare sicurezza, privacy e compliance

Privacy-by-design insieme a secure-by-design: DPIA dove necessario, minimizzazione dati, logging proporzionato.
Threat modeling su processi e prodotti (inclusa supply chain); test di penetrazione mirati.
Gestione vulnerabilità orchestrata: criteri di rischio, SLA, comunicazione clienti e Autorità.
Formazione mirata per sviluppatori e operations; esercitazioni tabletop multi-ruolo.
Metriche: dal controllo “di conformità” a KPI che misurano resilienza reale (tempo di patch, riduzione superfici d’attacco, copertura SBOM).
Certificazione dove strategica (schemi ENISA): dimostra compliance e differenziazione.

Snippet utili: script e modelli per accelerare l’adeguamento

Esempio – Valutazione rapida di conformità (pseudo-Python)

requirements = {

  "NIS2": ["incident_24h","incident_72h","final_30d","risk_management","business_continuity","audit_interno"],

  "CRA":  ["secure_by_design","vuln_mgmt","sbom","update_policy","cvd_channel"]

}

controls = {

  "incident_24h": True,

  "incident_72h": True,

  "final_30d": False,

  "risk_management": True,

  "business_continuity": False,

  "audit_interno": False,

  "secure_by_design": "partial",

  "vuln_mgmt": True,

  "sbom": "partial",

  "update_policy": False,

  "cvd_channel": True

}

def score(val):

    return 1 if val is True else (0.5 if val=="partial" else 0)

nis2 = sum(score(controls[r]) for r in requirements["NIS2"])/len(requirements["NIS2"])

cra  = sum(score(controls[r]) for r in requirements["CRA"])/len(requirements["CRA"])

print({"NIS2_score": nis2, "CRA_score": cra})

Idea: ottenere un “termometro” per la gap analysis (0–1) e collegare i punteggi ai KPI.

Esempio – security.txt per CVD

Contact: mailto:security@example.com

Encryption: https://example.com/pgp.txt

Policy: https://example.com/security-policy

Acknowledgments: https://example.com/hall-of-fame

Preferred-Languages: it, en

Sanzioni e enforcement: perché serve agire ora

NIS2 prevede sanzioni efficaci, proporzionate e dissuasive (importi e criteri a livello nazionale; in Italia definite dal D.Lgs. 138/2024 con ruoli ACN e autorità settoriali). La non conformità a reporting incidenti e misure di gestione del rischio è tra le violazioni più gravi.
CRA
Dal 2027, immissione sul mercato di prodotti non conformi espone a blocchi, richiami e sanzioni; impatti diretti sul time-to-market e sulla supply chain.
AI Act
Fino a 35 milioni di euro o 7% del fatturato per violazioni gravi (range indicativo in comunicazioni ufficiali e stampa). Applicazioni scaglionate e work-in-progress su codici di condotta/GPAI nel 2025.

Prospettive: AI Act, GPAI, guidance e codici di pratica

Nel 2025 la Commissione ha confermato la timeline dell’AI Act e ha promosso un Code of Practice per supportare la conformità dei modelli GPAI: utile per dare certezze interpretative e allineare industria e regolatore. Per le aziende significa preparare sin d’ora inventari AI, classificazione per rischio, policy interne e data governance.

Caso operativo (esempio): come un programma integrato riduce incidenti e tempi di risposta

Un’azienda manifatturiera con prodotti connessi e portale clienti:

Avvia gap analysis NIS2/CRA → scopre assenza di SBOM e runbook di reporting incidenti incompleti.
Implementa pipeline DevSecOps, SBOM CycloneDX e policy gate; definisce template NIS2 24/72/30.
Aggiorna contratti con fornitori per SLA di patching e notifica.
Esegue due tabletop/anno con CISO, team compliance, IT e legale.
Risultato: MTTD ridotto del 40%, MTTR del 35%, 100% incidenti notificati entro 72 ore, nessuna non conformità in audit, time-to-patch CVSS≥7 da 21 a 10 giorni. (Esempio realistico di impatto KPI).

Conclusioni

Il nuovo equilibrio europeo spinge le organizzazioni a passare dalla “compliance episodica” alla resilienza continua. NIS2 obbliga a governance, reporting incidenti e audit interno; il CRA porta la sicurezza dentro il prodotto con secure-by-design e SBOM; il Cyber Security Act offre strumenti di certificazione per la fiducia; l’AI Act chiude il cerchio su sistemi e modelli di intelligenza artificiale (GPAI, alto rischio). Agire ora con gap analysis, roadmap e KPI – significa ridurre rischi, evitare sanzioni e guadagnare vantaggio competitivo.

Bonus operativo: mini-roadmap pronta all’uso (riassunto)

0–30 giorni
Ruoli (CISO, team compliance), template report incidenti, inventario asset/prodotti.
30–90 giorni
SBOM per prodotto core, baseline secure-by-design, esercitazione tabletop.
3–12 mesi
Pipeline DevSecOps con SAST/DAST/SCA, policy gate, contratti supply-chain.
12–24 mesi
Certificazione dove strategica, integrazione AI Act per casi alto rischio, audit interno a regime.

Domande frequenti

Che differenza c’è tra NIS2 e Cyber Resilience Act?
NIS2 regola la resilienza dei servizi e la gestione del rischio a livello organizzativo, inclusi reporting incidenti e sanzioni; il CRA impone requisiti di secure-by-design ai prodotti con elementi digitali (software/hardware), SBOM e gestione vulnerabilità lungo il ciclo di vita.
Siamo una PMI: dobbiamo preoccuparci?
Sì. NIS2 amplia l’ambito soggettivo; se rientrate come “importanti”/“essenziali” avrete obblighi stringenti. Anche se fuori da NIS2, il CRA può toccarvi se producete o immettete sul mercato prodotti digitali.
Quali sono le scadenze per NIS2 nel reporting incidenti?
24 ore per l’early warning, 72 ore per la notifica, 30 giorni per il report finale (con aggiornamenti intermedi se necessario).
Quando si applica il Cyber Resilience Act?
In vigore dal 10 dicembre 2024; obblighi principali applicano dall’11 dicembre 2027.
Che cos’è una SBOM e perché è importante per il CRA?
È l’elenco delle componenti software (e relative versioni/licenze). Serve a gestire vulnerabilità e rischi della supply chain e a dimostrare secure-by-design.
Come si collega il Cyber Security Act a questi obblighi?
Fornisce il quadro di certificazione europeo (schemi ENISA, livelli basic/substantial/high) che può supportare la compliance e la fiducia della supply chain.
Cosa cambia con l’AI Act per chi usa modelli di AI generativa (GPAI)?
Dal 2 agosto 2025 scattano obblighi di trasparenza e documentazione per GPAI; per sistemi alto rischio servono requisiti più severi (data governance, human oversight, ecc.).
Quali sono le sanzioni previste?
NIS2: sanzioni nazionali significative (in Italia vedi D.Lgs. 138/2024). AI Act: fino a 35 milioni o 7% del fatturato per casi gravi. Nel CRA, dal 2027, immissione di prodotti non conformi può portare a blocchi e sanzioni.
Come iniziare una gap analysis efficace?
Mappa requisiti NIS2/CRA su controlli esistenti; misura maturità 0–5; definisci priorità per rischio/costo; pianifica roadmap a 90 giorni/12 mesi/24 mesi con KPI chiari.
La certificazione è obbligatoria?
Non sempre. Ma gli schemi ENISA stanno diventando un “linguaggio comune” di fiducia: utili per gare, supply chain e mercati regolati.