Governance dei progetti ICT con sicurezza fin dalla progettazione nel 2026

Il progetto era nei tempi, finché l’audit non ha posto una domanda

Il Responsabile della sicurezza delle informazioni di una società di tecnologie di pagamento in forte crescita aveva buone notizie per il Consiglio di amministrazione. La nuova piattaforma di onboarding dei clienti era pronta per il lancio. Il team di prodotto aveva consegnato l’esperienza mobile, l’ingegneria aveva integrato la verifica dell’identità, l’ufficio legale aveva formalizzato gli accordi con i fornitori cloud e API, e le operations avevano provato il piano di messa in esercizio in produzione.

Poi l’auditor interno ha posto una domanda semplice:

“Mostratemi dove sicurezza e privacy sono state considerate in ciascuna fase del progetto.”

La sala progetto è rimasta in silenzio.

C’era un rapporto di penetration test, ma era arrivato tardi. C’era un diagramma di architettura cloud, ma nessuna evidenza che i flussi di dati fossero stati riesaminati rispetto ai principi GDPR. C’era un questionario di due diligence sui fornitori, ma non era stato collegato al registro dei rischi. C’era un ticket di modifica per il rilascio in produzione, ma l’approvazione non menzionava l’impatto su servizi critici, segnalazione degli incidenti, test di resilienza, notifica ai clienti o escalation della violazione dei dati personali. C’erano note di sprint, ma i requisiti di sicurezza erano dispersi tra storie utente e messaggi di chat.

Nulla appariva chiaramente negligente. Tutto sembrava un moderno progetto ICT molto intenso. Tuttavia, per un’entità finanziaria soggetta a DORA, un fornitore SaaS potenzialmente nel campo di applicazione di NIS2 e un titolare del trattamento o responsabile del trattamento ai sensi di GDPR, il problema non era più solo se la sicurezza esistesse. Il problema era se la sicurezza fin dalla progettazione potesse essere dimostrata.

Questo è il problema del 2026. I progetti ICT non sono più valutati solo in base a rapidità di consegna, controllo dei costi e qualità tecnica. Sono valutati in base alle evidenze di governance: valutazioni del rischio, decisioni progettuali, due diligence sui fornitori, registrazioni dello sviluppo sicuro, approvazioni delle modifiche, decisioni privacy, risultati dei test e supervisione della direzione.

ISO/IEC 27001:2022 offre alle organizzazioni una dorsale pratica di sistema di gestione per risolvere questo problema. Aiuta CISO, responsabili della conformità, sponsor di progetto, DPO, architetti, team di approvvigionamento e auditor a trasformare i progetti ICT significativi in evidenze difendibili di sicurezza fin dalla progettazione.

Perché la governance dei progetti ICT è ora un problema di evidenze normative

Una migrazione cloud, un portale clienti, una piattaforma di pagamento, un’implementazione CRM, un cambio di provider di identità, una pipeline di analisi, un’integrazione API, un flusso di lavoro SaaS, un’applicazione low-code o una transizione verso un servizio gestito possono modificare il profilo di rischio dell’organizzazione. Nel 2026, questi cambiamenti avvengono in presenza di obblighi sovrapposti.

NIS2 si applica ampiamente ai soggetti essenziali e importanti nei settori degli Annex I e Annex II, inclusi infrastruttura digitale, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti e fornitori digitali. NIS2 Article 20 rende gli organi di gestione responsabili dell’approvazione delle misure di gestione del rischio di cibersicurezza e della supervisione della loro attuazione. NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate per gestione del rischio, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione sicura, sviluppo sicuro, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, crittografia, controllo degli accessi, gestione degli asset e comunicazioni sicure.

DORA si applica alle entità finanziarie e si concentra sulla resilienza operativa digitale. DORA Article 5 attribuisce all’organo di gestione la responsabilità della gestione del rischio ICT. DORA Article 6 richiede un quadro di gestione del rischio ICT solido, completo e ben documentato. DORA disciplina inoltre la segnalazione degli incidenti connessi all’ICT, i test di resilienza operativa, la continuità operativa ICT, risposta e ripristino, condivisione di informazioni sulle minacce informatiche, gestione del rischio ICT di terze parti, accordi contrattuali e supervisione dei fornitori terzi critici di servizi ICT.

