Allegati e moduli operativi

Nome e cognome

_____________________________

Ruolo / qualifica

_____________________________

Data di onboarding

_____________________________

Firma

_____________________________

Dichiarazione

Il/La sottoscritto/a dichiara:

• Di aver ricevuto, letto e compreso il Codice Etico di NexStudio nella sua versione vigente.
• Di impegnarsi a rispettarne i principi, le regole di comportamento e le procedure in esso contenute.
• Di aver ricevuto o di ricevere secondo il piano formativo la formazione obbligatoria su sicurezza informatica, privacy (PDPA e GDPR), gestione dati sensibili, uso responsabile dell’AI e pratiche di coding sicuro.
• Di impegnarsi a segnalare, in buona fede e attraverso i canali previsti, eventuali violazioni del Codice di cui dovesse venire a conoscenza.
• Di essere consapevole che la violazione del Codice può comportare provvedimenti disciplinari proporzionati, fino alla risoluzione del rapporto contrattuale.
• Di accettare che la presente dichiarazione venga conservata nel proprio fascicolo personale e utilizzata ai fini della governance aziendale.

1. Definizione di Informazioni Confidenziali

• Per "Informazioni Confidenziali" si intende ogni dato, informazione, documento, know-how, codice sorgente, specifica tecnica, strategia commerciale, dato personale o sensibile, comunicazione o materiale — in qualsiasi forma (scritta, orale, elettronica, visiva) — che una parte (il "Divulgante") comunica all’altra (il "Ricevente") in relazione all’oggetto del rapporto, indipendentemente dal fatto che sia espressamente contrassegnato come confidenziale.
• Rientrano nelle Informazioni Confidenziali anche i dati personali trattati per conto del Titolare, i dati relativi a pazienti, clienti e assistiti (per i perimetri Legal Tech e Health Tech), i log di sistema, le credenziali e i risultati di test e audit.

2. Obblighi del Ricevente

• Utilizzare le Informazioni Confidenziali esclusivamente per le finalità concordate e per l’esecuzione del rapporto contrattuale.
• Non divulgare, copiare, riprodurre o distribuire le Informazioni Confidenziali a terzi senza preventiva autorizzazione scritta del Divulgante.
• Limitare l’accesso alle Informazioni Confidenziali ai soli soggetti autorizzati che abbiano necessità di conoscerle e che siano vincolati da obblighi di riservatezza almeno equivalenti.
• Adottare misure di sicurezza tecniche e organizzative adeguate per proteggere le Informazioni Confidenziali da accessi non autorizzati, perdita, furto o divulgazione.
• In caso di sub-affidamento (sub-processing), richiedere la preventiva autorizzazione scritta e imporre al sub-processore obblighi contrattuali equivalenti.

3. Esclusioni

• Informazioni già di pubblico dominio senza violazione del presente accordo.
• Informazioni già in possesso del Ricevente prima della divulgazione, come documentato.
• Informazioni ricevute legittimamente da terzi senza obblighi di riservatezza.
• Informazioni che il Ricevente è tenuto a divulgare per obbligo di legge o ordine dell’autorità (previa notifica al Divulgante, ove consentito).

4. Notifica in caso di violazione (Breach Notification)

• Il Ricevente deve notificare al Divulgante qualsiasi accesso non autorizzato, perdita o divulgazione di Informazioni Confidenziali entro 24 ore dalla scoperta, fornendo: descrizione dell’evento, dati e categorie di dati coinvolti, misure adottate o proposte per mitigare gli effetti, punto di contatto per informazioni.

5. Durata e restituzione

• L’obbligo di riservatezza permane per tutta la durata del rapporto e per i 5 anni successivi alla sua cessazione, salvo obblighi di legge più estesi.
• Alla cessazione del rapporto, il Ricevente deve restituire o distruggere tutte le Informazioni Confidenziali, fornendo attestazione scritta.

6. Misure di sicurezza equivalenti

• Crittografia a riposo e in transito con algoritmi aggiornati (minimo AES-256, TLS 1.3).
• Controllo degli accessi con principio del privilegio minimo e MFA obbligatorio.
• Logging immutabile per accessi a dati sensibili.
• Procedure di gestione incidenti documentate.
• Formazione del personale su sicurezza e privacy.

7. Legge applicabile e foro competente

• Legge thailandese, con possibile rinvio a clausole GDPR/PDPA per i trattamenti di dati personali. Foro competente: Bangkok, Thailandia, salvo diverso accordo scritto.

