Periodi di supporto per la sicurezza CRA UE con ISO 27001

Sono le 08:20 di un martedì e il responsabile di prodotto di un gateway B2B connesso riceve un messaggio da un cliente regolamentato: “Vi chiediamo di confermare il periodo di supporto per la sicurezza della versione firmware 4.6, lo SLA di risposta alle vulnerabilità e se il dispositivo continuerà a essere idoneo agli aggiornamenti di sicurezza per l’intera durata del nostro contratto di servizio quinquennale”.

Alle 09:00, l’ufficio acquisti ha inoltrato un questionario di due diligence DORA. Alle 10:15, la funzione legale chiede se il periodo di supporto pubblicizzato sia coerente con i contratti con i clienti. Alle 11:00, il CISO viene coinvolto in un riesame NIS2 del rischio dei fornitori perché il prodotto è utilizzato da un fornitore di servizi gestiti nell’UE. Dopo pranzo, la funzione privacy chiede se una libreria API non più supportata all’interno del prodotto possa incidere sulla sicurezza dei dati personali ai sensi del GDPR.

La verità scomoda emerge rapidamente. L’azienda dispone di una roadmap, di un processo di patching, di un calendario dei rilasci e di un portale di supporto clienti, ma non dispone di evidenze governate sul periodo di supporto per la sicurezza.

Questa lacuna è rilevante. Ai sensi del regolamento UE sulla ciberresilienza (Cyber Resilience Act), il periodo di supporto per la sicurezza non è solo un’etichetta di prodotto. È un impegno di ciclo di vita che incide sul trattamento delle vulnerabilità, sulla disponibilità degli aggiornamenti, sulla gestione del rischio di dipendenza dai fornitori, sulle comunicazioni ai clienti, sulle dichiarazioni contrattuali e sul monitoraggio post-immissione sul mercato. Per fornitori SaaS, fabbricanti di dispositivi, editori software, fornitori cloud e fornitori di servizi ICT, il periodo di supporto diventa un oggetto di conformità che auditor e acquirenti regolamentati sottoporranno a verifica.

La risposta pratica non è un altro foglio di calcolo di conformità scollegato. La risposta è governare il periodo di supporto per la sicurezza all’interno di un sistema di gestione per la sicurezza delle informazioni ISO/IEC 27001:2022, quindi mappare le stesse evidenze su NIS2, DORA, GDPR, NIST CSF 2.0 e aspettative di audit in stile COBIT.

Questo è il modello operativo di Clarysec: utilizzare il SGSI come motore delle evidenze, utilizzare politiche applicabili per definire le responsabilità, utilizzare Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint per costruire la tracciabilità e utilizzare Zenith Controls: The Cross-Compliance Guide Zenith Controls come bussola per la conformità trasversale.

Perché il periodo di supporto per la sicurezza è ora un oggetto di audit

Un periodo di supporto per la sicurezza risponde a una domanda semplice: per quanto tempo il fabbricante fornirà aggiornamenti di sicurezza, correzione delle vulnerabilità, indicazioni di mitigazione e supporto clienti correlato per un prodotto o una versione di prodotto?

In pratica, la risposta dipende da molti elementi:

• architettura del prodotto e manutenibilità;
• supporto dei componenti di terze parti e delle dipendenze open source;
• impegni dei fornitori e dei servizi cloud;
• processi di ricezione delle segnalazioni di vulnerabilità, triage, correzione e divulgazione;
• capacità di ingegneria del rilascio e di test;
• condizioni contrattuali con i clienti e obblighi normativi;
• percorsi di risposta agli incidenti e di notifica ai destinatari del servizio;
• conservazione delle evidenze e registrazioni delle approvazioni.

Se un fabbricante promette cinque anni di supporto per la sicurezza, ma una libreria crittografica critica perde il supporto dopo tre anni, il periodo di supporto diventa una decisione di rischio. Se il cliente è un’entità finanziaria soggetta a DORA, lo stesso periodo di supporto diventa parte dell’assurance sui fornitori terzi ICT. Se il prodotto tratta dati personali, il software non supportato può rientrare nella responsabilizzazione GDPR relativa alla sicurezza del trattamento. Se il prodotto supporta un soggetto essenziale o importante ai sensi di NIS2, la sicurezza del ciclo di vita diventa una questione di sicurezza della catena di fornitura.

