Dovezi DMARC pentru ISO 27001, NIS2, DORA și GDPR

Totul începe când directorul financiar îi redirecționează CISO-ului un e-mail la 07:42.

„L-am trimis noi?”

Mesajul arată impecabil. Același logo, același subsol, același ton ca echipa de facturare. Susține că datele bancare au fost modificate. Numele afișat al expeditorului este corect. Domeniul nu este o eroare tipografică sau un domeniu cu asemănare vizuală. Atacatorul falsifică domeniul real.

La 08:15, echipa de securitate confirmă adevărul incomod: SPF există, dar este prea permisiv, DKIM este activat doar pentru platforma principală de e-mail, mai multe instrumente de marketing trimit mesaje nesemnate, DMARC este încă în mod de monitorizare, iar nimeni nu poate găsi ultima revizuire a politicii MTA-STS a domeniului. Organizația are „securitatea e-mailului” într-un set de prezentări, dar dovezile sunt răspândite în capturi de ecran DNS, portaluri ale furnizorilor, tichete Jira vechi și un fișier tabelar deținut de cineva care a plecat anul trecut.

La 10:30, departamentul juridic întreabă dacă pot fi implicate date cu caracter personal ale clienților. Conformitatea întreabă dacă situația este relevantă pentru raportarea NIS2. Un client din servicii financiare întreabă dacă organizația poate demonstra controale ale riscurilor TIC aliniate la DORA. Auditul intern întreabă cum se mapează acest lucru la ISO/IEC 27001:2022. Consiliul de administrație pune o întrebare mai simplă: „Cum a putut cineva să ne uzurpe identitatea?”

Această întrebare explică de ce, în 2026, autentificarea e-mailului nu mai este un subiect DNS de nișă. DMARC, SPF, DKIM, MTA-STS și TLS-RPT sunt controale care produc dovezi. Acestea reduc riscul de phishing și de falsificare a domeniului, dar creează și artefactele pe care auditorii le așteaptă: decizii de politică, responsabilități, cerințe tehnice de bază, răspunderea furnizorilor, jurnale, înregistrări de monitorizare, excepții, aprobări ale schimbărilor și declanșatori pentru răspunsul la incidente.

Problema de conformitate nu este „Avem DMARC?”. Problema este „Putem demonstra că autentificarea e-mailului este guvernată, monitorizată, revizuită și legată de risc?”

Lacuna de dovezi pe care auditorii continuă să o găsească

Un al doilea scenariu este la fel de frecvent. Auditul extern este în desfășurare într-o companie fintech aflată în creștere rapidă. Auditorul trece de la continuitatea activității la gestionarea incidentelor și îl întreabă pe CISO despre compromiterea e-mailului de business.

CISO explică faptul că societatea are filtre anti-phishing și instruire trimestrială de conștientizare în securitate.

Auditorul aprobă din cap, apoi cere ceva mai specific: „Arătați-mi guvernanța pentru DMARC, SPF și DKIM. Trebuie să văd responsabilitățile, înregistrările schimbărilor, evaluarea riscurilor, dovezile de monitorizare și modul în care acestea se leagă de igiena cibernetică NIS2 și de cadrul de management al riscurilor TIC DORA.”

În sală se lasă liniștea.

Echipa tehnică a implementat DMARC cu luni în urmă, dar SMSI nu are nicio referință de politică, niciun pachet central de dovezi, nicio legătură cu registrul riscurilor și nicio foaie de parcurs aprobată pentru impunerea politicii. Controlul poate exista tehnic, dar este invizibil pentru guvernanță.

Aceasta este lacuna de dovezi.

Un program matur de autentificare a e-mailului răspunde la șase întrebări de audit:

1. Ce domenii și subdomenii sunt în domeniul de aplicare?
2. Cine este responsabil pentru fiecare domeniu, zonă DNS, flux de e-mail și serviciu de trimitere?
3. Ce sisteme au voie să trimită mesaje în numele organizației?
4. Ce mecanisme de autentificare sunt aplicate, monitorizate și revizuite?
5. Cum sunt aprobate excepțiile, cum este acceptat riscul și cum sunt retrase excepțiile?
6. Ce dovezi demonstrează că acest control a funcționat în timp?

