Conformità normativa

1. Premessa e perimetro

Nessuna delle norme citate in questa pagina prevede una certificazione di prodotto. La conformità di un software di supervisione si dimostra adottandone modelli, terminologia e strutture dati, implementandone i requisiti tecnici e documentandone la mappatura. Questa pagina è la sintesi pubblica di quella documentazione.

Distinzione fondamentale

Norme come 21 CFR Part 11, EU GMP Annex 11 e NIS 2 si applicano a soggetti — l'azienda che produce, il gestore dell'infrastruttura — non a un prodotto software. Opscadia non può rendere conforme il cliente: fornisce le funzioni tecniche senza le quali quella conformità non è dimostrabile, e le documenta. La qualifica dell'installazione (IQ/OQ/PQ), la validazione del processo, le procedure operative e le decisioni organizzative restano in capo all'utilizzatore.

1.1 Cosa copre questa pagina

Log di runtime

Campioni di processo, eventi di allarme, modifiche di configurazione e accessi registrati dal runtime presso l'impianto.

Audit trail della piattaforma

Registro delle azioni sulla piattaforma cloud: accessi, progetti, collaboratori, licenze, azioni amministrative.

Allarmi

Ciclo di vita, razionalizzazione, riduzione del rumore, metriche di prestazione, allarmi di sicurezza funzionale.

Batch

Modello fisico e procedurale ISA-88, ricette, esecuzione, Batch Production Record e firme elettroniche.

Comunicazione

Qualità del dato, time-tag della sorgente, gestione dei salti di orologio e del dato obsoleto.

Sicurezza e dati personali

Controllo accessi, MFA, crittografia, gestione incidenti, trattamento dei dati personali presenti nei log.

1.2 Legenda degli stati

Implementato requisito coperto per intero nel prodotto. Parziale coperto con una limitazione, sempre esplicitata. Fuori scope non implementato per scelta dichiarata, con indicazione di chi se ne fa carico.

2. Quadro normativo di riferimento

Norma	Ambito	Dove incide in Opscadia
21 CFR Part 11	Record e firme elettroniche, FDA — farmaceutico, biotech, food regolamentato	Log di runtime, audit trail, batch record
EU GMP Annex 11	Sistemi computerizzati in ambito GMP, versione UE	Audit trail, identità operatore, motivi obbligatori, backup
GAMP 5 (2ª ed.)	Metodo, non legge: rischio del dato, data integrity by design, ALCOA+	Impostazione generale dei log e della retention
ISA-18.2 / IEC 62682	Gestione dei sistemi di allarme nei processi industriali	Motore allarmi, KPI, Management of Change
EEMUA 191	Benchmark di carico operatore e criteri di usabilità	Soglie KPI, distribuzione priorità, report periodico
IEC 61511	Sicurezza funzionale: allarmi usati come strato di protezione (IPL)	Allarmi safety, bypass, proof test, restrizione modifiche
ISA-88 / IEC 61512	Controllo batch, Parti 1–5 + ISA-TR88.00.02 (PackML)	Modello fisico, ricette, esecuzione, BPR
IEC 60870-5-101/104	Telecontrollo: qualità del dato, time-tag, causa di trasmissione	Driver IEC 104, storico, decisioni di allarme
IEC 61850	Automazione di sottostazione: qualità e sequenza degli eventi	Qualità del dato via gateway/OPC UA
ISA-101	Progettazione dell'interfaccia operatore	Banner allarmi, colori, codifica ridondante, modali
IEC 62443-3-3	Cybersecurity industriale, requisiti di sistema	Audit degli eventi, storage, timestamp, controllo accessi
NIS 2 + D.lgs. 138/2024	Sicurezza delle reti e dei sistemi informativi, notifica incidenti	MFA, log per rilevazione incidenti, procedura di notifica
GDPR (UE 2016/679)	Dati personali presenti nei log, nell'account e nel trail	Base giuridica, retention, diritti dell'interessato, art. 32
Art. 4 L. 300/1970	Controllo a distanza dei lavoratori	Interruttore del tracciamento tempo attivo dei collaboratori
D.Lgs. 127/2015, DPR 633/1972, art. 2220 c.c.	Fatturazione elettronica, P.IVA, conservazione documenti contabili	Dati aziendali e di fatturazione dell'account

2.1 Norme di riferimento tecnico (non di conformità)

