ISO 27001 richiede il penetration test? Controlli 8.8, 8.29 e 5.35

Non per nome. La ISO/IEC 27001:2022 ha due livelli e in nessuno dei due c'è un requisito che dica «esegui un penetration test».

• I capitoli da 4 a 10 sono i requisiti del sistema di gestione. Il capitolo sullo scopo, che la ISO pubblica liberamente, dice che escluderne anche uno solo non è accettabile quando un'organizzazione dichiara la conformità. Coprono contesto, leadership, valutazione e trattamento del rischio, supporto, attività operative, valutazione delle prestazioni (compreso l'audit interno) e miglioramento.
• L'Annex A è l'insieme di riferimento dei controlli. È normativo ed elenca per titolo i 93 controlli della ISO/IEC 27002:2022. Determini i controlli che ti servono con il trattamento del rischio, li confronti con l'Annex A perché nessuno venga omesso per errore (punto 6.1.3 c)) e registri nella Dichiarazione di applicabilità quali controlli si applicano e perché (6.1.3 d)).

Nessuno dei 93 titoli è «penetration test». I controlli che i test documentano più spesso sono l'8.8, gestione delle vulnerabilità tecniche, e l'8.29, test di sicurezza nello sviluppo e nell'accettazione; vicino a loro ci sono il 5.35, riesame indipendente della sicurezza delle informazioni, e l'8.34, protezione dei sistemi informativi durante i test di audit.

La risposta onesta ha quindi due metà. Nessuno può indicare un requisito della ISO/IEC 27001 che dica «penetration test annuale». E un'organizzazione con sistemi esposti su internet che dichiara l'8.8 attuato ed efficace senza alcun test tecnico a sostegno fa proprio l'affermazione che un auditor di certificazione tende ad approfondire.

I titoli che seguono vengono dall'indice della ISO/IEC 27002:2022, che l'Annex A della ISO/IEC 27001:2022 riprende; li riportiamo in traduzione. Il testo dei controlli è nella norma a pagamento: leggilo lì prima di scrivere la Dichiarazione di applicabilità.