ISO/IEC 27001:2022 transformă acest subiect într-o problemă de sistem de management. Clauzele 4.1 până la 4.4 impun organizației să înțeleagă contextul, cerințele părților interesate, limitele domeniului de aplicare, interfețele și dependențele. Autentificarea e-mailului le atinge pe toate. Registratorul de domenii poate fi un furnizor. DNS poate fi găzduit în infrastructură cloud. CRM-ul, platforma de salarizare, instrumentul de facturare, furnizorul de automatizare de marketing și sistemul de suport pentru clienți pot trimite toate e-mailuri folosind brandul organizației.

Clauzele 5.1 până la 5.3 transformă acest subiect într-o problemă de leadership. Conducerea de vârf trebuie să atribuie responsabilități și să integreze securitatea informației în procesele de afaceri. O decizie DMARC de trecere de la p=none la p=quarantine sau p=reject poate afecta comunicările cu clienții, notificările financiare, integrarea personalului HR, campaniile de vânzări și furnizorii externalizați.

Clauzele 6.1.1 până la 6.1.3 impun evaluarea riscurilor, tratarea riscurilor, selectarea controalelor și o Declarație de aplicabilitate. Falsificarea domeniului trebuie tratată ca scenariu de risc, cu SPF, DKIM, DMARC, MTA-STS și TLS-RPT selectate ca parte a tratării riscului, acolo unde este cazul. Clauza 8.1 impune apoi planificare și control operațional, inclusiv control asupra proceselor, produselor și serviciilor furnizate extern care sunt relevante pentru SMSI.

Ce demonstrează fiecare control de autentificare a e-mailului

SPF, DKIM, DMARC, MTA-STS și TLS-RPT funcționează împreună, dar demonstrează lucruri diferite.

SPF și DKIM sunt semnale de identitate și integritate. DMARC este stratul de politică ce transformă aceste semnale în acțiuni ale destinatarilor. MTA-STS și TLS-RPT sprijină transportul securizat al e-mailurilor, contribuind la prevenirea riscurilor de downgrade și de configurare greșită.

Pentru auditori, valoarea mai profundă constă în dovezi repetabile. Rapoartele agregate DMARC arată cine trimite folosind domeniul organizației. Rapoartele TLS arată dacă livrarea criptată eșuează. Tichetele de schimbare arată dacă există guvernanță. Înregistrările furnizorilor arată dacă dependențele din lanțul de aprovizionare sunt cunoscute.

Includeți mai întâi domeniile în registrul activelor

Autentificarea e-mailului nu poate fi guvernată dacă domeniile nu sunt tratate ca active.

Politica de management al activelor pentru IMM-uri Politica de management al activelor - IMM include explicit domeniile și identitățile asociate e-mailului în domeniul de aplicare:

„Credențiale și servicii digitale: nume de domenii, certificate digitale, chei API, conturi de e-mail, autentificări cloud”

Din secțiunea „Domeniu de aplicare”, clauza de politică 2.2.4.

Pentru organizațiile mai mari, Politica de management al activelor la nivel enterprise Politica de management al activelor aplică aceeași logică:

„Active logice: nume de domenii, licențe, conturi de utilizator, configurații de referință”

Din secțiunea „Domeniu de aplicare”, clauza de politică 2.2.5.

Dacă domeniile sunt active, ele pot avea responsabili, niveluri de criticitate, cicluri de revizuire, dependențe față de furnizori, controale ale schimbărilor și locații ale dovezilor. Dacă sunt doar intrări DNS, ele rămân de obicei negestionate până când ceva se defectează.

Un registru al domeniilor și al serviciilor de trimitere a e-mailurilor, pregătit pentru audit, trebuie să includă:

Acest registru sprijină controlul ISO/IEC 27001:2022 Anexa A A.5.9 Inventarul informațiilor și al altor active asociate, A.8.9 managementul configurației, A.5.19 securitatea informației în relațiile cu furnizorii și A.5.23 securitatea informației pentru utilizarea serviciilor cloud. De asemenea, sprijină rezultatele NIST CSF 2.0 privind inventarul activelor, serviciilor, furnizorilor și criticității.

Utilizați managementul schimbărilor pentru deciziile DNS și de flux de e-mail

Autentificarea e-mailului se defectează atunci când managementul schimbărilor este slab. O echipă de vânzări adaugă o platformă de contactare. HR adoptă un instrument de urmărire a candidaților. Finanțele schimbă software-ul de facturare. Marketingul trece la un nou furnizor de servicii de e-mail. Fiecare decizie de afaceri creează un nou expeditor.

Politica de management al schimbărilor la nivel enterprise Politica de management al schimbărilor formulează explicit cerința privind dovezile:

„Toate cererile de schimbare, revizuirile, aprobările și dovezile-suport trebuie înregistrate în sistemul centralizat de management al schimbărilor.”

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.

Un tichet solid de schimbare pentru autentificarea e-mailului trebuie să includă:

• Justificarea de afaceri pentru noul expeditor.
• Domeniul sau subdomeniul afectat.
• Impactul asupra includerilor SPF sau asupra IP-ului de trimitere.
• Selectorul DKIM și deținerea cheii.
• Rezultatul testului de aliniere DMARC.
• Impactul asupra MTA-STS sau MX, dacă există.
• Clasificarea datelor pentru mesajele trimise.
• Referința revizuirii de securitate a furnizorului.
• Planul de revenire.
• Aprobarea de către responsabilul domeniului și securitate.
• Dovezi de testare post-implementare.
• Data revizuirii sau data expirării pentru setările temporare.

Aceasta este diferența dintre „un administrator DNS a modificat o înregistrare” și „SMSI a controlat o schimbare relevantă pentru risc”.

Un plan practic de 30 de zile pentru dovezi DMARC, SPF, DKIM și MTA-STS

Un CISO nu are nevoie de un proiect de transformare de șase luni pentru a îmbunătăți maturitatea dovezilor. Un sprint concentrat de 30 de zile poate produce o bază de referință defensabilă.

Săptămâna 1: Descoperiți domeniile, expeditorii și responsabilitățile

Exportați toate domeniile din registrator și de la furnizorul DNS. Extrageți datele despre fluxul de e-mail din gateway-ul de e-mail, CRM, helpdesk, platforma de marketing, sistemul de facturare și serviciile de notificare cloud. Construiți registrul domeniilor și al serviciilor de trimitere.

Includeți și domeniile parcate și înregistrările defensive. Domeniile parcate sunt adesea ignorate, dar pot fi în continuare abuzate dacă DMARC lipsește sau este slab.

Săptămâna 2: Corectați alinierea SPF și DKIM

Revizuiți SPF pentru mecanisme prea permisive, includeri învechite, furnizori dublați și riscuri privind limita de interogări. Pentru DKIM, identificați fiecare expeditor care nu semnează e-mailurile sau care semnează cu un domeniu ce nu se va alinia cu DMARC.

Nu aprobați un expeditor SaaS doar pentru că e-mailul funcționează. Aprobați-l deoarece:

• Furnizorul este listat în registrul serviciilor de trimitere.
• Configurația SPF și DKIM este documentată.
• Selectorii DKIM sunt inventariați.
• Deținerea cheilor și așteptările de revizuire sunt clare.
• Documentația de securitate a furnizorului susține gestionarea securizată a e-mailului.
• Responsabilul operațional acceptă orice excepție temporară.

Aici NIS2 și DORA devin practice. NIS2 Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale, inclusiv analiza riscului, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția și mentenanța securizate, evaluarea eficacității, igiena cibernetică, criptografia, controlul accesului și comunicațiile securizate. DORA Article 28 impune entităților financiare să gestioneze riscurile TIC asociate terților ca parte a cadrului de management al riscurilor TIC, inclusiv verificare prealabilă, așteptări contractuale, monitorizare și planificare de ieșire.