Sicurezza

Code review completata e approvata

[ ]

Test automatici superati (CI verde)

[ ]

Analisi statica del codice (SAST) senza vulnerabilità critiche o high

[ ]

Analisi delle dipendenze (SCA) senza vulnerabilità note con CVSS ≥ 7

[ ]

Penetration test o scansione dinamica (DAST) eseguita su build pre-release

[ ]

Nessuna credenziale, token o segreto hardcodato nel codice

[ ]

Intestazioni di sicurezza HTTP configurate (HSTS, CSP, X-Frame-Options, ecc.)

[ ]

CORS configurato correttamente (nessun * su origini sensibili)

[ ]

Rate limiting attivo sugli endpoint pubblici

[ ]

Dipendenze aggiornate all’ultima versione stabile (o patch di sicurezza applicate)

[ ]

Privacy e dati

Nessun dato personale reale negli ambienti di test (solo dati sintetici/anonimizzati)

[ ]

Crittografia a riposo abilitata per tutti i dati sensibili

[ ]

Crittografia in transito (TLS 1.3) attiva su tutti gli endpoint

[ ]

Logging privo di dati personali o sensibili in chiaro

[ ]

Meccanismi di consenso verificabili e registrati (se applicabile)

[ ]

Procedure di cancellazione/diritto all’oblio testate e funzionanti

[ ]

Politica di retention implementata e verificata

[ ]

DPIA aggiornata per i trattamenti coinvolti nel rilascio

[ ]

Operazioni

Piano di rollback documentato e testato

[ ]

Changelog compilato con impatti noti

[ ]

Notifica agli stakeholder interni (supporto, security, DPO)

[ ]

Monitoraggio e alerting configurati per le nuove funzionalità

[ ]

Firme: Sviluppatore _______   Reviewer _______   CISO/DPO _______   Data _______

Flowchart: fasi della gestione incidenti

• 1. RILEVAZIONE — L’incidente viene rilevato da: sistema di monitoring automatico, segnalazione interna, bug bounty/reporter esterno, notifica di un fornitore o partner.
• 2. TRIAGE E CLASSIFICAZIONE (max 1 ora) — Il team di sicurezza valuta: tipo di incidente (violazione dati, accesso non autorizzato, malware, DDoS, ecc.), severità (bassa/media/alta/critica), perimetro coinvolto (piattaforma, Legal Tech, Health Tech), dati coinvolti (personali, sensibili, sanitari, legali).
• 3. CONTAINMENT (immediato) — Isolare i sistemi compromessi, revocare credenziali o token esposti, bloccare IP o account malevoli, attivare il team di risposta designato.
• 4. ERADICAZIONE — Rimuovere la causa root (patch, riconfigurazione, rimozione malware), verificare che non ci siano backdoor o persistenza, documentare le azioni intraprese.
• 5. RECOVERY — Ripristinare i sistemi da backup puliti, applicare patch e mitigazioni, validare il funzionamento in ambiente isolato prima del ritorno in produzione.
• 6. NOTIFICA — Entro 72 ore dalla scoperta: notificare il DPO e il Legal & Compliance; se violazione di dati personali, valutare obbligo di notifica all’autorità (PDPA/GDPR) e agli interessati. Usare il template di notifica (vedi sotto).
• 7. POST-MORTEM (entro 5 giorni lavorativi) — Analisi delle cause root, lezioni apprese, aggiornamento playbook e controlli di sicurezza, comunicazione interna (senza colpevolizzare).

Template notifica incidente

Da inviare internamente e, se richiesto, esternamente.

ID Incidente

INC-YYYY-NNN

Data e ora rilevazione

_____________________

Data e ora contenimento

_____________________

Severità

[ ] Bassa [ ] Media [ ] Alta [ ] Critica

Tipo

[ ] Violazione dati [ ] Accesso non autorizzato [ ] Malware [ ] DDoS [ ] Altro: ___

Perimetro

[ ] Piattaforma [ ] Legal Tech / LexAura [ ] Health Tech / MediAura

Sistemi coinvolti

_____________________

Dati coinvolti

Categorie: ___ Numero interessati stimato: ___

Descrizione

_____________________

Azioni intraprese

_____________________

Misure per gli interessati

_____________________

Punto di contatto

Nome: ___ Email: ___ Telefono: ___

Compilato da

_____________________

Modello DPIA — Sezioni obbligatorie

1. Titolo del trattamento

Descrizione sintetica del trattamento oggetto di valutazione.

