Důkazní podklady DMARC pro ISO 27001, NIS2, DORA a GDPR

Začíná to tím, že finanční ředitel v 07:42 přepošle e-mail řediteli informační bezpečnosti.

„Odeslali jsme to my?“

Zpráva vypadá dokonale. Stejné logo, stejná patička, stejný tón jako u fakturačního týmu. Tvrdí, že se změnily bankovní údaje. Zobrazované jméno odesílatele je správné. Doména není podobně vypadající překlep. Útočník podvrhuje skutečnou doménu.

V 08:15 bezpečnostní tým potvrzuje nepříjemnou skutečnost: SPF existuje, ale je příliš široké, DKIM je zapnuto pouze pro hlavní e-mailovou platformu, několik marketingových nástrojů odesílá nepodepsané e-maily, DMARC je stále v režimu monitorování a nikdo nedokáže najít poslední přezkum politiky MTA-STS pro danou doménu. Organizace má „zabezpečení e-mailu“ v prezentaci pro vedení, ale důkazní podklady jsou rozptýlené mezi snímky obrazovky DNS, portály dodavatelů, starými tikety Jira a tabulkou, kterou spravoval někdo, kdo odešel už loni.

V 10:30 se právní oddělení ptá, zda mohly být dotčeny osobní údaje zákazníků. Tým compliance se ptá, zda je událost relevantní pro hlášení podle NIS2. Zákazník z finančního sektoru se ptá, zda společnost dokáže doložit opatření řízení rizik v oblasti ICT v souladu s DORA. Interní audit se ptá, jak to navazuje na ISO/IEC 27001:2022. Správní rada pokládá jednodušší otázku: „Proč se za nás někdo mohl vydávat?“

Právě tato otázka je důvodem, proč autentizace e-mailu v roce 2026 už není úzce technické téma DNS. DMARC, SPF, DKIM, MTA-STS a TLS-RPT jsou opatření vytvářející důkazní podklady. Snižují riziko phishingu a podvržení domény, ale zároveň vytvářejí artefakty, které auditoři očekávají: rozhodnutí o politikách, vlastnictví, technické baseline, odpovědnost dodavatelů, protokoly, záznamy z monitorování, výjimky, schválení změn a spouštěče reakce na incidenty.

Problém souladu nezní: „Máme DMARC?“ Zní: „Umíme prokázat, že autentizace e-mailu je řízená, monitorovaná, přezkoumávaná a navázaná na rizika?“

Mezera v důkazních podkladech, kterou auditoři stále nacházejí

Druhý scénář je stejně běžný. Ve rychle rostoucí fintechové společnosti probíhá externí audit. Auditor přechází od kontinuity činností k řízení incidentů a ptá se ředitele informační bezpečnosti na kompromitaci firemní e-mailové komunikace.

Ředitel informační bezpečnosti vysvětluje, že společnost má antiphishingové filtry a čtvrtletní školení bezpečnostního povědomí.

Auditor přikývne a poté požádá o něco konkrétnějšího: „Ukažte mi řízení DMARC, SPF a DKIM. Potřebuji vidět vlastnictví, záznamy změn, posouzení rizik, důkazy z monitorování a vazbu na kybernetickou hygienu podle NIS2 a rámec řízení rizik v oblasti ICT podle DORA.“

V místnosti se rozhostí ticho.

Technický tým implementoval DMARC před několika měsíci, ale ISMS neobsahuje žádný odkaz na politiku, žádný centrální balíček důkazních podkladů, žádnou vazbu na registr rizik a žádný schválený plán přechodu k vynucování. Opatření může technicky existovat, ale z pohledu správy a řízení je neviditelné.

To je mezera v důkazních podkladech.

Vyspělý program autentizace e-mailu odpovídá na šest auditních otázek:

1. Které domény a subdomény jsou v rozsahu?
2. Kdo vlastní jednotlivé domény, zóny DNS, tok pošty a odesílací služby?
3. Které systémy smějí odesílat jménem organizace?
4. Které autentizační mechanismy jsou vynucovány, monitorovány a přezkoumávány?
5. Jak jsou schvalovány výjimky, přijímána rizika a ukončována dočasná povolení?
6. Jaké důkazní podklady prokazují, že opatření v čase fungovalo?

ISO/IEC 27001:2022 z toho činí otázku systému řízení. Kapitoly 4.1 až 4.4 vyžadují, aby organizace rozuměla kontextu, požadavkům zainteresovaných stran, hranicím rozsahu, rozhraním a závislostem. Autentizace e-mailu se dotýká všech těchto oblastí. Registrátor domény může být dodavatelem. DNS může být hostováno v cloudové infrastruktuře. CRM, mzdová platforma, fakturační nástroj, poskytovatel marketingové automatizace i systém zákaznické podpory mohou všechny odesílat e-maily s využitím vaší značky.

Kapitoly 5.1 až 5.3 z toho činí otázku vedení. Vrcholové vedení musí přiřadit odpovědnosti a začlenit bezpečnost informací do obchodních procesů. Rozhodnutí přejít u DMARC z p=none na p=quarantine nebo p=reject může ovlivnit zákaznickou komunikaci, finanční oznámení, onboarding HR, prodejní kampaně a outsourcované poskytovatele.

Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, výběr bezpečnostních opatření a Prohlášení o použitelnosti. Podvržení domény musí být posuzováno jako rizikový scénář, přičemž SPF, DKIM, DMARC, MTA-STS a TLS-RPT mají být tam, kde je to vhodné, vybrány jako součást ošetření rizika. Kapitola 8.1 následně vyžaduje operativní plánování a řízení, včetně řízení externě poskytovaných procesů, produktů a služeb relevantních pro ISMS.

Co jednotlivá opatření autentizace e-mailu prokazují

SPF, DKIM, DMARC, MTA-STS a TLS-RPT fungují společně, ale prokazují různé skutečnosti.

SPF a DKIM jsou signály identity a integrity. DMARC je vrstva politiky, která tyto signály převádí na akci příjemce. MTA-STS a TLS-RPT podporují bezpečný transport e-mailu tím, že pomáhají předcházet rizikům downgrade útoků a chybné konfigurace.

Pro auditory má hlubší hodnotu opakovatelný důkaz. Agregované reporty DMARC ukazují, kdo odesílá jako vaše doména. Reporty TLS ukazují, zda selhává šifrované doručování. Tikety změn ukazují, zda existuje správa a řízení. Záznamy o dodavatelích ukazují, zda jsou známy závislosti v dodavatelském řetězci.

Nejprve zařaďte domény do registru aktiv

Autentizaci e-mailu nelze řídit, pokud domény nejsou považovány za aktiva.

Politika správy aktiv pro SME Politika správy aktiv pro SME výslovně zahrnuje domény a identity související s e-mailem do rozsahu:

„Digitální přihlašovací údaje a služby: názvy domén, digitální certifikáty, API klíče, e-mailové účty, cloudová přihlášení“

Ze sekce „Rozsah“, kapitola politiky 2.2.4.

U větších organizací používá podniková Politika správy aktiv Politika správy aktiv stejnou logiku:

„Logická aktiva: názvy domén, licence, uživatelské účty, konfigurační baseline“

Ze sekce „Rozsah“, kapitola politiky 2.2.5.

Pokud jsou domény aktivy, mohou mít vlastníky, hodnocení kritičnosti, cykly přezkumu, závislosti na dodavatelích, řízení změn a umístění důkazních podkladů. Pokud jsou to pouze záznamy DNS, obvykle zůstávají neřízené, dokud se něco nerozbije.

Registr domén a e-mailového odesílání připravený pro audit by měl obsahovat:

Tento registr podporuje opatření ISO/IEC 27001:2022 v příloze A: A.5.9 Evidence informací a dalších souvisejících aktiv, A.8.9 Řízení konfigurace, A.5.19 Bezpečnost informací ve vztazích s dodavateli a A.5.23 Bezpečnost informací pro používání cloudových služeb. Podporuje také výsledky NIST CSF 2.0 v oblasti evidence aktiv, služeb, dodavatelů a kritičnosti.

Používejte řízení změn pro rozhodnutí týkající se DNS a toku pošty

Autentizace e-mailu selhává, když je řízení změn slabé. Prodejní tým přidá platformu pro oslovení zákazníků. HR zavede nástroj pro sledování kandidátů. Finance změní fakturační software. Marketing přejde k novému poskytovateli e-mailových služeb. Každé obchodní rozhodnutí vytvoří nového odesílatele.

Podniková Politika řízení změn Politika řízení změn stanoví požadavek na důkazní podklady výslovně:

„Všechny požadavky na změnu, přezkumy, schválení a podpůrné důkazy musí být zaznamenány v centralizovaném systému řízení změn.“

Ze sekce „Požadavky na implementaci politiky“, kapitola politiky 6.1.1.

Kvalitní tiket změny pro autentizaci e-mailu by měl obsahovat:

• Obchodní odůvodnění nového odesílatele.
• Dotčenou doménu nebo subdoménu.
• Dopad na SPF include nebo odesílací IP adresy.
• Selektor DKIM a vlastnictví klíče.
• Výsledek testu zarovnání DMARC.
• Případný dopad na MTA-STS nebo MX.
• Klasifikaci dat v odesílaných zprávách.
• Odkaz na bezpečnostní přezkum dodavatele.
• Plán návratu změny.
• Schválení vlastníkem domény a bezpečností.
• Důkazní podklady z testování po implementaci.
• Datum přezkumu nebo expiraci dočasných nastavení.

To je rozdíl mezi tvrzením „správce DNS změnil záznam“ a stavem „ISMS řídil změnu relevantní z hlediska rizika“.

Praktický 30denní plán pro důkazní podklady DMARC, SPF, DKIM a MTA-STS

Ředitel informační bezpečnosti nepotřebuje šestiměsíční transformační projekt, aby zlepšil vyspělost důkazních podkladů. Soustředěný 30denní sprint může vytvořit obhajitelný výchozí stav.

1. týden: zjistěte domény, odesílatele a vlastnictví

Exportujte všechny domény z registrátora a poskytovatele DNS. Získejte data o toku pošty z e-mailové brány, CRM, helpdesku, marketingové platformy, fakturačního systému a cloudových notifikačních služeb. Vytvořte registr domén a odesílání.

Zahrňte také zaparkované domény a obranné registrace. Zaparkované domény jsou často přehlíženy, ale pokud DMARC chybí nebo je slabé, stále mohou být zneužity.

2. týden: opravte zarovnání SPF a DKIM

Přezkoumejte SPF z hlediska příliš permisivních mechanismů, neplatných zahrnutých konfigurací, duplicitních poskytovatelů a rizik limitu lookupů. U DKIM identifikujte každého odesílatele, který poštu nepodepisuje nebo podepisuje doménou, která se nebude zarovnávat s DMARC.

Neschvalujte odesílatele SaaS jen proto, že pošta funguje. Schvalte jej proto, že:

• Dodavatel je uveden v registru odesílání.
• Konfigurace SPF a DKIM je dokumentována.
• Selektory DKIM jsou evidovány.
• Vlastnictví klíčů a očekávání pro přezkum jsou jasné.
• Bezpečnostní dokumentace dodavatele podporuje bezpečné nakládání s e-mailem.
• Obchodní vlastník akceptuje případnou dočasnou výjimku.

Zde se NIS2 a DORA stávají praktickými. NIS2 Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a údržby, posuzování účinnosti, kybernetické hygieny, kryptografie, řízení přístupu a bezpečné komunikace. DORA Article 28 vyžaduje, aby finanční subjekty řídily rizika třetích stran v oblasti ICT jako součást rámce řízení rizik v oblasti ICT, včetně náležité péče, smluvních očekávání, monitorování a plánování ukončení spolupráce.

