Approvvigionamento software secure-by-demand nel 2026

È martedì mattina, all’inizio del 2026, e Maria, Chief Information Security Officer (CISO) di una società europea di pagamenti in rapida crescita, sta presentando al consiglio di amministrazione. L’ultimo punto all’ordine del giorno dovrebbe essere ordinario: l’approvazione di una nuova piattaforma di rilevamento delle frodi basata su AI. Il fornitore ha una demo convincente, uno sconto a tempo limitato, una panoramica di sicurezza di una pagina e un contratto standard.

Poi iniziano le domande.

L’amministratore delegato chiede: “Come sappiamo che questa piattaforma è sicura? I nostri clienti dei servizi finanziari chiedono evidenze di conformità a DORA e questo fornitore diventa parte della nostra infrastruttura critica.”

La funzione Legale chiede se l’Accordo sul trattamento dei dati (DPA) è pronto, dove saranno trattati i dati dei clienti dell’UE e se i sub-responsabili sono dichiarati. Il responsabile della resilienza operativa chiede informazioni sulla pianificazione dell’uscita, sulle esportazioni dei backup e sulla continuità per le funzioni critiche. L’ingegnere di sicurezza di prodotto chiede evidenze su divulgazione delle vulnerabilità, applicazione delle patch e un SBOM o una dichiarazione equivalente di trasparenza dei componenti. La funzione Acquisti pone la domanda che rende costoso il rischio dei fornitori: “Possiamo approvare ora e raccogliere i documenti dopo la firma?”

È il momento in cui il moderno approvvigionamento software diventa un controllo oppure un futuro rapporto di incidente.

Nel 2026, l’approvvigionamento software sicuro non può basarsi sulla buona volontà successiva al contratto. La sicurezza della catena di fornitura prevista da NIS2, il rischio di terze parti ICT previsto da DORA, la responsabilizzazione dei responsabili del trattamento prevista dal GDPR e le aspettative del Cyber Resilience Act sulla sicurezza di prodotto hanno spostato l’assurance dei fornitori nel punto decisionale dell’approvvigionamento. Gli acquirenti hanno bisogno di un approvvigionamento software secure-by-demand, in cui il cliente definisce evidenze di sicurezza, clausole contrattuali, gate di onboarding e responsabilità operative prima dell’acquisto.

Per i clienti Clarysec, la risposta non è un altro foglio di calcolo destinato a perdersi nelle e-mail. È un sistema di controllo dell’approvvigionamento allineato a ISO/IEC 27001:2022, mappato attraverso le politiche Clarysec, il Zenith Blueprint: An Auditor’s 30-Step Roadmap e Zenith Controls, in modo che ogni acquisto di software o SaaS disponga di una traccia sostenibile dalla necessità aziendale alla decisione sul rischio del fornitore.

Secure-by-demand è il nuovo controllo per l’approvvigionamento software

Secure-by-design viene di solito discusso dal punto di vista del fornitore. Secure-by-demand è la disciplina lato acquirente: l’organizzazione rifiuta di acquistare software se il fornitore non può dimostrare che sicurezza, privacy, resilienza, gestione delle vulnerabilità e verificabilità sono integrate nell’offerta.

Questo cambia il dialogo di acquisto. Invece di chiedere “Avete sicurezza?”, la funzione Acquisti pone domande più mirate:

• Quali dati tratterete, dove e con quale ruolo giuridico?
• Da quale funzione aziendale dipenderete e quanto è critica?
• Quali evidenze dimostrano che i vostri controlli funzionano, e non solo che sono documentati?
• Quali tempistiche di notifica degli incidenti vi impegnate a rispettare?
• Quali evidenze potete fornire su divulgazione delle vulnerabilità, applicazione delle patch, SBOM o VEX?
• Quali subappaltatori o sub-responsabili avranno accesso ai nostri dati o al nostro servizio?
• Possiamo effettuare audit, ispezioni o richiedere evidenze durante la durata del contratto?
• Che cosa accade in caso di cessazione, migrazione, violazione, insolvenza o richiesta dell’autorità di regolamentazione?