2. Titolare e responsabili

Titolare: ___ Responsabile/i: ___ Sub-responsabili: ___ DPO: ___

3. Finalità del trattamento

Descrivere perché i dati vengono trattati, base giuridica e necessità.

4. Categorie di dati

[ ] Personali comuni [ ] Particolari (salute, legali, biometrici) [ ] Giudiziari

5. Categorie di interessati

[ ] Pazienti [ ] Clienti di studi [ ] Dipendenti [ ] Utenti piattaforma [ ] Altro: ___

6. Operazioni di trattamento

Raccolta, registrazione, organizzazione, conservazione, consultazione, comunicazione, cancellazione, ecc.

7. Tecnologie utilizzate

Database, cloud, API, AI/ML, etc.

8. Valutazione dei rischi

Probabilità × Impatto per ciascun rischio identificato. Misure di mitigazione previste.

9. Misure di sicurezza

Crittografia, controllo accessi, logging, backup, ecc.

10. Consultazione DPO

Parere del DPO: ___ Data: ___

11. Decisione finale

[ ] Rischio accettabile [ ] Rischio mitigato [ ] Necessaria consultazione autorità [ ] Trattamento da non avviare

12. Data e firme

Compilatore: ___ DPO: ___ Titolare: ___

Esempio compilato — MediAura: gestione dati clinici in cloud

1. Titolo

Gestione e archiviazione dati clinici dei pazienti su piattaforma MediAura (cloud, Bangkok).

2. Titolare e responsabili

Titolare: studio medico/clinica sottoscrittrice. Responsabile: NexStudio. Sub-responsabili: cloud provider certificato ISO 27001.

3. Finalità

Archiviazione e consultazione di dati clinici per supporto alla pratica medica. Base giuridica: esecuzione del contratto e consenso del paziente (informativa firmata).

4. Categorie dati

Particolari: dati sanitari (diagnosi, prescrizioni, referti). Personali comuni: anagrafica, contatti.

5. Interessati

Pazienti (adulti e minori tramite tutori).

6. Operazioni

Raccolta, registrazione, organizzazione, conservazione, consultazione da personale autorizzato, cancellazione su richiesta.

7. Tecnologie

Database cifrato (AES-256), API REST con TLS 1.3, AI per suggerimenti clinici (supervisione umana obbligatoria).

8. Rischi

Accesso non autorizzato a dati sanitari (probabilità bassa, impatto alto → mitigato con MFA, cifratura e audit log). Perdita dati (probabilità bassa, impatto critico → mitigato con backup giornalieri, disaster recovery testato).

9. Misure sicurezza

Crittografia a riposo AES-256 e in transito TLS 1.3. MFA obbligatorio. Log immutabili. Backup automatico giornaliero. Test di ripristino trimestrale.

10. DPO

Parere favorevole con raccomandazione di audit annuale.

11. Decisione

Rischio mitigato — trattamento approvato con revisione annuale.

Informativa sul trattamento dei dati personali

Ai sensi del PDPA (Thailandia) e, ove applicabile, del GDPR (UE).

Titolare del trattamento

[Nome studio / struttura], con sede in [indirizzo], email: [___], telefono: [___].

Responsabile del trattamento (fornitore piattaforma)

NexStudio, Bangkok, Thailandia, email: privacy@nexstudio.com.

Finalità del trattamento

Gestione dei servizi [legali/sanitari], archiviazione documentale, comunicazioni relative al servizio, adempimenti di legge.

Base giuridica

[Consenso dell’interessato / Esecuzione del contratto / Obbligo legale / Interesse legittimo].

Categorie di dati trattati

Dati anagrafici e di contatto. Dati relativi alla pratica [legale/sanitaria]. [Se sanitario: dati sulla salute ai sensi dell’art. 9 GDPR / PDPA].

Periodo di conservazione

[X anni] dalla conclusione del rapporto o come previsto dalla policy di retention.

Destinatari dei dati

Personale autorizzato del Titolare. NexStudio (responsabile del trattamento). Fornitori di servizi cloud (sub-responsabili con garanzie contrattuali). Autorità pubbliche, se richiesto per legge.

Trasferimenti internazionali

[Descrivere se i dati sono trasferiti fuori dalla Thailandia/UE e su quale base giuridica].

Diritti dell’interessato

Accesso, rettifica, cancellazione, limitazione, portabilità, opposizione, revoca del consenso. Per esercitare i diritti, contattare il Titolare all’indirizzo sopra indicato.