Pokud poskytovatel marketingových služeb odesílá neautentizovaný e-mail s využitím vaší domény, nejde pouze o marketingový problém. Jde o dodavatelské riziko, riziko vydávání se za značku a potenciálně o újmu zákazníkům.

3. týden: posuňte DMARC k vynucování

Režim monitorování je užitečný, ale trvalé p=none bez schváleného plánu je slabý důkaz.

Obhajitelný plán vynucování DMARC by měl zahrnovat:

• Přezkum výchozích agregovaných reportů.
• Identifikaci legitimních a nelegitimních zdrojů.
• Nápravu legitimních selhávajících zdrojů.
• Obchodní validaci kritických toků pošty.
• Postupné zvýšení politiky na pct=25, pct=50, pct=100.
• Přechod z p=none na p=quarantine.
• Přechod na p=reject, pokud to riziko a připravenost organizace umožňují.
• Samostatné zacházení se subdoménami pomocí sp=.
• Registr výjimek s daty expirace.
• Schválení zbytkového rizika vedením.

To podporuje ISO/IEC 27001:2022 Clause 6.1.3 ošetření rizik a Clause 8.1 operativní plánování a řízení. Internímu auditu to také poskytuje jasnou stopu: rozhodnutí, implementaci, monitorování, výjimku, schválení a přezkum.

4. týden: validujte MTA-STS, TLS-RPT a monitorování

MTA-STS je často opomíjeno, protože nezastavuje podvržení značky u odchozí pošty stejným způsobem jako DMARC. Je však velmi relevantní pro bezpečnou komunikaci a ochranu informací při přenosu. Kompatibilním odesílajícím serverům říká, že pošta do vaší domény má být doručována přes TLS, a validuje identitu MX.

Podniková Politika kryptografických opatření Politika kryptografických opatření stanoví jasnou baseline pro zabezpečení transportu:

„Zabezpečení transportu: TLS 1.2 nebo vyšší (preferovaně TLS 1.3)“

Ze sekce „Požadavky na implementaci politiky“, kapitola politiky 6.1.1.5.

Politika kryptografických opatření pro SME Politika kryptografických opatření pro SME výslovně zahrnuje přenos e-mailem:

„Data přenášená prostřednictvím e-mailu, firemních VPN a webových portálů“

Ze sekce „Požadavky na implementaci politiky“, kapitola politiky 6.1.1.4.

Testování by mělo zahrnovat validaci TLS pro MX, dostupnost souboru politiky MTA-STS, stav HTTPS certifikátu, přezkum reportů TLS-RPT a záznamy o třídění selhání.

Namapujte autentizaci e-mailu na přílohu A ISO/IEC 27001:2022

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls pomáhá propojit technické důkazní podklady s auditními očekáváními napříč rámci. Nejde o samostatnou sadu opatření. Jde o mapovací a auditní průvodce pro opatření ISO/IEC 27001:2022 a související normy.

Pro opatření ISO/IEC 27001:2022 v příloze A A.5.14 Přenos informací Zenith Controls vysvětluje vztah ke kryptografii:

„Bezpečný přenos informací závisí na kryptografických opatřeních, jak je podrobně uvedeno v 8.24.“

To je vztah mezi firemním e-mailem, DKIM, MTA-STS a TLS. E-mail je kanál pro přenos informací. DKIM podporuje autenticitu a integritu zpráv. MTA-STS a TLS podporují ochranu transportu.

U opatření přílohy A A.8.24 Používání kryptografie Zenith Controls propojuje kryptografii s přenosem informací, soukromím, ochranou osobně identifikovatelných údajů, klasifikací a řízením zranitelností. U opatření přílohy A A.8.15 Protokolování a A.8.16 Monitorovací činnosti průvodce propojuje protokoly a monitorování s řízením událostí, sběrem důkazů, přezkumem, analýzou a auditovatelností.

