ISO/IEC 27001: Nais certifica la progettazione e lo sviluppo di applicativi

Il 23 luglio 2026 Nais ha esteso il campo di applicazione della propria certificazione ISO/IEC 27001:2022 alla progettazione e allo sviluppo di applicativi, con certificato rilasciato da DNV Business Assurance Italy sotto accreditamento ACCREDIA. In parallelo, i controlli delle linee guida ISO/IEC 27034-3:2018 sulla sicurezza applicativa sono stati integrati nella Dichiarazione di Applicabilità e sottoposti a verifica dell’organismo di certificazione.

Non è una formalità documentale. In un SOC agentico il software non osserva soltanto: decide e agisce dentro l’infrastruttura del cliente. Sotto trovi perché il ciclo di sviluppo diventa parte della superficie di attacco del servizio, cosa è stato effettivamente certificato e cosa una certificazione non risolve.

L’estensione ISO/IEC 27001 in sintesi

• Oggetto: estensione del campo di applicazione di una certificazione ISO/IEC 27001:2022 già in essere.
• Ambito aggiunto: progettazione e sviluppo di applicativi.
• Data di rilascio: 23 luglio 2026.
• Organismo di certificazione: DNV Business Assurance Italy.
• Accreditamento: ACCREDIA.
• Linee guida adottate: ISO/IEC 27034-3:2018, con i relativi controlli dichiarati nella Dichiarazione di Applicabilità (SoA).
• Perimetro operativo interessato: la piattaforma Fluxstormdel SOC agentico Nais.
• Rilevanza normativa:due diligence sui fornitori, sicurezza della supply chain in ambito NIS2, requisiti di auditabilità e supervisione umana dell’AI Act.

Perché in un SOC agentico lo sviluppo software diventa il punto critico

Nel modello tradizionale di security operations il software del SOC osserva e segnala. Un errore di sviluppo produce un alert sbagliato, un dato mancante, al limite un falso negativo. È un problema serio ma circoscritto.

Nel modello agentico il perimetro cambia. Il sistema classifica, arricchisce, decide e agisce: su alcune classi di azione lo fa in autonomia, su altre chiede approvazione. In entrambi i casi il software smette di essere un osservatore e diventa un attore che opera dentro l’infrastruttura di qualcun altro.

Ne discende una conseguenza che riguarda chi quel software lo costruisce. Il ciclo di sviluppo entra a far parte della superficie di attacco del servizio, e le pratiche interne, per quanto solide, smettono di bastare come garanzia verso il cliente. Serve che qualcuno di esterno le verifichi.

A luglio abbiamo chiuso un carosello sul SOC agentico proprio su questa domanda: se l’intelligenza artificiale entra nel ciclo operativo di un SOC, la sicurezza del software che governa quel ciclo diventa un tema? La risposta che avevamo dato era netta: sì, e diventa il tema. Questo articolo racconta cosa abbiamo fatto per tenere fede a quell’affermazione.

Cosa è stato certificato

Il campo di applicazione della certificazione ISO/IEC 27001:2022 di Nais comprende ora la progettazione e lo sviluppo di applicativi. Il certificato è rilasciato da DNV Business Assurance Italy sotto accreditamento ACCREDIA, l’ente unico di accreditamento italiano.

Alla certificazione si affianca l’adozione dei controlli previsti dalle linee guida ISO/IEC 27034-3:2018, dedicate alla sicurezza applicativa, integrati nella Dichiarazione di Applicabilità del sistema di gestione.

ISO/IEC 27034-3 non è una norma certificabile

Su questo punto la confusione è frequente e vale la pena essere espliciti.

ISO/IEC 27034-3:2018 è una linea guida, non uno standard certificabile. Nessuna organizzazione può dichiararsi “certificata ISO/IEC 27034-3”, e chi lo fa sta comunicando qualcosa di tecnicamente scorretto.

Il modo corretto di utilizzarla è quello che abbiamo seguito: adottarne i controlli all’interno di un sistema di gestione certificato ISO/IEC 27001, dichiararli nella Dichiarazione di Applicabilità e sottoporli alla verifica dell’organismo di certificazione. La certificazione resta ISO/IEC 27001; la 27034-3 fornisce il riferimento tecnico per i controlli applicativi.

Cosa comporta in pratica portare lo sviluppo dentro un perimetro certificato

