Guida alla decisione: scegliere un fornitore di servizi IT in base a criteri di rischio, conformità e sicurezza

Chi deve selezionare fornitori IT non decide solo su tariffe giornaliere e disponibilità, ma anche sull’ampliamento della propria superficie di attacco, sugli obblighi di dimostrazione a fini regolamentari e sulla velocità con cui Lei potrà tornare operativo in caso di incidente. In molte aziende i fornitori diventano di fatto co-gestori: amministrano sistemi, spostano dati, configurano meccanismi di sicurezza e influenzano i processi operativi. Proprio per questo una «buona impressione nel pitch» non basta.

Questo contributo è pensato come ausilio decisionale per la direzione IT, la sicurezza delle informazioni (ISMS), la protezione dei dati, la compliance e la direzione aziendale. Mostra un approccio praticabile per valutare i fornitori basandosi sul rischio: quali evidenze sono sensate, quali controlli sono imprescindibili, come impostare governance e responsabilità, e come evitare trappole tipiche (subfornitori, accesso ai log, exit, catene di prova). L’obiettivo è una decisione di selezione che regga in sede di audit e non generi sorprese in esercizio.

1) Ausgangspunkt: Was bedeutet «Risiko» bei IT-Dienstleistern konkret?

Nel contesto dei fornitori il rischio non è astratto, ma molto concreto: si tratta della combinazione tra probabilità di accadimento e impatto su riservatezza, integrità e disponibilità (triade CIA). In aggiunta conta la verificabilità: può Lei dimostrare che i controlli esistono e sono efficaci?

Per la valutazione è utile una chiara separazione in quattro domini di rischio:

• Rischio dei dati: quali dati elabora il fornitore (dati personali, riservati, segreti commerciali)? Dove sono archiviati, come vengono cifrati, chi ha accesso?
• Rischio di accesso e operativo: il fornitore ottiene accesso admin, accesso shell, accesso VPN o solo accesso basato su ticket? Sono previsti accessi di emergenza? Le modifiche vengono effettuate secondo il change management?
• Rischio della catena di fornitura: subfornitori (p.es. cloud provider, catene di supporto), trasferimenti di sede, dipendenze, strumenti proprietari, barriere all’uscita.
• Rischio di compliance e audit: DSGVO, regole di settore, policy interne, conservazione, registrazione, obblighi di documentazione, diritti di ispezione.

Una decisione di selezione solida presuppone che Lei descriva per prima cosa in modo preciso il uso previsto del fornitore: sistemi, classi di dati, privilegi, finestre operative, RTO/RPO (tempo di ripristino/punto di ripristino) e interfacce organizzative. Senza questa delimitazione ogni assessment risulterà o troppo morbido («tutto è importante») o troppo rigido («tutto è vietato»).

2) Risikoklassifizierung vor dem Screening: Tiering statt Bauchgefühl

Nella pratica si è dimostrato utile un Tiering (classificazione in livelli di criticità), che regola lo sforzo per la due diligence e le clausole contrattuali. In questo modo si evita di attivare l’intera macchina di audit per ogni piccolo contratto di supporto – e contemporaneamente si garantisce che i partner critici non sfuggano al controllo.

Proposta per 4 Tier (adattabili)

• Tier 1 – Critico: accessi Admin/Root, reti vicine alla produzione, trattamento di dati sensibili, esercizio di processi critici, impatti significativi in caso di indisponibilità.
• Tier 2 – Alto: accesso a sistemi importanti o a grandi volumi di dati, ma con limitazioni (es. solo tramite jump-host, ambito rigorosamente separato).
• Tier 3 – Medio: accesso limitato, prevalentemente attività di consulenza/progetto, trattamento dati ridotto.
• Tier 4 – Basso: nessun o minimo trattamento dei dati, nessun accesso ai sistemi produttivi (es. formazione).

Un Tiering non dovrebbe basarsi solo su „Cloud vs. On-Prem“, ma su privilegi, classi di dati e responsabilità operative. Un amministratore esterno nella rete interna è spesso più rischioso di un servizio SaaS con un modello di tenant pulito e evidenze chiare.

3) Domanda centrale nel processo di selezione: quale modello operativo assumete voi internamente – e cosa delegate realmente?

Molti conflitti successivi nascono da aspettative poco chiare: „Managed“ non significa automaticamente 24/7, non significa automaticamente applicazione di patch, né automaticamente test di backup-RESTore. Per questo il modello operativo deve essere descritto in linguaggio operativo prima della chiusura del contratto.

Definizione pratica: RACI e artefatti operativi