GDPR aggiunge il livello della responsabilizzazione per i dati personali. GDPR Article 25 richiede protezione dei dati fin dalla progettazione e per impostazione predefinita. I titolari del trattamento devono poter dimostrare la conformità a principi quali liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione dei dati, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. Quando il trattamento può presentare un rischio elevato, può essere richiesta anche una valutazione d’impatto sulla protezione dei dati ai sensi di GDPR Article 35.

Il filo conduttore sono le evidenze. Autorità di regolamentazione e auditor non chiedono solo se una piattaforma sia stata cifrata, patchata, sottoposta a scansione o testata. Chiedono se l’organizzazione possa dimostrare che sicurezza, privacy, rischio dei fornitori e resilienza hanno fatto parte del processo decisionale sin dall’inizio.

Per questo la governance dei progetti ISO/IEC 27001:2022 è così efficace. Consente all’organizzazione di gestire NIS2, DORA, GDPR, NIST CSF 2.0, obblighi contrattuali e assurance dei clienti attraverso un unico processo SGSI ripetibile, invece di molteplici checklist scollegate.

La dorsale ISO 27001 per la governance dei progetti

ISO/IEC 27001:2022 è spesso fraintesa come un esercizio di certificazione. Per i progetti ICT, il suo valore operativo è più ampio. Fornisce una dorsale di governance per il cambiamento aziendale.

Le clausole da 4.1 a 4.4 richiedono alle organizzazioni di comprendere fattori interni ed esterni, parti interessate, requisiti legali, normativi e contrattuali, ambito di applicazione del SGSI, interfacce e dipendenze. In termini di progetto, ciò significa che il project charter deve identificare servizi interessati, clienti, fornitori, normative, processi aziendali, dati personali, operazioni critiche e servizi esternalizzati.

Le clausole da 5.1 a 5.3 richiedono impegno della leadership, allineamento alle politiche, risorse, integrazione nei processi aziendali e responsabilità assegnate. Questo è rilevante perché sia NIS2 sia DORA collocano la cibersicurezza e il rischio ICT sotto la responsabilità dell’organo di gestione. Un progetto che modifica una piattaforma clienti critica non può basarsi su un commento informale di sicurezza in una chat. Richiede una chiara attribuzione delle responsabilità.

Le clausole da 6.1.1 a 6.1.3 richiedono un processo ripetibile di valutazione e trattamento del rischio, criteri di rischio, titolari del rischio, valutazione di riservatezza, integrità e disponibilità, piani di trattamento del rischio, Dichiarazione di applicabilità e approvazione del rischio residuo. È qui che il rischio di progetto diventa evidenza per l’audit.

Le clausole da 7.1 a 7.5 richiedono risorse, competenza, consapevolezza, comunicazione e controllo delle informazioni documentate. È così che le registrazioni di progetto diventano evidenze affidabili anziché artefatti dispersi.

La clausola 8.1 richiede pianificazione operativa e controllo, informazioni documentate che dimostrino che i processi sono stati svolti come pianificato, controllo delle modifiche pianificate, riesame delle modifiche non previste, mitigazione degli effetti avversi e controllo di processi, prodotti o servizi forniti dall’esterno e rilevanti per il SGSI. Le clausole 8.2 e 8.3 richiedono valutazioni e trattamento dei rischi per la sicurezza delle informazioni a intervalli pianificati o quando si verificano modifiche significative.

L’Allegato A collega poi questo ciclo di gestione ai controlli pratici. Per la sicurezza fin dalla progettazione nei progetti ICT, tre controlli dell’Allegato A di ISO/IEC 27001:2022 sono centrali:

Il Zenith Blueprint: roadmap in 30 fasi per auditor di Clarysec tratta la sicurezza delle informazioni nella gestione dei progetti come un tema di governance trasversale a tutti i tipi di progetto, non solo allo sviluppo software:

“Qualsiasi progetto — una migrazione di un sistema marketing, un trasferimento di sede, una riprogettazione di un processo aziendale, una piattaforma di onboarding HR, persino una fusione o acquisizione — può incidere sulla riservatezza, integrità o disponibilità delle informazioni. E quando ciò accade, la sicurezza deve sedere al tavolo.”

La stessa sezione sintetizza la lezione centrale di attuazione:

“L’obiettivo di questo controllo non è appesantire i progetti con burocrazia. È garantire che la sicurezza sia trattata come input di progettazione, non come fase di test.”

Questa distinzione separa il teatro della conformità dalla sicurezza fin dalla progettazione difendibile.

Come si presenta la sicurezza fin dalla progettazione in un progetto ICT

La sicurezza fin dalla progettazione inizia prima del primo sprint, della prima richiesta di approvvigionamento, del primo diagramma architetturale o del primo runbook di migrazione. Pone una domanda semplice: che cosa potrebbe cambiare questo progetto rispetto al rischio?

Un modello pratico di governance dei progetti usa sette gate di evidenza.

Il punto non è la burocrazia. Il punto è rendere la sicurezza visibile nel luogo in cui avvengono davvero le decisioni di progetto.

La Politica per la sicurezza delle informazioni Clarysec Enterprise lo esprime direttamente:

“La governance della sicurezza deve essere integrata con la governance aziendale, la gestione dei progetti, l’approvvigionamento e le funzioni di supervisione legale, per assicurare che la sicurezza delle informazioni non sia isolata ma incorporata in tutto il processo decisionale aziendale.”

Dalla sezione “Requisiti di governance”, clausola della politica 5.5.

Rende inoltre i cicli di vita dei progetti un tema di applicazione:

“Cicli di vita dei progetti (ad es. sviluppo sicuro, modellazione delle minacce)”

Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.3.1.1.

E afferma il principio di audit che molte organizzazioni scoprono troppo tardi:

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

Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.6.1.

In altre parole, un’attività di sicurezza che non sia governata, conservata e mappata spesso non supera l’audit, anche se i team tecnici hanno preso decisioni ragionevoli.

Dalla modellazione delle minacce alle evidenze: un esempio fintech pratico

Consideriamo un progetto per il lancio di un nuovo portale di onboarding dei clienti UE per una fintech. Il portale raccoglie documenti di identità, esegue verifica biometrica tramite una terza parte, archivia lo stato di onboarding, si integra con il CRM, attiva notifiche ai clienti e alimenta il punteggio di rischio.

Un approccio di sicurezza fin dalla progettazione costruirebbe le evidenze man mano che il progetto avanza.

Per prima cosa, aprire una registrazione di classificazione della sicurezza del progetto. Identificare se il progetto incide su funzioni critiche o importanti, dati personali, categorie particolari di dati personali, autenticazione, disponibilità di servizi rivolti ai clienti, servizi ICT esternalizzati, processi di segnalazione regolamentati o comunicazioni ai clienti. Ai sensi di GDPR, i dati biometrici usati per l’identificazione univoca sono una categoria particolare di dati personali, salvo applicazione di una specifica eccezione. Questo aumenta immediatamente il livello richiesto di analisi legale e misure di protezione.

In secondo luogo, creare una valutazione del rischio di progetto. La Politica di gestione del rischio Clarysec SME rende la gestione del rischio parte della pianificazione, non un esercizio trimestrale su foglio di calcolo:

“1.2 Garantisce che la gestione del rischio sia una componente attiva della pianificazione, dell’esecuzione dei progetti, della selezione dei fornitori e della risposta agli incidenti, in allineamento con ISO 27001, ISO 31000 e i requisiti normativi applicabili.”

Dalla sezione “Finalità”, clausola della politica 1.2.

Per gli ambienti enterprise, la Politica di gestione del rischio Clarysec Enterprise definisce l’ambito su livelli progettuali e tecnici:

“Copre i rischi per la sicurezza delle informazioni a livello strategico, operativo, progettuale e tecnico ed è obbligatoria per tutto il personale, i contraenti e i fornitori di servizi coinvolti nelle attività del Sistema di gestione della sicurezza delle informazioni (SGSI).”