Non significa scrivere procedure nuove. Significa prendere processi che in gran parte esistono già e renderli dimostrabili a qualcuno che non lavora con te e che non ha nessuna ragione di fidarsi sulla parola.

Il lavoro si è concentrato su quattro aree.

1. Requisiti di sicurezza definiti all’inizio: Entrano nella progettazione insieme ai requisiti funzionali, anziché essere verificati alla fine.
2. Tracciabilità delle modifiche al codice: Una catena che collega la richiesta, l’approvazione, il rilascio e il responsabile di ciascun passaggio.
3. Ruoli e separazione delle responsabilità formalizzati: Un auditor non valuta le intenzioni, valuta i controlli effettivamente in essere.
4. Evidenze prodotte durante il lavoro: non ricostruite quando arriva la verifica.

Tracciabilità, supervisione umana e AI Act

Sull’ultimo punto conviene insistere, perché è quello che ha più a che fare con l’intelligenza artificiale.

Un sistema che decide in autonomia richiede che ogni passo lasci una traccia verificabile a posteriori. Senza quella traccia la supervisione umana resta una dichiarazione di intenti anziché un controllo, e in sede di audit la differenza tra le due cose è tutto.

È anche il punto in cui i requisiti di auditabilità e supervisione umana introdotti dall’AI Act smettono di essere un adempimento documentale e diventano una caratteristica del sistema. La logica è la stessa che regge la certificazione: una decisione che non si può ricostruire non è una decisione governata.

Perché conta che a verificare sia un terzo

Un’autodichiarazione di buone pratiche di sviluppo vale quanto la reputazione di chi la firma.

Una certificazione rilasciata da un organismo accreditato introduce un elemento diverso: un soggetto che non ha alcun interesse a confermare quello che gli racconti e che valuta le evidenze secondo criteri definiti da uno standard internazionale.

Per un cliente enterprise che gestisce una due diligence sui fornitori, o che deve dimostrare a sua volta la sicurezza della propria supply chain nel quadro NIS2, la distinzione è concreta e verificabile a partire dal certificato.

Cosa una certificazione non risolve

Una certificazione non rende sicuro un software. Attesta che esiste un sistema di gestione con controlli definiti, applicati e verificati, e che quel sistema copre anche il modo in cui il software viene progettato e sviluppato. È una condizione necessaria e non sufficiente, e proprio per questo ha senso dichiararla con precisione invece di trasformarla in uno slogan.

Il principio che guida il nostro lavoro sul SOC agentico resta lo stesso: l’autonomia dei sistemi può crescere solo se cresce insieme alla capacità di ricostruire ogni decisione presa e di dimostrarla a chi la chiede.

Domande frequenti

Nais è certificata ISO/IEC 27001 per lo sviluppo software?

Sì. Dal 23 luglio 2026 il campo di applicazione della certificazione ISO/IEC 27001:2022 di Nais include la progettazione e lo sviluppo di applicativi.

Chi ha rilasciato il certificato?

DNV Business Assurance Italy, organismo di certificazione operante sotto accreditamento ACCREDIA.

Ci si può certificare ISO/IEC 27034-3?

No. ISO/IEC 27034-3:2018 è una linea guida sulla sicurezza applicativa e non è una norma certificabile. I suoi controlli possono essere adottati all’interno di un sistema di gestione certificato ISO/IEC 27001, dichiarati nella Dichiarazione di Applicabilità e verificati dall’organismo di certificazione.

Che differenza c’è tra ISO/IEC 27001 e ISO/IEC 27034-3?

ISO/IEC 27001 è lo standard certificabile che definisce i requisiti di un sistema di gestione della sicurezza delle informazioni. ISO/IEC 27034-3 è una linea guida che fornisce indicazioni tecniche sulla sicurezza delle applicazioni. La prima si certifica, la seconda si adotta.

Cosa cambia per i clienti Nais?

La sicurezza del ciclo di sviluppo della piattaforma non è più un’autodichiarazione ma un elemento verificato da un terzo accreditato, documentabile in fase di due diligence sui fornitori e utilizzabile come evidenza nella gestione della supply chain in ambito NIS2.

Riferimenti:

ISO/IEC 27001:2022; ISO/IEC 27034-3:2018; certificato rilasciato da DNV Business Assurance Italy sotto accreditamento ACCREDIA in data 23 luglio 2026. Contenuto a scopo informativo, aggiornato al 10 settembre 2026; per la verifica del campo di applicazione fa fede il certificato.