NIS2 rende esplicito questo profilo di governance. Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, incluse analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione sicura, sviluppo e manutenzione sicuri, trattamento e divulgazione delle vulnerabilità, valutazione dell’efficacia, igiene cyber, crittografia, controllo degli accessi, gestione degli asset e autenticazione. Article 23 aggiunge obblighi progressivi di segnalazione degli incidenti significativi.

DORA crea una pressione analoga per le entità finanziarie. Richiede gestione del rischio ICT, test della resilienza operativa digitale, gestione degli incidenti e governance del rischio di terze parti ICT. DORA Article 28 disciplina i principi di gestione del rischio di terze parti ICT, mentre Article 30 richiede accordi contrattuali scritti con descrizioni chiare dei servizi, misure di sicurezza, assistenza in caso di incidente, diritti di audit, diritti di risoluzione e accordi di uscita.

GDPR aggiunge il livello privacy. Se il prodotto tratta dati personali, titolari del trattamento e responsabili del trattamento necessitano di misure tecniche e organizzative adeguate ai sensi di Article 32, chiarezza contrattuale ai sensi di Article 28 e preparazione alla valutazione e alla notifica delle violazioni ai sensi di Articles 33 e 34.

Per questo motivo il periodo di supporto per la sicurezza CRA deve essere governato come una famiglia di controlli del SGSI, non gestito come un campo isolato di product management.

ISO 27001 come dorsale dei controlli per i periodi di supporto per la sicurezza CRA

ISO/IEC 27001:2022 è utile perché è scalabile, basata sul rischio e orientata al sistema di gestione. Richiede all’organizzazione di definire contesto, parti interessate, ambito di applicazione e processi interagenti, quindi di tradurre requisiti legali, normativi e contrattuali in valutazione del rischio, trattamento del rischio, controlli operativi ed evidenze ISO/IEC 27001:2022.

Per la governance dei periodi di supporto per la sicurezza, ciò significa che l’organizzazione deve:

1. identificare prodotti, versioni, moduli, servizi cloud e dipendenze compresi nell’ambito di applicazione;
2. identificare le parti interessate, inclusi clienti, autorità di regolamentazione, distributori, importatori, integratori, titolari del trattamento, responsabili del trattamento, sub-responsabili, partner di risposta agli incidenti e fornitori;
3. registrare gli obblighi legali, normativi e contrattuali relativi al supporto;
4. valutare i rischi che potrebbero impedire il rispetto degli impegni di supporto;
5. selezionare controlli per gestione delle vulnerabilità, sviluppo sicuro, assurance dei fornitori, gestione degli incidenti, continuità operativa, privacy e informazioni documentate;
6. creare note della Dichiarazione di Applicabilità che spieghino perché i controlli si applicano;
7. riesaminare il periodo di supporto quando cambiano architettura, dipendenze dai fornitori, esposizione alle minacce o impegni verso i clienti.

Zenith Controls individua tre controlli ISO/IEC 27002:2022 connessi al tema come ancoraggi centrali per questo problema di governance: 5.31 Requisiti legali, statutari, regolamentari e contrattuali, 8.8 Gestione delle vulnerabilità tecniche e 8.25 Ciclo di vita dello sviluppo sicuro. Non sono gli unici controlli coinvolti, ma costituiscono la dorsale della governance.

L’elemento chiave è la tracciabilità. Un periodo di supporto del prodotto deve essere tracciabile dall’obbligo allo scenario di rischio, dallo scenario di rischio ai controlli selezionati, dai controlli ai requisiti delle politiche e dai requisiti delle politiche alle evidenze.

Zenith Blueprint, fase di Risk Management, Step 13, descrive direttamente questa disciplina di tracciabilità:

“Riferimento incrociato alle normative: se determinati controlli sono implementati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase di Risk Management, Step 13: Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità Zenith Blueprint

Per un periodo di supporto per la sicurezza CRA, la Dichiarazione di Applicabilità non deve limitarsi a indicare che “la gestione delle vulnerabilità si applica”. Deve spiegare che la gestione delle vulnerabilità si applica perché l’azienda ha impegni CRA di ciclo di vita, aspettative NIS2 di sviluppo sicuro e catena di fornitura, richieste di due diligence dei clienti DORA, obblighi GDPR di sicurezza quando sono trattati dati personali e promesse contrattuali di supporto.