Dalla sezione “Ambito di applicazione”, clausola della politica 2.3.

In terzo luogo, eseguire una modellazione delle minacce prima dell’inizio dello sviluppo. La Politica di sviluppo sicuro Enterprise è esplicita:

“Tutte le nuove applicazioni e le modifiche rilevanti devono essere sottoposte a riesame dell’architettura sicura e modellazione delle minacce prima dell’inizio dello sviluppo.”

Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.1.1.

Per il portale di onboarding, il modello delle minacce dovrebbe coprire interfacce esposte, flussi di identità, confini dei privilegi, casi di abuso delle API, spoofing dei webhook, attacchi di replay, credenziali compromesse, percorsi di perdita di dati, rischio di dipendenza, requisiti di logging, assunzioni sui backup, requisiti di ripristino e modalità di guasto del provider.

In quarto luogo, aggiornare le evidenze privacy. La Politica di protezione dei dati e privacy SME stabilisce la baseline:

“5.3.1. La protezione dei dati fin dalla progettazione e per impostazione predefinita deve essere applicata in tutti i nuovi sistemi e servizi”

Dalla sezione “Requisiti di governance”, clausola della politica 5.3.1.

La registrazione di progetto deve includere finalità, base giuridica, ruolo di titolare del trattamento o responsabile del trattamento, decisioni di minimizzazione dei dati, regole di conservazione, ruoli di accesso, scelte di cifratura, considerazioni sull’impatto sugli interessati, requisiti di trasparenza, clausole del responsabile del trattamento e percorsi di notifica della violazione dei dati personali.

In quinto luogo, registrare le evidenze di sviluppo sicuro. La Politica di sviluppo sicuro SME fornisce un elenco sintetico di evidenze adatto a team di piccole e medie dimensioni:

“5.3 Il Direttore generale (GM) deve mantenere registrazioni di: 5.3.1 Tutti i progetti attivi di sviluppo software e gli sviluppatori o fornitori responsabili 5.3.2 Checklist di sicurezza usate per ciascun progetto 5.3.3 Revisioni del codice eseguite e persone che le hanno eseguite 5.3.4 Risultati dei test prima del rilascio 5.3.5 Componenti di terze parti e relativo stato di licenza o rischio”

Dalla sezione “Requisiti di governance”, clausola della politica 5.3.

In sesto luogo, controllare il rilascio come una modifica. La Politica di gestione dei cambiamenti SME afferma:

“1.1 Questa politica assicura che tutte le modifiche ai sistemi IT, alle configurazioni, alle applicazioni aziendali o ai servizi cloud siano pianificate, valutate in termini di rischio, testate e approvate prima dell’attuazione.”

Dalla sezione “Finalità”, clausola della politica 1.1.

Per il portale di onboarding, il ticket di modifica dovrebbe includere servizi interessati, valutazione del rischio, risultati dei test, piano di rollback, piano di monitoraggio, approvazioni di sicurezza, approvazione formale privacy, preparazione del fornitore, aggiornamenti dell’escalation degli incidenti e trigger di comunicazione ai clienti.

Infine, mappare gli obblighi. La Politica di conformità legale e normativa SME fornisce la regola operativa:

“5.2.2 Quando una normativa si applica a più aree (ad es., GDPR si applica a conservazione, sicurezza e privacy), ciò deve essere chiaramente mappato nel registro di conformità e nei materiali formativi.”

Dalla sezione “Requisiti di governance”, clausola della politica 5.2.2.

Quel registro di conformità diventa il ponte tra i controlli ISO/IEC 27001:2022, le misure di NIS2 Article 21, gli obblighi DORA sul rischio ICT, la responsabilizzazione GDPR e gli impegni contrattuali verso i clienti.

Mappare un unico pacchetto di evidenze di progetto su NIS2, DORA, GDPR e NIST CSF 2.0

La strategia di conformità più efficiente non consiste nel duplicare il lavoro. Consiste nel mappare un insieme solido di evidenze su molteplici obblighi.