ISO/IEC 27001:2022 fornisce l’ossatura del sistema di gestione per questo cambiamento. La clausola 4 richiede che l’organizzazione comprenda contesto, parti interessate e campo di applicazione del SGSI, inclusi i requisiti esterni normativi e dei fornitori. La clausola 5 trasforma il rischio dei fornitori in una responsabilità di leadership e governance. La clausola 6 richiede valutazione del rischio, trattamento del rischio, selezione dei controlli, Dichiarazione di Applicabilità e decisioni sul rischio residuo. La clausola 8 richiede l’esecuzione controllata dei processi, inclusi i processi affidati all’esterno. La clausola 9 richiede monitoraggio, audit interno e riesame della direzione.

Ciò significa che l’approvvigionamento software non è solo un flusso di lavoro commerciale. Diventa un processo del SGSI gestito e verificabile. Autorità di regolamentazione e auditor chiedono sempre più spesso perché un’organizzazione abbia accettato un fornitore prima di comprenderne il rischio. L’approvvigionamento secure-by-demand offre una risposta chiara: il rischio è stato valutato, trattato, contrattualizzato e assegnato prima della creazione della dipendenza.

Perché NIS2, DORA, GDPR e CRA convergono nella selezione dei fornitori

Il consiglio di amministrazione di Maria pone le domande giuste perché un singolo fornitore software può attivare più obblighi contemporaneamente.

NIS2 si applica in base a settore, dimensione e criticità, con Annex I e Annex II che portano nell’ambito di applicazione molte organizzazioni digitali, finanziarie, infrastrutturali, dipendenti da prestatori di servizi gestiti e dal cloud. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, incluse sicurezza della catena di fornitura, acquisizione sicura, sviluppo e manutenzione sicuri, gestione delle vulnerabilità, controllo degli accessi, gestione degli asset, continuità, trattamento dell’incidente e valutazione dell’efficacia dei controlli. Article 21(3) richiede specificamente attenzione alle vulnerabilità dei fornitori diretti e alle pratiche di cibersicurezza dei fornitori. Article 23 introduce aspettative di segnalazione per fasi degli incidenti significativi, incluso un preallarme entro 24 ore e una notifica entro 72 ore.

DORA si applica dal 17 gennaio 2025 alle entità finanziarie rientranti nel suo ambito di applicazione. Introduce requisiti uniformi per la gestione del rischio ICT, la segnalazione degli incidenti connessi all’ICT, i test di resilienza operativa digitale e la gestione del rischio di terze parti ICT. DORA è particolarmente prescrittivo per l’approvvigionamento. Le entità finanziarie devono disporre di strategie per il rischio di terze parti ICT, registri degli accordi relativi a servizi ICT, due diligence, analisi del rischio di concentrazione, contratti scritti con disposizioni su sicurezza e resilienza, diritto di audit e di accesso, obblighi di cooperazione, diritti di recesso e piani di uscita. Articles 28 e 30 sono centrali per il rischio di terze parti ICT e i controlli contrattuali, mentre Articles 17 to 23 definiscono gestione degli incidenti e segnalazione.

Il GDPR aggiunge il gate di responsabilizzazione per i responsabili del trattamento. Articles 5, 28, 32, 33 e 34 richiedono responsabilizzazione, contratti con i responsabili del trattamento, sicurezza adeguata, cooperazione per la notifica delle violazioni e gestione dell’impatto sugli interessati. Un fornitore SaaS che tratta dati personali non è semplicemente un fornitore. Diventa parte della postura di conformità del titolare del trattamento. Il DPA, le misure tecniche e organizzative, l’elenco dei sub-responsabili, le misure di protezione per i trasferimenti, le regole di conservazione e gli obblighi di cancellazione devono essere compresi prima dell’inizio del trattamento.

Le aspettative CRA aggiungono l’assurance di prodotto. Anche quando l’acquirente non è il produttore, i team di approvvigionamento devono richiedere evidenze di sviluppo sicuro, gestione delle vulnerabilità, supporto del prodotto, aggiornamenti di sicurezza, divulgazione coordinata delle vulnerabilità e trasparenza dei componenti, come un SBOM o una dichiarazione equivalente. Questi requisiti devono essere inclusi nelle RFP, negli allegati di sicurezza e nei gate di accettazione.

