Evidenze DMARC per ISO 27001, NIS2, DORA e GDPR

Tutto inizia con un direttore finanziario che alle 07:42 inoltra un’e-mail al CISO.

“L’abbiamo inviata noi?”

Il messaggio sembra perfetto. Stesso logo, stesso footer, stesso tono del team di fatturazione. Sostiene che le coordinate bancarie siano cambiate. Il nome visualizzato del mittente è corretto. Il dominio non è un refuso simile all’originale. L’attaccante sta effettuando spoofing del dominio reale.

Alle 08:15, il team di sicurezza conferma una verità scomoda: SPF esiste ma è troppo permissivo, DKIM è abilitato solo per la piattaforma e-mail principale, diversi strumenti di marketing inviano e-mail non firmate, DMARC è ancora in modalità di monitoraggio e nessuno riesce a trovare l’ultimo riesame della policy MTA-STS del dominio. L’organizzazione parla di “sicurezza della posta elettronica” in una presentazione, ma le evidenze sono disperse tra screenshot DNS, portali dei fornitori, vecchi ticket Jira e un foglio di calcolo gestito da una persona che ha lasciato l’azienda l’anno precedente.

Alle 10:30, la funzione legale chiede se possano essere coinvolti dati personali dei clienti. La funzione compliance chiede se l’evento sia rilevante ai fini della notifica NIS2. Un cliente del settore finanziario chiede se l’azienda sia in grado di dimostrare controlli del rischio ICT allineati a DORA. L’audit interno chiede come il tema si mappi su ISO/IEC 27001:2022. Il consiglio di amministrazione pone una domanda più semplice: “Perché qualcuno ha potuto impersonarci?”

Questa domanda spiega perché nel 2026 l’autenticazione delle e-mail non è più un tema DNS di nicchia. DMARC, SPF, DKIM, MTA-STS e TLS-RPT sono controlli che generano evidenze. Riducono il rischio di phishing e spoofing del dominio, ma producono anche gli artefatti che gli auditor si aspettano: decisioni di policy, titolarità, baseline tecniche, responsabilità dei fornitori, log, registrazioni di monitoraggio, eccezioni, approvazioni delle modifiche e trigger di risposta agli incidenti.

Il problema di conformità non è: “Abbiamo DMARC?”. È: “Possiamo dimostrare che l’autenticazione delle e-mail è governata, monitorata, riesaminata e collegata al rischio?”.

La lacuna di evidenze che gli auditor continuano a rilevare

Un secondo scenario è altrettanto comune. L’audit esterno è in corso presso una fintech in forte crescita. L’auditor passa dalla continuità operativa alla gestione degli incidenti e chiede al CISO informazioni sulla compromissione della posta elettronica aziendale.

Il CISO spiega che l’azienda dispone di filtri anti-phishing e di formazione e sensibilizzazione alla sicurezza trimestrale.

L’auditor annuisce, poi chiede qualcosa di più specifico: “Mostratemi la governance di DMARC, SPF e DKIM. Devo vedere la titolarità, le registrazioni delle modifiche, la valutazione del rischio, le evidenze di monitoraggio e il collegamento con l’igiene informatica NIS2 e con il quadro di gestione del rischio ICT DORA.”

Nella stanza cala il silenzio.

Il team tecnico ha implementato DMARC mesi prima, ma il SGSI non contiene alcun riferimento di policy, nessun pacchetto centrale di evidenze, nessun collegamento al registro dei rischi e nessuna roadmap approvata per l’applicazione della policy. Il controllo può esistere tecnicamente, ma è invisibile alla governance.

Questa è la lacuna di evidenze.

Un programma maturo di autenticazione delle e-mail risponde a sei domande di audit:

1. Quali domini e sottodomini rientrano nell’ambito di applicazione?
2. Chi è responsabile di ciascun dominio, zona DNS, flusso di posta e servizio di invio?
3. Quali sistemi sono autorizzati a inviare per conto dell’organizzazione?
4. Quali meccanismi di autenticazione sono applicati, monitorati e riesaminati?
5. Come vengono approvate le eccezioni, accettati i rischi e ritirate le deroghe?
6. Quali evidenze dimostrano che il controllo ha operato nel tempo?