Dacă un furnizor de marketing trimite e-mailuri neautentificate folosind domeniul organizației, aceasta nu este doar o problemă de marketing. Este risc asociat furnizorilor, risc de uzurpare a brandului și prejudiciu potențial pentru clienți.

Săptămâna 3: Treceți DMARC la impunerea politicii

Modul de monitorizare este util, dar menținerea permanentă a p=none fără o foaie de parcurs aprobată reprezintă dovezi slabe.

Un plan defensabil de impunere DMARC trebuie să includă:

• Revizuirea inițială a rapoartelor agregate.
• Identificarea surselor legitime și nelegitime.
• Remedierea surselor legitime care eșuează.
• Validarea operațională a fluxurilor critice de e-mail.
• Creșterea graduală a politicii la pct=25, pct=50, pct=100.
• Trecerea de la p=none la p=quarantine.
• Trecerea la p=reject atunci când riscul și pregătirea organizației permit.
• Tratarea separată a subdomeniilor cu sp=.
• Registrul excepțiilor cu date de expirare.
• Aprobarea de către management a riscului rezidual.

Acest lucru sprijină ISO/IEC 27001:2022 Clauza 6.1.3 privind tratarea riscului și Clauza 8.1 privind planificarea și controlul operațional. De asemenea, oferă auditului intern o pistă clară: decizie, implementare, monitorizare, excepție, aprobare și revizuire.

Săptămâna 4: Validați MTA-STS, TLS-RPT și monitorizarea

MTA-STS este adesea omis, deoarece nu oprește falsificarea externă a brandului în același mod ca DMARC. Totuși, este foarte relevant pentru comunicații securizate și protecția informațiilor în tranzit. Acesta indică serverelor expeditoare compatibile că e-mailul către domeniul organizației trebuie livrat prin TLS și validează identitatea MX.

Politica privind controalele criptografice la nivel enterprise Politica privind controalele criptografice stabilește o bază clară pentru securitatea transportului:

„Securitatea transportului: TLS 1.2 sau superior (de preferat TLS 1.3)”

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.5.

Pentru IMM-uri, Politica privind controalele criptografice pentru IMM-uri Politica privind controalele criptografice - IMM include explicit transmiterea prin e-mail:

„Date transmise prin e-mail, VPN corporativ și portaluri web”

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.4.

Testarea trebuie să includă validarea TLS pentru MX, disponibilitatea fișierului de politică MTA-STS, starea certificatelor HTTPS, revizuirea rapoartelor TLS-RPT și înregistrări de triaj pentru eșecuri.

Mapați autentificarea e-mailului la ISO/IEC 27001:2022 Anexa A

Zenith Controls: Ghidul de conformitate încrucișată al Clarysec Zenith Controls ajută la conectarea dovezilor tehnice cu așteptările de audit din mai multe cadre. Nu este un set separat de controale. Este un ghid de mapare și audit pentru controalele ISO/IEC 27001:2022 și standardele conexe.

Pentru controlul ISO/IEC 27001:2022 Anexa A A.5.14 Transferul de informații, Zenith Controls explică relația cu criptografia:

„Transferul securizat al informațiilor se bazează pe controale criptografice, așa cum sunt detaliate în 8.24.”

Aceasta este relația dintre e-mailul de business, DKIM, MTA-STS și TLS. E-mailul este un canal de transfer al informațiilor. DKIM sprijină autenticitatea și integritatea mesajului. MTA-STS și TLS sprijină protecția transportului.

Pentru controlul din Anexa A A.8.24 Utilizarea criptografiei, Zenith Controls leagă criptografia de transferul informațiilor, confidențialitate, protecția informațiilor cu caracter personal (PII), clasificare și managementul vulnerabilităților. Pentru controalele din Anexa A A.8.15 Jurnalizare și A.8.16 Activități de monitorizare, ghidul conectează jurnalele și monitorizarea la managementul evenimentelor, colectarea dovezilor, revizuire, analiză și auditabilitate.