RACI assegna ruoli: Responsible (esecutore), Accountable (responsabile ultimo), Consulted (consultato), Informed (informato). Per gli audit è particolarmente importante che «Accountable» rimanga chiaramente definito, anche quando un fornitore agisce operativamente.

Artefatti che dovRESTe richiedere in modo vincolante ai fornitori critici:

• Manuale operativo / Runbooks (procedure routinarie e di emergenza)
• Processo di change inclusivo di regole di approvazione e rollback
• Percorsi di monitoraggio e allertamento (incl. reperibilità)
• Piano di backup e RESTore (incl. evidenze dei test)
• Patch e Vulnerability Management (cicli, eccezioni, approvazioni del rischio)
• Gestione degli incidenti incl. evidence (salvaguardia delle prove) e matrice di comunicazione

4) Compliance e prove: quali documenti sono davvero utili?

La compliance viene spesso confusa con la «carta». Ciò che conta è se le prove sono verificabili e coerenti con lo scope. Un certificato ISO 27001 può essere prezioso – ma senza verifica dello scope dice poco. Un report SOC 2 (Tipo II) può essere molto utile – ma solo se i controlli corrispondono al vostro rischio e le eccezioni (Exceptions) sono comprese e affrontate.

Prove che nella pratica hanno sostanza

• Evidenze ISMS: ISO 27001 (scope, Statement of Applicability), policy interne, trattamento del rischio.
• SOC 2 Tipo II: periodo, Trust Services Criteria verificati, findings/exceptions, organizzazioni subservice.
• Prove di penetration test / vulnerability management: frequenza, scope, gestione dei findings (senza che dobbiate necessariamente ricevere i report dettagliati).
• Documentazione sulla protezione dei dati: AVV (elaborazione per conto), TOMs (misure tecniche e organizzative), elenco dei sub-processori, piano di cancellazione e RESTituzione.

Importante: „Wir erfüllen DSGVO“ non è una dichiarazione. Per la GDPR servono elementi concreti: AVV, finalità, categorie delle persone interessate, tipologie di dati, termini di cancellazione, misure tecniche, trasferimenti internazionali (es. clausole contrattuali standard) e una gestione solida dei subfornitori.

5) Criteri di sicurezza per la selezione: controlli che contano in esercizio

Per la decisione di selezione dovreste formulare i criteri di sicurezza in modo che possano essere poi operacionalizzati. Invece di «alta sicurezza» servono requisiti verificabili. Di seguito le famiglie di controllo che nelle relazioni con i fornitori risultano regolarmente decisive.

Identità e accessi privilegiati (IAM/PAM)

IAM (Identity and Access Management) regola identità, ruoli e autorizzazioni. PAM (Privileged Access Management) governa gli accessi amministrativi particolarmente potenti, idealmente limitati nel tempo e tracciabili.

• Utenti individuali invece di account condivisi
• MFA (autenticazione a più fattori) obbligatoria
• Just-in-Time/Just-Enough-Access, dove possibile
• Accesso tramite Jump-Hosts/Bastion, niente login amministrativi diretti da Internet
• Session Recording o almeno audit log dettagliati per azioni privilegiate

Domanda di verifica: In caso di incidente potete dimostrare chi quando cosa ha fatto, e potete revocare accessi nell’arco di pochi minuti?

Reti e separazione dei tenant

Soprattutto nei Managed Services la segmentazione è decisiva: reti separate per management, produzione, backup, logging; regole firewall chiare; e un regolamento documentato per le eccezioni. L’isolamento dei tenant è centrale per i fornitori SaaS: separazione logica (Tenant-Isolation), cifratura e protezione contro fuoriuscite di dati dovute a errata configurazione.

Gestione delle vulnerabilità e delle patch

Per la selezione e il contratto conta meno il «turno di patch» che la capacità di gestire i rischi: come viene prioritizzato (critico/alto/medio), come vengono documentate le eccezioni, come avviene la compensazione (es. regole WAF, isolamento), e con quale rapidità si possono applicare hotfix.

Una prova semplice ma efficace è un’esportazione regolare dal processo ticket/vulnerability (anonimizzata) che mostri: ingresso, valutazione, scadenza, attuazione, review.

Logging, monitoring, capacità forense

Qui si decide la prontezza all’audit: senza log affidabili (timestamp, protezione dell’integrità, conservazione) gli incidenti restano materia di opinioni. Per i fornitori è particolarmente delicato se i log risiedono presso il fornitore, mentre voi come cliente avete l’onere della prova.

• Fonti di log definite (auth, azioni admin, modifiche di sistema, accessi API)
• Archivio centrale con concetto di accesso (principio del minimo privilegio)
• Termini di conservazione adeguati alla normativa e alle policy interne
• Integrità (protezione contro la manomissione) e sincronizzazione temporale (NTP)

