Domande sulla sicurezza aziendale da porre ai fornitori di piattaforme di negoziazione

Gli acquirenti che valutano la sicurezza delle piattaforme di negoziazione dovrebbero chiedere ai fornitori di dimostrare — non limitarsi ad affermare — come isolano i dati dei clienti, gestiscono la conservazione e la cancellazione, applicano la crittografia, limitano le autorizzazioni e producono registri di audit affidabili. Questi controlli dovrebbero coprire l’intera architettura della piattaforma di negoziazione, inclusi prompt, allegati, embedding, backup, strumenti di assistenza, integrazioni e sub-responsabili.

Per la sicurezza della negoziazione con IA e la privacy dei dati delle piattaforme di negoziazione, un questionario è solo il punto di partenza. I team aziendali addetti agli acquisti hanno bisogno di diagrammi architetturali, risultati dei test, dimostrazioni delle configurazioni, esempi di log, impegni contrattuali e approvazione umana responsabile del rischio residuo. Una certificazione può contribuire alla valutazione, ma non può sostituire le prove specifiche del prodotto.

Risposta rapida

Chiedete come il fornitore separa ogni tenant, quali dati conserva e cancella, dove si applica la crittografia, chi può eseguire azioni sensibili e quali eventi i clienti possono sottoporre ad audit. Richiedete diagrammi architetturali, risultati dei test, calendari di conservazione, dettagli sulla gestione delle chiavi, matrici delle autorizzazioni ed esempi di log. Trasformate poi le risposte accettate in obblighi contrattuali, con l’approvazione delle eccezioni da parte dei responsabili di sicurezza, privacy, legale, acquisti e business.

Cinque controlli, cinque requisiti probatori

Usate questo riepilogo per strutturare il primo incontro con il fornitore.

Il NIST Cybersecurity Framework 2.0 individua l’autorizzazione degli accessi, la protezione dei dati e la generazione di log come risultati di sicurezza informatica. È un utile riferimento di base, ma non dimostra che un determinato fornitore abbia attuato efficacemente tali risultati.

1. Verificate l’isolamento nell’intera architettura

L’isolamento dei tenant consiste nell’impedire a un cliente o a un carico di lavoro di accedere a un altro o di influenzarlo. Un fornitore potrebbe affermare che ogni record del database contiene un identificativo del cliente, ma questa risposta non considera gli indici di ricerca, le cache, i sistemi di analisi, l’archiviazione dei file, le integrazioni e i servizi di IA.

Chiedete al fornitore di identificare ogni componente in cui possono coesistere informazioni dei clienti:

• Servizi applicativi e API
• Database, repliche e data warehouse
• Archiviazione di oggetti e allegati
• Cache e code di messaggi
• Indici di ricerca e recupero
• Sistemi di analisi e diagnostica
• Prompt, output, embedding e dati di valutazione
• Ambienti di sviluppo, test, dimostrazione e assistenza
• Fornitori di modelli e altri sub-responsabili

Chiedete poi come viene verificata l’identità del tenant per ogni richiesta relativa a un oggetto e per ogni chiamata API. L’isolamento è imposto dall’infrastruttura, dagli account, dagli schemi, dalle policy del database o dal codice applicativo? In quali punti un errore di programmazione potrebbe oltrepassare un confine?

La NIST SP 800-53 Release 5.2.0 include controlli relativi agli accessi, alle risorse condivise e alla protezione delle informazioni archiviate. La pubblicazione complementare sulla valutazione, NIST SP 800-53A, avvalora un importante principio per gli acquirenti: chiedete prove che un controllo sia stato implementato e sia operativo, non soltanto una policy che ne prescriva l’esistenza.

Domande sulle prove di isolamento

1. L’ambito dei test di penetrazione include esplicitamente l’accesso tra tenant?
2. Sono stati testati i percorsi API, di ricerca, esportazione, cache e archiviazione dei file?
3. I dati di produzione vengono mai copiati in ambienti non di produzione?
4. Come ottiene il personale del fornitore l’accesso temporaneo alla produzione?
5. L’accesso viene approvato, limitato nel tempo, registrato e sottoposto a revisione?
6. Prompt, indici di recupero, output ed embedding dell’IA sono isolati per tenant?
7. Il fornitore ha subito un’esposizione confermata o sospetta di dati tra clienti? In tal caso, come l’ha gestita?