Politika protokolování a monitorování pro SME Politika protokolování a monitorování pro SME stanoví:

„Protokolování musí být zapnuto a nakonfigurováno tam, kde je dostupné“

Ze sekce „Požadavky na správu a řízení“, kapitola politiky 5.5.1.1.

Podniková Politika protokolování a monitorování Politika protokolování a monitorování zahrnuje:

„Externí komunikaci a spouštěče pravidel firewallu“

Ze sekce „Požadavky na implementaci politiky“, kapitola politiky 6.1.1.6.

U autentizace e-mailu by externí komunikace měla zahrnovat události poštovní brány, zpracování agregovaných reportů DMARC, trendy selhání DKIM, podezřelou zdrojovou infrastrukturu, selhání TLS-RPT a pokusy o spoofing, které spouštějí třídění incidentů.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint zasazuje tuto oblast do praktické validace kontrol. Ve fázi Controls in Action, kroku 20, týmům ukládá validovat bezpečnost síťových služeb:

„Vyjmenujte všechny interní a externí síťové služby (DNS, VPN, SMTP, DHCP, API brány atd.).

✓ U každé potvrďte, že používá zabezpečené protokoly (např. DNSSEC, TLS 1.2+, SSH namísto Telnet).
✓ Přezkoumejte, jak je řízen přístup ke každé službě (např. IP allowlisty, autentizace, certifikáty).
✓ Pokud jsou spravovány třetími stranami (např. DNS, SD-WAN, hostovaná VPN), přezkoumejte bezpečnostní doložky v SLA nebo dodavatelské smlouvě. Aktualizujte svůj registr služeb a uveďte, kde leží odpovědnosti za bezpečnost, interně nebo externě.“

Při aplikaci na e-mail se z toho stává pracovní plán pro DNS, SMTP, TLS, hostované poštovní brány, dodavatelské odesílatele a hranice odpovědností.

Mapování napříč předpisy: jeden balíček důkazních podkladů, mnoho povinností

Stejný balíček důkazních podkladů může podporovat ISO/IEC 27001:2022, NIS2, DORA, GDPR a NIST CSF 2.0, pokud je správně strukturován.

NIS2 je zvlášť relevantní pro základní a významné subjekty a pro určité kategorie digitální infrastruktury a digitálních poskytovatelů. Article 20 činí správu a řízení kybernetické bezpečnosti odpovědností řídicího orgánu, zatímco Article 21 stanoví baseline řízení rizik. Důkazní podklady autentizace e-mailu pomáhají prokázat, že bezpečná komunikace, vztahy s dodavateli, zvládání incidentů, posuzování účinnosti a kybernetická hygiena jsou provozní realitou, nikoli teorií.

U finančních subjektů se DORA použije od 17. ledna 2025. Articles 5 a 6 vyžadují odpovědnost řídicího orgánu a dokumentovaný rámec řízení rizik v oblasti ICT. Article 17 vyžaduje procesy k detekci, řízení, zaznamenávání, klasifikaci, eskalaci a nápravě incidentů souvisejících s ICT. Article 28 činí z řízení rizik třetích stran v oblasti ICT formální odpovědnost. Poskytovatelé e-mailu, marketingové platformy, systémy platebních oznámení a nástroje zákaznické komunikace se mohou stát součástí tohoto řetězce závislostí ICT.

U GDPR je klíčovou otázkou, zda se e-mail používá ke zpracování osobních údajů. Article 5 zahrnuje integritu, důvěrnost a odpovědnost. Article 32 vyžaduje vhodná technická a organizační opatření. Pokud faktury, zprávy HR, oznámení k účtům, tikety podpory nebo nástupní e-maily obsahují osobní údaje, autentizace e-mailu a zabezpečení transportu se stávají součástí důkazních podkladů o zabezpečení zpracování.