Reclami

L’interessato ha diritto di proporre reclamo all’autorità di controllo competente (PDPC in Thailandia / Garante Privacy nell’UE).

Modulo di consenso

Da compilare e firmare dall’interessato.

• Io sottoscritto/a _____________________, nato/a il ____________,
• dichiaro di aver ricevuto e letto l’informativa sul trattamento dei dati personali.
• [ ] Acconsento al trattamento dei miei dati personali per le finalità indicate nell’informativa.
• [ ] Acconsento al trattamento dei miei dati particolari (es. dati sanitari / dati legali) per le finalità indicate.
• [ ] Acconsento alla comunicazione dei miei dati ai soggetti indicati nell’informativa.
• Data: ____________   Firma: _____________________

Istruzioni

Compilare per ogni componente open source o di terze parti utilizzato nel prodotto. Aggiornare a ogni release.

• Generare automaticamente con strumenti come: CycloneDX, SPDX, Syft, Trivy, OWASP Dependency-Track.
• Il formato raccomandato è CycloneDX JSON o SPDX tag-value.
• Di seguito il template in formato tabellare per revisione manuale.

Inventario componenti

Nome componente

Versione | Licenza | Tipo licenza (copyleft/permissiva) | Fornitore/URL | Utilizzo nel prodotto | Vulnerabilità note (CVE) | CVSS score | Data ultimo aggiornamento

Esempio prima riga: React | 18.3.1 | MIT | Permissiva | https://react.dev | Frontend UI | Nessuna | N/A | 2026-04-01

Riepilogo

Totale componenti

___

Componenti con licenze copyleft

___ (verificare compatibilità)

Componenti con vulnerabilità note

___ (dettaglio sopra)

Componenti senza licenza dichiarata

___ (da verificare)

Data generazione SBOM

____________

Generato da

[Nome] — [Ruolo]

Principi generali

• I dati personali sono conservati solo per il tempo necessario al raggiungimento delle finalità per cui sono stati raccolti.
• Alla scadenza del periodo di retention, i dati sono anonimizzati o cancellati in modo sicuro e irreversibile.
• I periodi di retention sono documentati, giustificati e comunicati agli interessati nell’informativa privacy.
• La policy è soggetta a revisione almeno annuale o a fronte di modifiche normative.

Tabella dei periodi di retention

Dati anagrafici e di contatto

Periodo: 10 anni dalla cessazione del rapporto (obblighi fiscali e legali). Giustificazione: normativa fiscale thailandese. Cancellazione: anonimizzazione al termine.

Dati sanitari (MediAura / Health Tech)

Periodo: durata del rapporto + 10 anni (o come da normativa locale applicabile). Giustificazione: normative sanitarie, contenziosi, esigenze cliniche. Cancellazione: distruzione sicura con certificazione.

Dati legali / pratiche (LexAura / Legal Tech)

Periodo: durata del rapporto + 10 anni. Giustificazione: obblighi deontologici forensi, prescrizione, contenziosi. Cancellazione: previa verifica con il titolare dello studio.

Log di accesso e audit trail

Periodo: 2 anni. Giustificazione: sicurezza, investigazioni, compliance. Cancellazione: rotazione automatica.

Dati di fatturazione

Periodo: 10 anni. Giustificazione: obblighi fiscali e contabili. Cancellazione: anonimizzazione al termine.

Dati di candidati non assunti

Periodo: 12 mesi dalla candidatura. Giustificazione: eventuali future opportunità (con consenso). Cancellazione: distruzione al termine.

Cookie e dati di tracciamento

Periodo: come da cookie policy (max 12 mesi). Giustificazione: analisi e funzionalità del sito. Cancellazione: scadenza automatica o su richiesta.

Backup

Periodo: 30 giorni (backup operativi), 12 mesi (backup storici). Giustificazione: disaster recovery e business continuity. Cancellazione: rotazione automatica. I dati personali contenuti nei backup sono soggetti agli stessi periodi di retention e vengono cancellati dal backup attivo al termine.

Modalità di cancellazione

• Cancellazione logica: i dati sono resi inaccessibili all’utente ma conservati in area segregata per il periodo di retention.
• Cancellazione fisica: al termine del periodo di retention, i dati sono sovrascritti o distrutti in modo irreversibile (crypto-shredding, degaussing, distruzione fisica per supporti).
• Anonimizzazione: i dati sono trasformati in modo irreversibile in forma anonima e non riconducibile all’interessato.
• Per ogni cancellazione è prodotta evidenza documentale (log, certificazione).