Una lettera generica sui test di penetrazione non è sufficiente se il prodotto acquistato, la regione di distribuzione, le funzioni di IA o i confini tra tenant non rientravano nell’ambito dei test.

2. Mappate la conservazione prima di negoziare la cancellazione

La privacy dei dati delle piattaforme di negoziazione dipende da molto più di una promessa di «cancellare i dati del cliente alla cessazione del contratto». Una negoziazione negli acquisti può generare offerte, allegati dei fornitori, note interne, cronologie delle approvazioni, prompt, output dei modelli e metadati commercialmente sensibili. Possono inoltre esistere copie nei log, nelle repliche, nei ticket di assistenza, nei backup e nei sistemi dei sub-responsabili.

Preparate una matrice di conservazione prima di accettare le condizioni proposte dal fornitore:

Non copiate da una checklist un periodo di conservazione universale. I periodi appropriati dipendono dalle esigenze investigative, dai termini per le controversie, dalle policy aziendali, dagli obblighi di legge, dalla sensibilità dei dati e dai ruoli delle parti.

Quando si applicano le norme GDPR sui responsabili del trattamento, i contratti devono generalmente disciplinare la restituzione o la cancellazione dei dati personali e il supporto agli audit. Il regolamento stabilisce inoltre il principio della limitazione della conservazione. Consultate il testo ufficiale del GDPR. Spetta ai consulenti legali determinare se e in che modo tali norme si applichino a una specifica implementazione.

Domande contrattuali sulla conservazione

• L’acquirente può configurare la conservazione per categoria di dati?
• Che cosa cancella effettivamente un’azione di cancellazione disponibile all’utente?
• In quanto tempo vengono rimosse le copie attive, le cache e le repliche?
• Quando scadono i backup immutabili?
• La cancellazione comprende gli indici derivati e gli embedding?
• Quali dati possono essere conservati a causa di un obbligo legale?
• Il fornitore offrirà assistenza per l’esportazione prima della cessazione del contratto?
• Chi firma la certificazione di cancellazione?
• Requisiti equivalenti vengono imposti anche ai sub-responsabili?

Le indicazioni della FTC sulla sicurezza dei fornitori raccomandano di specificare contrattualmente le aspettative sull’uso, la conservazione, la condivisione e la cancellazione dei dati da parte dei fornitori, e di verificarne il rispetto anziché affidarsi a semplici rassicurazioni.

3. Guardate oltre gli slogan sulla crittografia

«Crittografato con AES-256» non chiarisce dove si applichi la crittografia, chi controlli le chiavi o cosa accada quando l’applicazione utilizza dati in chiaro. La crittografia non può impedire l’uso improprio da parte di un’applicazione o di un amministratore autorizzato, né da parte di un account compromesso.

Chiedete al fornitore di illustrare ogni stato dei dati:

• In transito: sessioni del browser, API, integrazioni, connessioni ai fornitori di modelli, canali di assistenza ed esportazioni di dati
• A riposo: database, allegati, log, repliche, backup, indici ed embedding
• In uso: ricerca, analisi, inferenza dei modelli, elaborazione dei documenti e generazione di raccomandazioni

La gestione delle chiavi dovrebbe comprendere generazione, archiviazione, accesso, rotazione, revoca, backup e distruzione. Questo ciclo di vita è descritto nella definizione NIST di gestione delle chiavi.

Domande su crittografia e gestione delle chiavi

1. Quali protocolli e algoritmi proteggono ogni categoria di archiviazione e percorso dei dati?
2. Le chiavi sono separate per cliente, ambiente, servizio o regione?
3. Chi può amministrare o utilizzare le chiavi?
4. Le operazioni sulle chiavi vengono registrate e sottoposte a doppio controllo?
5. L’acquirente può usare chiavi gestite dal cliente? Quali dati restano al di fuori di tale controllo?
6. La revoca rende inaccessibili i dati interessati?
7. Come vengono distrutte le chiavi alla cessazione del contratto?
8. Quali moduli crittografici specifici sono convalidati in modo indipendente?

