Prodotto · Policy

Nove policy editabili, distribuite e firmate.

Template scritti da un Lead Auditor BSI, variabili compilate una sola volta, adozione con approvalHash firmato, distribuzione ai dipendenti con proof-of-presence, revisione annuale guidata. Niente foglio bianco, niente cartelle SharePoint con versioni che si sovrascrivono.

§01 · Le nove policy corecopertura Art. 21 NIS2

Nove policy che coprono i requisiti policy-related dell'Art. 21.

Le abbiamo selezionate non per essere complete, ma per essere quelle che l'auditor effettivamente chiede al primo giro: cosa devi avere scritto e adottato per non bloccarti su un controllo obbligatorio. Sono editabili: parti dal nostro testo, lo adatti alla tua realtà.

P01

Sicurezza delle informazioni

Politica generale di sicurezza, ambito di applicazione, ruoli e responsabilità, principi guida. È la policy ombrello che le altre referenziano.

P02

Controllo degli accessi

Gestione delle utenze, principio del minimo privilegio, autenticazione multi-fattore, revoca tempestiva al turn-over. Copre Art. 21.i NIS2 (controllo accessi).

P03

Backup e ripristino

Strategia 3-2-1, frequenza dei backup, test di ripristino periodici, RPO/RTO, conservazione off-site. Copre Art. 21.c (continuità) lato dati.

P04

Gestione degli incidenti

Classificazione degli incidenti, escalation, ruoli del crisis team, comunicazione interna ed esterna, notifica ACN. Copre Art. 21.b + Art. 23 NIS2.

P05

Continuità operativa (BCP)

Scenari di crisi, RTO/RPO per servizi critici, piano di continuità, esercitazioni periodiche, ruoli del team di crisi. Copre Art. 21.c NIS2.

P06

Acquisizione e sviluppo sicuro

Sicurezza nel ciclo di sviluppo software, gestione delle vulnerabilità, patch management, change management. Copre Art. 21.e + 21.f NIS2.

P07

Sicurezza dei fornitori

Selezione e qualifica fornitori critici, clausole contrattuali NIS2/GDPR, DPA, audit di filiera, monitoraggio della supply chain. Copre Art. 21.d NIS2.

P08

Dispositivi e mobilità (BYOD)

Uso di dispositivi aziendali e personali, smarrimento e furto, smartworking, separazione tra dati personali e aziendali. Copre parte di Art. 21.h.

P09

Formazione e consapevolezza

Obbligo formativo annuale dipendenti, formazione organo direttivo, awareness training, modalità di erogazione, conservazione attestati. Copre Art. 21.g NIS2.

§02 · Il ciclo di vita di una policydal template alla revisione

Sei passi dal foglio bianco evitato alla revisione annuale.