Dalla promessa di supporto al ciclo di vita governato

Un periodo di supporto per la sicurezza definito dal fabbricante deve superare sei test di governance.

Primo, deve essere definito. L’organizzazione necessita di una tassonomia standard, ad esempio supporto attivo, supporto solo sicurezza, supporto esteso, supporto limitato e non supportato. Ogni stato deve descrivere disponibilità degli aggiornamenti, trattamento delle vulnerabilità, comunicazione ai clienti e percorsi di escalation.

Secondo, deve essere sottoposto a valutazione del rischio. Cinque anni di supporto per un prodotto SaaS gestito in cloud con canali di aggiornamento controllati sono diversi da cinque anni per un dispositivo embedded con vincoli sul campo, dipendenze da chip di terze parti e finestre di deployment gestite dal cliente.

Terzo, deve essere approvato. Prodotto, sicurezza, funzione legale, privacy, supporto clienti e management responsabile devono approvare il periodo di baseline e le eccezioni.

Quarto, deve essere comunicato. I clienti devono comprendere data di inizio del supporto, data di fine, metodo di aggiornamento, canale di segnalazione delle vulnerabilità, aspettative di correzione, conseguenze della fine del supporto e opzioni di estensione disponibili.

Quinto, deve essere monitorato. Le dipendenze cambiano. I fornitori interrompono il supporto delle librerie. Emergono vulnerabilità. Gli ambienti dei clienti evolvono. La governance del periodo di supporto deve includere monitoraggio del ciclo di vita dei componenti, riesame dei fornitori, feed di vulnerabilità, log delle patch, test dei rilasci e lezioni apprese dagli incidenti.

Sesto, deve essere dimostrabile con evidenze. Se un auditor, un’autorità di regolamentazione o un cliente regolamentato chiede una prova, l’organizzazione deve mostrare il registro di conformità, il registro del supporto prodotto, la valutazione del rischio, la mappatura della SoA, il registro delle vulnerabilità, le registrazioni delle patch, i riesami dei fornitori, le approvazioni dei rilasci e le comunicazioni ai clienti.

Le politiche Clarysec rendono pratico questo approccio. La Legal and Regulatory Compliance Policy Enterprise Legal and Regulatory Compliance Policy richiede:

“Tutti gli obblighi legali e normativi devono essere mappati a politiche, controlli e proprietari specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).”

Fonte: Legal and Regulatory Compliance Policy, Policy Implementation Requirements, clausola 6.2.1 Legal and Regulatory Compliance Policy

Per le PMI, la disciplina equivalente inizia da un registro più semplice. La Legal and Regulatory Compliance Policy-sme per PMI Legal and Regulatory Compliance Policy - PMI stabilisce:

“Il GM deve mantenere un Registro di conformità semplice e strutturato che elenchi:”

Fonte: Legal and Regulatory Compliance Policy-sme, Governance Requirements, clausola 5.1.1 Legal and Regulatory Compliance Policy - PMI

Un impegno relativo al periodo di supporto deve essere presente nel registro di conformità se deriva da legge, contratto con il cliente, regolamentazione settoriale o aspettativa di un acquirente regolamentato. Non deve rimanere solo nelle note di rilascio o nel materiale marketing.

Costruire un registro dei periodi di supporto per la sicurezza CRA in un workshop

Immaginiamo un fornitore SaaS che vende un’appliance di analytics connessa a operatori logistici dell’UE e a clienti del settore finanziario. Il prodotto include un agente embedded, una API cloud, un’app mobile di amministrazione e diverse librerie open source. Il team vendite vuole promettere cinque anni di supporto per la sicurezza per ogni versione maggiore dell’appliance.

Il CISO può condurre un workshop mirato con prodotto, engineering, funzione legale, privacy e gestione dei fornitori.

Step 1: creare il registro dei periodi di supporto

Creare una riga per ogni versione di prodotto e includere:

• prodotto e versione;
• data di rilascio;
• data di inizio del supporto;
• data standard di fine del supporto per la sicurezza;
• opzione di supporto esteso;
• metodo di distribuzione degli aggiornamenti;
• canale di divulgazione delle vulnerabilità;
• obiettivo per le patch critiche;
• ruolo nel trattamento dei dati, ad esempio titolare del trattamento, responsabile del trattamento o entrambi;
• fornitori e componenti critici;
• settori dei clienti interessati;
• responsabile del rischio;
• data di approvazione;
• ubicazione delle evidenze.

Questo registro diventa informazione documentata nell’ambito del SGSI. Zenith Blueprint, fase ISMS Foundation and Leadership, Step 6, definisce l’aspettativa di controllo documentale:

“I documenti devono avere un’identificazione adeguata (un titolo, eventualmente un numero di documento o un identificativo univoco, un autore), un formato appropriato e un riesame e un’approvazione di adeguatezza prima dell’uso.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase ISMS Foundation and Leadership, Step 6: Informazioni documentate e costruzione della libreria del SGSI Zenith Blueprint

La PIMS Documented Information Evidence Management Policy Enterprise di Clarysec PIMS Documented Information Evidence Management Policy applica principi analoghi per le evidenze alla documentazione privacy:

“[All] Il Privacy Lead / PIMS Manager DEVE assegnare un identificativo del documento, un proprietario, un numero di versione, uno stato di approvazione, una data di efficacia e una data di riesame in REG12 prima di pubblicare le informazioni documentate del PIMS.”

Fonte: PIMS Documented Information Evidence Management Policy, Creazione, approvazione, controllo delle versioni e pubblicazione, clausola 4.2.1 PIMS Documented Information Evidence Management Policy

Anche se il registro dei periodi di supporto non è, di default, un documento privacy, si applica la stessa disciplina: proprietario, versione, approvazione, data di efficacia e data di riesame.

Step 2: collegare le promesse di supporto al trattamento del rischio

Per ogni versione di prodotto, creare scenari di rischio quali:

• viene scoperta una vulnerabilità critica in una versione supportata, ma la capacità di engineering non è disponibile;
• un componente di terze parti perde il supporto prima della fine del periodo di supporto per la sicurezza dichiarato;
• un fornitore modifica il luogo di hosting o il subappaltatore e incide sulla distribuzione degli aggiornamenti;
• una vulnerabilità riguarda dati personali e attiva la valutazione della violazione dei dati personali;
• un cliente finanziario regolamentato richiede evidenze della resilienza di terze parti ICT.

Le clausole ISO/IEC 27001:2022 da 6.1.1 a 6.1.3 forniscono il motore di pianificazione: identificare i rischi, valutare probabilità e conseguenze, assegnare i responsabili del rischio, selezionare i trattamenti, confrontare i controlli selezionati con l’Annex A, produrre la Dichiarazione di Applicabilità e ottenere l’approvazione del rischio residuo.

Per il rischio “componente non supportato prima della data di fine supporto”, la registrazione del rischio deve includere i controlli ISO/IEC 27002:2022 5.31, 8.8 e 8.25, oltre ai controlli sui fornitori quali 5.19 Sicurezza delle informazioni nei rapporti con i fornitori, 5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori, 5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT e 5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori.

Step 3: definire le regole sulle evidenze di vulnerabilità e patch

Un periodo di supporto è credibile solo se la gestione delle vulnerabilità funziona durante tale periodo.

La Vulnerability and Patch Management Policy-sme per PMI Vulnerability and Patch Management Policy - PMI stabilisce un requisito rigoroso per le esposizioni urgenti:

“Le patch critiche devono essere applicate entro 3 giorni dal rilascio, in particolare per i sistemi esposti a Internet”

Fonte: Vulnerability and Patch Management Policy-sme, Policy Implementation Requirements, clausola 6.1.1 Vulnerability and Patch Management Policy - PMI

Richiede inoltre registrazioni idonee all’audit:

“Deve essere mantenuto un registro delle patch, da riesaminare durante gli audit e le attività di risposta agli incidenti”

Fonte: Vulnerability and Patch Management Policy-sme, Governance Requirements, clausola 5.4.1 Vulnerability and Patch Management Policy - PMI