ISO/IEC 27001:2022 rende questo tema una questione di sistema di gestione. Le clausole da 4.1 a 4.4 richiedono che l’organizzazione comprenda il contesto, i requisiti delle parti interessate, i confini dell’ambito di applicazione, le interfacce e le dipendenze. L’autenticazione delle e-mail li tocca tutti. Il registrar del dominio può essere un fornitore. Il DNS può essere ospitato su infrastruttura cloud. Il CRM, la piattaforma paghe, lo strumento di fatturazione, il provider di marketing automation e il sistema di assistenza clienti possono tutti inviare e-mail utilizzando il brand dell’organizzazione.

Le clausole da 5.1 a 5.3 rendono il tema una responsabilità della leadership. L’alta direzione deve assegnare responsabilità e integrare la sicurezza delle informazioni nei processi aziendali. Una decisione DMARC da p=none a p=quarantine o p=reject può incidere sulle comunicazioni ai clienti, sulle notifiche finanziarie, sull’onboarding HR, sulle campagne commerciali e sui fornitori esternalizzati.

Le clausole da 6.1.1 a 6.1.3 richiedono valutazione del rischio, trattamento del rischio, selezione dei controlli e una Dichiarazione di Applicabilità. Lo spoofing del dominio deve essere trattato come uno scenario di rischio, con SPF, DKIM, DMARC, MTA-STS e TLS-RPT selezionati come parte del trattamento, ove appropriato. La clausola 8.1 richiede quindi pianificazione e controllo operativi, compreso il controllo dei processi, prodotti e servizi forniti dall’esterno rilevanti per il SGSI.

Che cosa dimostra ciascun controllo di autenticazione delle e-mail

SPF, DKIM, DMARC, MTA-STS e TLS-RPT lavorano insieme, ma dimostrano aspetti diversi.

SPF e DKIM sono segnali di identità e integrità. DMARC è il livello di policy che trasforma quei segnali in un’azione del destinatario. MTA-STS e TLS-RPT supportano il trasporto sicuro delle e-mail contribuendo a prevenire rischi di downgrade e di errata configurazione.

Per gli auditor, il valore più profondo è la ripetibilità delle evidenze. I report aggregati DMARC mostrano chi invia come il dominio dell’organizzazione. I report TLS mostrano se la consegna cifrata non riesce. I ticket di modifica mostrano se esiste governance. Le registrazioni dei fornitori mostrano se le dipendenze della catena di fornitura sono note.

Inserire prima i domini nel registro degli asset

L’autenticazione delle e-mail non può essere governata se i domini non sono trattati come asset.

La Politica di gestione degli asset per PMI Politica di gestione degli asset - PMI include esplicitamente nell’ambito di applicazione domini e identità correlate alla posta elettronica:

“Credenziali e servizi digitali: nomi di dominio, certificati digitali, chiavi API, account e-mail, accessi cloud”

Dalla sezione “Ambito di applicazione”, clausola di policy 2.2.4.

Per le organizzazioni più grandi, la Politica di gestione degli asset Politica di gestione degli asset applica la stessa logica:

“Asset logici: nomi di dominio, licenze, account utente, baseline di configurazione”

Dalla sezione “Ambito di applicazione”, clausola di policy 2.2.5.

Se i domini sono asset, possono avere proprietari, livelli di criticità, cicli di riesame, dipendenze dai fornitori, controlli sulle modifiche e ubicazioni delle evidenze. Se sono solo voci DNS, di solito restano non gestiti finché qualcosa non si rompe.

Un registro dei domini e dei mittenti e-mail pronto per l’audit deve includere:

Questo registro supporta il controllo A.5.9 dell’Allegato A di ISO/IEC 27001:2022, Inventario delle informazioni e degli altri asset associati, A.8.9 gestione della configurazione, A.5.19 sicurezza delle informazioni nei rapporti con i fornitori e A.5.23 sicurezza delle informazioni per l’uso dei servizi cloud. Supporta inoltre gli outcome di inventario NIST CSF 2.0 per asset, servizi, fornitori e criticità.

Usare la gestione delle modifiche per le decisioni DNS e sui flussi di posta

L’autenticazione delle e-mail si rompe quando la gestione delle modifiche è debole. Un team commerciale aggiunge una piattaforma di outreach. HR adotta uno strumento di tracciamento dei candidati. La funzione finanza cambia software di fatturazione. Il marketing migra a un nuovo provider di servizi e-mail. Ogni decisione aziendale crea un nuovo mittente.

La Politica di gestione delle modifiche aziendale Politica di gestione delle modifiche rende esplicito il requisito relativo alle evidenze:

“Tutte le richieste di modifica, i riesami, le approvazioni e le evidenze a supporto devono essere registrati nel sistema centralizzato di gestione delle modifiche.”

Dalla sezione “Requisiti di applicazione della policy”, clausola di policy 6.1.1.

Un solido ticket di modifica per l’autenticazione delle e-mail deve includere:

• Giustificazione aziendale per il nuovo mittente.
• Dominio o sottodominio interessato.
• Impatto sugli include SPF o sugli IP di invio.
• Selector DKIM e titolarità della chiave.
• Risultato del test di allineamento DMARC.
• Impatto su MTA-STS o MX, se presente.
• Classificazione dei dati dei messaggi inviati.
• Riferimento al riesame di sicurezza del fornitore.
• Piano di rollback.
• Approvazione del proprietario del dominio e della funzione sicurezza.
• Evidenza dei test post-implementazione.
• Data di riesame o scadenza per impostazioni temporanee.

Questa è la differenza tra “un amministratore DNS ha modificato un record” e “il SGSI ha controllato una modifica rilevante per il rischio”.

Un piano pratico di 30 giorni per le evidenze DMARC, SPF, DKIM e MTA-STS

Un CISO non ha bisogno di un progetto di trasformazione di sei mesi per migliorare la maturità delle evidenze. Uno sprint mirato di 30 giorni può produrre una baseline sostenibile.

Settimana 1: individuare domini, mittenti e titolarità

Esportare tutti i domini dal registrar e dal provider DNS. Estrarre i dati dei flussi di posta dal gateway e-mail, dal CRM, dall’helpdesk, dalla piattaforma di marketing, dal sistema di fatturazione e dai servizi di notifica cloud. Costruire il registro dei domini e dei mittenti.

Includere anche i domini parcheggiati e le registrazioni difensive. I domini parcheggiati sono spesso ignorati, ma possono comunque essere abusati se DMARC è assente o debole.

Settimana 2: correggere l’allineamento SPF e DKIM

Riesaminare SPF per individuare meccanismi troppo permissivi, include obsoleti, provider duplicati e rischi legati ai limiti di lookup. Per DKIM, identificare ogni mittente che non firma la posta o che firma con un dominio non allineabile a DMARC.

Non approvare un mittente SaaS solo perché la posta funziona. Approvarlo perché:

• Il fornitore è presente nel registro dei mittenti.
• La configurazione SPF e DKIM è documentata.
• I selector DKIM sono inventariati.
• La titolarità delle chiavi e le aspettative di riesame sono chiare.
• La documentazione di sicurezza del fornitore supporta una gestione sicura della posta.
• Il proprietario del processo accetta eventuali eccezioni temporanee.

Qui NIS2 e DORA diventano concreti. L’Article 21 di NIS2 richiede misure tecniche, operative e organizzative adeguate e proporzionate, compresi analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, valutazione dell’efficacia, igiene informatica, crittografia, controllo degli accessi e comunicazioni sicure. L’Article 28 di DORA richiede agli enti finanziari di gestire il rischio ICT di terze parti nell’ambito del quadro di gestione del rischio ICT, includendo due diligence, aspettative contrattuali, monitoraggio e pianificazione dell’uscita.