Se un fornitore dichiara una convalida FIPS, chiedete il numero del certificato, la versione del prodotto, il modulo e l’ambiente operativo. La FIPS 140-3 riguarda i moduli crittografici; il solo utilizzo di un algoritmo approvato non dimostra che il prodotto distribuito sia convalidato.

4. Distinguete l’accesso dall’autorità decisionale

I sistemi aziendali di negoziazione hanno bisogno di più dei ruoli di base di amministratore e utente. Le autorizzazioni potrebbero dover variare in base a fornitore, unità aziendale, negoziazione, campo e azione.

Richiedete una dimostrazione dal vivo di:

• Single sign-on SAML o OIDC
• Autenticazione a più fattori obbligatoria
• Provisioning e deprovisioning tramite SCIM o equivalente
• Ruoli con impostazione predefinita di diniego e privilegi minimi
• Ruoli personalizzati e ambiti granulari
• Restrizioni sulle esportazioni e sui download in blocco
• Titolarità degli account di servizio e rotazione dei token
• Accesso di assistenza limitato nel tempo
• Certificazione periodica degli accessi
• Avvisi per escalation dei privilegi, impersonificazione ed esportazioni massive

La verifica più importante riguarda la separazione dei compiti. Un utente che redige un’offerta non dovrebbe poterla approvare e trasmettere automaticamente. Allo stesso modo, un servizio di IA può raccomandare una condizione senza ricevere l’autorità di impegnare l’azienda.

Le indicazioni CISA sulla sicurezza per progettazione raccomandano MFA per gli utenti privilegiati, SSO basato su standard e log di audit utili e accessibili ai clienti. Gli acquirenti dovrebbero inoltre chiarire se questi controlli sono inclusi nel livello commerciale effettivamente preso in considerazione.

Per una visione più ampia di come la sicurezza si inserisca nel flusso operativo, consultate negoziazioni con IA e la guida correlata alla preparazione dei dati per una piattaforma di negoziazione. Gli acquirenti che confrontano flussi di lavoro specifici per il sourcing possono consultare anche il software per la negoziazione negli acquisti.

5. Esigete verificabilità, non semplicemente «registrazione degli eventi»

La registrazione degli eventi consiste nella produzione di record. La verificabilità richiede record sufficientemente completi, affidabili, protetti, conservati e accessibili da consentire la ricostruzione di un evento.

Chiedete se la piattaforma di negoziazione registra:

• Accessi riusciti e non riusciti
• Modifiche a MFA, utenti, ruoli e autorizzazioni
• Accessi del personale di assistenza del fornitore e impersonificazioni
• Visualizzazione, creazione, modifica e cancellazione di record
• Cronologia di offerte, controfferte e approvazioni
• Caricamenti, download, condivisioni ed esportazioni in blocco
• Attività delle API e degli account di servizio
• Modifiche alla configurazione e alle policy di conservazione
• Raccomandazioni generate dall’IA
• Accettazione, modifica o rifiuto umano degli output dell’IA
• Modifiche alle impostazioni di registrazione

Ogni evento rilevante dovrebbe indicare chi o che cosa ha agito, quando, quale oggetto è stato interessato, quale azione è stata eseguita e se ha avuto esito positivo. Chiedete timestamp sincronizzati, preferibilmente in UTC, oltre a schemi documentati ed esportazione automatizzata verso un SIEM.

La Cloud Security Technical Reference Architecture della CISA osserva che i clienti SaaS possono essere limitati dai log resi disponibili dal fornitore. Favorisce il trasferimento automatizzato dei log e sottolinea l’importanza della registrazione centralizzata e della coerenza dei timestamp.

Checklist riutilizzabile per la due diligence sulla sicurezza

Usate la checklist seguente durante una negoziazione aziendale. Contrassegnate ogni voce come Verificata, Parziale, Non verificata o Non applicabile. «Verificata» significa che le prove sono state esaminate, non che il fornitore ha risposto affermativamente.