Per gli ambienti enterprise, la Vulnerability and Patch Management Policy Enterprise Vulnerability and Patch Management Policy richiede:

“Il Security Operations Team deve mantenere un Registro della gestione delle vulnerabilità centralizzato, riesaminato mensilmente dal CISO o dall’autorità delegata.”

Fonte: Vulnerability and Patch Management Policy, Governance Requirements, clausola 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, fase Controls in Action, Step 19, spiega l’aspettativa operativa alla base del controllo ISO/IEC 27002:2022 8.8:

“Rimanere informati sui nuovi bug di sicurezza (tramite avvisi dei fornitori, feed CVE, ecc.) relativi al software e all’hardware. Valutare quali siano rilevanti (usiamo questo software? quanto è critico il bug?) e applicare tempestivamente correzioni o mitigazioni.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controls in Action, Step 19: Controlli tecnologici I Zenith Blueprint

Ogni versione di prodotto supportata richiede una traccia delle evidenze sulle vulnerabilità: ricezione della segnalazione, analisi di rilevanza, gravità, versioni interessate, piano di correzione, rilascio della correzione, indicazioni di mitigazione, comunicazione al cliente e approvazione della chiusura.

Step 4: collegare lo sviluppo sicuro alla durata del supporto

Il supporto per la sicurezza inizia prima del rilascio. Dipende da pratiche di sviluppo che rendano il prodotto manutenibile.

La Secure Development Policy-sme per PMI Secure Development Policy - PMI stabilisce:

“I componenti devono essere aggiornati regolarmente quando vengono rilasciate patch di sicurezza. Se viene identificata una vulnerabilità critica, il componente deve essere aggiornato o sostituito immediatamente.”

Fonte: Secure Development Policy-sme, Policy Implementation Requirements, clausola 6.6.3 Secure Development Policy - PMI

La Application Security Requirements Policy-sme per PMI Application Security Requirements Policy - PMI richiede che contratti e requisiti:

“specifichino gli obblighi relativi alla divulgazione delle vulnerabilità, ai tempi di risposta e all’applicazione delle patch.”

Fonte: Application Security Requirements Policy-sme, Governance Requirements, clausola 5.3.2 Application Security Requirements Policy - PMI

Se l’azienda promette supporto fino al 2031, l’architettura deve consentire aggiornamenti manutenibili, sostituzione delle dipendenze, pipeline di build sicure, test di regressione e rilasci di emergenza. I controlli ISO/IEC 27002:2022 per sviluppo sicuro, architettura sicura, programmazione sicura, test di sicurezza, sviluppo esternalizzato, separazione degli ambienti e gestione delle modifiche diventano abilitatori del periodo di supporto.

Un unico set di evidenze per CRA, NIS2, DORA e GDPR

Le stesse evidenze sul periodo di supporto possono soddisfare interlocuzioni regolamentari diverse, ma ogni quadro di riferimento formula la domanda in modo diverso.

La dipendenza dai fornitori è spesso il punto in cui gli impegni di supporto falliscono. La Supplier Dependency Risk Management Policy Enterprise Supplier Dependency Risk Management Policy richiede:

“Registro delle dipendenze dai fornitori: il VMO deve mantenere un registro aggiornato di tutti i fornitori critici, inclusi dettagli quali servizi/prodotti forniti; se il fornitore è a fornitura esclusiva; fornitori alternativi disponibili o sostituibilità; termini contrattuali vigenti; e una valutazione dell’impatto in caso di fallimento o compromissione del fornitore.”

Fonte: Supplier Dependency Risk Management Policy, Implementation Requirements, clausola 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, fase Controls in Action, Step 23, avverte che gli auditor esamineranno gli accordi con i fornitori e le evidenze di monitoraggio dei fornitori:

“Gli auditor esamineranno contratti o accordi di servizio campione. Cercano clausole esplicite di sicurezza delle informazioni, quali tempistiche di notifica delle violazioni, restrizioni di accesso, obblighi di trattamento dei dati, requisiti di cifratura o diritti di audit.”

Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controls in Action, Step 23: Controlli organizzativi Zenith Blueprint