Il punto comune è semplice: l’organizzazione acquirente deve sapere che cosa sta acquistando, quale rischio importa e quali evidenze può produrre quando autorità di regolamentazione, clienti o auditor le richiedono.

La dorsale dei controlli ISO 27001 per l’assurance dei fornitori

Il modello più efficace di approvvigionamento secure-by-demand non è costruito regolamento per regolamento. È prima di tutto basato sui controlli. Clarysec utilizza ISO/IEC 27001:2022 come dorsale del SGSI, supportata dalla guida ai controlli ISO/IEC 27002:2022 e dalla mappatura di conformità trasversale in Zenith Controls.

In Zenith Controls, l’assurance dei fornitori è ancorata ai controlli ISO/IEC 27002:2022 5.19, 5.20 e 5.21. Non sono elementi isolati di una checklist. Formano un ciclo di vita dell’approvvigionamento.

Zenith Controls mappa questi controlli ISO rispetto ad aspettative normative e di audit. Non crea controlli proprietari separati chiamati Zenith Controls. Aiuta i team a comprendere come i controlli ISO/IEC 27002:2022 supportino NIS2, DORA, GDPR, NIST CSF 2.0 e assurance orientata a COBIT.

Anche la rete di controlli di supporto è importante. L’assurance dei fornitori si collega a gestione degli asset, controllo degli accessi, sicurezza cloud, gestione delle vulnerabilità, registrazione, gestione degli incidenti, prontezza ICT per la continuità operativa, sviluppo sicuro, sicurezza delle applicazioni, gestione della configurazione, backup, ridondanza, conformità legale, privacy, gestione dei cambiamenti e riesame indipendente. La funzione Acquisti coordina il processo, ma la titolarità del rischio deve includere il titolare dell’attività, la sicurezza delle informazioni, la funzione Legale, la privacy, l’IT, la finanza e il responsabile del servizio.

Gate delle politiche Clarysec prima della firma

Il modello di politiche Clarysec porta deliberatamente l’assurance dei fornitori a monte. Il linguaggio più forte appare nel punto corretto: prima della firma degli accordi, prima dell’attivazione degli abbonamenti cloud e prima della condivisione dei dati.

La versione per PMI della Politica di sicurezza delle terze parti e dei fornitori di Clarysec stabilisce:

Valutare e documentare i rischi dei fornitori prima della firma degli accordi o della concessione degli accessi.

Questo proviene dalla sezione “Obiettivi”, clausola di policy 3.3. La clausola è breve perché l’intento del controllo non è negoziabile: nessuna valutazione del rischio, nessun contratto, nessun accesso.

Per gli ambienti enterprise, la Politica di sicurezza delle terze parti e dei fornitori di Clarysec rafforza il gate precontrattuale:

Tutti i nuovi fornitori devono essere sottoposti a una valutazione di sicurezza documentata prima della formalizzazione del contratto.

Questo proviene dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.1.1. La stessa politica identifica anche il “Diritto di audit, ispezione e richiesta di evidenze di sicurezza” nella sezione “Requisiti di governance”, clausola di policy 5.3.4.

Per l’acquisto di cloud e SaaS, la Politica di utilizzo del cloud per PMI aggiunge un gate pratico di approvazione:

Tutto l’uso dei servizi cloud deve essere riesaminato e approvato dal Direttore generale (GM) prima dell’attuazione o della sottoscrizione.

Questo proviene dalla sezione “Requisiti di governance”, clausola di policy 5.1. In una piccola organizzazione, tale approvazione può equivalere a un comitato di governance cloud. In un’impresa, diventa un flusso di lavoro tra approvvigionamento, sicurezza, privacy e architettura. La Politica di utilizzo del cloud enterprise supporta anche requisiti contrattuali cloud, incluse disposizioni applicabili nei contratti con i CSP.

Per l’acquisizione di software, la Politica sui requisiti di sicurezza delle applicazioni enterprise è esplicita:

Le acquisizioni software o gli accordi di esternalizzazione devono includere requisiti di sicurezza in RFP, contratti e SLA, comprese disposizioni sulle tempistiche di remediation delle vulnerabilità e sul diritto di audit da parte di terze parti.