Politica de jurnalizare și monitorizare pentru IMM-uri Politica de jurnalizare și monitorizare - IMM prevede:

„Jurnalizarea trebuie activată și configurată acolo unde este disponibilă”

Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.5.1.1.

Politica de jurnalizare și monitorizare la nivel enterprise Politica de jurnalizare și monitorizare include:

„Comunicații externe și declanșatori ai regulilor de firewall”

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.6.

Pentru autentificarea e-mailului, comunicațiile externe trebuie să includă evenimente ale gateway-ului de e-mail, prelucrarea rapoartelor agregate DMARC, tendințe ale eșecurilor DKIM, infrastructură-sursă suspectă, eșecuri TLS-RPT și tentative de falsificare care declanșează triajul incidentelor.

Zenith Blueprint: Foaia de parcurs în 30 de pași pentru auditori Zenith Blueprint plasează acest subiect în validarea practică a controalelor. În faza Controale în acțiune, Pasul 20, acesta solicită echipelor să valideze securitatea serviciilor de rețea:

„Listați toate serviciile de rețea interne și externe (DNS, VPN, SMTP, DHCP, gateway-uri API etc.).

✓ Pentru fiecare, confirmați că utilizează protocoale securizate (de exemplu, DNSSEC, TLS 1.2+, SSH în loc de Telnet).
✓ Revizuiți modul în care accesul la fiecare serviciu este controlat (de exemplu, liste de permitere IP, autentificare, certificate).
✓ Dacă sunt gestionate de terți (de exemplu, DNS, SD-WAN, VPN găzduit), revizuiți clauzele de securitate din SLA sau din contractul cu furnizorul. Actualizați Registrul serviciilor și notați unde se află responsabilitățile de securitate, intern sau extern.”

Aplicat e-mailului, acest lucru devine un plan de lucru pentru DNS, SMTP, TLS, gateway-uri de e-mail găzduite, expeditori furnizori și limite de responsabilitate.

Mapare de conformitate încrucișată: un singur pachet de dovezi, mai multe obligații

Același pachet de dovezi poate sprijini ISO/IEC 27001:2022, NIS2, DORA, GDPR și NIST CSF 2.0 dacă este structurat corespunzător.

NIS2 este deosebit de relevantă pentru entitățile esențiale și importante, precum și pentru anumite categorii de infrastructură digitală și furnizori digitali. Article 20 transformă guvernanța securității cibernetice într-o responsabilitate a organului de conducere, iar Article 21 stabilește baza pentru managementul riscurilor. Dovezile privind autentificarea e-mailului ajută la demonstrarea faptului că comunicațiile securizate, relațiile cu furnizorii, gestionarea incidentelor, evaluarea eficacității și igiena cibernetică sunt operaționale, nu teoretice.

Pentru entitățile financiare, DORA se aplică din 17 ianuarie 2025. Articles 5 și 6 impun responsabilitatea organului de conducere și un cadru documentat de management al riscurilor TIC. Article 17 impune procese pentru detectarea, gestionarea, înregistrarea, clasificarea, escaladarea și remedierea incidentelor legate de TIC. Article 28 transformă managementul riscurilor TIC asociate terților într-o responsabilitate formală. Furnizorii de e-mail, platformele de marketing, sistemele de notificare a plăților și instrumentele de comunicare cu clienții pot deveni toate parte din acest lanț de dependențe TIC.

Pentru GDPR, întrebarea-cheie este dacă e-mailul este utilizat pentru prelucrarea datelor cu caracter personal. Article 5 include integritatea, confidențialitatea și responsabilitatea. Article 32 impune măsuri tehnice și organizatorice adecvate. Dacă facturile, mesajele HR, notificările de cont, tichetele de suport sau e-mailurile de integrare conțin date cu caracter personal, autentificarea e-mailului și securitatea transportului devin parte a dovezilor privind securitatea prelucrării.