Il Zenith Blueprint, nella fase di gestione del rischio, Step 14, raccomanda questo tipo di lavoro di riferimento incrociato:

“Per ciascuna normativa, se applicabile, è possibile creare una semplice tabella di mappatura (anche come appendice a un rapporto) che elenchi i principali requisiti di sicurezza della normativa e i controlli/le politiche corrispondenti nel proprio SGSI.”

Aggiunge che ciò è utile perché mostra ad auditor e valutatori “che non gestite la sicurezza nel vuoto, ma conoscete il contesto legale.”

Zenith Controls: la guida alla conformità incrociata di Clarysec supporta lo stesso approccio integrato mappando i controlli ISO/IEC 27001:2022 su altri quadri di riferimento, aspettative di audit ed esigenze di conformità. Per la governance dei progetti ICT, inquadra A.5.8, A.8.25 e A.8.32 come controlli preventivi che proteggono riservatezza, integrità e disponibilità nei temi di governance, sicurezza delle applicazioni, ecosistema, protezione e sicurezza di sistemi e reti.

Questa tabella non sostituisce l’analisi legale. È un acceleratore di governance. Assicura che CISO, DPO, sponsor di progetto, responsabile dell’approvvigionamento, proprietario del sistema e auditor interno guardino alle stesse evidenze.

Anche NIST CSF 2.0 si integra naturalmente in questo modello. La sua funzione GOVERN aiuta le organizzazioni a stabilire politiche, ruoli, propensione al rischio, supervisione e consapevolezza legale o contrattuale. Le funzioni IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER aiutano i team a discutere asset, servizi dei fornitori, controllo degli accessi, sicurezza dei dati, sicurezza della piattaforma, sviluppo software sicuro, monitoraggio, risposta agli incidenti e ripristino usando un linguaggio operativo condiviso.

Un unico processo allineato a ISO 27001 e centrato sull’Allegato A.5.8 può generare evidenze difendibili per tutte queste aspettative.

Lo sviluppo sicuro è più ampio della scrittura del codice

Molti fallimenti nei progetti ICT si verificano perché l’organizzazione tratta lo sviluppo sicuro come qualcosa che riguarda solo gli sviluppatori. Nel 2026, lo sviluppo sicuro include anche configurazione SaaS, automazione dei flussi di lavoro, infrastructure as code, integrazioni API, regole di identità, cloud landing zone, pipeline di analisi, robotic process automation e applicazioni aziendali low-code.

Il Zenith Blueprint, nella fase Controls in Action, Step 20, affronta il controllo ISO/IEC 27002:2022 8.25 Secure Development Life Cycle:

“Questo controllo si applica sia quando si scrivono applicazioni proprie, sia quando si configurano piattaforme come sistemi ERP o CRM, si personalizzano flussi di lavoro SaaS o si gestiscono ambienti infrastructure-as-code.”

Spiega inoltre che i requisiti di sicurezza devono stare accanto ai requisiti funzionali e che la modellazione delle minacce aiuta a identificare parti esposte del sistema, ruoli utente rischiosi e flussi di dati che richiedono una protezione più elevata.

Per un progetto moderno, le evidenze di sviluppo sicuro possono includere:

• Requisiti di sicurezza collegati ai requisiti aziendali
• Modello delle minacce o riesame dell’architettura sicura
• Checklist di codifica sicura o configurazione sicura
• Registrazioni di revisione del codice o peer review
• Inventario dei componenti e stato del rischio di dipendenza
• Decisioni sugli strumenti di gestione dei segreti
• Progettazione del controllo degli accessi e del principio del privilegio minimo
• Requisiti di logging e monitoraggio
• Risultati delle scansioni di vulnerabilità e registrazioni di remediation
• Test di sicurezza pre-produzione
• Test di backup, ripristino e resilienza ove pertinenti
• Evidenze di approvazione del rilascio e rollback