Se un provider di marketing invia e-mail non autenticate utilizzando il dominio dell’organizzazione, non si tratta solo di un problema di marketing. È rischio dei fornitori, rischio di impersonificazione del brand e potenziale danno per i clienti.

Settimana 3: portare DMARC verso l’applicazione della policy

La modalità di monitoraggio è utile, ma un p=none permanente senza una roadmap approvata è una debole evidenza.

Un piano sostenibile di applicazione della policy DMARC deve includere:

• Riesame della baseline dei report aggregati.
• Identificazione delle fonti legittime e illegittime.
• Azioni correttive sulle fonti legittime non conformi.
• Validazione aziendale dei flussi di posta critici.
• Incremento graduale della policy a pct=25, pct=50, pct=100.
• Transizione da p=none a p=quarantine.
• Transizione a p=reject quando il rischio e la preparazione operativa lo consentono.
• Gestione separata dei sottodomini con sp=.
• Registro delle eccezioni con date di scadenza.
• Approvazione della direzione per il rischio residuo.

Questo supporta la clausola 6.1.3 di ISO/IEC 27001:2022 sul trattamento del rischio e la clausola 8.1 sulla pianificazione e controllo operativi. Offre inoltre all’audit interno una traccia chiara: decisione, attuazione, monitoraggio, eccezione, approvazione e riesame.

Settimana 4: convalidare MTA-STS, TLS-RPT e monitoraggio

MTA-STS viene spesso trascurato perché non blocca lo spoofing del brand in uscita allo stesso modo di DMARC. Tuttavia, è molto rilevante per le comunicazioni sicure e per la protezione delle informazioni in transito. Indica ai server di invio compatibili che la posta verso il dominio deve essere consegnata tramite TLS e convalida l’identità MX.

La Politica sui controlli crittografici aziendale Politica sui controlli crittografici definisce una baseline chiara per la sicurezza del trasporto:

“Sicurezza del trasporto: TLS 1.2 o superiore (preferibilmente TLS 1.3)”

Dalla sezione “Requisiti di applicazione della policy”, clausola di policy 6.1.1.5.

Per le PMI, la Politica sui controlli crittografici per PMI Politica sui controlli crittografici - PMI include esplicitamente la trasmissione via e-mail:

“Dati trasmessi tramite e-mail, VPN aziendali e portali web”

Dalla sezione “Requisiti di applicazione della policy”, clausola di policy 6.1.1.4.

I test devono includere la convalida TLS degli MX, la disponibilità del file di policy MTA-STS, lo stato di salute del certificato HTTPS, il riesame dei report TLS-RPT e le registrazioni di triage per gli errori.

Mappare l’autenticazione delle e-mail sull’Allegato A di ISO/IEC 27001:2022

Zenith Controls: la guida alla conformità trasversale di Clarysec Zenith Controls aiuta a collegare le evidenze tecniche alle aspettative di audit nei diversi quadri di riferimento. Non è un set di controlli separato. È una guida di mappatura e audit per i controlli ISO/IEC 27001:2022 e gli standard correlati.

Per il controllo A.5.14 dell’Allegato A di ISO/IEC 27001:2022 sul trasferimento delle informazioni, Zenith Controls spiega la relazione con la crittografia:

“Il trasferimento sicuro delle informazioni si basa sui controlli crittografici descritti in 8.24.”

Questa è la relazione tra e-mail aziendale, DKIM, MTA-STS e TLS. L’e-mail è un canale di trasferimento delle informazioni. DKIM supporta autenticità e integrità dei messaggi. MTA-STS e TLS supportano la protezione del trasporto.

Per il controllo A.8.24 dell’Allegato A sull’uso della crittografia, Zenith Controls collega la crittografia al trasferimento delle informazioni, alla tutela della privacy, alla protezione dei dati personali identificabili, alla classificazione e alla gestione delle vulnerabilità. Per i controlli A.8.15 registrazione degli eventi e A.8.16 attività di monitoraggio dell’Allegato A, la guida collega log e monitoraggio alla gestione degli eventi, alla raccolta delle evidenze, al riesame, all’analisi e alla verificabilità.

