Revisioni degli accessi utente che superano ogni audit
Le revisioni degli accessi sono uno dei controlli più spesso non superati negli audit: raramente perché nessuno le ha eseguite, più spesso perché nessuno è in grado di dimostrare che siano state fatte correttamente.
Questo articolo copre i 11 framework che ControlMapping aveva mappato al momento della stesura. Da allora sono stati aggiunti DORA, CPS 234, Cyber Essentials il 2026-10-27; le relative pagine e la matrice di copertura li includono.

Pochi controlli sono tanto universali quanto frequentemente non superati come le revisioni degli accessi utente. Ogni framework prevede che qualcuno verifichi periodicamente che ogni persona abbia ancora bisogno degli accessi che possiede. La maggior parte delle organizzazioni esegue la revisione. Molte meno sono in grado di mostrare a un auditor che è stata completa, indipendente e seguita da azioni concrete.
Cosa richiedono i framework
| Framework | Controllo degli accessi | Collegamento |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01PR.AA-05 | Definizione dell'argomento |
| ISO 27001 | A.5.15A.5.16A.5.18A.8.3 | Crosswalk |
| CIS v8.1 | CIS 5.1CIS 6.1CIS 6.2CIS 6.7CIS 6.8CIS 3.3CIS 5.2CIS 5.3CIS 5.5CIS 5.6CIS 6.6CIS 12.5 | Crosswalk |
| SOC 2 | CC6.1CC6.2CC6.3 | Redazione |
| PCI DSS | 7.2.17.2.27.2.48.2.1 | Crosswalk |
| CMMC | AC.L2-3.1.1AC.L2-3.1.2 | Crosswalk |
| 800-53 | AC-2AC-3 | Crosswalk |
| HIPAA | §164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d) | Crosswalk |
| GDPR | Art.25(2)Art.32(1)(b) | Redazione |
| NIS2 | 11.111.211.5 | Crosswalk |
| Essential Eight | — | Nessuna mappatura nei nostri dati |
Dettaglio completo e motivazione di ogni collegamento: Controllo degli accessi nei framework →
PCI DSS è l'unico con una frequenza fissa: tutti gli account utente e i privilegi devono essere riesaminati almeno ogni sei mesi (7.2.4), così come gli account di applicazioni e di sistema (7.2.5.1). Gli auditor di SOC 2 verificano che l'accesso sia autorizzato, modificato e rimosso in modo appropriato (CC6.2, CC6.3) e cercano revisioni periodiche come evidenza. ISO 27001 richiede che i diritti di accesso siano riesaminati a intervalli regolari (A.5.18). HIPAA richiede la gestione dell'accesso alle informazioni e la revisione delle attività (§164.308(a)(4)). CMMC prevede che l'accesso sia limitato agli utenti e alle funzioni autorizzate (AC.L2-3.1.1, 3.1.2) e il principio del privilegio minimo.
Una revisione che supera l'audit
- Popolazione completa. Estrai l'elenco utenti direttamente dal sistema (un export, non un foglio di calcolo mantenuto a mano), inclusi gli account di servizio e quelli condivisi.
- Revisore corretto. Il proprietario del sistema o dei dati, oppure il responsabile di ciascun utente, non l'amministratore che ha concesso l'accesso.
- Contesto sufficiente. Mostra ai revisori il ruolo e il livello di accesso di ciascun utente, così che «approva» sia una decisione consapevole.
- Una decisione per account. Mantieni, modifica o rimuovi, con nome e data del revisore.
- Modifiche effettivamente applicate. Apri ticket per le rimozioni e conserva la prova del loro completamento.
- Evidenze conservate. Export, decisioni, ticket e approvazione, archiviati insieme.

Frequenza
Usa i sei mesi di PCI DSS come base per tutti i sistemi in ambito e riesamina i privilegi di accesso ogni trimestre. Se disponi di un SOC 2 Type II, assicurati che almeno una revisione (idealmente due) ricada in ciascun periodo di osservazione.
Cosa trovano gli auditor
- Approvazioni di routine: ogni account approvato in pochi minuti da qualcuno che non poteva saperlo.
- Popolazioni incomplete: la revisione ha coperto l'applicazione ma non il database, oppure gli account umani ma non quelli di servizio.
- Autoverifica: amministratori che approvano i propri accessi.
- Rimozioni non completate: la revisione prevedeva la rimozione, ma l'account esiste ancora mesi dopo.
- Ex dipendenti individuati dalla revisione: segno che il processo di offboarding non funziona, cosa che gli auditor verificheranno separatamente.
Punti chiave
- Le revisioni falliscono gli audit per mancanza di evidenze, non di impegno: popolazioni incomplete, autoverifica e rimozioni mai completate.
- Usa un export di sistema, il revisore corretto, una decisione per account e la prova delle modifiche.
- Revisioni semestrali (regola di PCI DSS) e trimestrali per i privilegi di accesso soddisfano tutti i framework.
- Limita il perimetro ai sistemi che contano e automatizza la parte operativa.
Renderla sostenibile
Automatizza l'export e i promemoria, esegui la revisione per sistema anziché per utente e limita il perimetro ai sistemi che contano: produzione, dati dei clienti, strumenti privilegiati e qualsiasi elemento nel perimetro di un framework. Una revisione più piccola ma ben documentata è preferibile a una revisione estesa che è sempre in ritardo.
Consulta le pagine degli argomenti Access Control e Privileged Access per ogni requisito con la sua fonte, e il nostro articolo sul riutilizzo delle evidenze tra SOC 2, ISO 27001 e PCI DSS.
Domande
Con quale frequenza vanno riesaminati gli accessi utente?
PCI DSS richiede che gli account utente e i privilegi di accesso siano riesaminati almeno ogni sei mesi (7.2.4). La maggior parte degli altri framework richiede una revisione periodica con una frequenza definita dall'organizzazione; trimestrale per i privilegi di accesso e semestrale per gli altri è una base comune.
Chi deve eseguire una revisione degli accessi?
Il proprietario del sistema o dei dati, oppure il responsabile dell'utente, non l'amministratore che ha concesso l'accesso. Gli auditor verificano l'indipendenza e un revisore consapevole.
Gli account di servizio richiedono revisioni degli accessi?
Sì. Gli auditor includono sempre più spesso gli account di servizio, condivisi e API nella popolazione da riesaminare; PCI DSS richiede esplicitamente la revisione periodica degli account di applicazioni e di sistema (7.2.5.1).
Dati aggiornati al 2026-10-27: i numeri di questo articolo sono calcolati dal crosswalk attuale e si aggiornano quando questo cambia. Crosswalk una tabella di corrispondenza pubblicata (NIST, ENISA, CIS, PCI SSC) stabilisce il collegamento · Redazione Giudizio di ControlMapping dove non esiste una tabella di corrispondenza; la motivazione è indicata · condivide solo un esito di CSF 2.0: da verificare, non è una mappatura · Nessuna mappatura nei nostri dati nessuna mappatura nei nostri dati; spesso si tratta di lavoro nuovo, ma verifica le note sulla copertura. Non è una consulenza di conformità.