AuditRails supporta 8 framework di conformità pronti all’uso. Per ciascuno, tipi di evento specifici, garanzie di archiviazione e funzionalità della dashboard sono mappati direttamente sui controlli normativi, così puoi dimostrare la conformità senza raccolta manuale delle evidenze.
L’elenco autorevole è sempre GET https://app.auditrails.io/api/v1/frameworks. Se un framework non è presente in quella risposta, non è disponibile per l’attivazione.
Per iniziare
Prima di mappare gli eventi sui controlli, assicurati di essere configurato correttamente.
Abilita un framework di conformità
Vai su Impostazioni → Framework di conformità e attiva i framework rilevanti per la tua organizzazione. Ogni piano include la registrazione dei framework di conformità. Quanti puoi abilitare contemporaneamente dipende dal tuo piano: Starter Trails ne ottiene uno, scelto in fase di registrazione e bloccato; Framework Trails ne ottiene fino a tre, sostituibili in autonomia; Compliance Trails li ottiene tutti, inclusi gratuitamente.
Rivedi la checklist di conformità
Apri Dashboard → Conformità e seleziona il tuo framework. Ogni voce della checklist è mappata su un controllo specifico e ne mostra lo stato attuale.
Inizia a registrare gli eventi richiesti
Strumenta la tua applicazione per emettere i tipi di evento elencati per il tuo framework nelle sezioni seguenti. Usa l’SDK AuditRails o l’API REST.
Esegui la verifica automatica
Usa la funzione di verifica automatica nella dashboard di conformità per confermare che la tua catena di hash sia integra e che la copertura degli eventi richiesti sia soddisfatta.
Monitora i progressi
Monitora la checklist nel tempo. Ogni controllo diventa verde non appena AuditRails rileva gli eventi e la configurazione richiesti.
Riferimento framework
Il Regolamento UE sulla Resilienza Operativa Digitale (2022/2554) si applica alle entità finanziarie e ai loro fornitori ICT. Enfatizza la continuità operativa, le tempistiche degli incidenti e il rischio da terze parti.Scadenze di segnalazione: 4 ore (notifica iniziale), 72 ore (relazione intermedia), 1 mese (relazione finale). Registra gli eventi incident.detected e incident.notified per creare una traccia con timestamp per ciascuna scadenza.Conservazione: 5 anni (impostata automaticamente quando DORA è abilitato).Il requisito dell’Art.6 di DORA per la registrazione con catena di hash è soddisfatto nativamente. Ogni evento è concatenato con SHA-256, e puoi verificare la catena in qualsiasi momento tramite dashboard o API.
Gli obblighi GDPR spaziano dalla responsabilizzazione nel trattamento dei dati, alla gestione del consenso, ai diritti dell’interessato, alla notifica delle violazioni. Consulta la guida alla conformità GDPR per i passaggi di configurazione completi.Conservazione: 5 anni (impostata automaticamente quando GDPR è abilitato).consent.given richiede actor_id, metadata.legal_basis e metadata.purpose. Gli eventi privi di un campo richiesto vengono rifiutati in fase di ingestione, quindi una checklist superata significa che l’evidenza è realmente completa.
La Direttiva UE NIS2 (2022/2555) si applica alle entità essenziali e importanti. Impone la registrazione degli eventi di sicurezza, i controlli di accesso, il monitoraggio della supply chain e la segnalazione degli incidenti.Scadenze di segnalazione: 24 ore (allarme preventivo), 72 ore (notifica dell’incidente), 1 mese (relazione finale). incident.early_warning richiede actor_id, metadata.incident_id e metadata.authority.Conservazione: 5 anni (impostata automaticamente quando NIS2 è abilitato). Il Regolamento (UE) 2024/1689 si applica ai fornitori e utilizzatori di sistemi di IA. L’articolo 12 richiede che i sistemi ad alto rischio registrino automaticamente gli eventi lungo il loro ciclo di vita, esattamente ciò che offre un registro append-only con catena di hash.Conservazione: 10 anni, la più lunga tra tutti i framework supportati da AuditRails (impostata automaticamente quando l’EU AI Act è abilitato).aiact.model_inference_logged richiede actor_id, resource, metadata.system_id e metadata.model_id. I campi opzionali coprono input_hash, output_hash, risk_tier, decision e human_oversight, che è ciò che trasforma un log di inferenza grezzo in un’evidenza ai sensi dell’Art.12.
I controlli dell’Annex A di ISO 27001:2022 si mappano strettamente sulle capacità di registrazione, monitoraggio e integrità di AuditRails.Conservazione: 3 anni (impostata automaticamente quando ISO 27001 è abilitato).L’isolamento per tenant significa che la catena di hash di ogni cliente è indipendente. Una violazione nella catena di un tenant non può influenzare quella di un altro, soddisfacendo i controlli multi-tenant dell’A.5.23.
I Trust Services Criteria di SOC 2 richiedono di registrare eventi di accesso, attività di autenticazione, modifiche dei permessi e modifiche di configurazione, e di dimostrare che tali log non possano essere manomessi.Capacità chiave: registro di audit immutabile, archiviazione WORM, ruolo RBAC di revisore (accesso in sola lettura per i revisori), export CSV per pacchetti di evidenze.Conservazione: 1 anno (impostata automaticamente quando SOC 2 è abilitato).Il ruolo RBAC di revisore ti consente di concedere al tuo revisore esterno un accesso in sola lettura alla dashboard di conformità senza esporre le impostazioni di configurazione sensibili.
Il provvedimento del Garante italiano del 27 novembre 2008 (aggiornato nel 2009) sugli amministratori di sistema richiede che ogni accesso amministrativo ai sistemi che trattano dati personali sia individualmente attribuibile, completamente registrato, a prova di manomissione e conservato per almeno sei mesi.Conservazione: 1 anno, superiore al minimo di sei mesi previsto dal provvedimento (impostata automaticamente quando il framework è abilitato).admin.operation richiede actor_id, resource, metadata.operation_type, metadata.before e metadata.after. La coppia before/after è ciò che rende il record probante e non una semplice nota che qualcosa è cambiato.
Il Requisito 10 di PCI DSS v4.0 impone log di audit dettagliati per ogni accesso agli ambienti dei dati dei titolari di carta, con protezione da manomissione e ricerca per intervallo temporale.Conservazione: 1 anno (impostata automaticamente quando PCI DSS è abilitato). Questo soddisfa il minimo di 12 mesi del Requisito 10.7, con 3 mesi immediatamente disponibili.Ogni evento in AuditRails include per impostazione predefinita i campi actor_id, resource, action, timestamp, indirizzo IP ed esito, soddisfacendo il mandato del “record completo” del Requisito 10.3 senza configurazione aggiuntiva.
Conservazione in sintesi
Abilitare un framework innalza la tua conservazione effettiva al suo minimo. Dove più framework sono abilitati, vince il più lungo.
La conservazione non è di per sé una funzionalità legata al piano. Consulta Conservazione dei dati per capire come interagiscono il periodo base e i minimi dei framework.
Copertura multi-framework
Se la tua organizzazione deve soddisfare più framework contemporaneamente, AuditRails ne unisce i requisiti. Un singolo evento auth.login, ad esempio, soddisfa contemporaneamente SOC 2 CC6.2, PCI DSS 10.2.1 e NIS2 Art.21(2)(i).
Abilita tutti i framework applicabili prima di iniziare la registrazione. Questo garantisce che la dashboard di conformità monitori la copertura su tutti fin dal primo giorno e che venga applicato il periodo di conservazione corretto (il più lungo tra tutti i framework abilitati).