La Politica di registrazione e monitoraggio per PMI Politica di registrazione e monitoraggio - PMI stabilisce:

“La registrazione deve essere abilitata e configurata ove disponibile”

Dalla sezione “Requisiti di governance”, clausola di policy 5.5.1.1.

La Politica di registrazione e monitoraggio aziendale Politica di registrazione e monitoraggio include:

“Comunicazioni esterne e trigger delle regole del firewall”

Dalla sezione “Requisiti di applicazione della policy”, clausola di policy 6.1.1.6.

Per l’autenticazione delle e-mail, le comunicazioni esterne devono includere eventi dei gateway di posta, elaborazione dei report aggregati DMARC, tendenze dei fallimenti DKIM, infrastruttura sorgente sospetta, fallimenti TLS-RPT e tentativi di spoofing che attivano il triage degli incidenti.

Zenith Blueprint: una roadmap in 30 passaggi per l’auditor Zenith Blueprint colloca questo tema nella convalida pratica dei controlli. Nella fase Controlli in azione, passaggio 20, indica ai team di convalidare la sicurezza dei servizi di rete:

“Elencare tutti i servizi di rete interni ed esterni (DNS, VPN, SMTP, DHCP, gateway API, ecc.).

✓ Per ciascuno, confermare che utilizzi protocolli sicuri (ad esempio DNSSEC, TLS 1.2+, SSH invece di Telnet).
✓ Riesaminare come è controllato l’accesso a ciascun servizio (ad esempio liste di autorizzazione IP, autenticazione, certificati).
✓ Se gestiti da terze parti (ad esempio DNS, SD-WAN, VPN ospitata), riesaminare le clausole di sicurezza nello SLA o nel contratto con il fornitore. Aggiornare il registro dei servizi e annotare dove risiedono le responsabilità di sicurezza, interne o esterne.”

Applicato alla posta elettronica, questo diventa un piano di lavoro per DNS, SMTP, TLS, gateway di posta ospitati, mittenti dei fornitori e confini di responsabilità.

Mappatura di conformità trasversale: un solo pacchetto di evidenze, molti obblighi

Lo stesso pacchetto di evidenze può supportare ISO/IEC 27001:2022, NIS2, DORA, GDPR e NIST CSF 2.0 se è strutturato correttamente.

NIS2 è particolarmente rilevante per i soggetti essenziali e importanti e per alcune categorie di infrastrutture digitali e provider digitali. L’Article 20 attribuisce la governance della cybersicurezza alla responsabilità dell’organo di gestione, mentre l’Article 21 stabilisce la baseline di gestione del rischio. Le evidenze di autenticazione delle e-mail aiutano a dimostrare che comunicazioni sicure, rapporti con i fornitori, gestione degli incidenti, valutazione dell’efficacia e igiene informatica sono operativi, non teorici.

Per gli enti finanziari, DORA si applica dal 17 gennaio 2025. Gli Articles 5 e 6 richiedono responsabilità dell’organo di gestione e un quadro documentato di gestione del rischio ICT. L’Article 17 richiede processi per rilevare, gestire, registrare, classificare, segnalare internamente e rimediare agli incidenti connessi all’ICT. L’Article 28 rende la gestione del rischio ICT di terze parti una responsabilità formale. Provider e-mail, piattaforme di marketing, sistemi di notifica dei pagamenti e strumenti di comunicazione con i clienti possono tutti diventare parte di questa catena di dipendenze ICT.

Per GDPR, la domanda chiave è se l’e-mail sia utilizzata per trattare dati personali. L’Article 5 include integrità, riservatezza e responsabilizzazione. L’Article 32 richiede misure tecniche e organizzative adeguate. Se fatture, messaggi HR, avvisi sugli account, ticket di supporto o e-mail di onboarding contengono dati personali, l’autenticazione delle e-mail e la sicurezza del trasporto diventano parte delle evidenze relative alla sicurezza del trattamento.