Per i clienti DORA, questo è critico. I contratti per servizi ICT che supportano funzioni essenziali o importanti richiedono descrizioni chiare dei servizi, condizioni di subappalto, misure di sicurezza, assistenza in caso di incidente, diritti di audit e ispezione, diritti di risoluzione e accordi di transizione. Un fornitore che non è in grado di sostenere tali impegni può impedire al fabbricante di formulare una promessa credibile sul periodo di supporto.

Crosswalk dei controlli per una governance del periodo di supporto idonea all’audit

Questo crosswalk consente ai team di sicurezza, legale, prodotto e vendite di parlare un’unica lingua. Il registro dei periodi di supporto non è solo evidenza CRA. È assurance dei fornitori per NIS2, assurance di terze parti per DORA, supporto alla sicurezza del trattamento per GDPR e artefatto di governance per la certificazione ISO 27001.

Il profilo privacy: quando non supportato diventa non sicuro

La governance del periodo di supporto per la sicurezza non è solo un tema di cibersicurezza. Se il prodotto archivia, trasmette o tratta dati personali, il software non supportato può diventare un rischio privacy.

GDPR si applica al trattamento nel contesto di uno stabilimento nell’UE e può applicarsi anche a organizzazioni non UE che offrono beni o servizi a persone nell’UE o ne monitorano il comportamento. Definisce in modo ampio i dati personali e qualifica una violazione dei dati personali come violazione della sicurezza che comporta distruzione, perdita, modifica, divulgazione non autorizzata o accesso non autorizzato, accidentali o illeciti, a dati personali trattati.

Per la governance dei periodi di supporto, i team privacy devono sapere quali versioni di prodotto trattano PII, quali sistemi sono ancora supportati e se le vulnerabilità incidono su riservatezza, integrità o disponibilità dei dati personali.

La PII Security Access Control Policy Enterprise di Clarysec PII Security Access Control Policy richiede:

“[Both] Il System Owner / Application Owner DEVE registrare in REG12 la copertura della valutazione delle vulnerabilità per i sistemi che trattano PII almeno trimestralmente e dopo una modifica tecnica sostanziale.”

Fonte: PII Security Access Control Policy, Configurazione sicura e gestione delle vulnerabilità, clausola 4.7.4 PII Security Access Control Policy

La Processor Subprocessor Third Party Privacy Management Policy Enterprise Processor Subprocessor Third Party Privacy Management Policy aggiunge un monitoraggio continuativo per le relazioni privacy ad alto rischio:

“[All] Il Vendor / Procurement Owner DEVE monitorare trimestralmente le relazioni attive ad alto rischio con responsabili del trattamento e sub-responsabili, e annualmente le altre relazioni attive con responsabili del trattamento e sub-responsabili di PII, rispetto a condizioni di due diligence, stato contrattuale, stato di assurance, problematiche aperte e date di riesame in REG08.”

Fonte: Processor Subprocessor Third Party Privacy Management Policy, Monitoraggio continuativo, assistenza, interfaccia di comunicazione e uscita, clausola 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

Quando una vulnerabilità diventa un incidente, la PII Incident Breach Management Policy Enterprise PII Incident Breach Management Policy richiede la valutazione dei trigger su più quadri di riferimento:

“[Conditional] Il Privacy Lead / PIMS Manager DEVE valutare i trigger di segnalazione legali, settoriali, del settore finanziario, di cibersicurezza, contrattuali, dei clienti e dei destinatari del servizio applicabili per ciascun incidente relativo ai dati personali ad alto impatto e registrare l’esito dell’applicabilità in REG01, REG08 e REG10.”

Fonte: PII Incident Breach Management Policy, Classificazione e valutazione della violazione, clausola 4.2.6 PII Incident Breach Management Policy

Questa è la sovrapposizione pratica tra impegni di supporto CRA, comunicazione degli incidenti NIS2, gestione degli incidenti gravi connessi alle TIC ai sensi di DORA e responsabilizzazione GDPR sulle violazioni.

Come gli auditor testano lo stesso processo di periodo di supporto

Un processo solido di governance del periodo di supporto deve resistere a diversi stili di audit. Le evidenze cambiano poco, ma cambia la prospettiva dell’auditor.