Questo proviene dalla sezione “Requisiti di governance”, clausola di policy 5.4. Si noti l’ordine: RFP, contratti e SLA. La sicurezza compare nella fase di coinvolgimento del mercato, non come allegato successivo all’aggiudicazione.

Per l’approvvigionamento guidato dal GDPR, la Politica di conformità legale e normativa per PMI di Clarysec richiede:

Le clausole dell’accordo di trattamento dei dati o termini contrattuali equivalenti devono essere concordati prima che qualsiasi dato personale o sensibile sia condiviso.

Questo proviene dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.3.2. Ciò previene uno dei più comuni fallimenti di onboarding SaaS: caricare dati personali in uno strumento prima che siano concordati i termini del responsabile del trattamento, gli obblighi in caso di violazione e le condizioni sui sub-responsabili.

Per la sicurezza delle applicazioni dei fornitori, la Politica sui requisiti di sicurezza delle applicazioni per PMI richiede alla funzione Acquisti di:

specificare obblighi per la divulgazione delle vulnerabilità, i tempi di risposta e l’applicazione delle patch.

Questo proviene dalla sezione “Requisiti di governance”, clausola di policy 5.3.2. Stabilisce inoltre:

Il GM deve richiedere documentazione o certificazioni (ad es. SOC 2, ISO 27001, rapporti di test di sicurezza) come evidenza della conformità del fornitore, ove applicabile.

Questo proviene dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.3.2. La parola chiave è evidenza. L’approvvigionamento secure-by-demand non si basa su dichiarazioni di fiducia. Si basa su artefatti riesaminabili.

Il gate di approvvigionamento del Zenith Blueprint

Il Zenith Blueprint tratta la sicurezza dei fornitori come un controllo operativo, non come uno slogan di procurement. Nella fase Controls in Action, lo Step 23 copre i controlli organizzativi 5.19 to 5.37, inclusa la sicurezza delle informazioni nei rapporti con i fornitori.

Il Blueprint spiega:

Si inizia con la classificazione del fornitore. Non tutti i fornitori comportano lo stesso rischio. Un servizio di pulizia può avere accesso fisico agli uffici, ma non alle reti. Una società di test di penetrazione o un provider di hosting cloud, invece, può avere accesso tecnico profondo al cuore stesso della vostra infrastruttura. La classificazione deve considerare se il fornitore gestisce o tratta direttamente le vostre informazioni, se fornisce infrastrutture o piattaforme sulle quali operate, se gestisce o mantiene sistemi per vostro conto e se la sua compromissione potrebbe incidere sui vostri obiettivi di riservatezza, integrità o disponibilità.

Per il controllo 5.20, il Blueprint è diretto:

Le aree chiave normalmente trattate negli accordi con i fornitori includono obblighi di riservatezza; responsabilità di controllo degli accessi; misure tecniche e organizzative per protezione dei dati, cifratura, trasmissione sicura, backup e impegni di disponibilità; tempistiche e protocolli di segnalazione degli incidenti; diritto di audit, inclusi frequenza, ambito e accesso alle evidenze pertinenti; controlli sui subappaltatori; e disposizioni di fine contratto quali restituzione o distruzione dei dati, ripristino degli asset e disattivazione degli account.

Conclude che il controllo 5.20 è “l’ultima leva negoziale” e “appartiene al gate di approvvigionamento”. Una volta firmato il contratto, la leva si riduce. Prima della firma, evidenze e obblighi possono diventare condizioni di acquisto.

Per lo sviluppo esternalizzato, la fase Controls in Action, Step 21, controllo 8.30, aggiunge un ulteriore requisito di approvvigionamento. Il Blueprint afferma:

Al centro di questo controllo vi è il principio secondo cui la sicurezza deve essere un requisito contrattuale, non un’aspettativa verbale.

I team esternalizzati devono rispettare gli stessi standard di sviluppo sicuro dei team interni, inclusi analisi statica, peer review, cifratura, MFA verso i repository e visibilità su codice, decisioni architetturali, vulnerabilità, richieste di modifica, log CI/CD e risultati delle scansioni.

Costruire un gate RFP secure-by-demand in un pomeriggio