Architettura e isolamento

• Forniti diagrammi aggiornati dell’architettura e dei flussi di dati
• Identificati tutti i livelli condivisi di archiviazione ed elaborazione
• Spiegato il metodo di applicazione dell’isolamento del tenant alle richieste dell’interfaccia utente e delle API
• Testato l’isolamento di ricerca, cache, allegati, analisi ed esportazioni
• Isolati prompt, output, embedding e indici di recupero dell’IA
• Separati gli ambienti di produzione e non di produzione
• Accesso privilegiato del personale di assistenza approvato, limitato nel tempo e registrato
• I test tra tenant sono inclusi nell’ambito di una valutazione recente

Uso, conservazione e cancellazione dei dati

• Fornito un inventario completo dei dati
• Documentata la finalità del trattamento per ogni categoria di dati
• Documentate le regole sull’uso secondario e sull’addestramento dei modelli
• Definiti i periodi di conservazione per categoria di dati e livello di archiviazione
• Definito il termine per la cancellazione dai sistemi attivi
• Definita la scadenza di repliche, cache e backup
• Documentata la gestione degli obblighi legali di conservazione
• Confermati gli obblighi di cancellazione dei sub-responsabili
• Inclusi nelle condizioni proposte l’assistenza all’esportazione e la certificazione di cancellazione

Crittografia e chiavi

• Mappata la copertura della crittografia in transito, a riposo, nei backup e durante l’elaborazione
• Documentati protocolli e algoritmi
• Spiegati la titolarità delle chiavi e i controlli di accesso
• Documentate rotazione, revoca, backup e distruzione
• Registrate le operazioni sulle chiavi
• Dichiarate le limitazioni delle chiavi gestite dal cliente
• I certificati FIPS dichiarati corrispondono al modulo e all’ambiente distribuiti

Identità, autorizzazioni e approvazioni

• Dimostrati SSO e MFA
• Testati il provisioning automatizzato e la revoca immediata degli accessi
• Fornita la matrice di ruoli e autorizzazioni
• Possibilità di definire l’ambito degli accessi per unità aziendale, fornitore, negoziazione e azione
• Separati i compiti di creazione, modifica, approvazione e trasmissione
• Dimostrati i controlli su esportazioni, token API e account di servizio
• Sottoposto a revisione periodica l’accesso privilegiato
• L’IA non può assumere impegni vincolanti senza l’approvazione di una persona autorizzata

Registrazione e garanzie

• Forniti esempi di log e schema degli eventi
• Registrati gli eventi di amministratori, assistenza, API, IA, esportazioni e approvazioni
• Presenti identità univoche e timestamp affidabili
• Protetti i log da modifiche ordinarie da parte degli amministratori
• Dimostrata l’esportazione automatizzata verso un SIEM
• La conservazione dei log è conforme ai requisiti dell’acquirente
• L’ambito dell’audit indipendente corrisponde al servizio acquistato
• I rilievi dei test di penetrazione hanno responsabili e stato di risoluzione
• Esaminate le procedure di risposta agli incidenti e di notifica ai clienti
• Esaminate le prove dei test di continuità operativa e ripristino

Contratto e uscita

• I controlli accettati sono inclusi nel contratto o nell’allegato sulla sicurezza
• L’allegato sulla sicurezza prevale su policy web meno rigorose
• Concordati la notifica dei sub-responsabili e il processo di opposizione
• Le riduzioni sostanziali dei controlli richiedono una notifica
• Definiti l’accesso alle prove, la risoluzione dei problemi e i diritti di audit
• Definiti i criteri che attivano la notifica degli incidenti e le relative scadenze
• Definita l’assistenza per l’esportazione e la cancellazione dei dati
• Un responsabile del rischio nominato dall’acquirente approva ogni eccezione

Trasformate le prove in una decisione documentata

Una scheda di valutazione pratica dovrebbe preservare l’incertezza, anziché nasconderla dietro un’unica percentuale.

Non compensate un controllo obbligatorio non superato facendo la media. Un rapporto di audit ben presentato non può compensare un confine tra tenant non testato, così come una crittografia robusta non può compensare privilegi eccessivi.