6) Protezione dei dati e sovranità dei dati: AVV è solo l’inizio

Nella scelta del fornitore la protezione dei dati viene spesso ridotta al solo AVV. Questo è rischioso, perché le questioni critiche risiedono nell’implementazione tecnica: dove vengono elaborati i dati, come vengono cifrati, come avviene la cancellazione e come viene gestita la RESTituzione dei dati in caso di exit?

Requisiti concreti che dovRESTe documentare

• Localizzazione dei dati: regioni/centri dati, trasferimenti internazionali, basi giuridiche.
• Crittografia: in transito (TLS) e a riposo; gestione delle chiavi (KMS), accesso alle chiavi.
• Backup: contengono dati personali? Come vengono cancellati i backup? Quale retention si applica?
• Richieste dell’interessato (Data Subject Requests): supporto per accesso/cancellazione/esportazione, termini e processo.
• Modello dei ruoli: chi è il Titolare, chi il Responsabile del trattamento, chi il sub-responsabile?

Se avete requisiti severi (p. es. chiavi sotto il vostro controllo, „Bring Your Own Key“), tali requisiti devono essere inseriti prima della selezione nei criteri obbligatori. Successivamente questi punti sono spesso costosi o tecnicamente non realizzabili.

7) Subfornitori e catena di fornitura: il punto cieco nella gestione dei fornitori

Molti rischi non nascono dal partner selezionato, ma nella catena: cloud hosting, NOC 24/7, team di sviluppo esterni, supporto in altre giurisdizioni. I subfornitori non sono di per sé negativi – ma devono essere trasparenti, verificabili e coperti contrattualmente.

Cosa dovRESTe esigere

• Elenco aggiornato dei subfornitori con percentuali di servizio e accessi ai dati
• Processo di modifica: comunicazione preventiva e diritti di opposizione o di risoluzione del contratto in caso di modifiche critiche
• Clausole di „flow-down“: i requisiti di sicurezza e protezione dei dati si applicano lungo tutta la catena
• Diritti di accesso alle evidenze rilevanti (es. report SOC dell’organizzazione del subfornitore)

8) Logica contrattuale e SLA: i requisiti di sicurezza devono diventare misurabili

I contratti raramente falliscono per un paragrafo mancante, ma per aspettative non misurabili. Le SLA (Service Level Agreements) descrivono gli obiettivi di servizio (es. disponibilità, tempi di risposta). Le OLA (Operational Level Agreements) sono accordi interni/operativi tra team o tra unità del fornitore che rendono le SLA effettivamente realizzabili.

Componenti tipiche delle SLA che dovRESTe concretizzare

• Classificazione degli incidenti: definizioni P1/P2/P3 basate sull’impatto sul business
• Tempi di reazione e di ripristino: non solo „Response“, ma „RESTore“
• Finestra per le modifiche: Standard vs. Emergency Changes, obbligo di documentazione
• SLA di sicurezza: Tempi per la risoluzione delle vulnerabilità critiche, cicli di patch, regole per eccezioni
• Reporting: report di servizio mensili con indicatori definiti e analisi delle deviazioni

Importante dal punto di vista dell’audit: se formalizzate contrattualmente i controlli di sicurezza, serve anche una routine di misurazione e dimostrazione. Altrimenti si crea una discrepanza tra contratto e realtà.

9) Prospettiva dell’audit: cosa gli auditor tipicamente vogliono vedere

Gli audit raramente verificano singoli dettagli tecnici, ma la governabilità: esiste una procedura, le decisioni sono documentate, le responsabilità sono chiare e i controlli sono efficaci. Per i rapporti con fornitori molte verifiche si riducono a tre domande:

• I rischi sono stati valutati prima dell’incarico? (Due Diligence, Tiering, autorizzazioni)
• I controlli sono operativi e sanciti nel contratto? (SLA, requisiti di sicurezza, protezione dei dati, subfornitori)
• Potrete dimostrare l’efficacia? (report, log, test, protocolli di revisione)

Essere auditabile non significa „documentazione pesante“. Significa: decisioni tracciabili, documentare in modo sintetico, conservare le evidenze centralmente e condurre review regolari.

10) Lista di controllo pratica: domande di Due-Diligence che aiutano realmente nella selezione

La lista che segue è pensata come nucleo pragmatico. Non sostituisce un’analisi del rischio personalizzata, ma copre i criteri decisionali tipici che in seguito saranno rilevanti in esercizio e per l’audit.

A) Ambito e accesso