Reakce na incidenty: když se reporty stanou včasným varováním

Agregované reporty DMARC nejsou pouze důkazními podklady pro soulad. Jsou to data včasného varování. Nárůst selhané autentizace z neznámé infrastruktury může indikovat aktivní spoofing, shadow IT, chybnou konfiguraci dodavatele nebo kompromitovaného odesílatele.

Podle NIS2 Article 23 musí základní a významné subjekty oznamovat významné incidenty bez zbytečného odkladu, a to prostřednictvím fázovaného hlášení zahrnujícího včasné varování, oznámení incidentu a závěrečné hlášení. Ne každý pokus o spoofing podléhá hlášení, ale organizace musí být schopna posoudit závažnost, provozní narušení, finanční ztrátu, přeshraniční dopad a újmu příjemcům.

Podle DORA Article 17 musí finanční subjekty definovat a implementovat proces řízení incidentů souvisejících s ICT, zaznamenávat incidenty a významné kybernetické hrozby, identifikovat kořenové příčiny, používat indikátory včasného varování, klasifikovat podle závažnosti a kritičnosti služby, přiřazovat role, definovat komunikaci a eskalovat závažné incidenty. DORA Article 19 se následně zabývá hlášením závažných incidentů souvisejících s ICT.

U GDPR jde o otázku, zda událost způsobila náhodné nebo protiprávní zničení, ztrátu, změnu, neoprávněné zpřístupnění nebo přístup k osobním údajům. Podvržený e-mail, který přiměje zákazníky předat osobní údaje útočníkovi, může vyvolat posouzení porušení zabezpečení osobních údajů, i když interní systémy nebyly kompromitovány.

Podniková Politika monitorování auditu a souladu Politika monitorování auditu a souladu vysvětluje, proč jsou disciplinované důkazní podklady důležité:

„Vytvářet obhajitelné důkazy a auditní stopu na podporu regulačních šetření, soudních řízení nebo požadavků zákazníků na doložení zajištění.“

Ze sekce „Cíle“, kapitola politiky 3.4.

Politika monitorování auditu a souladu pro SME Politika monitorování auditu a souladu pro SME doplňuje požadavek na kvalitu důkazů:

„Metadata (např. kdo je shromáždil, kdy a z jakého systému) musí být dokumentována.“

Ze sekce „Požadavky na implementaci politiky“, kapitola politiky 6.2.3.

Vyšetřovací spis DMARC by proto měl dokumentovat zdroj reportu, čas sběru, analytika, dotčené domény, podezřelé IP adresy odesílatelů, výsledky autentizace, posouzení dopadů na obchodní činnost, přijatá rozhodnutí a schválení uzavření.

Na co se budou auditoři ptát

Různí auditoři používají různý jazyk, ale důkazní podklady se překrývají.

Očekávejte praktické otázky:

• Ukažte reporty DMARC za poslední čtvrtletí.
• Ukažte, jak byly přezkoumány.
• Ukažte výjimku pro tohoto selhávajícího odesílatele.
• Ukažte, kdo schválil tuto změnu SPF.
• Ukažte, zda jsou selektory DKIM evidovány a přezkoumávány.
• Ukažte, jak se MTA-STS testuje po změnách poštovní brány.
• Ukažte, jak události spoofingu vstupují do třídění incidentů.
• Ukažte, jak jsou odesílatelé dodavatelů odstraňováni při ukončení smlouvy.

Stručný kontrolní seznam interního auditu pro rok 2026

Použijte tento kontrolní seznam jako výchozí bod pro interní audit, testování opatření nebo přezkum důkazních podkladů k autentizaci e-mailu.

