Evidenza di change management che gli auditor accettano

In un audit SOC 2 Type II, il change management (CC8.1) è uno dei controlli più campionati: l'auditor seleziona modifiche nell'intero periodo e chiede di dimostrare che ciascuna sia stata autorizzata, testata e approvata prima della produzione. ISO 27001 (A.8.32), PCI DSS (6.5.1, 6.5.2) e il Regolamento di esecuzione NIS2 (punto 6.4) chiedono la stessa cosa con parole diverse. I team di ingegneria di solito svolgono il lavoro; a mancare sono le evidenze.

Cosa verificano gli auditor

Su un campione di modifiche, vogliono vedere:

1. La modifica è stata richiesta e descritta: un ticket o una pull request che spiega cosa e perché.
2. È stata revisionata da una persona diversa dall'autore: separazione dei compiti.
3. È stata testata prima della produzione, con i risultati.
4. È stata approvata prima del rilascio.
5. Ciò che è stato rilasciato corrisponde a ciò che è stato approvato: nessun codice non revisionato è arrivato in produzione.
6. La popolazione è completa: ogni modifica in produzione è passata dal processo, incluse infrastruttura e configurazione.

Evidenze che superano l'audit

• Protezione del branch: il branch principale richiede almeno una approvazione da parte di una persona diversa dall'autore, e controlli superati, prima del merge. Esporta le impostazioni e dimostra che non sono cambiate nel periodo.
• Deployment solo tramite pipeline: i rilasci in produzione avvengono solo dal branch protetto tramite CI/CD; gli ingegneri non possono effettuare push diretti.
• Record collegati: ogni rilascio è collegato alla pull request unita, che a sua volta è collegata al proprio ticket.
• Infrastructure as code soggetta alle stesse regole, così le modifiche infrastrutturali lasciano la stessa traccia.
• Un elenco completo delle modifiche esportato dallo strumento di rilascio per il periodo, da cui l'auditor può campionare.

Modifiche di emergenza

Ogni processo necessita di un percorso rapido per gli incidenti, e gli auditor se lo aspettano. Definiscilo: chi può approvare, con quale rapidità avviene la revisione successiva (entro uno o due giorni lavorativi è prassi comune) e come la modifica è collegata all'incidente. Poi assicurati che le modifiche di emergenza siano davvero rare.

Cosa fa fallire gli audit

• Amministratori con accesso diretto alla produzione che a volte aggirano la pipeline.
• Pull request auto-approvate, o revisioni effettuate solo da bot.
• Modifiche di configurazione effettuate in una console senza alcuna registrazione.
• Protezione del branch disattivata "temporaneamente" durante il periodo.
• Nessuna evidenza di test oltre a "CI superata", quando la modifica ne richiedeva di più.

Campionamento: cosa farà davvero l'auditor

In un SOC 2 Type II, l'auditor di norma chiede l'intera popolazione delle modifiche in produzione nel periodo, seleziona un campione (la dimensione dipende dalla popolazione e dalla metodologia dell'auditor) e chiede di mostrare, per ciascuna modifica campionata: la richiesta, la revisione da parte di una persona diversa dall'autore, i risultati dei test, l'approvazione e la corrispondenza tra ciò che è stato rilasciato e ciò che è stato approvato.

Ne derivano due conseguenze pratiche. Primo, la popolazione deve essere completa ed esportabile: se le modifiche possono arrivare in produzione per più di una via, ciascuna via richiede una registrazione. Secondo, una singola modifica campionata senza evidenze diventa un'eccezione nel report. È meno costoso correggere il processo in modo che le evidenze siano automatiche che ricostruirle durante l'audit.

La pagina SOC 2 CC8.1 mostra come il criterio si mappa su ISO 27001, PCI DSS e NIS2.

Un unico processo, ogni framework

Nei nostri dati, i requisiti di change management sono collegati tra i vari framework:

Direzione	Mappato	Correlazione debole	Nessuna mappatura
Hai SOC 2 → ti serve NIS2	47 di 49 (96%)	1	1	report →
Hai NIS2 → ti serve SOC 2	37 di 61 (61%)	0	24	report →

Un processo basato su pull request, con branch protetti e deployment solo tramite pipeline, soddisfa insieme SOC 2, ISO 27001, PCI DSS e NIS2. PCI DSS aggiunge alcuni elementi in più: la separazione tra pre-produzione e produzione (6.5.3), la mancata presenza di dati di account reali nei test (6.5.5) e la conferma dei requisiti di sicurezza dopo modifiche significative (6.5.2).

Vedi l'argomento Secure Development per i requisiti correlati e il nostro articolo su come riutilizzare le evidenze tra SOC 2, ISO 27001 e PCI DSS.

Domande

Le pull request valgono come approvazione delle modifiche per SOC 2?

Di solito sì, se il repository impone una revisione da parte di una persona diversa dall'autore prima del merge, il deployment è limitato al codice approvato e puoi dimostrarlo per un campione di modifiche nel periodo.

Come vanno gestite le modifiche di emergenza ai fini dell'audit?

Con un processo di emergenza definito: intervento immediato se necessario, poi revisione e approvazione successive entro un tempo stabilito, e una registrazione che collega la modifica all'incidente che l'ha giustificata.