Informazioni generali

Nome del sistema/modello

_____________________

Versione

_____________________

Perimetro

[ ] Piattaforma [ ] Legal Tech / LexAura [ ] Health Tech / MediAura

Responsabile tecnico

_____________________

Data valutazione

_____________________

1. Descrizione del sistema AI

• Descrivere lo scopo del sistema, le funzionalità, gli utenti target e il contesto d’uso. Specificare se il sistema prende decisioni automatizzate o fornisce raccomandazioni con supervisione umana.

2. Dataset e provenienza

Fonti dei dati di training

[ ] Dati interni [ ] Dati pubblici [ ] Dati di terze parti [ ] Dati sintetici

Volume e caratteristiche

Numero di record: ___ Features: ___ Bilanciamento classi: ___

Qualità e limiti noti

Descrivere eventuali bias noti, dati mancanti, rumore, qualità della labeling.

Pre-elaborazione

Descrivere pulizia, normalizzazione, feature engineering.

Conformità privacy

[ ] Dati anonimizzati [ ] Consenso ottenuto [ ] DPIA eseguita [ ] Base giuridica documentata

3. Bias assessment

• Descrivere le analisi condotte per identificare e mitigare bias (demografici, culturali, di genere, etnici, ecc.).
• Indicare metriche di fairness utilizzate e risultati ottenuti.
• [object Object]
• [object Object]
• [object Object]

4. Supervisione umana

Livello di automazione

[ ] Fully automated [ ] Human-in-the-loop [ ] Human-on-the-loop [ ] Solo raccomandazione

Meccanismo di override

Come l’utente può sovrascrivere la decisione del sistema?

Avvisi e limitazioni

Quali avvisi vengono mostrati all’utente sui limiti del sistema?

5. Explainability e trasparenza

Metodo di explainability

[ ] SHAP [ ] LIME [ ] Feature importance [ ] Attention maps [ ] Altro: ___

Documentazione per l’utente

Descrivere come vengono spiegate le decisioni all’utente finale.

Limitazioni comunicate

Come sono comunicati limiti, accuratezza e margini di errore?

6. Monitoraggio post-release

Metriche monitorate

Accuratezza, precision, recall, F1, drift detection, fairness metrics, latenza.

Frequenza monitoraggio

[ ] Continuo [ ] Giornaliero [ ] Settimanale [ ] Mensile

Alerting

Soglie di allarme definite per drift e degrado delle performance.

Piano di rollback

Procedura per disattivare o sostituire il modello in caso di comportamenti inattesi o dannosi.

7. Valutazione dei rischi

Impatto su diritti fondamentali

[ ] Basso [ ] Medio [ ] Alto — spiegare: ___

Impatto su salute o sicurezza

[ ] Nessuno [ ] Potenziale [ ] Diretto — spiegare: ___

Rischio di discriminazione

[ ] Basso [ ] Medio [ ] Alto — spiegare: ___

Rischio di opacità

[ ] Basso [ ] Medio [ ] Alto — spiegare: ___

8. Approvazione

Compilatore

Nome: ___ Firma: ___ Data: ___

CTO / Referente tecnico

Nome: ___ Firma: ___ Data: ___

DPO / Referente privacy

Nome: ___ Firma: ___ Data: ___

Legal & Compliance

Nome: ___ Firma: ___ Data: ___

Comitato etico (se applicabile)

Parere: ___ Data: ___

1. Obiettivi

• Assicurare che ogni collaboratore conosca Codice Etico, obblighi di sicurezza e privacy, e limiti del proprio ruolo sui dati (piattaforma, Legal Tech, Health Tech).
• Ridurre il rischio operativo e regolatorio nei primi 90 giorni e mantenere competenze aggiornate con refresh annuale.
• Produrre evidenze documentali (attestati, quiz, registro) per audit e KPI di formazione completata.

2. Destinatari e responsabilità

Tutti i collaboratori

Fondatori, dipendenti, consulenti e appaltatori con accesso a sistemi o dati NexStudio.

Owner del piano

HR (calendario, registro, reminder).

Owner contenuti

CISO (sicurezza), DPO (privacy), Legal (Codice Etico / compliance), CTO (coding sicuro / AI).

Manager di linea

Verificano completamento entro le scadenze e segnalano ritardi a HR.

3. Moduli obbligatori (core)

M1 — Codice Etico e condotta