• Všechny domény a subdomény jsou uvedeny v registru aktiv.
• Zaparkované a obranné domény mají pokrytí DMARC.
• Každý autorizovaný odesílatel má obchodního vlastníka a technického vlastníka.
• Záznamy SPF jsou přezkoumávány z hlediska neplatných include a nadměrného rozsahu.
• DKIM je zapnuto pro legitimní odesílatele tam, kde je podporováno.
• Selektory DKIM jsou evidovány a přezkoumávány.
• DMARC je nasazeno pro kořenové domény a relevantní subdomény.
• DMARC má plán vynucování, nikoli neomezený režim monitorování.
• Agregované reporty DMARC jsou přezkoumávány ve stanovené periodě.
• MTA-STS je nakonfigurováno pro domény příchozí pošty tam, kde je to použitelné.
• Reporty TLS-RPT jsou shromažďovány a tříděny.
• Změny autentizace e-mailu se řídí procesem řízení změn.
• Onboarding dodavatelů zahrnuje požadavky na e-mailové odesílání.
• Offboarding dodavatelů odstraňuje SPF include, selektory DKIM a oprávnění k odesílání.
• Výjimky mají vlastníky rizik, data expirace a kompenzační opatření.
• Nárůsty spoofingu a selhání autentizace vstupují do reakce na incidenty.
• Důkazní podklady zahrnují metadata, zdroj, datum, osobu, která je shromáždila, a systém.
• Vedení dostává pravidelné metriky a aktualizace rizik.

Zenith Blueprint, fáze Risk Management, krok 14, doporučuje vytvořit regulační mapovací tabulky pro použitelné povinnosti:

„Pro každý právní předpis můžete tam, kde je použitelný, vytvořit jednoduchou mapovací tabulku (například jako přílohu zprávy), která uvádí klíčové bezpečnostní požadavky daného předpisu a odpovídající opatření/politiky ve vašem ISMS. V ISO 27001 to není povinné, ale je to užitečné interní cvičení, které pomáhá zajistit, že nic nepropadlo mezerami. Na auditory/posuzovatele také působí dobře, protože ukazuje, že neřídíte bezpečnost ve vakuu, ale vnímáte právní kontext.“

U autentizace e-mailu se tato tabulka stává mostem mezi technickou realitou DNS a ujištěním na úrovni správní rady.

Přeměňte autentizaci e-mailu na důkazní podklady připravené pro audit

Vaši zákazníci se možná nikdy nezeptají, zda má váš záznam SPF dokonalou syntaxi. Zeptají se, zda dokážete chránit svou značku, snižovat riziko phishingu, zabezpečit komunikaci, řídit dodavatele a prokázat, že vaše opatření fungují.

Clarysec pomáhá organizacím přeměnit autentizaci e-mailu z křehkých technických nastavení na systém opatření připravený pro audit. Praktickým dalším krokem je cílený přezkum důkazních podkladů k autentizaci e-mailu:

1. Vytvořte registr domén a odesílání.
2. Namapujte stav SPF, DKIM, DMARC, MTA-STS a TLS-RPT.
3. Identifikujte dodavatele, neřízené odesílatele a výjimky.
4. Vytvořte plán vynucování DMARC.
5. Validujte důkazní podklady pro řízení změn, protokolování a reakci na incidenty.
6. Propojte důkazní podklady s ISO/IEC 27001:2022, NIS2, DORA, GDPR a NIST CSF 2.0.
7. Připravte balíček důkazních podkladů pro audit s využitím Zenith Blueprint, Zenith Controls a relevantních politik Clarysec.

Pokud se vaše organizace připravuje na certifikaci ISO/IEC 27001:2022, připravenost na NIS2, ujištění podle DORA, přezkumy odpovědnosti podle GDPR nebo zákaznické bezpečnostní dotazníky, začněte u opatření, která útočníci zneužívají nejviditelněji: u vašich domén, odesílatelů a řetězce důvěry e-mailu.

Stáhněte si Zenith Blueprint, použijte Zenith Controls pro mapování napříč požadavky na soulad a proveďte 30denní přezkum důkazních podkladů k autentizaci e-mailu dříve, než další spoofingový incident nebo auditní požadavek vynutí tuto diskusi.