Risposta agli incidenti: quando i report diventano allerta precoce

I report aggregati DMARC non sono solo evidenze di conformità. Sono dati di allerta precoce. Un picco di autenticazioni fallite da infrastrutture sconosciute può indicare spoofing attivo, shadow IT, errata configurazione di un fornitore o un mittente compromesso.

Ai sensi dell’Article 23 di NIS2, i soggetti essenziali e importanti devono notificare gli incidenti significativi senza indebito ritardo, mediante una segnalazione per fasi che include allerta precoce, notifica dell’incidente e relazione finale. Non ogni tentativo di spoofing è soggetto a segnalazione, ma l’organizzazione deve essere in grado di valutarne gravità, interruzione operativa, perdita finanziaria, impatto transfrontaliero e danno ai destinatari.

Ai sensi dell’Article 17 di DORA, gli enti finanziari devono definire e implementare un processo di gestione degli incidenti connessi all’ICT, registrare gli incidenti e le minacce informatiche significative, identificare le cause radice, utilizzare indicatori di allerta precoce, classificare per gravità e criticità del servizio, assegnare ruoli, definire comunicazioni ed effettuare l’escalation degli incidenti gravi. L’Article 19 di DORA disciplina poi la segnalazione degli incidenti gravi connessi all’ICT.

Per GDPR, la domanda è se l’evento abbia causato distruzione, perdita, modifica, divulgazione non autorizzata o accesso non autorizzato a dati personali in modo accidentale o illecito. Un’e-mail contraffatta che induce i clienti a trasmettere dati personali a un attaccante può attivare una valutazione di violazione dei dati personali, anche se i sistemi interni non sono stati compromessi.

La Politica di audit e monitoraggio della conformità aziendale Politica di audit e monitoraggio della conformità spiega perché la disciplina delle evidenze è importante:

“Generare evidenze sostenibili e una traccia di audit a supporto di richieste dell’autorità di regolamentazione, procedimenti legali o richieste di assurance da parte dei clienti.”

Dalla sezione “Obiettivi”, clausola di policy 3.4.

La Politica di audit e monitoraggio della conformità per PMI Politica di audit e monitoraggio della conformità - PMI aggiunge un requisito di qualità delle evidenze:

“I metadati (ad esempio chi li ha raccolti, quando e da quale sistema) devono essere documentati.”

Dalla sezione “Requisiti di applicazione della policy”, clausola di policy 6.2.3.

Un fascicolo di indagine DMARC deve quindi documentare la fonte del report, l’ora di raccolta, l’analista, i domini interessati, gli IP mittenti sospetti, i risultati di autenticazione, la valutazione di impatto aziendale, le decisioni assunte e l’approvazione della chiusura.

Che cosa chiederanno gli auditor

Auditor diversi usano linguaggi diversi, ma le evidenze si sovrappongono.

Aspettatevi domande pratiche:

• Mostrate i report DMARC dell’ultimo trimestre.
• Mostrate come sono stati riesaminati.
• Mostrate l’eccezione per questo mittente non conforme.
• Mostrate chi ha approvato questa modifica SPF.
• Mostrate se i selector DKIM sono inventariati e riesaminati.
• Mostrate come viene testato MTA-STS dopo modifiche al gateway di posta.
• Mostrate come gli eventi di spoofing entrano nel triage degli incidenti.
• Mostrate come i mittenti dei fornitori vengono rimossi alla risoluzione del contratto.

Una checklist sintetica di audit interno per il 2026

Utilizzare questa checklist come punto di partenza per l’audit interno, i test dei controlli o un riesame delle evidenze di autenticazione delle e-mail.