NIST CSF 2.0 è utile come livello di comunicazione perché la sua funzione GOVERN include obblighi legali, normativi, contrattuali e privacy, obiettivi di gestione del rischio, propensione al rischio, ruoli, politiche e supervisione. I suoi outcome sulla catena di fornitura coprono strategia dei fornitori, criticità, contratti, due diligence, monitoraggio, coordinamento degli incidenti e disposizioni di fine rapporto.

Gli auditor in stile COBIT e ISACA si concentrano spesso sul disegno della governance: chi è titolare della decisione, quale processo è definito, quali metriche dimostrano le prestazioni, come sono approvate le eccezioni e come viene gestito il miglioramento continuo.

La Information Security Policy Enterprise di Clarysec Information Security Policy coglie il principio di verificabilità:

“Tutti i controlli implementati devono essere verificabili, supportati da procedure documentate ed evidenze conservate del loro funzionamento.”

Fonte: Information Security Policy, Policy Implementation Requirements, clausola 6.6.1 Information Security Policy

Questa è la frase che ogni periodo di supporto per la sicurezza deve poter soddisfare.

Estendere, abbreviare o terminare il supporto senza creare falsa assurance

I momenti di governance più difficili non si verificano al lancio del prodotto. Si verificano quando la realtà cambia.

Può essere necessario estendere il supporto perché clienti regolamentati dipendono dal prodotto, la migrazione non è fattibile o un cliente di settore ha esigenze contrattuali di continuità. Può essere necessario abbreviare o limitare il supporto perché un fornitore interrompe la manutenzione di sicurezza, un componente diventa impossibile da correggere, una piattaforma raggiunge limiti tecnici o l’architettura del prodotto non può supportare in modo sicuro una classe di vulnerabilità.

Una modifica controllata del periodo di supporto deve includere:

• trigger della modifica, quali fine vita del fornitore, vulnerabilità critica, contratto con il cliente o modifica normativa;
• prodotti, versioni, clienti e settori interessati;
• analisi dell’impatto su dati personali e servizi critici;
• riesame di fattibilità su fornitori e componenti;
• valutazione del rischio e decisione sul rischio residuo;
• registro dei periodi di supporto aggiornato;
• comunicazione al cliente e posizione contrattuale aggiornate;
• note SoA aggiornate quando cambiano controlli o obblighi;
• approvazione della direzione e data di riesame.

La Coordinated Vulnerability Disclosure Policy Enterprise Coordinated Vulnerability Disclosure Policy è utile quando la modifica è determinata da una vulnerabilità:

“Deve essere sviluppato un piano di remediation o mitigazione per tutte le vulnerabilità confermate. L’implementazione della correzione deve essere prioritizzata in base alla gravità. Ad esempio, le vulnerabilità critiche devono essere corrette o mitigate entro 14 giorni, ove fattibile, o prima se viene rilevato sfruttamento attivo, mentre i problemi di gravità inferiore devono essere gestiti entro un termine ragionevole.”

Fonte: Coordinated Vulnerability Disclosure Policy, Implementation Requirements, clausola 6.6 Coordinated Vulnerability Disclosure Policy

Se una correzione completa non può essere distribuita immediatamente, controlli compensativi, funzionalità disabilitate, monitoraggio rafforzato o indicazioni di configurazione per i clienti possono essere accettabili temporaneamente, ma la decisione deve essere documentata e comunicata.

Checklist pratica Clarysec per la preparazione del periodo di supporto

Utilizzare questa checklist prima di pubblicare o rinnovare qualunque impegno relativo al periodo di supporto per la sicurezza CRA.