Supponiamo che la vostra organizzazione voglia una piattaforma di analisi dei clienti. Ingerirà identificativi dei clienti, eventi comportamentali, metadati di supporto e riferimenti alle transazioni. Il titolare dell’attività vuole un’approvazione rapida. Il team di sicurezza ha una settimana.

Iniziate con una registrazione del gate di approvvigionamento usando la Politica di sicurezza delle terze parti e dei fornitori, la Politica sui requisiti di sicurezza delle applicazioni, la Politica di utilizzo del cloud, la Politica di conformità legale e normativa e lo Step 23 del Zenith Blueprint come documenti sorgente.

Allegate alla RFP un questionario secure-by-demand. Evitate domande generiche come “Cifrate i dati?”. Ponete domande basate sulle evidenze:

1. Fornire il rapporto di assurance di sicurezza indipendente attuale, il certificato o evidenze equivalenti dei controlli.
2. Identificare sedi di hosting, opzioni di localizzazione dei dati, sedi dei backup e sedi da cui avviene l’accesso di supporto.
3. Fornire il DPA, l’elenco dei sub-responsabili e il processo di informativa per le modifiche dei sub-responsabili.
4. Confermare le tempistiche di notifica degli incidenti, incluso il supporto al preallarme entro 24 ore ove possano essere attivati flussi di lavoro NIS2 e il supporto alla segnalazione per fasi per i clienti regolamentati da DORA.
5. Fornire la politica di divulgazione delle vulnerabilità, gli SLA per le patch per gravità e le evidenze della recente governance della remediation delle vulnerabilità.
6. Fornire evidenze di sicurezza di prodotto, quali descrizione del ciclo di vita dello sviluppo sicuro, sintesi del test di penetrazione, SBOM o dichiarazione di trasparenza dei componenti e periodo di supporto agli aggiornamenti di sicurezza.
7. Confermare MFA, principio del privilegio minimo, registrazione, monitoraggio degli accessi amministrativi e diritto del cliente di audit o di richiesta di evidenze.
8. Descrivere esportazione, cancellazione, restituzione, supporto alla cessazione e assistenza alla transizione.
9. Elencare i subappaltatori significativi e le dipendenze ICT a supporto del servizio.
10. Confermare se i dati del cliente sono usati per addestramento, analisi, miglioramento del prodotto o sviluppo di modelli AI e identificare la base giuridica o il modello di istruzione del responsabile del trattamento.

Quindi valutate il fornitore prima della negoziazione.

Infine, aggiornate il Registro dei rischi e la Dichiarazione di Applicabilità. La registrazione del trattamento del rischio deve mostrare perché si applicano i controlli ISO/IEC 27002:2022 5.19, 5.20 e 5.21, quali requisiti contrattuali e tecnici sono stati selezionati, chi è titolare del rischio residuo e quale cadenza di monitoraggio si applica. Se l’azienda vuole procedere nonostante le lacune, utilizzate una registrazione formale di accettazione del rischio con data di scadenza, controlli compensativi e approvazione della direzione esecutiva.

Clausole contrattuali che trasformano la regolamentazione in obblighi applicabili

Le aspettative di sicurezza devono diventare impegni contrattuali. Un certificato può essere utile, ma raramente risponde a tutte le domande relative al servizio specifico, alla localizzazione dei dati, ai subappaltatori, al modello di supporto, agli impegni sugli incidenti o ai diritti di uscita.

Questa tabella è il ponte pratico tra obblighi legali e attività di approvvigionamento. Aiuta anche funzione Legale, sicurezza e Acquisti a negoziare a partire dalla stessa baseline dei controlli.

Mappatura della conformità trasversale: un solo fascicolo fornitore, molti obblighi

Il vantaggio di usare ISO/IEC 27001:2022 come dorsale è che un unico fascicolo di assurance dei fornitori può supportare più interlocuzioni normative.

NIST CSF 2.0 è utile come livello di comunicazione. La sua funzione GOVERN enfatizza consapevolezza legale, normativa, contrattuale, privacy e delle dipendenze. I risultati GV.SC relativi alla catena di fornitura richiedono processi di gestione del rischio della catena di fornitura, ruoli dei fornitori, prioritizzazione dei fornitori per criticità, requisiti contrattuali, due diligence, monitoraggio, pianificazione degli incidenti e pianificazione della cessazione.