• 8.8 Management of technical vulnerabilities (gestione delle vulnerabilità tecniche). È la sede delle scansioni di vulnerabilità e il posto naturale dei risultati dei penetration test, perché un test mostra quali vulnerabilità sono davvero sfruttabili. La tabella di corrispondenza dell'ENISA per il regolamento di esecuzione NIS2 2024/2690 associa il requisito sulla gestione delle vulnerabilità (punto 6.10) al solo 8.8.
• 8.29 Security testing in development and acceptance (test di sicurezza nello sviluppo e nell'accettazione). Come dice il titolo, i test di sicurezza durante lo sviluppo e prima dell'accettazione in produzione; test di sicurezza applicativa e penetration test prima del rilascio sono le evidenze abituali. L'ENISA associa il requisito sui test di sicurezza del regolamento (punto 6.5) all'8.29, all'8.33 (informazioni di test) e all'8.34.
• 8.34 Protection of information systems during audit testing (protezione dei sistemi informativi durante i test di audit). Il controllo da citare quando testi sistemi in produzione. In pratica significa concordare perimetro, tempi e tecniche ammesse con i responsabili dei sistemi prima di iniziare, e metterlo per iscritto.
• 5.35 Independent review of information security (riesame indipendente della sicurezza delle informazioni). Un riesame indipendente di come gestisci la sicurezza delle informazioni, non un requisito per ogni test tecnico. L'ENISA associa il requisito del regolamento sul riesame indipendente (punto 2.3) ai punti 9.2 e 10.1 e ai controlli 5.35 e 8.34.

Intorno ci sono i requisiti del sistema di gestione che danno peso ai test: valutazione e trattamento del rischio (6.1.2, 6.1.3, 8.2, 8.3), monitoraggio e misurazione (9.1), audit interno (9.2), riesame di direzione (9.3) e azioni correttive (10.2). Un finding che non entra nel piano di trattamento del rischio e non viene seguito fino alla chiusura è un'evidenza debole.

La certificazione è facoltativa. La ISO non certifica nessuno: lo fanno gli organismi di certificazione accreditati, e secondo la stessa ISO un certificato rilasciato da un organismo accreditato dà più fiducia perché un ente di accreditamento ne ha verificato la competenza. Un certificato fa sempre riferimento a un'edizione datata, oggi «ISO/IEC 27001:2022».

L'auditor valuta se i controlli che hai scelto sono attuati ed efficaci rispetto ai tuoi rischi. Le regole di accreditamento per la transizione al 2022, lo IAF MD 26, lo hanno scritto in modo esplicito: l'audit di transizione doveva coprire attuazione ed efficacia dei controlli nuovi o modificati e «non deve basarsi solo sull'esame documentale, in particolare per i controlli di sicurezza tecnologici».

In pratica, sull'8.8 e sull'8.29 aspettati domande come queste:

1. Dichiarazione di applicabilità: l'8.8 e l'8.29 sono inclusi? Se uno dei due è escluso, con quale motivazione?
2. Trattamento del rischio: dove compaiono le vulnerabilità tecniche nella valutazione dei rischi e quale trattamento hai scelto?
3. Procedura: come vieni a sapere delle vulnerabilità, come esegui scansioni, priorità e patch, chi decide sulle eccezioni?
4. Registrazioni: risultati delle scansioni, report di penetration test se il piano di trattamento li prevede, ticket di correzione e risultati dei retest.
5. Modifiche: quali test di sicurezza sono stati fatti prima dell'ultimo rilascio o dell'ultima modifica infrastrutturale significativa?
6. Seguito: i finding arrivano all'audit interno, al riesame di direzione e alle azioni correttive?

Se i tuoi documenti dicono «penetration test esterno annuale» e per l'ultimo anno manca il report, è una non conformità rispetto al tuo stesso SGSI, qualunque cosa dica la norma sui test.

Cadenza. La ISO/IEC 27001:2022 non fissa alcun intervallo per scansioni o penetration test. Lo stabilisci tu nel trattamento del rischio, e l'auditor verifica che discenda dalla valutazione dei rischi, sia scritto e sia stato rispettato. Se rispondi anche al PCI DSS 11.4 o al §500.5 NYDFS, il loro minimo di almeno un test ogni 12 mesi è un riferimento naturale; i sistemi esposti su internet e le modifiche significative giustificano di solito una cadenza più stretta. Vedi la guida mondiale agli obblighi di penetration test per normativa.

Indipendenza. La norma non richiede un penetration tester esterno né una certificazione particolare per chi testa. L'indipendenza di cui parla riguarda il sistema di gestione: l'audit interno del punto 9.2 e il riesame indipendente del 5.35. Per un test tecnico registra chi l'ha eseguito, con quali qualifiche e perché non sta verificando il proprio lavoro: un team interno può testare, ma non dovrebbe essere lo stesso team che ha costruito e gestisce i sistemi nel perimetro senza che nessun altro guardi.

L'organismo di certificazione è indipendente da te per definizione, ma verifica il tuo SGSI: non esegue il tuo penetration test e il suo audit non lo sostituisce.

Lo IAF MD 26:2023, il documento obbligatorio per gli organismi di certificazione accreditati, ha fissato un periodo di transizione di 36 mesi terminato il 31 ottobre 2025. Stabilisce che tutte le certificazioni basate sulla ISO/IEC 27001:2013 scadono o vengono ritirate alla fine del periodo di transizione.

Per chi valuta i fornitori, questo rende semplice un controllo: un certificato ISO/IEC 27001 accreditato presentato oggi deve riferirsi all'edizione 2022. L'audit di transizione doveva coprire l'analisi delle differenze, la Dichiarazione di applicabilità aggiornata, il piano di trattamento del rischio dove è cambiato, e l'attuazione e l'efficacia dei controlli nuovi o modificati.

Il nuovo insieme di controlli ha cambiato anche il posto in cui si registrano i test. L'edizione 2013 aveva 114 controlli in 14 capitoli; quella del 2022 ne ha 93 in quattro capitoli (controlli organizzativi, sulle persone, fisici e tecnologici), con 11 controlli nuovi, 24 accorpati e 58 aggiornati secondo lo IAF MD 26. Policy e report di test che citano ancora la numerazione del 2013 vanno aggiornati a quella del 2022.

Scritto nella norma:

• I capitoli da 4 a 10, con valutazione del rischio, trattamento del rischio e Dichiarazione di applicabilità, valutazione delle prestazioni, audit interno, riesame di direzione e azioni correttive.
• L'Annex A come insieme normativo di riferimento con cui confrontare i tuoi controlli, con l'8.8, l'8.29, l'8.34 e il 5.35 tra i suoi 93 controlli.

Basato sul rischio, deciso da te:

• Se eseguire penetration test, con quale perimetro, profondità e frequenza, e se con tester interni o esterni, purché la scelta discenda dalla valutazione dei rischi e sia documentata.

Regole di accreditamento, non la norma:

• Lo IAF MD 26 sulla transizione al 2022, compresa l'indicazione di non basarsi solo sull'esame documentale per i controlli tecnologici.

Non scritto da nessuna parte:

• Un penetration test annuale obbligatorio, un fornitore di test imposto, una certificazione del tester o l'idea che l'organismo di certificazione testi i tuoi sistemi.

1. Metti i test nel piano di trattamento del rischio. Indica i rischi che trattano (vulnerabilità sfruttabili nei sistemi esposti su internet e in quelli interni critici) e collegali all'8.8, all'8.29 e all'8.34 nella Dichiarazione di applicabilità.
2. Scrivi metodo e cadenza. Scansioni a calendario e dopo ogni modifica significativa; penetration test almeno annuali sui sistemi più importanti, dall'esterno della rete e con i privilegi di un utente ordinario. Vedi black box e gray box e vulnerability assessment e penetration test.
3. Pianifica i test in produzione secondo l'8.34. Perimetro, tempi, tecniche ammesse e approvazioni concordati con i responsabili dei sistemi prima di iniziare.
4. Testa prima della messa in esercizio secondo l'8.29. Lega i test di sicurezza ai rilasci e alle modifiche infrastrutturali, non solo al calendario.
5. Chiudi il ciclo. Ogni finding ha un responsabile, una data e un retest; i rischi accettati hanno un approvatore con nome e cognome; i risultati arrivano all'audit interno e al riesame di direzione.
6. Conserva il fascicolo. Report, qualifiche dei tester, esiti dei retest ed eccezioni, conservati secondo le tue regole sulle informazioni documentate, pronti per il prossimo audit di sorveglianza.

Zero Hunt è un red team AI autonomo per reti e infrastrutture: penetration test automatizzati su un'appliance on-premise, con AI privata e human in the loop. Non certifica nulla, non è un organismo di certificazione e non sostituisce l'audit interno, il riesame indipendente del 5.35 o un tester indipendente dove il tuo trattamento del rischio lo prevede. Cambia invece la quantità di evidenze tecniche disponibili tra un test annuale e l'altro.

• Mappatura sull'Annex A. La ISO/IEC 27001:2022 è uno dei 34 framework su cui il motore mappa i risultati, con tutti i 93 controlli dell'Annex A. I finding alimentano in automatico l'8.8 e l'8.29; controlli come il 5.35 e l'8.34 sono segnalati come evidenze da fornire tu, e il report ISO/IEC 27001 si può esportare.
• Black box e gray box, a calendario. Campagne dall'esterno e con i privilegi di un utente standard, eseguite una volta, ogni giorno, ogni settimana, ogni mese o con una pianificazione personalizzata, e dopo ogni modifica: i test seguono la cadenza stabilita dal tuo trattamento del rischio.
• Sfruttato, non solo rilevato. Ogni finding registra se la vulnerabilità è stata effettivamente sfruttata nel tuo ambiente, e ogni correzione si ritesta con la stessa prova.
• Approvazione umana dei passi rischiosi. Cinque livelli di autonomia stabiliscono cosa deve attendere un operatore: così i test sui sistemi in produzione restano dentro quanto concordato secondo l'8.34. Vedi human in the loop.
• Registri che reggono. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256, e i report esportati sono firmati ECDSA.
• Nessun dato del cliente lascia l'appliance. I modelli girano sull'appliance, senza servizi AI esterni: nessun fornitore AI esterno tratta ciò che i test trovano.

La certificazione ISO/IEC 27001 di Zero Hunt è in corso; lo stato aggiornato è nel Trust Center. Per capire come si inserisce nella tua Dichiarazione di applicabilità, prenota una call di readiness di 30 minuti.

• ISO/IEC 27001:2022, scheda e FAQ (ISO)
• ISO/IEC 27001:2022, anteprima sull'Online Browsing Platform: scopo e titoli dei capitoli (ISO)
• ISO/IEC 27002:2022, anteprima sull'Online Browsing Platform: introduzione (ISO)
• ISO/IEC 27002:2022, scheda (ISO)
• IAF MD 26:2023, Transition Requirements for ISO/IEC 27001:2022 (IAF, PDF)
• ENISA, NIS2 Technical Implementation Guidance, giugno 2025 (ENISA)
• ENISA, tabella di corrispondenza v1.2 con la ISO/IEC 27001:2022 e altri framework (ENISA, XLSX)