Una policy non è un PDF in archivio. È un oggetto vivo che cambia nel tempo, viene adottato formalmente, distribuito alle persone giuste, riconosciuto, e periodicamente rivisto. Comprova gestisce tutto il ciclo, lasciando una traccia per ognuno dei sei passaggi.

  1. Fase 1

    Parti dal template, non dal foglio bianco

    Le 9 policy sono già scritte da un Lead Auditor BSI. Modifichi le sezioni che vuoi adattare alla realtà aziendale (procedure interne, eccezioni, integrazioni con sistemi esistenti). Niente templating in Word, niente caccia ai modelli online.

  2. Fase 2

    Variabili dinamiche compilate una sola volta

    Nome azienda, sede legale, P.IVA, DPO esterno, riferimenti sistemi: tutti i campi variabili sono compilati una volta nelle Impostazioni e propagati automaticamente in tutte le 9 policy. Quando cambi sede, modifichi un campo e tutte le policy si allineano alla revisione successiva.

  3. Fase 3

    Adozione formale con approvalHash

    Quando l'org_admin adotta la policy, il sistema crea uno snapshot immutabile (PolicyAdoption) con un approvalHash SHA-256 firmato. Da quel momento esiste una versione 'adottata il giorno X' che né tu né nessun altro può alterare a posteriori — solo sostituirla con una versione successiva esplicita.

  4. Fase 4

    Distribuzione ai dipendenti

    La policy adottata viene distribuita ai membri dell'organizzazione con notifica email. Ognuno apre la policy, la legge, e dichiara 'ho letto'. Il tasso di copertura è visibile in dashboard. Reminder automatici a chi non ha ancora confermato dopo N giorni.

  5. Fase 5

    Proof-of-presence con timestamp

    L'acknowledgment del dipendente entra come EvidenceFile derivato: dichiarazione + timestamp + ID utente + hash della versione di policy letta. È la prova che l'auditor chiede per il controllo 'policy diffusa al personale': non un'email generica, ma una traccia per dipendente con la versione specifica.

  6. Fase 6

    Revisione annuale guidata

    Il sistema notifica al responsabile compliance N giorni prima della scadenza annuale (default 365 giorni dall'adozione). Apre il workflow di revisione: rileggi, modifichi se serve, riadotti. Lo storico di tutte le versioni precedenti resta tracciabile. L'acknowledgment dei dipendenti si rinnova sulla nuova versione.

§03 · Proof-of-presenceacknowledgment con timestamp

La policy diffusa è una policy provata.

Un controllo NIS2 ricorrente è "la policy è stata diffusa al personale". La risposta più frequente in audit suona così: "sì, l'abbiamo mandata via email a tutti i dipendenti." È una risposta che non regge: l'email può essere stata cancellata, ignorata, finita in spam, ricevuta da chi non era più dipendente. Niente prova oggettiva.

La proof-of-presence di Comprova è un'altra cosa: ogni dipendente, in piattaforma, dichiara "ho letto" in modo esplicito sulla versione specifica della policy. La dichiarazione entra come EvidenceFile derivato con: ID dipendente, ID policy, versione, timestamp, hash. Se l'auditor chiede "chi ha letto la policy P02 versione 1.3 e quando", la risposta è una tabella ordinata.

È lo stesso meccanismo che l'Annex A della ISO 27001 (controllo 6.3) chiede in termini di "awareness, education and training" — l'evidenza non è la formazione fatta, è la traccia che è stata fatta.

§04 · Domande frequenti

Quello che ci chiedono di solito.

Le 9 policy coprono il 100% dei controlli NIS2?
Coprono tutti i requisiti policy-related dell'Art. 21 (controlli a-j). Non coprono i controlli operativi che richiedono evidenze tecniche concrete (es. Art. 21.j MFA — la policy lo prescrive, l'evidenza è il log abilitazione MFA che carichi nel Vault). Il principio è: la policy dice cosa fai, l'evidenza dimostra che lo fai davvero. Ti servono entrambe.
Posso aggiungere policy mie?
Sì, nei piani Importante ed Essenziale. Crei una policy custom partendo da template vuoto o da una delle 9 core, gli dai un nome, la rendi disponibile per adozione. Lo stesso ciclo di vita (adozione → distribuzione → ack → revisione) si applica anche alle policy custom. Il piano Pronto include solo le 9 core, perché il sub-fornitore tipicamente non ha bisogno di altro.
Posso esportare una policy in Word per farla revisionare dall'avvocato?
Sì. Da ogni policy editi/adottata generi un PDF (per la firma) o un export DOCX (per la modifica esterna). Quando l'avvocato ti restituisce la versione modificata, la incolli/importi nel sistema, la riadotti come versione N+1. La cronologia tiene traccia anche di chi ha contribuito esternamente.
Cosa succede se un dipendente non clicca 'ho letto'?
Resta nella lista 'pending' della copertura. L'org_admin vede il numero in dashboard e può inviare reminder mirati. Nessun blocco automatico dell'utenza: in compliance la coercizione tecnica è raramente la risposta giusta — meglio una conversazione mirata. Se la copertura resta bassa nel tempo, è un segnale per l'auditor che il processo formativo va rinforzato.
Le revisioni rompono gli acknowledgment storici?
No, le rendono solo 'parziali'. Esempio: la Policy P01 v1.0 è stata letta da 47/50 dipendenti. Pubblichi la v2.0. I 47 acknowledgment di v1.0 restano validi come prova storica, ma per la copertura corrente parte una nuova fase di acknowledgment su v2.0. L'auditor che chiede 'come è stata distribuita la policy nel tempo' ha la storia completa: v1.0 a maggio 2025, v2.0 a marzo 2026.
Chi può adottare le policy?
Solo il ruolo org_admin (e compliance_owner sui piani Importante/Essenziale). L'adozione è un atto formale che produce uno snapshot immutabile firmato dal nome dell'utente. I MEMBER (dipendenti) possono leggere le policy adottate e darne acknowledgment, ma non modificarle né adottarle. La separazione dei ruoli è esplicita perché è quello che chiede un Lead Auditor in revisione.

Le nove policy si attivano insieme alla Piattaforma.

Sono parte della Piattaforma completa: policy, evidenze, registri rischi, incidenti, fornitori, formazione, audit pack — tutti insieme, su preventivo. Parliamone in call.