Ciò si mappa in modo pulito allo Step 23 del Zenith Blueprint e ai controlli ISO/IEC 27002:2022 5.19 to 5.21 come mappati in Zenith Controls. Offre inoltre ai consigli di amministrazione un linguaggio comprensibile: stato attuale, stato obiettivo, lacuna, rischio, azione, proprietario e data.

Che cosa chiederanno gli auditor

Un processo robusto di approvvigionamento secure-by-demand deve reggere a diverse prospettive di audit.

Un auditor ISO/IEC 27001:2022 partirà da contesto e campo di applicazione del SGSI. Chiederà se interfacce e dipendenze dei fornitori sono incluse, se i requisiti delle parti interessate comprendono NIS2, DORA, GDPR e contratti con i clienti, e se i rischi dei fornitori sono valutati in modo coerente secondo la metodologia di rischio. Seguirà la traccia verso trattamento del rischio, Dichiarazione di Applicabilità, controlli sui fornitori, evidenze operative, audit interno e riesame della direzione.

Un revisore DORA si concentrerà sulle funzioni aziendali supportate dall’ICT, sulle funzioni critiche o importanti, sulle registrazioni delle dipendenze da terze parti, sulle clausole contrattuali, sul diritto di audit e di accesso, sulla cooperazione sugli incidenti, sui test di resilienza, sulle strategie di uscita e sul rischio di concentrazione. Se un SaaS supporta una funzione critica o importante, un questionario leggero al fornitore non sarà sufficiente.

Un’autorità NIS2 chiederà come l’organizzazione ha valutato le pratiche di cibersicurezza dei fornitori, le vulnerabilità dei fornitori diretti, il supporto alla notifica degli incidenti, le dipendenze di continuità e le decisioni di acquisizione sicura. Verificherà se l’assurance dei fornitori supporta gli obblighi dell’organizzazione ai sensi di Article 21 e Article 23.

Un revisore GDPR chiederà se i ruoli di titolare e responsabile del trattamento erano compresi prima dell’inizio del trattamento, se un DPA o termini equivalenti erano stati concordati prima della condivisione dei dati, se i sub-responsabili erano dichiarati, se le misure di sicurezza erano adeguate, se la cooperazione in caso di violazione è contrattualizzata e se la restituzione o cancellazione dei dati è applicabile.

Un auditor in stile COBIT 2019 o ISACA si concentrerà su governance e responsabilizzazione: chi ha approvato il fornitore, quale rischio è stato accettato, se i requisiti delle politiche sono stati seguiti, se le eccezioni sono tracciate e se benefici, rischi e risorse sono stati bilanciati.

Il pacchetto di evidenze deve includere classificazione del fornitore, approvazione del titolare dell’attività, valutazione del rischio, requisiti di sicurezza della RFP, risposte del fornitore, DPA, allegato di sicurezza, SLA, diritto di audit, registro dei sub-responsabili, impegni sulle vulnerabilità, clausole sugli incidenti, evidenze sulla localizzazione cloud, evidenze di registrazione e cifratura, termini di uscita, registrazioni di rivalutazione, eccezioni e mappatura della Dichiarazione di Applicabilità.

Schemi di fallimento comuni nell’acquisto di software

Il primo fallimento è trattare l’approvvigionamento come un flusso di lavoro commerciale e la sicurezza come un flusso di lavoro tecnico. Quando la sicurezza riceve il contratto, l’azienda si è già impegnata psicologicamente, la data di attuazione è stata annunciata e la leva negoziale è debole.

Il secondo fallimento è la sostituzione delle evidenze. Un fornitore consegna un certificato e l’acquirente presume che risponda a ogni domanda. La certificazione può aiutare, ma potrebbe non coprire il prodotto esatto, la regione di hosting, il modello di supporto, la catena dei subappaltatori, gli obblighi sugli incidenti, l’uso dei dati per AI o i requisiti di uscita.