Esempio ipotetico: valutazione di un flusso di negoziazione con IA

Ipotetico — non è un’affermazione su alcun fornitore: un team aziendale addetto agli acquisti vuole usare una piattaforma per analizzare le proposte dei fornitori e suggerire opzioni di risposta. I record includono prezzi dei fornitori, obiettivi interni, allegati e identità degli utenti.

Durante la valutazione, il fornitore dimostra l’esistenza di controlli a livello di database per i tenant e di SSO. Tuttavia, le prove non chiariscono se gli embedding siano separati per tenant, se le acquisizioni diagnostiche abbiano un periodo di cancellazione definito o se l’impersonificazione da parte del personale di assistenza compaia nei log accessibili al cliente.

Il team non dovrebbe considerare automaticamente superati questi punti sconosciuti. Può:

1. Classificare i tre elementi come non verificati.
2. Richiedere dettagli architetturali e prove di test mirate.
3. Eseguire un test del flusso configurato usando dati non di produzione.
4. Richiedere che l’accesso del personale di assistenza sia approvato, temporaneo e registrato.
5. Aggiungere all’allegato sulla sicurezza la conservazione dei dati diagnostici e la cancellazione degli embedding.
6. Impedire l’uso in produzione finché il responsabile della sicurezza non approva le prove o accetta formalmente il rischio residuo.

Se Negotiations.AI fosse presa in considerazione per questo flusso di acquisto, dovrebbe essere sottoposta alla stessa valutazione basata sulle prove. La notorietà del marchio o la pertinenza del flusso di lavoro non esonererebbero l’acquirente dall’obbligo di convalidare l’implementazione acquistata.

Che cosa è verificato, presunto, stimato e raccomandato?

Fatti verificati

• Il NIST ha pubblicato CSF 2.0 il 26 febbraio 2024, includendo risultati relativi ad autorizzazione, protezione dei dati e log.
• Il NIST ha pubblicato SP 800-53 e SP 800-53A Release 5.2.0 il 27 agosto 2025.
• FIPS 140-3 definisce i requisiti di sicurezza per i moduli crittografici.
• La CISA raccomanda impostazioni predefinite sicure, MFA per gli utenti privilegiati, SSO basato su standard e log accessibili e di alta qualità.
• Gli accordi applicabili con i responsabili del trattamento ai sensi del GDPR disciplinano generalmente la cancellazione o la restituzione dei dati e il supporto agli audit.

Le fonti primarie collegate supportano queste affermazioni; nessuna dimostra che un determinato fornitore sia sicuro.

Presupposti

Questo quadro presuppone una piattaforma SaaS di negoziazione multi-tenant che tratta dati commerciali e identificativi sensibili. Presuppone inoltre che alcune implementazioni utilizzino IA generativa, servizi di ottimizzazione o di raccomandazione. Un’implementazione privata, a tenant singolo o on-premises potrebbe richiedere un insieme di prove diverso.

Stime

Dagli standard citati non è possibile calcolare la probabilità di una violazione, un punteggio di sicurezza universale o un periodo di conservazione universalmente sicuro. Gli obiettivi di ripristino, i periodi di conservazione e la durata dei log devono essere scelti in base al contesto dell’acquirente.

Raccomandazioni

Considerate l’isolamento un controllo obbligatorio; documentate i cicli di vita dei dati; testate i confini delle autorizzazioni; richiedete log esportabili; inserite nel contratto gli impegni accettati. Sono raccomandazioni, non conclusioni secondo cui ogni organizzazione debba attuarle nello stesso modo.

Dove l’approvazione umana responsabile resta obbligatoria

La sicurezza della negoziazione con IA è una responsabilità di governance, non l’esito automatizzato di un questionario. Le persone responsabili devono decidere:

• Se la piattaforma può trattare informazioni privilegiate, regolamentate, soggette a controlli sulle esportazioni o altamente riservate
• Se i rapporti di garanzia coprono il prodotto, le funzionalità, la regione e i sub-responsabili dell’implementazione acquistata
• Quali periodi di conservazione ed eccezioni per obblighi legali siano accettabili
• Se le chiavi gestite dal fornitore o l’infrastruttura condivisa comportino un rischio residuo tollerabile
• Chi può approvare l’accesso privilegiato e di emergenza del personale di assistenza
• Se sia giustificata un’eccezione alla separazione dei compiti
• Se le raccomandazioni dell’IA possano orientare, ma mai autorizzare, prezzi, condizioni, aggiudicazioni o impegni rilevanti
• Se un incidente richieda una notifica ai dirigenti, ai clienti, ai legali o alle autorità di regolamentazione
• Chi accetta ogni eccezione contrattuale o tecnica irrisolta

Gli strumenti di sicurezza possono raccogliere prove e segnalare lacune. Non possono assumersi la responsabilità dell’accettazione del rischio.

Limiti di questo quadro

Questa checklist non è un metodo di certificazione. Gli audit esterni sono circoscritti dal loro ambito e dal periodo di revisione. I test di penetrazione forniscono prove riferite a un determinato momento. La crittografia non impedisce l’uso improprio autorizzato né la compromissione degli endpoint. I log sono utili solo se gli eventi importanti vengono registrati e riesaminati. La cancellazione dall’archiviazione attiva non implica la distruzione immediata dei backup immutabili.

I requisiti variano inoltre in base alla giurisdizione, al settore, alla categoria di dati, al modello di hosting e al rapporto tra titolare e responsabile del trattamento. Gli ambienti altamente regolamentati o di sicurezza nazionale potrebbero richiedere controlli ulteriori rispetto a quelli descritti in questo articolo. Al contrario, le domande sull’isolamento dei tenant potrebbero essere meno pertinenti per un’installazione realmente dedicata, anche se occorre comunque valutare l’isolamento di ambienti, amministratori e reti.

Domande frequenti

Un rapporto SOC è sufficiente per approvare la sicurezza di una piattaforma di negoziazione?

No. Può fornire preziose garanzie indipendenti, ma gli acquirenti dovrebbero verificare il periodo e l’ambito del rapporto, le eccezioni, i sub-responsabili, le funzionalità del prodotto e le regioni di distribuzione. Restano necessarie prove specifiche del prodotto relative ad architettura, configurazione e test.

I dati delle negoziazioni dovrebbero essere usati per addestrare un modello di IA?

Solo se l’uso è esplicitamente compreso e autorizzato. Chiedete se prompt, allegati, output, feedback o dati derivati vengono usati per l’addestramento dei modelli o per migliorare il prodotto. Richiedete che la risposta sia inserita in condizioni vincolanti e, ove opportuno, ottenete l’approvazione dei responsabili di privacy, sicurezza, legale e business.

Qual è il controllo più importante per la sicurezza della negoziazione con IA?

Non esiste un unico controllo valido in ogni situazione. L’isolamento dei tenant è fondamentale nei servizi SaaS condivisi, ma autorizzazioni deboli, conservazione poco chiara, log inaccessibili o sub-responsabili non governati possono, ciascuno per conto proprio, creare rischi inaccettabili. Trattate i controlli obbligatori come condizioni vincolanti, non come componenti compensabili di un punteggio.

Come dovrebbero comportarsi gli acquirenti se un fornitore non può divulgare i risultati dettagliati dei test?

Richiedete prove alternative: un rapporto esecutivo redatto, un’attestazione del revisore, una revisione controllata, una dimostrazione dal vivo della configurazione o un impegno contrattuale a porre rimedio. Documentate ciò che resta ignoto. Spetta al responsabile del rischio dell’acquirente, non al fornitore, decidere se l’incertezza residua sia accettabile.

Approfondimenti

• NIST Cybersecurity Framework 2.0
• NIST SP 800-53: controlli di sicurezza e privacy
• CISA: principi e approcci per la sicurezza per progettazione e per impostazione predefinita
• Indicazioni FTC sulla sicurezza informatica dei fornitori

Avvertenza: questo articolo fornisce informazioni generali sugli acquisti e sulla sicurezza; non costituisce consulenza legale, in materia di privacy o sicurezza informatica, né consulenza finanziaria.