Procedura - Vendor due diligence e supply chain (ISMS)

Ultimo aggiornamento: Giugno 2026

Scopo

Valutare, documentare e riesaminare periodicamente i rischi legati a fornitori e subfornitori rilevanti per sicurezza delle informazioni e continuità del servizio, con particolare riferimento alle dipendenze di architettura/erogazione (cloud, identità, intelligenza artificiale, canali di messaggistica, posta elettronica e analoghi elencati in DPA / Annex e in ISMS_Scope).

La procedura si integra con:

• Risk_Register.md, Risk_Assessment_Methodology.md, Risk_Treatment_Plan.md
• Continuous_Improvement.md e il riesame di gestione (ciclo almeno annuale — allineato alla voce “analisi rischio aggiornate annualmente” del questionario tipo ACN e al perimetro Q107)
• Misure di sicurezza — §1.2a (dipendenze AWS e servizi connessi)

Perimetro fornitori (esemplificativo, non esaustivo)

Nel modello operativo tipico rientrano, ove effettivamente in uso:

Categoria	Esempi	Note
Infrastruttura cloud	AWS	Responsabilità condivisa; controlli lato configurazione Flowvenue.
Identità / accesso	Auth0 (OIDC, tenant UE), JWT	Coerente con documentazione API e sicurezza.
Intelligenza artificiale (inferenza platform-managed)	OpenAI (default), Anthropic ove abilitato	DPA / Trust portal; ZDR e residenza UE (OpenAI) come da accordo.
LLM BYOK / endpoint privato	Fornitore scelto dal Cliente	Non sub-responsabile Flowvenue per inferenza; chiavi cifrate AES-256-GCM lato Flowvenue; due diligence Cliente.
Client LLM esterni (MCP)	Ambiente LLM del Cliente (cloud o privato)	Flowvenue espone MCP Server (OAuth PKCE, scope, rate limit); inferenza sul stack Cliente.
Messaggistica	Meta / WhatsApp Business (ove abilitato), Telegram ove integrato	Token e segreti gestiti secondo §1.5 Misure.
Posta / notifiche	Provider email/PEC	Solo per invii transazionali / operativi concordati.

Altri fornitori rilevanti sono inclusi se emergono da offerta, Annex al DPA o da nuove integrazioni: devono seguire lo stesso flusso di onboarding.

Attività — onboarding

1. Identificazione del fornitore come subprocessore o dipendenza tecnica rilevante (dati, disponibilità, integrità).
2. Scheda due diligence iniziale (sicurezza, privacy, legal): questionario, policy, certificazioni pubbliche del fornitore.
3. Valutazione rischio (likelihood/impatto) e aggiornamento Risk_Register / trattamenti dove necessario.
4. Accordi: DPA / sub-responsabilità, clausole di sicurezza, SCC o strumenti equivalenti ove applicabile; NDA ove richiesto per materiali riservati.
5. Owner interno e data del prossimo riesame (vedi sotto).

Attività — valutazione certificazioni e attestazioni

• Per cloud e fornitori critici: verifica di attestazioni pubbliche del fornitore (es. SOC, ISO 27001 del provider, report di conformità pubblicati dal vendor) e coerenza con il modello di responsabilità condivisa.
• Per fornitori senza certificazione equivalente: compensazione tramite contratto, questionario, audit documentale e piano di monitoraggio.

Attività — riesame periodico e allineamento al ciclo annuale (Q107)

1. Almeno annualmente (e comunque in occasione del riesame di gestione / management review ISMS, nonché dopo incidenti o cambi architetturali rilevanti): riesame dell’elenco fornitori, delle schede e dei rischi associati; aggiornamento documentazione e Risk_Register ove serva.
2. Incrocio con esiti VA/PT, audit interni e osservazioni da certificazione esterna.
3. Output: verbale o nota di riesame, aggiornamento versioni procedure/policy ove impattate.

Attività su AWS (fornitori cloud correlati)

1. Verificare allineamento al modello shared responsibility e alla documentazione pubblica §1.2a Misure.
2. Validare regione, residenza dati e controlli disponibili rispetto al contratto con il committente.

Approvazione e governance formale

• Le policy ISMS (es. Information_Security_Policy.md) e le procedure manuali pubblicate in compliance sono soggette a versionamento, revisione e adozione nel perimetro ISMS (vedi anche riesame policy e management review).
• L’introduzione di nuovi fornitori critici o modifiche sostanziali ai flussi dati richiede autorizzazione secondo change management e valutazione rischio documentata.

Esempio pratico

• Nuovo fornitore API: onboarding solo dopo verifica DPA, retention e scheda due diligence; inserimento in registro subprocessori e owner per riesame annuale.

Output

• Scheda due diligence fornitore
• Registro / elenco subprocessori (allineato al DPA)
• Evidenze di riesame (verbale management review, note di aggiornamento registro rischi)

Frequenza

Onboarding obbligatorio prima dell’uso in produzione; riesame almeno annuale e su evento, in coerenza con Continuous_Improvement.md e con il ciclo descritto per l’aggiornamento del profilo di rischio (Q107).