Răspuns la incidente: când rapoartele devin avertizare timpurie

Rapoartele agregate DMARC nu sunt doar dovezi de conformitate. Ele sunt date de avertizare timpurie. O creștere bruscă a autentificărilor eșuate dintr-o infrastructură necunoscută poate indica falsificare activă, IT din umbră, configurare greșită la furnizor sau un expeditor compromis.

Conform NIS2 Article 23, entitățile esențiale și importante trebuie să notifice incidentele semnificative fără întârzieri nejustificate, folosind raportare etapizată care include avertizare timpurie, notificarea incidentului și raportare finală. Nu orice tentativă de falsificare este raportabilă, dar organizația trebuie să poată evalua severitatea, perturbarea operațională, pierderea financiară, impactul transfrontalier și prejudiciul pentru destinatari.

Conform DORA Article 17, entitățile financiare trebuie să definească și să implementeze un proces de gestionare a incidentelor legate de TIC, să înregistreze incidentele și amenințările cibernetice semnificative, să identifice cauzele principale, să utilizeze indicatori de avertizare timpurie, să clasifice după severitate și criticitatea serviciului, să atribuie roluri, să definească comunicările și să escaladeze incidentele majore. DORA Article 19 abordează apoi raportarea incidentelor majore legate de TIC.

Pentru GDPR, întrebarea este dacă evenimentul a cauzat distrugerea, pierderea, modificarea accidentală sau ilegală, divulgarea neautorizată a datelor cu caracter personal sau accesul neautorizat la acestea. Un e-mail falsificat care determină clienții să transmită date cu caracter personal unui atacator poate declanșa o evaluare a încălcării securității datelor cu caracter personal, chiar dacă sistemele interne nu au fost compromise.

Politica de audit și monitorizare a conformității la nivel enterprise Politica de audit și monitorizare a conformității explică de ce dovezile disciplinate contează:

„Pentru a genera dovezi defensabile și o pistă de audit în sprijinul solicitărilor autorităților de reglementare, procedurilor juridice sau cererilor clienților privind asigurarea controalelor.”

Din secțiunea „Obiective”, clauza de politică 3.4.

Politica de audit și monitorizare a conformității pentru IMM-uri Politica de audit și monitorizare a conformității - IMM adaugă o cerință privind calitatea dovezilor:

„Metadatele (de exemplu, cine le-a colectat, când și din ce sistem) trebuie documentate.”

Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2.3.

Prin urmare, un dosar de investigație DMARC trebuie să documenteze sursa raportului, ora colectării, analistul, domeniile afectate, IP-urile suspecte ale expeditorilor, rezultatele autentificării, evaluarea impactului asupra afacerii, deciziile luate și aprobarea închiderii.

Ce vor solicita auditorii

Auditorii folosesc formulări diferite, dar dovezile se suprapun.

Așteptați-vă la întrebări practice:

• Arătați rapoartele DMARC pentru ultimul trimestru.
• Arătați cum au fost revizuite.
• Arătați excepția pentru acest expeditor care eșuează.
• Arătați cine a aprobat această schimbare SPF.
• Arătați dacă selectorii DKIM sunt inventariați și revizuiți.
• Arătați cum este testat MTA-STS după schimbările gateway-ului de e-mail.
• Arătați cum intră evenimentele de falsificare în triajul incidentelor.
• Arătați cum sunt eliminați expeditorii furnizori la încetarea contractului.

O listă concisă de verificare pentru audit intern în 2026

Utilizați această listă de verificare ca punct de plecare pentru audit intern, testarea controalelor sau o revizuire a dovezilor privind autentificarea e-mailului.