L’obiettivo non è obbligare ogni progetto a seguire lo stesso processo pesante. L’obiettivo è la proporzionalità. Una modifica minore a un flusso di lavoro interno non richiede le stesse evidenze di una migrazione di una piattaforma di pagamento core. Tuttavia, ogni progetto deve essere classificato, valutato in termini di rischio e governato in funzione dell’impatto.

La gestione dei cambiamenti protegge il progetto da sé stesso

Il momento più rischioso in molti progetti non è la progettazione o la codifica. È il rilascio in produzione.

Un team può eseguire modellazione delle minacce, revisione del codice, valutazione dei fornitori e riesame privacy, e creare comunque un’indisponibilità o una violazione a causa di una modifica in produzione affrettata. Un flag di debug rimane abilitato. Una regola del firewall è più ampia di quanto approvato. Uno script di migrazione copia dati personali in un ambiente non di produzione. Un endpoint webhook di terze parti viene distribuito senza autenticazione. Una modifica al logging registra numeri di documenti di identità. Un job di backup fallisce in modo silente dopo il cutover.

Il Zenith Blueprint, nella fase Controls in Action, Step 21, descrive il controllo ISO/IEC 27002:2022 8.32 Change Management in termini diretti:

“Il cambiamento è inevitabile, ma nella cibersicurezza il cambiamento non controllato è pericoloso.”

Prosegue:

“Alla base, una gestione dei cambiamenti efficace è un flusso di lavoro ripetibile. Inizia con una proposta chiara, che descrive che cosa cambia, perché, quando e quali sono i rischi potenziali.”

Una registrazione solida di modifica ICT deve rispondere a queste domande:

• Quale sistema, servizio, flusso di dati, fornitore o configurazione sta cambiando?
• Quali rischi sono stati identificati e chi ne è titolare?
• La modifica incide su dati personali, servizi critici, autenticazione, logging, backup o risposta agli incidenti?
• Quali verifiche di sicurezza, privacy, resilienza e fornitori sono state eseguite?
• Quali test sono stati completati prima del rilascio?
• Quale monitoraggio confermerà il comportamento atteso?
• Quale piano di rollback o ripristino esiste?
• Chi ha approvato il rischio residuo?
• Quali evidenze saranno conservate?

Per DORA, ciò supporta gestione documentata del rischio ICT, resilienza, continuità, classificazione degli incidenti e lezioni apprese. Per NIS2, supporta misure di gestione del rischio, sviluppo sicuro, prevenzione degli incidenti e continuità. Per GDPR, aiuta a dimostrare che le modifiche che incidono sui dati personali sono state riesaminate rispetto a finalità, minimizzazione, conservazione, accesso e principi di sicurezza.

Le decisioni su fornitori e cloud devono far parte della progettazione del progetto

Nei progetti ICT moderni, la decisione progettuale più rischiosa è spesso “comprare” anziché “costruire”. Servizi cloud, provider API, piattaforme di verifica dell’identità, processori di pagamento, fornitori di analisi, fornitori di servizi gestiti e fornitori di servizi di sicurezza gestiti diventano parte della superficie di rischio.

NIS2 include esplicitamente sicurezza della catena di fornitura, vulnerabilità dirette dei fornitori e dei fornitori di servizi, pratiche di cibersicurezza dei fornitori, procedure di sviluppo sicuro e risultati coordinati di valutazione del rischio della catena di fornitura. DORA va più in profondità per le entità finanziarie. Richiede gestione del rischio ICT di terze parti come parte del quadro di gestione del rischio ICT, responsabilità continua anche quando i servizi ICT sono esternalizzati, registri informativi, valutazioni precontrattuali, analisi del rischio di concentrazione, controlli contrattuali, diritti di audit e ispezione, trigger di risoluzione e strategie di uscita testate per funzioni critiche o importanti.

Per il portale di onboarding, il provider di verifica biometrica non può essere approvato solo perché all’approvvigionamento piace il prezzo e la documentazione API è buona. Il progetto richiede evidenze di due diligence di sicurezza, ruolo nel trattamento, localizzazione dei dati, subappaltatori, impegni di disponibilità, supporto agli incidenti, diritto di audit, assistenza alla cessazione, fattibilità dell’uscita e obblighi di monitoraggio.

