Un questionario TPRM può produrre un punteggio e lasciare irrisolto il problema che ha rivelato. Per scegliere uno strumento di gestione del rischio dei fornitori, fate dimostrare il percorso completo di un rilievo: constatazione, accordo sull’azione, scadenza, ritardo, escalation, prova di esecuzione e verifica della chiusura. L’articolo sul software DORA colloca i criteri di scelta per un caso regolato; qui il risultato è un copione di acquisto e prova applicabile al ciclo delle azioni, con un perimetro legale da verificare caso per caso.
Un prodotto che visualizza « completato » non dimostra, da solo, che il rischio sia cambiato. Un fornitore può caricare una nuova policy senza aver modificato il servizio; un esaminatore può chiudere un ticket per errore; un responsabile interno può accettare temporaneamente il rischio senza che l’azione sia conclusa. Occorre distinguere stati, persone e prove. Il NIST SP 1305 offre indicazioni sulla gestione del rischio di filiera nel Cybersecurity Framework; il NIST SP 800-53A spiega la logica di valutazione dei controlli. Nessuna delle due fonti prescrive un’interfaccia TPRM universale o attribuisce capacità specifiche a un venditore.
Partire da un rilievo concreto, non da una schermata
Preparate un caso di prova che rifletta un servizio acquistato. Nell’esempio fittizio, un fornitore SaaS conserva dati operativi e amministratori interni possono esportarli. L’ultima verifica mostra che gli accessi degli amministratori del fornitore non sono riesaminati dopo i cambi di mansione. Il rischio non è « punteggio 72 »: un ex amministratore potrebbe conservare un accesso non necessario e ottenere dati. La prova iniziale è un estratto datato del processo di concessione e revoca, con il limite esplicito che non sono stati ispezionati tutti gli account.
Il buyer consegna a ogni candidato lo stesso dossier sintetico, privo di dati sensibili reali. Chiede di creare un rilievo collegato al fornitore, al servizio, al controllo, all’evidenza iniziale e alla persona che l’ha esaminata. Deve poter vedere la differenza tra la data del rilievo e quella della valutazione del rischio. Se l’applicazione appiattisce tutto in una nota libera, chiedete come un altro revisore ricostruirà la decisione dopo sei mesi. Il software di conformità GDPR riguarda altre scelte applicative; non sostituisce questa prova del flusso correttivo.
Definite prima i criteri di successo. Per esempio, un rilievo deve mantenere il riferimento alla prova originale, avere un titolare interno, un contatto presso il fornitore, una gravità spiegata con il servizio, una scadenza concordata e uno stato distinguibile dalla chiusura. Non imponete che ogni strumento usi i vostri stessi nomi di campo. Chiedete che il rapporto esportato conservi il significato e le relazioni. La dimostrazione deve usare i dati del caso, non solo una presentazione preparata dal venditore.
Provare l’accordo sull’azione
Il fornitore propone di introdurre un riesame mensile degli amministratori e di revocare gli accessi non necessari. Questa promessa è ancora un piano. Registrate chi l’ha proposta, chi può impegnare il fornitore, quale popolazione di account copre e quale prova verrà consegnata. Un allegato « policy revisionata » non è equivalente a un elenco di account effettivamente riesaminati. La scelta della prova deve seguire il rischio identificato.
Chiedete al candidato TPRM di registrare una controproposta. Se il fornitore indica una data troppo lontana, il responsabile interno può chiedere una misura provvisoria, come una limitazione temporanea degli accessi. Il flusso deve conservare le versioni dell’impegno, non sovrascrivere la vecchia scadenza senza traccia. Verificate se la persona che accetta il rischio è diversa da quella che carica il documento. La segregazione dei ruoli conta soprattutto quando il rilievo riguarda una dipendenza critica e la pressione commerciale favorisce una chiusura prematura.
Un piano credibile descrive l’esito osservabile, non solo il compito. « Creare una procedura » è un’attività; « ogni account privilegiato del servizio compare in una revisione con esito e revoca dei privilegi non giustificati » è un criterio verificabile. Se l’azione è divisa in più tappe, la scadenza finale e le responsabilità devono rimanere visibili. Chiedete di mostrare che cosa accade se una tappa è chiusa e un’altra è scaduta: il rilievo principale non dovrebbe apparire risolto per effetto di un solo allegato.
Mettere alla prova il ritardo e l’escalation
Nel copione, fate passare la scadenza concordata senza caricare la prova. Chi riceve un avviso? Il contatto del fornitore, il proprietario del servizio e l’esaminatore sicurezza hanno ruoli diversi. Un avviso automatico è utile solo se la persona destinataria può agire e se il mancato riscontro viene trattato. Chiedete al venditore di dimostrare la regola di escalation, la possibilità di correggere un destinatario cessato e il registro delle notifiche effettivamente inviate.
Il ritardo non coincide automaticamente con una violazione contrattuale. Per stabilirlo bisogna leggere l’impegno sottoscritto e le condizioni applicabili. Nel flusso TPRM, invece, il ritardo è un fatto operativo: la prova non è arrivata alla data attesa. Il responsabile interno deve decidere se prorogare, restringere il servizio, attivare una misura transitoria o alzare il livello della decisione. La proroga va motivata e datata; spostare semplicemente il campo scadenza cancella la storia del rischio.
Provate anche la seconda scadenza mancata. Molti prodotti funzionano bene fino al primo sollecito, ma non chiariscono quando interviene il procurement o il titolare del rapporto. Il vostro script deve chiedere di esibire l’escalation a un responsabile diverso, con contesto sufficiente: servizio coinvolto, impatto possibile, prove esistenti, impegno originario, nuova proposta e opzioni di riduzione dell’esposizione. Un messaggio generico « task overdue » non basta a supportare una decisione.
Verificare la chiusura indipendentemente dalla dichiarazione
Il fornitore carica un file che dichiara completata la revisione degli accessi. La persona che aveva aperto il rilievo, o un revisore con indipendenza adeguata, controlla se il file copre il servizio, il periodo e tutti i ruoli pertinenti. Se mancano gli account di emergenza, la chiusura è parziale. Il sistema deve permettere una richiesta di chiarimento senza cancellare il tentativo di chiusura. La procedura di audit di sicurezza può aiutare a definire mandato ed evidenze; questa prova si concentra sul ciclo con il fornitore.
Conducete un piccolo retest: scegliete due identità del campione, confrontate il ruolo attuale con l’autorizzazione e accertate la revoca di un accesso non più giustificato. L’esito del retest può essere « adeguato », « parziale » o « non verificabile ». Registrate il metodo, la data e il limite del campione. Un file caricato non è sinonimo di misura efficace. Se il retest fallisce, il rilievo resta aperto o viene riaperto, con nuova azione e collegamento alla cronologia precedente.
Chiudere significa distinguere tre cose: il fornitore ha eseguito l’azione, la verifica ne ha constatato l’effetto nel perimetro esaminato, il responsabile ha deciso che il rischio residuo può essere trattato come previsto. Queste date possono essere diverse. Un software che offre un solo pulsante « chiuso » può comunque essere usato con discipline esterne, ma il costo di tali procedure manuali va incluso nella valutazione d’acquisto.
Scheda comparativa per la dimostrazione
Usate una griglia semplice. Il punteggio è un ausilio e non deve sostituire il giudizio su requisiti indispensabili. Alcune organizzazioni hanno bisogno di esportazioni complete e di separazione dei ruoli più di quanto abbiano bisogno di dashboard elaborate.
| Prova richiesta | Osservazione durante la demo | Esito da annotare |
|---|---|---|
| Origine del rilievo | Conserva fonte, servizio e prova iniziale | Sì, parziale o no, con schermata datata |
| Accordo | Mantiene impegno, proprietari e versione della data | Indicare campi mancanti |
| Ritardo | Avvisa il destinatario e apre escalation | Mostrare evento e responsabile |
| Proroga | Conserva vecchia scadenza e motivo | Controllare cronologia esportata |
| Chiusura | Distingue dichiarazione e verifica indipendente | Provare riapertura dopo fallimento |
| Esportazione | Ricostruisce relazione fornitore-servizio-rilievo | Aprire il file fuori dal prodotto |
Non fate attribuire punti per funzioni mostrate solo in una slide. Chiedete un accesso di prova o una dimostrazione con operazioni eseguite davanti al team. Qualora una funzione dipenda da un modulo extra o da un’integrazione, registrate condizioni commerciali, responsabilità e prova tecnica. La guida al software NIS2 offre criteri più ampi di scelta; l’esito di questa griglia riguarda esclusivamente la gestione delle azioni sui fornitori.
Misurare responsabilità e interoperabilità
Il rapporto può coinvolgere sicurezza, procurement, legale e proprietario del servizio. Definite chi apre il rilievo, chi concorda una correzione, chi accetta una proroga, chi verifica l’evidenza e chi prende la decisione finale. Il fornitore non deve poter chiudere autonomamente una non conformità che l’azienda non ha verificato. Nel test, cambiate l’assegnatario interno e osservate se il nuovo titolare vede il contesto e gli allegati senza ricostruire tutto a mano.
Un fornitore può operare più servizi con rischi diversi. Lo stesso ritardo non deve automaticamente contaminare una prestazione senza relazione con il controllo. D’altra parte, un problema sistemico su identità privilegiate può interessare più servizi e richiedere un’unica azione con destinatari collegati. Chiedete come lo strumento rappresenta tali relazioni e come evita duplicati che portano a date di chiusura incoerenti. Un modello dati troppo semplice può gonfiare il numero di task senza migliorare la conoscenza del rischio.
Provate l’esportazione al momento della selezione, non alla fine del contratto. Conserva gli identificativi, le versioni, le prove, gli esiti e i nomi dei responsabili? Può essere aperta fuori dall’ambiente del venditore? È possibile capire quali allegati contengono dati confidenziali e quali destinatari possono accedervi? Le risposte incidono sul costo di migrazione e sulla continuità della gestione. Non assumete che una API dichiarata risolva da sola la riconciliazione delle relazioni.
Separare governance generale e obblighi applicabili
Il ciclo delle azioni correttive è utile anche quando non si applicano norme settoriali particolari. Se l’ente è soggetto a DORA, occorre qualificare il servizio TIC, la funzione sostenuta e gli obblighi propri del regolamento prima di trasformare una buona pratica in requisito. Se la valutazione riguarda la catena di fornitura NIS2, considerate l’attuazione nazionale e il tipo di entità. Un software TPRM non rende conforme un’organizzazione per il solo fatto di esistere.
La politica di sicurezza informatica aziendale può stabilire criteri e deleghe. Il copione qui descritto permette di verificare che il prodotto scelto aiuti davvero a far rispettare la decisione nel tempo. Per i fornitori critici, aggiungete una prova di continuità o sostituzione quando l’azione resta scaduta. Per quelli a bassa dipendenza, un’escalation più leggera può essere proporzionata. La stessa interfaccia deve comunque lasciare chiaro chi ha accettato il rischio e su quali fatti.
L’esito della selezione dovrebbe essere un verbale concreto: capacità dimostrate, lacune, procedure manuali necessarie, condizioni commerciali e scelta motivata. Non scrivete « piattaforma migliore » sulla base del numero di funzioni pubblicizzate. Scrivete se un altro revisore riuscirebbe a seguire il rilievo iniziale fino a una chiusura realmente verificata, compresi ritardi, cambi di proprietario e prove respinte. È questa continuità che distingue un ciclo di correzione da un archivio di questionari.
Verificare un caso di fornitore che non collabora
Aggiungete alla dimostrazione un rifiuto motivato del fornitore: non può condividere un log integrale perché conterrebbe dati di altri clienti. Il prodotto deve consentire di registrare il limite senza trasformarlo in un « no » generico. Provate a chiedere una prova alternativa, come un estratto anonimizzato, un’attestazione circoscritta o una verifica condotta da un terzo. Annotate chi decide che la prova alternativa basta e per quale conclusione. Se il fornitore rifiuta anche queste opzioni, il responsabile del rapporto deve valutare se ridurre il servizio o cercare un’alternativa.
La funzione software non può decidere automaticamente quale rifiuto sia accettabile. Una prova utile per la disponibilità può non dire nulla sulla revoca degli amministratori. Lo strumento dovrebbe preservare domanda originale, risposta, motivazione, alternativa, decisione e data di riesame. Provate l’esportazione di questa sequenza: se dopo la migrazione resta solo lo stato « accettato », l’organizzazione perde la ragione dell’eccezione. La valutazione di uscita dei fornitori TIC può diventare rilevante per servizi finanziari in ambito DORA, ma il test di acquisto non deve assumere quel perimetro per ogni cliente.
Considerare il costo del lavoro dopo l’acquisto
Chiedete quanto tempo richiede creare un rilievo da un questionario già compilato, assegnare un proprietario, preparare l’escalation e riesaminare la prova. Ripetete con un secondo servizio dello stesso fornitore. Se il sistema genera duplicati, il risparmio di raccolta iniziale può essere assorbito dalla riconciliazione successiva. Fate eseguire il flusso a un utente dell’azienda, non solo al consulente del venditore; la familiarità con l’interfaccia influenza molto il tempo della demo.
Includete nella decisione il costo di formazione, configurazione dei ruoli e manutenzione delle regole di notifica. Una dashboard elegante può essere utile alla direzione, ma la qualità del ciclo dipende dalle persone che ricevono l’azione giusta e verificano l’evidenza. Se per ottenere questo risultato servono fogli di calcolo esterni, il verbale dovrebbe dirlo. Il confronto economico tra candidati deve partire dalle stesse attività e dallo stesso periodo, altrimenti premia chi ha mostrato la demo più facile.
Conservate infine l’esito della prova con data, versione del prodotto e condizioni dell’ambiente dimostrato. Una funzione vista in anteprima non è necessariamente disponibile nella licenza proposta; chiedete conferma scritta e ripetete le operazioni decisive prima dell’accettazione finale.