• Toate domeniile și subdomeniile sunt listate în registrul activelor.
• Domeniile parcate și defensive au acoperire DMARC.
• Fiecare expeditor autorizat are un responsabil operațional și un responsabil tehnic.
• Înregistrările SPF sunt revizuite pentru includeri învechite și domeniu de aplicare excesiv de permisiv.
• DKIM este activat pentru expeditorii legitimi acolo unde este suportat.
• Selectorii DKIM sunt inventariați și revizuiți.
• DMARC este implementat pentru domeniile rădăcină și subdomeniile relevante.
• DMARC are o foaie de parcurs pentru impunere, nu monitorizare pe termen nedeterminat.
• Rapoartele agregate DMARC sunt revizuite la o cadență definită.
• MTA-STS este configurat pentru domeniile de e-mail inbound acolo unde este aplicabil.
• Rapoartele TLS-RPT sunt colectate și triate.
• Schimbările privind autentificarea e-mailului urmează managementul schimbărilor.
• Integrarea furnizorilor include cerințe privind trimiterea e-mailurilor.
• Încetarea relației cu furnizorii elimină includerile SPF, selectorii DKIM și permisiunile de trimitere.
• Excepțiile au proprietari ai riscului, date de expirare și controale compensatorii.
• Creșterile bruște ale falsificării și eșecurile de autentificare alimentează răspunsul la incidente.
• Dovezile includ metadate, sursă, dată, colector și sistem.
• Managementul primește periodic metrici și actualizări privind riscurile.

Zenith Blueprint, faza Managementul riscurilor, Pasul 14, recomandă crearea de tabele de mapare reglementară pentru obligațiile aplicabile:

„Pentru fiecare reglementare, dacă este aplicabilă, puteți crea un tabel simplu de mapare (care poate fi anexă la un raport) ce listează cerințele-cheie de securitate ale reglementării și controalele/politicile corespunzătoare din SMSI. Acest lucru nu este obligatoriu în ISO 27001, dar este un exercițiu intern util pentru a vă asigura că nimic nu a fost omis. De asemenea, impresionează auditorii/evaluatorii, deoarece arată că nu gestionați securitatea în vid, ci țineți cont de contextul juridic.”

Pentru autentificarea e-mailului, acel tabel devine puntea dintre realitatea tehnică DNS și asigurarea la nivelul consiliului de administrație.

Transformați autentificarea e-mailului în dovezi pregătite pentru audit

Clienții pot să nu întrebe niciodată dacă înregistrarea SPF are o sintaxă perfectă. Ei vor întreba dacă puteți proteja brandul, reduce riscul de phishing, securiza comunicațiile, gestiona furnizorii și demonstra că funcționează controalele.

Clarysec ajută organizațiile să transforme autentificarea e-mailului din setări tehnice fragile într-un sistem de control pregătit pentru audit. Următorul pas practic este o revizuire concentrată a dovezilor privind autentificarea e-mailului:

1. Construiți registrul domeniilor și al serviciilor de trimitere.
2. Mapați starea SPF, DKIM, DMARC, MTA-STS și TLS-RPT.
3. Identificați furnizorii, expeditorii din IT-ul din umbră și excepțiile.
4. Creați o foaie de parcurs pentru impunerea DMARC.
5. Validați dovezile privind managementul schimbărilor, jurnalizarea și răspunsul la incidente.
6. Legați dovezile de ISO/IEC 27001:2022, NIS2, DORA, GDPR și NIST CSF 2.0.
7. Pregătiți un pachet de dovezi pentru auditor folosind Zenith Blueprint, Zenith Controls și politicile Clarysec relevante.

Dacă organizația dumneavoastră se pregătește pentru certificarea ISO/IEC 27001:2022, conformitatea cu NIS2, asigurarea conformității cu DORA, revizuiri ale responsabilității conform GDPR sau chestionare de securitate ale clienților, începeți cu controalele pe care atacatorii le abuzează cel mai vizibil: domeniile, expeditorii și lanțul de încredere al e-mailului.

Descărcați Zenith Blueprint, utilizați Zenith Controls pentru maparea de conformitate încrucișată și derulați o revizuire de 30 de zile a dovezilor privind autentificarea e-mailului înainte ca următorul incident de falsificare sau următoarea solicitare de audit să forțeze conversația.