In un modello maturo di evidenze, le decisioni su fornitori e cloud stanno dentro il pacchetto di evidenze di progetto, non in una cartella fornitori scollegata. Quando l’auditor chiede perché una terza parte è stata accettata, la risposta deve includere esigenza aziendale, valutazione del rischio, misure di protezione contrattuali, riesame della protezione dei dati, impatto sulla resilienza e monitoraggio continuo.

Come gli auditor riesamineranno le evidenze di sicurezza fin dalla progettazione

Auditor diversi affrontano lo stesso progetto ICT da prospettive diverse. Un auditor di certificazione, auditor interno, revisore DORA, autorità competente NIS2, auditor privacy, valutatore orientato a NIST o auditor in stile COBIT può richiedere evidenze simili ma interpretarle in modo diverso.

Gli auditor non cercano un bel set di slide di progetto. Cercano tracciabilità. Vogliono vedere che i requisiti hanno generato rischi, i rischi hanno generato controlli, i controlli hanno generato evidenze di attuazione e l’attuazione ha generato riesame.

Per questo Zenith Controls è utile nella preparazione agli audit. Aiuta i team a spiegare perché l’Allegato A.5.8, A.8.25 e A.8.32 sono controlli preventivi che proteggono riservatezza, integrità e disponibilità prima che guasti prevedibili raggiungano la produzione.

Il pacchetto minimo di evidenze di progetto Clarysec

Un solido pacchetto di evidenze per la sicurezza fin dalla progettazione non deve essere enorme. Deve essere coerente, proporzionato e mappato.

Per un progetto ICT a rischio medio, Clarysec raccomanda in genere il seguente pacchetto minimo:

1. Registrazione di classificazione della sicurezza del progetto
2. Nota di applicabilità normativa che copra NIS2, DORA ove pertinente, GDPR e obblighi contrattuali
3. Mappa dell’impatto su flussi di dati e asset
4. Valutazione del rischio di progetto e piano di trattamento del rischio
5. Modello delle minacce o riesame dell’architettura sicura
6. Valutazione dei fornitori e dei servizi cloud ove applicabile
7. Checklist di sviluppo sicuro o checklist di configurazione
8. Risultati dei test di sicurezza ed evidenze di remediation
9. Approvazione della modifica con piano di rollback e monitoraggio
10. Registrazione della protezione dei dati fin dalla progettazione, inclusa base giuridica e conservazione quando sono coinvolti dati personali
11. Aggiornamenti di risposta agli incidenti e monitoraggio
12. Riesame post-implementazione e lezioni apprese
13. Mappatura del registro di conformità su controlli e obblighi

Il Zenith Blueprint fornisce la logica della roadmap. Lo Step 22 porta la sicurezza delle informazioni in tutte le fasi del progetto. Lo Step 20 integra lo sviluppo sicuro in pianificazione, progettazione, codice, test e rilascio. Lo Step 21 rende la gestione dei cambiamenti strutturata, tracciabile e riesaminabile. Lo Step 14 raccomanda riferimenti incrociati a GDPR, NIS2, DORA e altri obblighi affinché i requisiti di conformità non cadano tra le maglie.

Le politiche forniscono le regole operative. La Politica per la sicurezza delle informazioni integra la sicurezza con gestione dei progetti, approvvigionamento e supervisione legale. La Politica di gestione del rischio rende i rischi di progetto parte dell’attività SGSI. La Politica di sviluppo sicuro richiede la modellazione delle minacce. La Politica di gestione dei cambiamenti richiede modifiche pianificate, valutate in termini di rischio, testate e approvate. La Politica di protezione dei dati e privacy richiede protezione dei dati fin dalla progettazione e per impostazione predefinita. La Politica di conformità legale e normativa richiede che le normative multi-area siano mappate nel registro di conformità.

Insieme, questi strumenti trasformano la sicurezza fin dalla progettazione da aspirazione a modello operativo verificabile.

Schemi di fallimento comuni nei progetti ICT

I fallimenti sono di solito prevedibili.