Durata: 1,5 h. Contenuti: valori, conflitti di interesse, segnalazioni, sanzioni. Output: dichiarazione di adesione firmata.

M2 — Sicurezza informatica

Durata: 2 h. Contenuti: phishing, password/MFA, classificazione dati, gestione dispositivi, incident reporting. Output: quiz ≥ 80%.

M3 — Privacy PDPA e GDPR

Durata: 2 h. Contenuti: basi giuridiche, diritti interessati, trasferimenti, breach notification 72h, ruoli titolare/responsabile. Output: quiz ≥ 80%.

M4 — Dati sensibili e perimetri prodotto

Durata: 1,5 h. Contenuti: LexAura (segreto professionale), MediAura (dati sanitari), minimizzazione, accessi privilegiati. Output: checklist di comprensione firmata.

M5 — Uso responsabile di AI/ML

Durata: 1,5 h. Contenuti: bias, supervisione umana, limiti del modello, divieto di usi incompatibili. Output: quiz ≥ 80%.

M6 — Coding sicuro e release (ruoli tecnici)

Durata: 2 h. Contenuti: OWASP top risks, secret management, checklist pre-release, SBOM. Obbligatorio per sviluppatori, DevOps, QA. Output: quiz ≥ 80% + esercizio su checklist.

4. Calendario onboarding 90 giorni

Giorno 0–7 (settimana 1)

M1 Codice Etico + firma adesione e NDA se applicabile. Accesso sistemi solo dopo MFA e briefing sicurezza base (estratto M2).

Giorno 8–30 (mese 1)

M2 Sicurezza completo + M3 Privacy. Nessun accesso a dati di produzione senza M2/M3 completati.

Giorno 31–60 (mese 2)

M4 Perimetri prodotto (LexAura/MediAura secondo ruolo) + M5 AI. Ruoli tecnici: avvio M6.

Giorno 61–90 (mese 3)

Completamento M6 (se dovuto). Review con manager: gap, formazione aggiuntiva, conferma registro. Checkpoint HR: 100% moduli obbligatori del ruolo.

Scadenze hard: adesione entro 7 giorni; core M2–M5 entro 60 giorni; M6 entro 90 giorni per i ruoli tecnici. Ritardi > 14 giorni: escalation a HR e manager, possibile limitazione accessi.

5. Formazione annuale ricorrente

• Refresh obbligatorio entro 12 mesi dal completamento precedente (o dalla data di onboarding).
• Durata minima aggregata: 3 ore (M1 aggiornato + M2/M3 delta normativi + richiamo AI).
• Trigger aggiuntivi: cambio normativo rilevante, incidente grave, nuovo perimetro prodotto, cambio ruolo critico.
• Formato ammesso: sessione live, e-learning asincrono con quiz, o workshop interno documentato.

6. Formazione aggiuntiva per ruoli critici

CISO / security

Incident response playbook, tabletop annuale, threat modeling.

DPO / privacy

DPIA workshop, diritti interessati, trasferimenti internazionali.

Legal & compliance

Aggiornamenti regolatori LexAura/MediAura, contratti sub-processori.

Sviluppo / DevOps

Secure SDLC avanzato, review SBOM, penetration test findings walkthrough.

Supporto / customer success

Accesso minimo ai dati cliente, script di escalation, divieto di uso fuori ticket.

7. Modalità di erogazione e materiali

• Lingue: italiano, inglese, thailandese (allineate al sito e al Codice Etico).
• Materiali: slide/video interni, Codice Etico vigente, allegati operativi (checklist, DPIA, AI impact).
• Valutazione: quiz a risposta multipla (soglia 80%) o attestato di presenza + exercise per workshop.
• Ripetizione: in caso di quiz insufficiente, ritentativo entro 14 giorni con tutoring del owner di dominio.

8. Registro formazione (template riga)

Campi obbligatori per ogni record

Nome collaboratore | Ruolo | Modulo (M1–M6 / annuale / critico) | Data | Durata (h) | Esito (superato / da ripetere) | Evidenza (link quiz / PDF / firma) | Owner verifica

Retention del registro: allineata alla policy retention (record di formazione e dichiarazioni di adesione). Formato consigliato: foglio condiviso o HRIS con export per audit.

9. KPI e controllo

• % onboarding con moduli obbligatori completati entro 90 giorni (target ≥ 95%).
• % personale con refresh annuale in regola (target ≥ 95%).
• Tempo medio di completamento M1–M5.
• Numero ritardi > 14 giorni e azioni correttive.