ISO 8601 — formato dei timestamp registrati (UTC, accanto all'epoch).
IEC 61131-3 — indirizzamento simbolico delle variabili nei driver CODESYS; l'SFC della norma è la base del PFC raccomandato da ISA-88 Parte 2.
ISA-95 — i livelli Enterprise / Site / Area appartengono al suo dominio e sono volutamente fuori dal modello di controllo batch di Opscadia.
RFC 6238 (TOTP) — implementazione MFA, verificata sui vettori di test della RFC.
RFC 9116 (security.txt) — canale di contatto per la segnalazione di vulnerabilità, servito sia dalla piattaforma sia dal sito.
NIST SP 800-63B — motivo per cui non è imposta la scadenza periodica forzata della password: le linee guida la sconsigliano in favore di MFA e password lunghe.

3. Log di runtime — integrità del dato

Riguarda le tabelle scritte dal runtime presso l'impianto: campioni di processo, eventi di allarme, registro delle modifiche di configurazione degli allarmi e log degli accessi, oltre al mirror su database remoto e agli export CSV/XML.

3.1 ALCOA+ tradotto in requisiti tecnici

Il denominatore comune di Part 11, Annex 11 e GAMP 5 è il principio ALCOA+ — Attributable, Legible, Contemporaneous, Original, Accurate, più Complete, Consistent, Enduring, Available. Tradotto in sei requisiti verificabili:

ogni record dice chi, con identità verificata dal server, mai dichiarata dal client;
ogni record dice quando, con timestamp affidabile e tracciamento dei salti d'orologio;
i record non si modificano né si cancellano silenziosamente: append-only e tamper-evident;
i record sono esportabili in forma leggibile e completa, senza colonne omesse;
i record sopravvivono per il periodo richiesto e la loro cancellazione è a sua volta registrata;
gli accessi al sistema sono registrati come gli eventi di processo.

3.2 21 CFR Part 11 / EU GMP Annex 11 — requisito per requisito

§	Requisito	Implementazione	Stato
11.10(a)	Capacità di rilevare record alterati	Catena di hash SHA-256 (`prev_hash` → `row_hash`) sul log accessi e sul registro delle modifiche allarmi. Verifica di integrità su richiesta, che indica il punto esatto in cui la catena si interrompe. La catena è per nodo: le righe ricevute dai peer in ridondanza portano la catena del nodo che le ha scritte e non falsano la verifica locale.	Implementato
11.10(b)	Copie accurate e complete, leggibili dall'ispettore	Export in archivio ZIP: tutte le tabelle in CSV con l'insieme completo delle colonne, un `manifest.json` con conteggi, SHA-256 di ogni file ed esito della verifica di integrità, un `README` con la legenda dei valori codificati.	Implementato
11.10(c)	Protezione dei record per tutto il periodo di conservazione	Retention configurabile e differenziata per tipo di dato: campioni, eventi di allarme, evidenza di audit. L'archiviazione CSV prima della cancellazione è fail-closed: se l'archiviazione non riesce, la cancellazione non avviene. La retention del registro modifiche è un ordine di grandezza superiore a quella dei campioni.	Implementato
11.10(d)	Accesso limitato ai soli autorizzati	Sessioni lato server con token opaco e timeout di inattività: il client presenta un token, non un nome. Con utenti configurati, una scrittura senza token valido è rifiutata e lascia una riga di accesso fallito. Ruoli di progetto (admin, maintainer, technician, operator) con visibilità per pagina ed elemento.	Implementato
11.10(e)	Audit trail generato dal sistema che non oscura mai il dato precedente	Trigger di database `BEFORE UPDATE` e `BEFORE DELETE` sulle tabelle di evidenza: la modifica è impedita dal motore, non solo evitata dal codice. La sincronizzazione verso il database remoto, in caso di conflitto, appende invece di sovrascrivere.	Implementato
11.10(k)	Controllo delle modifiche alla documentazione di sistema	Registro Management of Change sugli allarmi (autore, timestamp, motivazione, valore prima/dopo, insert once: non aggiornabile nemmeno in sincronizzazione) e motivo obbligatorio sulle scritture marcate come critiche.	Parziale — copre allarmi e scritture di processo, non ogni campo di progetto
11.100 11.200	Firma elettronica con componenti identificative e riautenticazione	Implementata sul batch record: firma con verifica password, mai la sola sessione, e significato vincolato a vocabolario chiuso. Non prevista sulla singola scrittura di processo, che resta tracciata ma non firmata.	Perimetro dichiarato
Annex 11 §4	Gestione dei cambiamenti	Registro modifiche allarmi, versionamento e approvazione delle ricette, audit trail delle azioni di progetto.	Implementato
Annex 11 §7.2	Backup verificabile	Backup giornaliero cifrato con rotazione, impronta SHA-256 e procedura automatizzata di test di ripristino su istanza usa-e-getta con verifica delle tabelle critiche.	Implementato
Annex 11 §9	Audit trail sui dati GMP-critici	Ogni campione ed evento di allarme porta la provenienza completa: PLC, operatore, ricetta, sequenza, azione HMI, batch, phase, più il motivo dichiarato.	Implementato
Annex 11 §12.4	Identità univoca dell'operatore e motivo delle modifiche critiche	Identità derivata dalla sessione verificata. Per i tag marcati «richiede motivo» il backend rifiuta con errore la scrittura priva di motivazione, che finisce nel campo di provenienza del record.	Implementato
—	Validazione formale del sistema (IQ/OQ/PQ)	Non fornita come servizio di prodotto: è responsabilità dell'utilizzatore in ambito regolamentato. Opscadia fornisce l'evidenza tecnica su cui la validazione si appoggia.	Fuori scope dichiarato

3.3 IEC 62443-3-3 — requisiti di sistema sull'audit

Req.	Requisito	Implementazione
SR 2.8	Audit degli eventi di accesso, uso e configurazione	Login, login fallito, logout, scadenza sessione, avvio e arresto del runtime, cancellazione per retention, export, salto di orologio, pseudonimizzazione GDPR.
SR 2.9	Gestione della capacità di storage dell'audit	Retention dedicata all'evidenza di audit, con archiviazione prima della cancellazione. Nessun troncamento silenzioso a numero di righe.
SR 2.10	Risposta al fallimento dell'audit	Cancellazione fail-closed; il mirror remoto segnala esplicitamente se sta perdendo righe per schema disallineato, invece di fallire in silenzio.
SR 2.11	Timestamp affidabili	Timestamp UTC ISO 8601 accanto all'epoch; rilevazione dei salti d'orologio confrontando l'orologio di sistema con quello monotono, con evento dedicato; ordinamento deterministico per (timestamp, sequenza).
SR 6.1	Accessibilità in sola lettura dell'audit	Consultazione ed export senza possibilità di modifica, garantita a livello di motore del database.

3.4 Provenienza di ogni variazione

Ogni riga di storico dichiara chi o cosa ha prodotto la variazione — PLC, operatore, ricetta, sequenza, azione HMI, batch, phase — insieme all'eventuale motivo. È l'attributo che rende il dato attribuibile nel senso di ALCOA+: senza di esso un valore cambiato resta indistinguibile fra lettura di campo e intervento umano.

Comportamento su progetti senza utenti

Su un progetto senza utenti configurati nulla cambia rispetto a un SCADA tradizionale: l'operatore resta anonimo e i campi di identità restano vuoti. La tracciabilità nominativa si attiva configurando gli utenti di progetto — è una scelta esplicita dell'utilizzatore, non un comportamento imposto.

4. Audit trail della piattaforma

Sistema distinto dallo storico d'impianto. Registra chi fa cosa sulla piattaforma: accessi, apertura, salvataggio ed export dei progetti, gestione dei collaboratori, licenze, azioni amministrative, generazione report. È stato portato allo stesso standard tecnico dell'historian di runtime.

Requisito	Implementazione	Stato
Rilevazione delle alterazioni	Catena di hash SHA-256 per account, con endpoint di verifica dedicato.	Implementato
Immutabilità	Trigger di database contro UPDATE e DELETE. È stato rimosso l'endpoint che permetteva a un utente di cancellare le proprie voci: un attore non può ripulire il proprio trail.	Implementato
Copie leggibili per l'ispettore	Export ZIP con CSV completo, manifest con SHA-256 ed esito della verifica di integrità.	Implementato
Gestione dello storage senza perdita silenziosa	Retention differenziata per finalità: log di accesso 2 anni, eventi di gestione e sicurezza 3 anni. Archiviazione fail-closed, job giornaliero che registra sé stesso nel trail. È stato sostituito il precedente pruning silenzioso a numero di righe.	Implementato
Risposta al fallimento dell'audit	Un errore di scrittura non viene più inghiottito: viene registrato a livello ERROR ed esposto da un contatore interrogabile.	Implementato
Timestamp affidabile	`created_at` in UTC incluso nel calcolo della catena di hash: non è modificabile a posteriori senza rompere la catena.	Implementato
Visibilità proporzionata	Il titolare dell'account vede il trail dell'intero team; il collaboratore vede solo le proprie voci.	Implementato
Righe antecedenti alla migrazione	Le voci scritte prima dell'introduzione della catena non hanno hash e non sono verificabili: la verifica riparte da quel punto senza dichiarare una rottura falsa.	Limite storico dichiarato

Perché due retention diverse

Il trail della piattaforma non contiene evidenza di processo o di lotto — quella resta nell'historian di runtime, con la sua retention separata e più lunga. Conservare per dieci anni i log di accesso alla piattaforma non era giustificato né da NIS 2 né da IEC 62443, che non impongono una durata fissa, e contrastava con il principio di minimizzazione del GDPR. Da qui le due soglie distinte.

5. Gestione allarmi

Opscadia implementa il ciclo di vita dell'allarme di ISA-18.2 / IEC 62682 e i benchmark di EEMUA 191, con le restrizioni aggiuntive di IEC 61511 sugli allarmi usati come strato di protezione. La filosofia di allarme è un documento fondativo i cui parametri sono applicati dal motore, non solo scritti su carta.

5.1 ISA-18.2 / IEC 62682

§	Requisito	Implementazione
5.2	Macchina a stati normalizzata	Normal, Unacknowledged, Acknowledged, RTN Unacknowledged, più gli stati fuori servizio: Shelved, Suppressed by design, Out of service. Un allarme rientrato ma non riconosciuto resta visibile.
6	Alarm philosophy documentata e classi di allarme	Documento di filosofia allarmi + impostazioni applicate dal motore; classi process, safety, equipment, quality, environmental.
7	Razionalizzazione: causa, conseguenza, azione dell'operatore, tempo di risposta	Scheda di razionalizzazione per allarme, con azione operatore obbligatoria. In modalità strict compliance un allarme non razionalizzato non viene pubblicato.
9	Priorità derivata dalla matrice gravità × tempo di risposta	Suggerimento della priorità dalla matrice nella scheda allarme. La priorità «diagnostica» non raggiunge l'operatore, non entra nei KPI e non genera notifiche.
12	Metodi di riduzione del rumore	Deadband, on-delay, off-delay, durata minima di attivazione, filtro anti-chattering, soppressione per stato impianto documentata, first-out sui consequenziali con finestra e rilascio automatico al rientro del padre.
12.4	Shelving temporaneo	Con motivazione obbligatoria e scadenza automatica: uno shelving non può diventare permanente per dimenticanza.
12	Gli allarmi nascosti restano ispezionabili	Elenco dedicato di shelvati, soppressi e fuori servizio, raggiungibile dal banner di runtime.
16	Metriche di prestazione	Rate giornaliero e orario, rilevazione di alarm flood su finestra scorrevole con eventi di inizio e fine, allarmi standing oltre soglia, top-10 dei contributori chattering, distribuzione delle priorità rilevata contro quella obiettivo.
17	Management of Change	Ogni modifica a limite, priorità, abilitazione o soppressione è registrata con autore, timestamp, motivazione e valore prima/dopo, su tabella append-only con catena di hash.

5.2 EEMUA 191 — carico dell'operatore

I benchmark della guida sono soglie configurabili con verdetto automatico ok / warn / fail:

Rate a regime: circa 150 allarmi al giorno accettabili, 300 come massimo tollerato; circa 6 all'ora «molto probabilmente accettabile», 12 come massimo gestibile.
Dopo un disturbo grave: non più di 10 allarmi nei primi 10 minuti — oltre la soglia il sistema è dichiarato in alarm flood.
Distribuzione priorità: obiettivo 80 % bassa / 15 % media / 5 % alta, confrontato con la distribuzione realmente rilevata.
Allarmi permanentemente attivi: trattati come difetto di progetto ed elencati come KPI, non normalizzati.
Azione univoca: ogni allarme deve avere una risposta definita dell'operatore, campo obbligatorio in razionalizzazione.
Report periodico di prestazione: generabile in PDF/CSV su periodo configurabile (default 30 giorni) e schedulabile.

5.3 IEC 61511 — allarmi come strato di protezione

Quando un allarme è dichiarato IPL (Independent Protection Layer), la norma impone vincoli che il motore applica come regole, non come raccomandazioni:

Requisito	Implementazione
Identificazione degli allarmi usati come IPL	Classe safety e flag dedicato, con riferimento alla SIF e al livello SIL.
Non shelvabile, riconoscimento obbligatorio	Il tentativo di shelving su un allarme safety è rifiutato dal motore.
Mai soppresso dalla logica di stato	I gruppi di soppressione per stato impianto saltano gli allarmi safety.
Bypass con motivazione registrata	La messa fuori servizio richiede una motivazione, genera una riga di Management of Change e un evento dedicato.
Indicazione permanente di bypass attivo	Contatore dedicato e badge «BYPASS SIS» sempre visibile nel banner di runtime.
Proof test periodico documentato	Scadenza per allarme, evento generato al maturare della scadenza, registro delle prove con esito e data della prossima.
Accesso in scrittura protetto	Le modifiche agli allarmi safety-related sono ristrette per ruolo e negate ai profili non autorizzati.

6. Batch — ISA-88 / IEC 61512

La modalità ISA-88 è opt-in per progetto. Con l'opzione disattivata il comportamento resta quello semplice (avvio e fine lotto, export CSV) e nessuna delle strutture della norma viene imposta a chi non ne ha bisogno.

6.1 Copertura per parte della norma

Parte	Titolo	Stato
88.00.01	Models and Terminology	Implementata
88.00.02	Data Structures and Guidelines for Languages	Strutture dati complete; canvas PFC grafico non implementato
88.00.03	General and Site Recipe Models	Implementata (semplificata)
88.00.04	Batch Production Records	Implementata
88.00.05	Modular Equipment Control	Implementata (semplificata)
TR88.00.02	PackML	Overlay terminologico, non un secondo motore

6.2 Modello fisico (Parte 1, §4)

Process Cell → Unit → Equipment Module → Control Module, con classi di apparecchiatura: le ricette vincolano su classe, non sulla singola unità. I vincoli di gerarchia sono validati sia dal backend sia dall'editor. Una unità esegue un solo lotto alla volta, con arbitraggio delle risorse condivise. I livelli Enterprise / Site / Area non sono modellati perché appartengono al dominio ISA-95.

6.3 Modello procedurale e macchina a stati (Parte 1, §5–6)

Procedure → Unit Procedure → Operation → Phase, con istanze di esecuzione distinte dalle definizioni.
12 stati della norma (idle … complete), con distinzione fra quiescenti, transienti e finali, e 8 comandi (start, pause, resume, hold, restart, stop, abort, reset).
Phase Logic Interface completa (comando, stato, modo, owner, indice di step, codice di errore, richiesta e dati di richiesta), con codifiche sovrascrivibili per PLC di terze parti.
Un comando non ammesso nello stato corrente non produce transizione: viene rifiutato con l'elenco dei comandi ammessi. Vincolo coperto da test su tutte le coppie stato × comando.
Modi automatico, semi-automatico e manuale, selezionabili per lotto e per singolo elemento in esecuzione.
Gestione eccezioni per elemento fra hold, stop, abort e intervento operatore: nessun «continue» silenzioso. La policy è sovrascrivibile a livello di ricetta con catena operation → unit procedure → default della phase, e viene congelata nello snapshot di control recipe.
Distinzione fra basic control, procedural control e coordination control, come richiesto dalla norma.

6.4 Ricette (Parte 1 §5, Parte 2)

Master recipe con header completo: versione, autore, date, stato di approvazione, approvatore, prodotto, nota di modifica.
Formula con categorie process input / parameter / output, unità di misura, tipo, minimo e massimo; voci scalabili con la dimensione del lotto.
Equipment requirements per classe, capacità, unità ammesse ed escluse, verificati prima dell'allocazione.
Versionamento e approvazione: una ricetta approvata non si modifica in place, si crea una nuova versione. Per default solo le ricette approvate producono; un lotto avviato con ricetta non approvata è marcato come non rilasciabile alla produzione nel BPR.
Control recipe come snapshot immutabile: se il lotto puntasse alla master recipe, modificarla cambierebbe retroattivamente ciò che risulta prodotto nei lotti passati.
Parte 3: general e site recipe con promozione esplicita verso la master recipe, mai automatica al salvataggio — il legame con l'impianto reale è una decisione umana, come la norma stessa prevede.
Parte 5: sequenze procedurali possedute dall'apparecchiatura, richiamabili per identificativo dalla ricetta ed espanse in fase di costruzione della control recipe.

6.5 Batch Production Record (Parte 4)

Il BPR è un journal append-only su database dedicato, separato da quello dei campioni: non viene toccato dalla retention dello storico e non partecipa alla sincronizzazione fra peer.

Contenuto richiesto dalla norma	Implementazione
Identificazione del lotto	Sezione di identificazione del documento
Ricetta usata, con versione e copia	Riferimento alla master recipe + snapshot completo della control recipe
Esecuzione procedurale con timestamp di ogni transizione	Transizioni alimentate direttamente dall'hook della macchina a stati
Parametri richiesti e valori effettivi	Valori di parametro e valori di report per ogni phase
Materiali	Eventi di materiale
Dati continui	Trend dei tag dichiarati nelle impostazioni di lotto
Eventi, allarmi, eccezioni	Sezioni dedicate, con deviazioni distinte dagli eventi ordinari
Interventi manuali e commenti	Eventi di commento e di deviazione, motivo obbligatorio
Tracciabilità dell'operatore	Identità su ogni singolo evento
Firma elettronica	Riautenticazione con password (mai la sola sessione) e significato vincolato a vocabolario chiuso: authored, reviewed, approved, reviewed and approved — nessun testo libero ambiguo
Revisione indipendente dall'operatore	Stato di revisione QA (non richiesta / in attesa / approvata / respinta): un secondo utente dispone il record già chiuso, distintamente dalla firma operativa. Attivabile per progetto
Ciclo di vita e chiusura	Alla chiusura si calcola l'SHA-256 del documento serializzato. Il documento congelato non viene mai ricostruito; le annotazioni successive restano eventi post-chiusura, fuori hash e dichiarati come tali

Export del BPR in JSON, CSV e XML nel formato BatchML/B2MML.

7. Comunicazione e qualità del dato

IEC 60870-5 e IEC 61850 impongono che la qualità e il tempo di origine del dato entrino nel processo decisionale, invece di essere scartati al confine del driver.

Requisito	Implementazione	Stato
Qualità del dato nel processo decisionale	Qualità per tag con comportamento configurabile in caso di qualità non buona: mantenere l'ultimo valore, azzerare o allarmare.	Implementato
Il dato obsoleto non genera decisioni	Timeout di obsolescenza per tag: oltre la soglia la qualità diventa stale e non alimenta la logica di allarme.	Implementato
Qualità registrata nello storico	Colonna dedicata sugli eventi di allarme: a posteriori si sa in che stato era il dato che ha generato la decisione.	Implementato
Time-tag della sorgente distinto dal tempo di scansione	IEC 60870-5-104 decodifica CP56Time2a sui tipi con marca temporale; OPC UA usa il SourceTimestamp. Il valore è salvato in colonna separata.	Implementato
Qualità nativa del protocollo	IEC 104: bit SIQ/DIQ/QDS → IV, NT, SB, BL, OV; doppio punto indeterminato marcato come non valido. OPC UA: StatusCode.	Implementato
Causa di trasmissione distinta	Distinzione fra dato spontaneo e dato ottenuto per interrogazione generale, per indirizzo.	Implementato
Gestione del salto di orologio	Scarto superiore a 300 s fra ora della sorgente e ora locale: si usa l'ora locale e il dato viene marcato come sostituito, mai accettato in silenzio.	Implementato
Sequenza degli eventi monotona	Identificativo di nodo e numero di sequenza, già usati dal meccanismo di ridondanza, garantiscono un ordinamento deterministico.	Implementato
Client IEC 61850 MMS nativo	La qualità 61850 è gestita attraverso gateway od OPC UA; report buffered e logical node di allarme nativi non sono implementati.	Fuori scope dichiarato
Time-tag di sorgente su protocolli che non lo trasportano	Su S7, Modbus, MC e simili resta il timestamp di scansione, dichiarato come tale e non spacciato per ora di origine.	Limite di protocollo

8. Interfaccia operatore — ISA-101

Colori saturi riservati agli allarmi: le variabili di colore ad alta saturazione sono usate esclusivamente dai componenti di allarme, così un colore acceso significa sempre una cosa sola.
Codifica ridondante colore + forma + testo, per non dipendere dalla sola percezione cromatica.
Lampeggio riservato al non riconosciuto: cessa all'acknowledgement, non alla scomparsa della condizione.
Contatori per priorità sempre visibili nel banner di runtime.
Indicazione di ciò che non viene mostrato: elenco esplicito di shelvati, soppressi e fuori servizio, raggiungibile in un clic.
Azione dell'operatore raggiungibile dall'allarme: causa, conseguenza e azione prescritta si aprono dal pannello informazioni dell'allarme stesso.
Nessuna finestra di dialogo nativa del browser: tutte le conferme sono modali dell'applicazione, sempre visibili sullo schermo di impianto e mai bloccanti in modo imprevisto.

9. Sicurezza — IEC 62443 e NIS 2

Come leggere questa sezione

NIS 2 si applica a soggetti, non a prodotti. Un software non è «certificato NIS 2». Ciò che un fornitore può fare è (a) implementare le misure tecniche che il cliente in perimetro deve poter dimostrare, e (b) reggere il questionario fornitori come anello della catena di approvvigionamento del cliente, ai sensi dell'art. 21(2)(d). Sotto sono elencate le misure tecniche effettivamente implementate.

9.1 Controllo degli accessi e autenticazione

MFA TOTP (RFC 6238) con enrolment, verifica, codici di recupero monouso e obbligo configurabile per ruolo; flusso di login a due passi su web, desktop e client API — rif. art. 21(2)(j).
Anti-brute-force: backoff esponenziale per identità e per indirizzo IP, con evento dedicato nell'audit trail.
Revoca delle sessioni: versione del token confrontata a ogni rinnovo, disconnessione da tutti i dispositivi, incremento automatico al cambio password e alla disattivazione MFA.
Politica password: minimo 12 caratteri, normalizzazione Unicode, blocco delle password comuni e di quelle derivate dall'email. Nessuna scadenza forzata, in linea con NIST SP 800-63B.
Durata dei token ridotta e cookie di rinnovo con SameSite=Strict e path limitato.
Ruoli: separazione fra titolare dell'account e collaboratori sul cloud; ruoli di progetto granulari (admin, maintainer, technician, operator) sul runtime.

9.2 Crittografia e protezione dei dati

Hashing delle password con bcrypt e salt casuale; nessuna password in chiaro, in nessun punto.
Cifratura in transito (TLS) verso la piattaforma.
Backup cifrati a chiave pubblica, con impronta SHA-256; il backup non cifrato non viene spedito.
Header di sicurezza HTTP (CSP, HSTS, anti-framing, nosniff, Referrer-Policy, Permissions-Policy, COOP) applicati anche al runtime on-premise.
Confronti a tempo costante sui segreti condivisi, per non esporre informazione tramite la durata della verifica.

9.3 Continuità operativa

Backup giornaliero con rotazione e copia fuori sede.
Test di ripristino automatizzato su istanza usa-e-getta con verifica delle tabelle critiche: un backup mai ripristinato non è un backup.
Ridondanza di device e sincronizzazione fra peer per la continuità della supervisione, con catena di hash per nodo che resta verificabile anche dopo il riallineamento.

9.4 Sviluppo sicuro e gestione delle vulnerabilità

SBOM, scansione delle vulnerabilità delle dipendenze e ricerca di segreti nel codice, con SLA di intervento dichiarato.
Policy di divulgazione coordinata (CVD) pubblica e security.txt conforme alla RFC 9116, servito sia dalla piattaforma sia dal sito — vedi Sicurezza e segnalazione vulnerabilità.
Test automatici dedicati alle misure di sicurezza (policy password, throttling, TOTP sui vettori della RFC, codici di recupero).

Programma in corso

Il piano di conformità NIS 2 è un percorso attivo, non un traguardo dichiarato chiuso: le misure tecniche sopra sono implementate e verificate, mentre la parte organizzativa (analisi dei rischi formalizzata, registro fornitori, formazione, riesame periodico degli accessi, KPI di efficacia) è in corso di completamento. Lo stato di avanzamento dettagliato è disponibile per i clienti in valutazione fornitori, su richiesta e sotto riservatezza.

10. Gestione e notifica degli incidenti

Esiste una procedura scritta di gestione degli incidenti di sicurezza con ruoli, rilevazione, triage e classificazione di gravità, contenimento, ripristino e post-mortem entro 10 giorni. Le scadenze di notifica seguono l'art. 23 NIS 2:

Termine	Obbligo	Destinatario
≤ 24 h	Pre-notifica (early warning): si sospetta un atto doloso? c'è impatto transfrontaliero?	ACN / CSIRT Italia
≤ 72 h	Notifica con valutazione iniziale, gravità, impatto, indicatori di compromissione	ACN / CSIRT Italia
Su richiesta	Rapporto intermedio	ACN / CSIRT Italia
≤ 1 mese	Rapporto finale: causa radice, mitigazione, impatto transfrontaliero	ACN / CSIRT Italia
Senza ritardo	Se l'incidente coinvolge dati personali: notifica ai sensi dell'art. 33 GDPR	Garante privacy (≤ 72 h)
Senza ritardo	Informativa ai destinatari del servizio potenzialmente interessati	Clienti

Principio operativo adottato: nel dubbio si notifica — la pre-notifica a 24 ore non richiede certezze e non costituisce ammissione. Il materiale probatorio è l'export ZIP con manifest e verifica di integrità, richiamato esplicitamente dai modelli di notifica.

11. Dati personali — GDPR

I log di runtime contengono nomi e identificativi di operatore: sono dati personali a tutti gli effetti. La trattazione completa è nella Privacy Policy; qui il riepilogo dei punti tecnici.

Art.	Requisito	Implementazione
6	Base giuridica dichiarata	Obbligo legale dove si applicano 21 CFR Part 11, Annex 11 o normative di settore equivalenti; negli altri casi legittimo interesse alla tracciabilità di processo e alla sicurezza dell'impianto.
5(1)(c)	Minimizzazione	Nessun dato personale oltre a identificativo, nome e indirizzo IP dell'attore. I dati industriali di progetto restano sui sistemi del cliente.
5(1)(e)	Limitazione della conservazione	Retention configurabile per tipo di dato e differenziata per finalità: campioni, evidenza normativa, log di accesso.
13	Informativa	Informativa pubblica; nota specifica in-app nella sezione «Privacy e dati» dell'account; modello di informativa per i collaboratori fornito al cliente.
15 / 20	Accesso e portabilità	Export self-service in JSON di tutti i dati dell'utente — account, referenti, dati aziendali, fatturazione, stato sicurezza, licenza, elenco progetti — con esclusione dei segreti (hash password, segreto MFA, codici di recupero).
17	Diritto alla cancellazione nei log normativi	Esercitato per pseudonimizzazione: il nome è sostituito, resta un identificativo opaco, la catena di hash si rompe volutamente e l'intervento è registrato come evento. È l'unico modo di conciliare l'art. 17 con §11.10(e), dove una modifica è ammessa ma non può essere silenziosa.
17	Cancellazione dell'account	Richiesta autenticata con password e motivazione, notificata all'amministratore e registrata nell'audit trail. Non è un hard-delete automatico: l'account può avere collaboratori e progetti collegati, quindi resta reversibile fino all'evasione.
7	Consenso versionato ai Termini	Versione e data di accettazione memorizzate; se il testo cambia, viene richiesta la ri-accettazione con banner dedicato.
28	Rapporto responsabile / titolare	Modello di DPA (accordo sul trattamento) con obblighi del responsabile, misure di sicurezza, sub-responsabili e notifica delle violazioni, da allegare al contratto.
32	Sicurezza del trattamento	Identità verificata lato server, log append-only, integrità verificabile su richiesta, cifratura in transito, backup cifrati.
33	Notifica delle violazioni	Integrata nella procedura incidenti: notifica al Garante entro 72 ore in caso di rischio per gli interessati.

Titolarità dei log d'impianto

I log scritti dal runtime restano sui sistemi del cliente, che ne è titolare autonomo del trattamento. Opscadia non vi accede se non su richiesta esplicita di assistenza.

12. Collaboratori e controllo a distanza

La gestione dei collaboratori tratta dati personali di persone che spesso sono lavoratori: email, nome, progetti assegnati, scadenza dell'accesso, log di IP e azioni, tempo attivo per progetto. Quest'ultimo dato, in presenza di lavoratori subordinati, ricade nell'art. 4 dello Statuto dei Lavoratori.

Interruttore del tracciamento: flag a livello di titolare dell'account. Quando è disattivato, la raccolta del tempo attivo di produttività cessa e la relativa tabella sparisce dall'interfaccia; i log di accesso e sicurezza, che hanno base giuridica distinta, restano. La modifica del flag è tracciata nell'audit trail.
Informativa specifica per i collaboratori (art. 13 GDPR) fornita come modello, con reminder nell'interfaccia di creazione a consegnarla prima del primo accesso.
Retention differenziata anche su questi log, documentata nell'informativa.
Eliminazione di un collaboratore subordinata a conferma con password del titolare.
Cancellazione GDPR tracciata: pseudonimizzazione con rottura registrata della catena, mai una cancellazione silenziosa.

Resta in capo al cliente

Valutare se i collaboratori sono lavoratori subordinati e, in tal caso, ottenere l'accordo sindacale o l'autorizzazione dell'Ispettorato del lavoro prima di attivare il monitoraggio del tempo. Lo strumento fornisce l'interruttore; la legittimità dell'uso è una decisione del titolare.

13. Account e dati fiscali

Validazione formale del Codice destinatario SDI (7 caratteri alfanumerici) e della PEC, applicata in registrazione e in modifica.
Dati aziendali (ragione sociale, P.IVA, codice fiscale, indirizzo) raccolti per gli adempimenti di fatturazione ai sensi del D.Lgs. 127/2015 e del DPR 633/1972.
Conservazione decennale dei documenti contabili ai sensi dell'art. 2220 c.c. e della normativa fiscale italiana.
Emissione e conservazione sostitutiva delle fatture: la piattaforma raccoglie i dati necessari ma non genera né invia fatture elettroniche — l'emissione e l'archiviazione a norma avvengono al di fuori della piattaforma.
Sezione «Privacy e dati» nell'account, che raccoglie export dei dati, richiesta di cancellazione e riferimento all'informativa.

14. Limiti dichiarati

Elencati esplicitamente: un elenco di conformità senza limiti non è verificabile, ed è il primo segnale che un auditor cerca.

Limite	Conseguenza pratica
Validazione IQ/OQ/PQ non fornita	La qualifica dell'installazione resta a carico dell'utilizzatore regolamentato. Opscadia fornisce l'evidenza tecnica, non il dossier di validazione.
Firma elettronica limitata al batch record	Le singole scritture di processo sono tracciate e attribuite, ma non firmate ai sensi di §11.200.
Management of Change non esteso a ogni campo di progetto	Copre allarmi e scritture di processo; altre modifiche di configurazione sono coperte dall'audit trail delle azioni, con granularità inferiore.
Righe antecedenti alle migrazioni prive di hash	Non verificabili crittograficamente; la verifica riparte dal primo record con catena, senza dichiarare rotture false.
Nessun client IEC 61850 MMS nativo	La qualità 61850 arriva tramite gateway od OPC UA.
Time-tag di sorgente assente su alcuni protocolli	Su S7, Modbus, MC resta il timestamp di scansione, dichiarato come tale.
Canvas PFC grafico non implementato (ISA-88 Parte 2)	Le strutture dati sono conformi (ordinamento sequenziale, parallelo, selettivo, cicli); l'editor è ad albero annidato. È una scelta di priorità, non un limite del modello dati.
Enterprise / Site / Area non modellati	Appartengono al dominio ISA-95, fuori dallo scope del controllo batch.
MFA non disponibile sugli utenti di progetto del runtime	La MFA copre gli account della piattaforma; l'autenticazione degli operatori di impianto resta a fattore singolo con sessione lato server.
Sessioni di runtime in memoria	Un riavvio del runtime chiude tutte le sessioni — evento a sua volta registrato.
Fatturazione elettronica non emessa dalla piattaforma	Emissione e conservazione a norma avvengono all'esterno.
Nessuna certificazione di prodotto	Nessuna delle norme citate la prevede. Chi la promette per un software SCADA sta descrivendo altro.

15. Ripartizione delle responsabilità

Ambito	Opscadia	Cliente / utilizzatore
Integrità dei record	Meccanismi append-only, catena di hash, verifica, export	Configurare utenti e retention, conservare gli export, eseguire le verifiche periodiche
Validazione	Documentazione tecnica, matrici requisito ↔ implementazione, test	IQ/OQ/PQ, validazione di processo, procedure operative
Allarmi	Motore, KPI, vincoli di norma applicati	Alarm philosophy dell'impianto, razionalizzazione, riesame periodico delle metriche
Batch	Modelli ISA-88, BPR, firme	Ricette, approvazioni, ruoli di firma e di revisione QA
Dati personali nei log d'impianto	Ruolo di responsabile o fornitore, secondo il DPA	Titolare del trattamento: informative, base giuridica, richieste degli interessati
Sicurezza dell'installazione	Prodotto sicuro per default, header, cifratura, aggiornamenti	Segmentazione di rete, TLS sul runtime, gestione fisica degli accessi, aggiornamenti applicati
NIS 2	Funzioni tecniche e risposte al questionario fornitori	Perimetro di applicabilità, registrazione presso l'autorità, notifiche

16. Documentazione disponibile su richiesta

Per una valutazione fornitori, un audit del cliente o un'ispezione sono disponibili, su richiesta e sotto riservatezza:

matrici requisito ↔ implementazione clausola per clausola: log di runtime, allarmi, ISA-88, audit trail della piattaforma;
documento di alarm philosophy;
modello di DPA ai sensi dell'art. 28 GDPR;
modello di informativa per i collaboratori (art. 13 GDPR);
procedura di gestione degli incidenti di sicurezza con i modelli di notifica;
descrizione dello schema dei log e legenda dei valori codificati.

17. Contatti

Domande di conformità, questionari fornitori, richieste di documentazione: info@opscadia.com.
Segnalazione di vulnerabilità: vedi Sicurezza e segnalazione vulnerabilità.
Trattamento dei dati personali: vedi Privacy Policy.

Questa pagina viene aggiornata a ogni modifica sostanziale dell'implementazione. Alcune funzionalità descritte richiedono una versione minima del software: fare riferimento alle release notes.