Il primo è il coinvolgimento tardivo della sicurezza. I riesami di sicurezza avvengono dopo che l’architettura è definita, i contratti sono firmati e le date di consegna sono pubbliche. A quel punto, la sicurezza diventa un blocco invece che un input di progettazione.

Il secondo è la frammentazione delle evidenze. Il progetto ha risultati dei test in uno strumento, riesame dei fornitori in un altro, commenti privacy via e-mail, accettazione del rischio in una registrazione di riunione e approvazione della modifica in un ticket. Nessun filo unico dimostra la governance.

Il terzo sono i punti ciechi sui fornitori. Il progetto si basa su un servizio cloud o su un provider API, ma nessuno verifica subappaltatori, localizzazione dei dati, diritto di audit, supporto agli incidenti, piani di uscita o rischio di concentrazione.

Il quarto è la deriva privacy. Un sistema costruito per una finalità inizia a supportare analisi, sperimentazione AI, esportazioni marketing o monitoraggio operativo senza riesaminare base giuridica, trasparenza, minimizzazione o conservazione.

Il quinto è la modifica non riesaminata. Un rilascio in produzione viene approvato per la funzionalità ma non valutato per impatto su accessi, logging, cifratura, backup, resilienza, dati personali o segnalazioni.

Il sesto è la debole supervisione della direzione. I rischi di progetto ad alto impatto sono accettati a un livello troppo basso, senza evidenze che il titolare del rischio responsabile abbia compreso le conseguenze normative.

Questi problemi non si risolvono acquistando un altro scanner. Si risolvono integrando la governance della sicurezza nel modo in cui i progetti sono proposti, progettati, approvvigionati, costruiti, testati, modificati e riesaminati.

Il messaggio per il CISO nel 2026

La sicurezza fin dalla progettazione nei progetti ICT è ormai un tema di consiglio, audit e normativa. NIS2 rende la gestione del rischio di cibersicurezza una responsabilità dell’organo di gestione. DORA rende rischio ICT, test di resilienza, gestione degli incidenti e supervisione delle terze parti un obbligo strutturato del settore finanziario. GDPR richiede responsabilizzazione per il trattamento dei dati personali e sicurezza adeguata. ISO/IEC 27001:2022 fornisce la struttura di sistema di gestione per rendere operativi questi obblighi.

Per i CISO, l’opportunità è smettere di confrontarsi con i team di progetto solo alla fine della consegna. Inserire la sicurezza in avvio, requisiti, progettazione, selezione dei fornitori, realizzazione, test, approvazione delle modifiche e riesame post-implementazione.

Per i responsabili della conformità, l’opportunità è sostituire evidenze disperse con un unico pacchetto di evidenze di progetto mappato.

Per gli auditor, l’opportunità è testare il ciclo di vita del progetto, non solo il sistema finale.

Per i titolari dell’attività, l’opportunità è una consegna più rapida e più sicura. La sicurezza fin dalla progettazione riduce rilavorazioni, previene sorprese di conformità, migliora le decisioni sui fornitori e offre alla leadership una narrazione del rischio difendibile.

Se i vostri progetti ICT procedono più velocemente del vostro modello di evidenze, iniziate con un progetto pilota. Usate il Zenith Blueprint di Clarysec per definire i gate di sicurezza del progetto, applicate le politiche Clarysec per gestione del rischio, sviluppo sicuro, gestione dei cambiamenti e privacy, e usate Zenith Controls per mappare la governance dei progetti ISO/IEC 27001:2022 su NIS2, DORA, GDPR e NIST CSF 2.0.

Clarysec può aiutarvi a costruire un pacchetto riutilizzabile di evidenze di progetto per la sicurezza fin dalla progettazione, allinearlo al vostro SGSI e prepararlo per audit interno, audit di certificazione, preparazione a DORA, governance NIS2 e responsabilizzazione GDPR.

Iniziate dal vostro prossimo progetto ICT significativo. Se modifica sistemi, fornitori, dati, accessi, resilienza o fiducia dei clienti, merita sicurezza fin dalla progettazione fin dal primo giorno.