• Il prodotto e la versione sono elencati nel registro dei periodi di supporto?
• La data di fine supporto è approvata da prodotto, sicurezza e management responsabile?
• I driver legali, normativi e contrattuali sono mappati nel registro di conformità?
• Lo scenario di rischio relativo al periodo di supporto è incluso nel registro dei rischi?
• I controlli sono mappati nella Dichiarazione di Applicabilità, inclusi 5.31, 8.8 e 8.25 ove applicabili?
• I fornitori e i componenti critici sono mappati nel registro delle dipendenze dai fornitori?
• Esistono evidenze che i componenti possano essere corretti o sostituiti durante il periodo di supporto?
• Sono definite le responsabilità di ricezione, triage, correzione e divulgazione delle vulnerabilità?
• Gli SLA per le patch critiche sono allineati alla politica e ai contratti con i clienti?
• Sono conservati i log delle patch, le registrazioni dei rilasci e le decisioni sulle vulnerabilità?
• I sistemi con dati personali sono coperti da evidenze di valutazione delle vulnerabilità dove sono trattati PII?
• Le comunicazioni ai clienti, le dichiarazioni di supporto e le condizioni contrattuali sono coerenti?
• Esiste un processo per estendere, abbreviare o terminare il supporto con approvazione del rischio?
• I riesami della direzione ricevono input su rischio del periodo di supporto, fornitori, vulnerabilità e incidenti?
• Le evidenze possono essere prodotte entro 48 ore per un audit del cliente o una richiesta dell’autorità di regolamentazione?

La PIMS Monitoring Audit Improvement Policy Enterprise PIMS Monitoring Audit Improvement Policy rafforza la disciplina del riesame della direzione per i programmi privacy:

“[Both] L’Alta direzione DEVE riesaminare in REG12, durante ogni riesame della direzione, gli input relativi a non conformità del PIMS, azione correttiva, risultato del monitoraggio, esito dell’audit, rischio privacy, assurance dei fornitori e modifiche delle parti interessate.”

Fonte: PIMS Monitoring Audit Improvement Policy, Riesame della direzione del PIMS, clausola 4.3.5 PIMS Monitoring Audit Improvement Policy

Per la governance del periodo di supporto per la sicurezza, lo stesso ritmo di riesame deve applicarsi a tutto il SGSI: vulnerabilità, prestazioni di patching, assurance dei fornitori, impegni verso i clienti, incidenti, eccezioni di supporto e azioni correttive devono alimentare il riesame della direzione.

Rendere difendibile il periodo di supporto per la sicurezza

Il regolamento UE sulla ciberresilienza (Cyber Resilience Act) cambia la mentalità sulla sicurezza di prodotto. Spinge fabbricanti e fornitori software a guardare oltre il giorno del rilascio. Il periodo di supporto per la sicurezza diventa una promessa di ciclo di vita che deve essere progettata, governata, monitorata e dimostrata con evidenze.

Per i CISO, la lezione è chiara: non lasciare il periodo di supporto solo al marketing di prodotto. Per i responsabili della conformità, non costruire un silo separato di evidenze CRA. Per gli auditor, verificare se gli impegni di supporto sono tracciabili a rischi, controlli, fornitori, incidenti e approvazioni documentate. Per i titolari dell’attività, ricordare che un periodo di supporto credibile può diventare un vantaggio di mercato, soprattutto nella vendita a settori regolamentati NIS2, entità finanziarie DORA e clienti sensibili alla privacy.

Clarysec aiuta le organizzazioni a rendere operativo questo modello tramite:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint per costruire tracciabilità del SGSI, informazioni documentate, mappatura SoA e capacità di dimostrare la conformità in audit;
• Zenith Controls: The Cross-Compliance Guide Zenith Controls per mappare i controlli ISO/IEC 27002:2022 su NIS2, DORA, GDPR, NIST CSF 2.0 e aspettative di audit;
• pacchetti di politiche Enterprise e PMI per gestione delle vulnerabilità, sviluppo sicuro, conformità legale, dipendenze dai fornitori, evidenze privacy e risposta agli incidenti;
• registri e workflow di evidenze pratici che trasformano le promesse sui periodi di supporto in governance verificabile.

Il prossimo passo è semplice: scegliere una versione di prodotto di punta e costruire il relativo fascicolo di evidenze del periodo di supporto per la sicurezza. Mappare l’obbligo, approvare il periodo di supporto, testare il processo di gestione delle vulnerabilità, validare le dipendenze dai fornitori, confermare la comunicazione ai clienti e conservare le registrazioni.

Se potete difendere un prodotto, potete scalare il modello. Se non potete difendere un prodotto, la lacuna non è documentale. È di governance.

Scaricate Zenith Blueprint, utilizzate Zenith Controls per mappare le vostre evidenze oppure richiedete una valutazione dello stato di preparazione Clarysec per trasformare i periodi di supporto per la sicurezza CRA in una governance ISO 27001 idonea all’audit.