Procurement Cybersecurity Policy (Template)
1) Scopo e ambito
Questa policy definisce come l’organizzazione acquista (o rinnova) prodotti/servizi/processi ICT in modo coerente con il rischio, assicurando requisiti minimi, criteri di criticità, soglie decisionali e un processo di deroga tracciabile.
Compilare i campi tra parentesi quadre: [Azienda], [Owner], [Date], [RTO/RPO], ecc.
2) Definizioni
- ICT (in questa policy): prodotti, servizi e processi tecnologici (on-prem, cloud, managed service, outsourcing).
- Fornitore: vendor, system integrator, MSP/MSSP, subfornitore rilevante, piattaforme SaaS/PaaS/IaaS.
- Deroga (eccezione): approvazione formale a deviare da un requisito (es. certificazione/preferenze, clausole contrattuali, assessment).
- Risk acceptance: accettazione documentata del rischio residuo con owner e scadenza di revisione.
3) Criteri di criticità e soglie
Obiettivo: decidere “quanto è critico” l’acquisto prima di scegliere requisiti, livello di due diligence e firme necessarie.
3.1 Criteri di criticità (scorecard rapida)
- Identità e accessi: il bene/servizio gestisce autenticazione, privilegi, directory, chiavi, certificati?
- Dati: tratta dati sensibili/strategici o dati di clienti/utenti? Volume e criticità.
- Continuità: impatta servizi core e obiettivi
[RTO/RPO]? - Esposizione: è Internet-facing, o integrato con ambienti produttivi/OT?
- Sostituibilità: quanto è sostituibile in tempi brevi (lock-in/monopolio tecnologico)?
- Supply chain: dipende da subfornitori critici o da componenti non trasparenti?
3.2 Livelli di criticità (classificazione)
| Livello | Definizione sintetica | Esempi tipici | Richieste minime |
|---|---|---|---|
| CRITICO | Impatta identità, rete core, dati critici, continuità dei servizi essenziali. | IAM/SSO, firewall, SIEM, EDR, cloud core, backup “enterprise”, piattaforme di produzione. | Due diligence approfondita + clausole contrattuali estese + approvazioni multi-firma + piano di exit. |
| ALTO | Impatto rilevante su operations e resilienza; rischio medio-alto verso terzi. | Email/collaboration, VPN, ticketing, monitoring, SaaS business-critical. | Due diligence standard + clausole contrattuali minime + approvazione Security + vendor register completo. |
| MEDIO | Impatto limitato; sostituibile; dati non critici. | Tool dipartimentali, servizi non-core, utility. | Baseline vendor check + requisiti contrattuali base. |
| BASSO | Impatto trascurabile; basso rischio; facile sostituzione. | Tool offline, commodity software non integrato, licenze marginali. | Best effort + tracciamento acquisto (minimo). |
- CRITICO: richiede approvazione CISO + CRO/ERM + CEO (o Board delegate) entro
[X]giorni. - ALTO: approvazione CISO + Procurement Head entro
[X]giorni. - MEDIO/BASSO: Procurement Head con consultazione Security “se necessario”.
4) Requisiti minimi e contrattuali
4.1 Requisiti minimi (per CRITICO e ALTO)
- Security posture verificabile: evidenze (assessment, attestazioni, audit, report) secondo policy interna.
- Vulnerability & patch: SLA patching (es. Critical entro 30 giorni) e canale di comunicazione vulnerabilità.
- Incident notification: obbligo di notifica al cliente entro
[X]ore se l’evento impatta i servizi acquistati. - Logging & auditability: capacità di audit e tracciabilità coerenti con la criticità del servizio.
- Subfornitori: trasparenza su subprocessor/subcontractor rilevanti e limiti al cambio non notificato.
- Exit plan: requisiti minimi di portabilità dati/config e tempi di uscita.
4.2 Clausole contrattuali (mini-set)
- Diritto di audit (o audit report indipendente) per CRITICO/ALTO.
- Obblighi di security-by-design, hardening e change management.
- Data residency/backup e protezioni (se applicabile).
- Penali/azioni correttive se non rispetta requisiti minimi (remediation plan con scadenze).
Nota: evitare requisiti “impossibili da verificare”. Ogni requisito deve avere una evidenza e un owner interno.
5) Flusso deroghe (eccezioni)
Le deroghe sono consentite solo con motivazione documentata, controlli compensativi e una data di revisione (non oltre 12 mesi).
5.1 Flusso (step-by-step)
- Richiesta: Procurement apre ticket “Deroga” con motivazione e criticità (CRITICO/ALTO/MEDIO/BASSO).
- Valutazione Security: CISO (o delegate) definisce rischio e controlli compensativi.
- Decisione: approvazioni secondo soglia (CRITICO: CISO+CRO+CEO; ALTO: CISO+Procurement Head).
- Condizioni: remediation plan (azioni e scadenze), limitazioni di scope, monitoraggio rafforzato, exit readiness.
- Chiusura: deroga chiusa quando requisito soddisfatto o quando sostituito il fornitore/servizio.
5.2 Modulo deroga (campi minimi)
- ID deroga, data apertura, scadenza revisione.
- Oggetto acquisto + livello criticità + motivazione.
- Requisito derogato (es. clausola, evidenza, assessment, preferenza certificazione).
- Rischio residuo sintetico + impatti (servizi, dati, terzi).
- Controlli compensativi + owner + scadenze.
- Firme (ruoli) + data decisione.
6) KPI per il Board (mensile/trimestrale)
| KPI | Definizione | Target | Owner |
|---|---|---|---|
| % acquisti CRITICO con due diligence completata | Quota di acquisti CRITICO con assessment + contratto conforme prima del go-live. | ≥ 95% | CISO / Procurement |
| % rinnovi CRITICO/ALTO “contratto aggiornato” | Rinnovi con clausole cyber minime aggiornate negli ultimi 12 mesi. | ≥ 85% | Procurement Head |
| Deroghe aperte > 6 mesi | Numero di deroghe vecchie senza remediation plan efficace. | ≤ 3 | CISO |
| Tempo medio decisione deroga | Tempo tra richiesta completa e decisione finale. | ≤ 5 giorni (CRITICO) | CISO / CRO |
| Incidenti attribuibili a fornitori ICT | Incidenti con root cause primaria su vendor/servizio acquistato. | 0 (o trend decrescente) | CISO |
Suggerimento governance: presentare al Board anche le “Top 5 deroghe” (rischio + piano + data chiusura) e le “Top 5 dipendenze vendor”.
7) Ruoli e responsabilità
- CEO / Direzione: approva soglie, presiede risk acceptance CRITICO, rimuove blocchi in caso di urgenze.
- CISO / Security: definisce requisiti minimi, conduce valutazioni, decide compensating controls, reporting KPI.
- CRO / ERM (se presente): valida risk acceptance e coerenza con risk appetite.
- Procurement: applica la policy, garantisce clausole, mantiene vendor register e ciclo rinnovi.
- IT Owner / Service Owner: definisce criticità tecnica, integra controlli (logging, accessi, backup) e gestisce exit plan.
- Legal: valida clausole (audit rights, liability, incident notification, subfornitori) e supporta dispute.
8) Revisione e audit trail
- Revisione: almeno annuale e dopo incidenti significativi o cambi rilevanti di supply chain.
- Audit trail minimo: vendor register, assessment, contratti, deroghe firmate, remediation plan, report KPI.
- Conservazione: per
[X]anni secondo policy interna e requisiti regolatori applicabili.
Riferimenti (da adattare al contesto e alla trasposizione nazionale): NIS2 (Art. 24 e collegamenti con Art. 21), framework UE di certificazione cybersecurity, pratiche di cybersecurity supply chain risk management.






