Sicurezza e conformità: il nostro stato reale, norma per norma
Questa pagina non contiene badge di conformità generici. Un badge non dice niente. Dice tutto invece dichiarare, norma per norma, con il riferimento all'articolo, cosa si applica a noi, cosa no, e cosa abbiamo implementato, così puoi verificare.
Tra il 2025 e il 2027 sei atti europei cambiano come si progetta, si vende e si documenta il software: European Accessibility Act, Cyber Resilience Act, NIS2, AI Act, la nuova direttiva sulla responsabilità da prodotto e DORA. Li abbiamo letti nei testi ufficiali EUR-Lex e Gazzetta Ufficiale. Questa è la fotografia della nostra posizione, aggiornata ad agosto 2026.
Quella che segue è la lettura tecnica di chi sviluppa software, non una consulenza legale.
regolamenti europei letti nei testi ufficiali
risposte di sicurezza pubblicate, in anticipo
fonti verificate su EUR-Lex e Gazzetta Ufficiale
badge di conformità generici
La nostra posizione, a colpo d'occhio
-
AI Act - implementato e attivo
Trasparenza (art. 50) e alfabetizzazione (art. 4) in produzione: contenuti generati marcati, revisione umana registrata, formazione tracciata. Il dettaglio è nella sezione qui sotto.
-
NIS2 - non soggetti, supplier-ready
Siamo sotto le soglie dell'art. 3 del D.Lgs. 138/2024. Ma se il tuo ufficio sicurezza deve valutarci come fornitori (art. 24 c.3), le dieci risposte sono già pubblicate in questa pagina.
-
Cyber Resilience Act - fuori ambito
I nostri SaaS non sono «prodotti con elementi digitali» (art. 3, Reg. 2024/2847). Adottiamo comunque le pratiche che il CRA renderà standard: inventario dei componenti e gestione delle vulnerabilità.
-
Accessibility Act - esenti, attrezzati
Le microimprese di servizi sono esentate (art. 3 c.3, D.Lgs. 82/2022). Ma gli e-commerce dei nostri clienti possono essere soggetti: progettiamo checkout, identificazione e pagamento già accessibili.
-
Responsabilità da prodotto - pronti
Dal 9/12/2026 il software è «prodotto» e la mancanza di aggiornamenti di sicurezza pesa (Dir. 2024/2853, art. 11). Nei nostri contratti chi mantiene cosa, e per quanto, è scritto, non implicito.
-
DORA - non applicabile, contratti pronti
Riguarda le entità finanziarie (Reg. 2022/2554). Se è il tuo settore, le clausole dell'art. 30 località dei dati, SLA, restituzione dei dati sono già il nostro standard su ogni progetto.
AI Act: non un impegno, un'implementazione
Programma interno documentato con matrice requisito → codice → evidenza (luglio 2026), attivo in produzione su AraLith COS. L'assistente Aralìx si presenta come IA al primo contatto, su tutte le nostre piattaforme (art. 50 c.1).
Il dettaglio, norma per norma
Le date, i regimi transitori e gli articoli che sostengono ogni affermazione delle card qui sopra.
Reg. (UE) 2024/1689
AI Act: date, trasparenza e cosa abbiamo attivato
Applicazione scaglionata (art. 113): divieti e disposizioni generali dal 2 febbraio 2025, modelli per finalità generali e sanzioni dal 2 agosto 2025, applicazione generale dal 2 agosto 2026, alto rischio incorporato in prodotti armonizzati dal 2 agosto 2027.
Per un CMS con funzioni AI gli obblighi concreti stanno nell'art. 50: informare chi interagisce con un'IA, marcare gli output sintetici in formato leggibile meccanicamente, dichiarare il testo generato pubblicato per informare il pubblico salvo revisione umana con responsabilità editoriale. È il processo che abbiamo implementato: ogni modifica AI su contenuti pubblicati passa da una coda di approvazione con revisore e data registrati. I nostri sistemi non rientrano nelle categorie ad alto rischio dell'Allegato III.
Approfondimento: gli obblighi di trasparenza dell'articolo 50.
D.Lgs. 138/2024 (dir. UE 2022/2555)
NIS2: chi è soggetto, cosa chiede ai fornitori, quali termini
Sono soggetti i medi e grandi operatori dei settori degli Allegati I-II, più alcune categorie a prescindere dalle dimensioni e le PA (art. 3). Una piccola software house non è soggetta, ma subisce gli obblighi dei clienti regolati: l'art. 24 c.3 impone loro di valutare «le pratiche di sicurezza informatica dei propri fornitori, comprese le procedure di sviluppo sicuro».
I termini non sono una data di calendario: decorrono dalla comunicazione individuale dell'Agenzia per la Cybersicurezza Nazionale 9 mesi per le notifiche, 18 per governance e misure (art. 42). Sanzioni fino a 10 milioni di euro o al 2% del fatturato mondiale per i soggetti essenziali (art. 38), con responsabilità personale degli organi di amministrazione.
Approfondimento: che cosa chiede la NIS2 ai fornitori software.
Reg. (UE) 2024/2847
Cyber Resilience Act: tre date, il transitorio, il confine del SaaS
Tre date di applicazione (art. 71): organismi di valutazione dall'11 giugno 2026, obblighi di segnalazione delle vulnerabilità attivamente sfruttate dall'11 settembre 2026, requisiti pieni dall'11 dicembre 2027.
Il transitorio (art. 69) contiene il punto che quasi nessuno racconta: i prodotti già sul mercato sfuggono ai requisiti finché non subiscono una modifica sostanziale, ma non sfuggono agli obblighi di segnalazione. Il confine per noi: un SaaS puro non è un «prodotto con elementi digitali» (art. 3) i nostri SaaS sono fuori ambito; inventario dei componenti, gestione delle vulnerabilità e periodo di supporto dichiarato li adottiamo comunque.
Approfondimento: le tre date del Cyber Resilience Act e il transitorio.
D.Lgs. 82/2022 (dir. UE 2019/882)
European Accessibility Act: chi riguarda, da quando, chi è esente
In vigore dal 28 giugno 2025, con tre regimi transitori: prodotti già in uso legittimo fino al 2030, contratti anteriori fino a scadenza (max 5 anni), terminali self-service fino a 20 anni. L'e-commerce è incluso fra i servizi (art. 1 c.3), senza soglie di fatturato; per un negozio online i requisiti specifici riguardano identificazione, sicurezza e pagamento (Allegato I).
Le microimprese che forniscono servizi meno di 10 persone e fino a 2 milioni di fatturato sono esentate (art. 3 c.3): è la nostra condizione. Le sanzioni vanno da 5.000 a 40.000 euro; il «5% del fatturato» che circola online appartiene a un'altra legge e riguarda solo i privati sopra i 500 milioni.
L'esenzione riguarda i nostri obblighi, non le nostre competenze. Conosciamo i criteri WCAG e li applichiamo da anni: su richiesta realizziamo siti, e-commerce e applicazioni pienamente conformi WCAG 2.0/2.1 livello AA. Per i clienti che rientrano nell'ambito EAA, e per chi vuole l'accessibilità come standard a prescindere dagli obblighi.
Approfondimento: chi riguarda l'European Accessibility Act e da quando.
Dir. (UE) 2024/2853
Responsabilità da prodotto: il software è un prodotto, gli aggiornamenti contano
La nuova direttiva include esplicitamente il software nella definizione di prodotto (art. 4) e si applica ai prodotti immessi sul mercato dopo il 9 dicembre 2026 stessa data del termine di recepimento nazionale, il cui stato va verificato al momento in cui leggi.
Il punto che cambia il mestiere: la difesa «il difetto non esisteva alla consegna» non vale quando il difetto deriva dalla mancanza degli aggiornamenti di sicurezza necessari, se il software è sotto il controllo del fabbricante (art. 11 c.2). È il motivo per cui nei nostri contratti chi mantiene cosa, e per quanto, è scritto. Il danno risarcibile (art. 6) copre le persone sempre, ma esclude beni e dati usati esclusivamente a fini professionali.
Approfondimento: il software come prodotto secondo la direttiva 2024/2853.
Reg. (UE) 2022/2554
DORA: quando il tuo fornitore software deve firmare certe clausole
Si applica dal 17 gennaio 2025 alle entità finanziarie banche, istituti di pagamento e di moneta elettronica, imprese di investimento, assicurazioni. Non si applica ai loro fornitori in quanto tali: arriva ai fornitori attraverso il contratto.
L'art. 30 elenca cosa deve contenere qualsiasi contratto di servizi TIC con un'entità finanziaria: località di esecuzione e conservazione dei dati, SLA, assistenza sugli incidenti a costo predefinito, cooperazione con le autorità e la clausola che condividiamo di più la restituzione dei dati in un formato accessibile se il fornitore cessa l'attività. Per noi non è una novità imposta: la portabilità completa di codice e dati è già il nostro standard, in ogni settore.
Approfondimento: che cosa finisce nei contratti dei fornitori ICT.
Il questionario NIS2, già compilato
Se la tua azienda è un soggetto essenziale o importante, l'art. 24 c.2 del D.Lgs. 138/2024 elenca dieci categorie di misure che devi presidiare — anche verso i fornitori. Prima o poi il tuo ufficio sicurezza ci manderebbe un questionario su queste dieci voci: ecco le risposte, in anticipo.
Ogni progetto parte da una discovery che censisce dati trattati, integrazioni e vincoli normativi del cliente; le decisioni di sicurezza sono documentate nel repository insieme al codice, con ADR (architecture decision record) per le scelte strutturali. Le piattaforme hanno istruzioni di sicurezza scritte e versionate che coprono header, upload, escaping, autorizzazioni, CORS, sessioni e logging.
Il canale di notifica è concordato con ogni cliente in fase contrattuale, di solito la PEC e la segnalazione avviene senza ingiustificato ritardo. Per gli eventi che coinvolgono l'infrastruttura, i tempi dipendono anche dalle notifiche dei fornitori di hosting, secondo la catena di responsabilità GDPR. I log applicativi sono centralizzati con accesso ristretto agli amministratori, le azioni rilevanti sono tracciate con utente e data, e un referente tecnico unico conosce l'intero sistema: la diagnosi non attraversa passaggi di consegne.
Backup giornalieri sull'infrastruttura delle piattaforme SaaS; il codice vive in repository Git con storia completa, replicata fuori dal server di produzione. Per i progetti su misura la strategia di backup è definita nel contratto insieme al cliente, in base ai suoi requisiti di continuità.
Le dipendenze software sono gestite con lockfile versionati (Composer, npm): ogni componente di terze parti è censito con versione esatta, di fatto una distinta base del software. I fornitori infrastrutturali critici (hosting, provider AI) sono pochi, noti e nominabili su richiesta in sede contrattuale.
Content-Security-Policy con nonce su ogni script, escaping sistematico dei template, autorizzazioni verificate lato server su ogni endpoint, segreti cifrati at-rest nel database, aggiornamento periodico delle dipendenze sulla base degli advisory di sicurezza. Le vulnerabilità scoperte internamente sono trattate come bug bloccanti, con fix documentato.
Audit interni documentati e datati l'ultimo programma completo, sulla governance AI, è del luglio 2026 con matrice requisito→implementazione→evidenza e revisione delle pratiche a ogni cambiamento normativo rilevante, con le fonti primarie citate nei documenti interni.
Sulla piattaforma è attivo un sistema di alfabetizzazione con guide obbligatorie, presa visione tracciata per utente e per versione del documento, e blocco dell'area amministrativa in caso di mancata conferma: la formazione non è dichiarata, è dimostrabile con un report esportabile.
Trasporto sempre su TLS; chiavi API e segreti di configurazione cifrati at-rest nel database con cifratura applicativa; nessuna credenziale in chiaro nei log i contenuti sensibili sono mascherati di default anche nel visualizzatore log interno.
Ruoli e permessi verificati lato server su ogni rotta amministrativa; gli strumenti più sensibili (log, configurazioni) sono ristretti agli amministratori; le azioni di modifica rilevanti registrano chi le ha compiute e quando. Gli asset (domini, server, repository, servizi) sono censiti e riconducibili a un responsabile unico.
Sì, su tutte le nostre piattaforme: accesso con OTP via email come secondo fattore sia su AraLith COS sia su AralithPulse; su AralithPulse è attiva anche la sessione singola per account — un nuovo accesso invalida il precedente.
Fonti: Reg. (UE) 2024/1689 (AI Act) · D.Lgs. 138/2024 (NIS2) · Reg. (UE) 2024/2847 (CRA) · D.Lgs. 82/2022 (EAA) · Dir. (UE) 2024/2853 (responsabilità da prodotto) · Reg. (UE) 2022/2554 (DORA) — verificate sui testi ufficiali di EUR-Lex e Gazzetta Ufficiale, ultimo aggiornamento agosto 2026.
Questa pagina descrive pratiche reali e verificabili; non è una certificazione né una consulenza legale.
Il tuo ufficio sicurezza ha altre domande?
Rispondiamo ai questionari di sicurezza dei fornitori con la stessa trasparenza di questa pagina. Se una risposta è «non lo facciamo», la trovi scritta così.