• Quali sistemi/ambienti rientrano nell’ambito (Prod/Stage/Dev)?
• Quali tipologie di accesso (VPN, jump host, API, solo ticket) sono necessarie?
• Come vengono concessi, registrati e revocati gli accessi privilegiati?

B) Controlli di sicurezza

• Quali standard minimi si applicano (MFA, policy delle password, hardening, EDR/AV)?
• Come viene gestito il patch/vulnerability management, incl. prioritizzazione ed eccezioni?
• Come viene implementato il logging, chi ha accesso e quale retention è applicata?

C) Protezione dei dati e gestione dei dati

• AVV/TOMs: sono aggiornati e coerenti con il processo effettivo?
• Localizzazione dei dati, subfornitori, trasferimenti internazionali: descritti in modo chiaro?
• Cancellazione, RESTituzione e retention dei backup: attuabili operativamente?

D) Esercizio, resilienza, emergenza

• Monitoring e on-call: orari, vie di escalation, canali di comunicazione?
• Backup/RESTore: i RESTore vengono testati e documentati?
• BCM/DR: ci sono test e quali sono stati gli ultimi risultati?

E) Governance e evidenze

• Quali attestazioni (ISO/SOC) sono disponibili e quale ambito coprono?
• Come vengono documentati change, incident e review?
• Esiste un diritto di verifica e come viene esercitato praticamente (es. audit remoto, accesso ai report)?

11) Approccio scorecard: rendere la decisione trasparente (senza falsa precisione)

Una scorecard aiuta a rendere comparabili più fornitori e a motivare le decisioni nei confronti della direzione, della revisione o della protezione dei dati. Importante: nessuna falsa precisione. Usate pochi criteri, pesature chiare e documentate le deviazioni con misure compensative.

Proposta di ponderazione (esempio)

• 30% Sicurezza & controllo degli accessi
• 25% Operatività & resilienza (RTO/RPO, runbook, on-call)
• 20% Conformità & evidenze (ISO/SOC/AVV, auditabilità)
• 15% Catena di fornitura & controllo dei subfornitori
• 10% Fattori commerciali (modello di costo, trasparenza, flessibilità)

Per i fornitori Tier-1 dovrebbero esistere criteri obbligatori che non possono essere „compensati“ (es. MFA, account individuali, AVV per dati personali, clausola di exit, logging). Se un criterio obbligatorio non è soddisfatto, il fornitore viene escluso oppure è necessaria una deroga formale di rischio approvata con compensazione.

12) Pianificazione dell’exit e delle emergenze: criterio di selezione, non un pensiero finale

Exit suona come la fine del contratto, ma è una leva per la sicurezza e l’operatività: cosa succede in caso di insolvenza, incidente grave, contenzioso, blocco regolamentare o cambio strategico? Senza un piano di exit aumenta il rischio di lock-in e in emergenza manca il tempo per trasferire correttamente dati e know-how.

Elementi che vanno inclusi nella selezione e nel contratto

• Restituzione dei dati: formati, completezza, finestra temporale, responsabilità
• Conferma di cancellazione: inclusi backup/copie di archivio (nella misura tecnicamente possibile, descritto in modo trasparente)
• Consegna della documentazione: runbooks, architettura, configurazioni, inventario di chiavi/certificati
• Supporto alla transizione: ore/contingenti definiti, attività prioritarie, accesso per il subentrante
• Exit d’emergenza: risoluzione straordinaria, accesso a sistemi/log, blocco delle modifiche

Dal punto di vista operativo è particolarmente importante che non riceviate solo i „dati“, ma anche la capacità operativa: configurazioni, modelli di accesso, setup di monitoraggio e procedure di ripristino.

13) Blocchi sorgente pratici: modelli per policy e comandi di verifica

Gli esempi seguenti sono volutamente generici e devono essere adattati al vostro ambiente. Potete usarli come punto di partenza per policy interne, requisiti per i fornitori o controlli di audit.

Modello di policy: requisiti minimi per l’accesso dei fornitori

POLICY: Accesso di terze parti ai sistemi IT (requisiti minimi)

1. Identità
- Solo account utente individuali, nessun account condiviso.
- MFA obbligatorio per tutti gli accessi esterni.
- Autorizzazioni basate sui ruoli (Least Privilege), diritti amministrativi temporanei limitati (Just-in-Time).

2. Vie di accesso
- Accessi amministrativi esclusivamente tramite Jump-Hosts/Bastion definiti o soluzione PAM.
- Nessun accesso amministrativo diretto da Internet.
- Accesso solo da reti/fonti autorizzate (Allowlist), nella misura praticabile.