• Tutti i domini e sottodomini sono elencati nel registro degli asset.
• I domini parcheggiati e difensivi hanno copertura DMARC.
• Ogni mittente autorizzato ha un proprietario del processo e un proprietario tecnico.
• I record SPF sono riesaminati per include obsoleti e ambito eccessivo.
• DKIM è abilitato per i mittenti legittimi, ove supportato.
• I selector DKIM sono inventariati e riesaminati.
• DMARC è distribuito per i domini radice e i sottodomini rilevanti.
• DMARC dispone di una roadmap di applicazione, non di monitoraggio indefinito.
• I report aggregati DMARC sono riesaminati con una cadenza definita.
• MTA-STS è configurato per i domini di posta in ingresso, ove applicabile.
• I report TLS-RPT sono raccolti e sottoposti a triage.
• Le modifiche all’autenticazione delle e-mail seguono la gestione delle modifiche.
• L’onboarding dei fornitori include requisiti di invio e-mail.
• L’offboarding dei fornitori rimuove include SPF, selector DKIM e autorizzazioni di invio.
• Le eccezioni hanno Titolari del rischio, date di scadenza e controlli compensativi.
• I picchi di spoofing e i fallimenti di autenticazione alimentano la risposta agli incidenti.
• Le evidenze includono metadati, fonte, data, raccoglitore e sistema.
• La direzione riceve metriche periodiche e aggiornamenti sul rischio.

Zenith Blueprint, fase di Gestione dei rischi, passaggio 14, raccomanda di creare tabelle di mappatura normativa per gli obblighi applicabili:

“Per ciascuna normativa, se applicabile, è possibile creare una semplice tabella di mappatura (eventualmente come appendice a un report) che elenchi i principali requisiti di sicurezza della normativa e i controlli/le politiche corrispondenti nel SGSI. Questo non è obbligatorio in ISO 27001, ma è un utile esercizio interno per assicurarsi che nulla sia sfuggito. Dimostra inoltre agli auditor/valutatori che la sicurezza non è gestita nel vuoto, ma con consapevolezza del contesto legale.”

Per l’autenticazione delle e-mail, quella tabella diventa il ponte tra la realtà tecnica del DNS e l’assurance a livello di consiglio di amministrazione.

Trasformare l’autenticazione delle e-mail in evidenze pronte per l’audit

I clienti potrebbero non chiedere mai se il record SPF ha una sintassi perfetta. Chiederanno se l’organizzazione è in grado di proteggere il proprio brand, ridurre il rischio di phishing, rendere sicure le comunicazioni, gestire i fornitori e dimostrare che i controlli funzionano.

Clarysec aiuta le organizzazioni a trasformare l’autenticazione delle e-mail da impostazioni tecniche fragili a un sistema di controlli pronto per l’audit. Il passo pratico successivo è un riesame mirato delle evidenze di autenticazione delle e-mail:

1. Costruire il registro dei domini e dei mittenti.
2. Mappare lo stato di SPF, DKIM, DMARC, MTA-STS e TLS-RPT.
3. Identificare fornitori, mittenti shadow ed eccezioni.
4. Creare una roadmap di applicazione DMARC.
5. Convalidare le evidenze di gestione delle modifiche, registrazione e risposta agli incidenti.
6. Collegare le evidenze a ISO/IEC 27001:2022, NIS2, DORA, GDPR e NIST CSF 2.0.
7. Preparare un pacchetto di evidenze pronto per l’auditor utilizzando Zenith Blueprint, Zenith Controls e le politiche Clarysec pertinenti.

Se la vostra organizzazione si sta preparando alla certificazione ISO/IEC 27001:2022, alla preparazione NIS2, all’assurance DORA, ai riesami di responsabilizzazione GDPR o ai questionari di sicurezza dei clienti, iniziate dai controlli che gli attaccanti abusano nel modo più visibile: i vostri domini, i vostri mittenti e la vostra catena di fiducia e-mail.

Scaricate Zenith Blueprint, utilizzate Zenith Controls per la mappatura di conformità trasversale ed eseguite un riesame di 30 giorni delle evidenze di autenticazione delle e-mail prima che il prossimo incidente di spoofing o la prossima richiesta di audit imponga la conversazione.