Il terzo fallimento è ignorare il rischio a valle. Un fornitore SaaS può dipendere da hosting cloud, strumenti di analisi, piattaforme di supporto, team di sviluppo offshore, provider di modelli AI e responsabili dei pagamenti. Il controllo ISO/IEC 27002:2022 5.21 richiede attenzione alla catena di fornitura ICT dietro il fornitore diretto. In DORA, questo si collega al subappalto e al rischio di concentrazione. Nel GDPR, si collega ai sub-responsabili. In NIS2, si collega alle vulnerabilità dei fornitori diretti e alle pratiche di cibersicurezza dei fornitori.

Il quarto fallimento è un linguaggio debole sugli incidenti. Un contratto che afferma “il fornitore notificherà tempestivamente il cliente” potrebbe non supportare il preallarme NIS2, la segnalazione per fasi DORA, le comunicazioni ai clienti o l’escalation interna. Le clausole sugli incidenti richiedono tempi, presupposti, contatti, obblighi di cooperazione e obblighi di evidenza.

Il quinto fallimento è l’assenza di diritti di uscita chiari. Se un fornitore diventa insicuro, non conforme, viene acquisito, diventa insolvente o non è più idoneo sul piano strategico, l’acquirente ha bisogno di esportazione, cancellazione, supporto alla transizione, disattivazione degli account ed evidenze di distruzione. L’uscita non è un dettaglio legale successivo. È un controllo di resilienza.

Dal gate di approvvigionamento all’assurance continua dei fornitori

L’approvvigionamento secure-by-demand non termina alla firma. Un ciclo di vita dei fornitori maturo in stile Clarysec ha cinque fasi.

Per i fornitori ad alto rischio, il monitoraggio deve includere aggiornamento delle evidenze, riunioni di riesame della sicurezza, partecipazione a esercitazioni tabletop sugli incidenti, riesame degli accessi, reportistica su vulnerabilità e patch, riesame delle modifiche del servizio e aggiornamenti sui sub-responsabili. Per i fornitori a rischio inferiore, può essere sufficiente un riesame annuale. Scalabilità di ISO 27001, proporzionalità di NIS2 e proporzionalità di DORA supportano tutte l’adattamento, ma l’adattamento deve essere giustificato e documentato.

Il prossimo passo con Clarysec

Il prossimo acquisto SaaS rischioso non attenderà una perfetta riprogettazione della governance. Iniziate dalla prossima richiesta di approvvigionamento.

Usate il Zenith Blueprint: An Auditor’s 30-Step Roadmap per applicare i controlli sui rapporti con i fornitori dello Step 23 e i controlli sullo sviluppo esternalizzato dello Step 21. Usate Zenith Controls per mappare i controlli ISO/IEC 27002:2022 5.19, 5.20 e 5.21 rispetto alle aspettative di audit orientate a NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT. Usate la libreria di politiche Clarysec, inclusa la Politica di sicurezza delle terze parti e dei fornitori, la Politica sui requisiti di sicurezza delle applicazioni, la Politica di utilizzo del cloud e la Politica di conformità legale e normativa, per rendere il gate applicabile.

Prima della firma del prossimo contratto, richiedete classificazione del fornitore, evidenze di sicurezza, preparazione del DPA, impegni sugli incidenti, gestione delle vulnerabilità, trasparenza sui subappaltatori, diritto di audit e termini di uscita.

Questo è approvvigionamento secure-by-demand. È il modo in cui i CISO trasformano la pressione normativa in potere d’acquisto. È il modo in cui i compliance manager trasformano obblighi sovrapposti in un unico fascicolo di evidenze. È il modo in cui gli auditor vedono che il rischio del fornitore è stato considerato prima della creazione della dipendenza. Ed è il modo in cui i titolari dell’attività acquistano software più rapidamente senza ereditare rischi non gestiti.

Pronti a trasformare il vostro prossimo acquisto software in un controllo idoneo agli audit? Esplorate la suite integrata di politiche Clarysec, scaricate il Zenith Blueprint, riesaminate Zenith Controls o prenotate una demo per costruire un programma di approvvigionamento secure-by-demand in grado di resistere a NIS2, DORA, GDPR, aspettative CRA e al vaglio concreto degli auditor.