3. Registrazione
- Autenticazione, azioni privilegiate e modifiche di configurazione vengono registrate centralmente.
- I log sono protetti contro la manomissione e vengono conservati in conformità alle policy di retention.

4. Onboarding/Offboarding
- Processo di approvazione prima della configurazione, incl. ticket e responsabile.
- Deprovisioning entro i tempi definiti dopo cambio ruolo/fine progetto.

5. Eccezioni
- Eccezioni solo con valutazione del rischio documentata, data di scadenza e misure compensative.

Comandi di verifica (esempi): tracciabilità degli accessi amministrativi su Linux

Per molti ambienti è importante che le azioni privilegiate siano tracciabili. I seguenti controlli aiutano a verificare le basi tipiche (Auditd/Journal/Sudo). Non costituiscono una verifica completa della sicurezza, ma una verifica rapida in fase di onboarding o review.

# Verificare se le azioni sudo vengono registrate (percorsi di esempio a seconda della distribuzione)
sudo grep -R "^Defaults" /etc/sudoers /etc/sudoers.d 2>/dev/null | head

# Ultimi eventi sudo (se acquisiti tramite journald)
sudo journalctl -u sudo --since "7 days ago" 2>/dev/null | tail -n 50

# Verificare se auditd è attivo
sudo systemctl status auditd --no-pager

# Mostrare le regole di audit (se viene utilizzato auditd)
sudo auditctl -l 2>/dev/null | head -n 50

Importante per la valutazione di un fornitore è meno quale strumento venga utilizzato e più se il vostro obiettivo sia raggiunto: tracce di audit immutabili, centralizzate e analizzabili per le azioni rilevanti.

14) Valutare realisticamente costi e sforzi: la sicurezza non è gratuita, l’insicurezza costa di più

La selezione basata sul rischio fa risparmiare denaro quando evita che acquistiate «a buon mercato» nel posto sbagliato. Tipici blocchi di costo che vengono sottostimati nei business case:

• Costi di transazione: onboarding, Due Diligence, revisione contrattuale, integrazioni degli strumenti
• Costi di controllo: revisioni, report, audit, pen-test, ricertificazione degli accessi
• Costi per incidenti: analisi forense, fermo operativo, comunicazione con i clienti, notifiche regolamentari
• Costi di lock-in: progetto di exit, migrazione dei dati, trasferimento di conoscenze

Un approccio pragmatico: pianificate i fornitori Tier-1 come se fossero sistemi critici interni. Questo non significa «fare tutto internamente», ma garantire la governabilità: ruoli chiari, indicatori di misura chiari, evidenze chiare.

15) Governance nella pratica: chi decide cosa – e chi assume quali responsabilità?

La governance dei fornitori funziona solo se viene applicata nella pratica quotidiana. Ciò richiede rituali fissi e responsabilità chiare ed inequivocabili:

• Service Owner sul lato cliente: responsabile tecnico/operativo, valuta i report, gestisce il backlog
• Security/Compliance: definisce i controlli obbligatori, verifica le deviazioni, approva le eccezioni
• Protezione dei dati: valuta i flussi di dati, AVV/TOMs, trasferimenti, piani di cancellazione
• Provider Manager (o Procurement/Legal): gestione contrattuale e delle escalation
• Operazioni IT: integra monitoring, logging, backup, change, processi on-call

Si sono dimostrati efficaci Service Review trimestrali (SLA, Incidents, Changes, Security Findings) e un Re-Assessment annuale per Tier-1/2. Non come formalità, ma come momento per porre domande difficili: sono cambiati ambito, subfornitori, classi di dati o modelli di accesso?

Fazit: IT-Dienstleister auswählen heißt steuerbare Risiken einkaufen

Una buona decisione di selezione nasce da un principio semplice: quanto maggiore è l’accesso e più critici sono i dati o la responsabilità operativa, tanto più stringenti devono essere le evidenze, i controlli e le regole di exit.

Se combinate correttamente Tiering, Scorecard e criteri obbligatori, eviterete due estremi: requisiti eccessivi per fornitori non critici e lacune pericolose con partner critici.

Puntate su criteri verificabili (IAM/PAM, logging, processi di patch, controllo dei subfornitori), ancorateli contrattualmente in modo misurabile (SLA/Security SLAs) e pianificate fin dall’inizio exit e consegne di emergenza. Così la gestione dei fornitori sarà meno basata sull’intuito e più una disciplina auditabile e operativamente sostenibile.

Per questo tema sono importanti anche la gestione del rischio dei fornitori terzi e la gestione dei fornitori IT. Il contributo inquadra in modo comprensibile questi aspetti e indica gli elementi rilevanti nella pratica quotidiana.