Revisionsunderlag för DMARC för ISO 27001, NIS2, DORA och GDPR

Det börjar med att en ekonomidirektör vidarebefordrar ett e-postmeddelande till informationssäkerhetschefen kl. 07:42.

”Skickade vi det här?”

Meddelandet ser perfekt ut. Samma logotyp, samma sidfot, samma ton som faktureringsteamet. Det påstår att bankuppgifterna har ändrats. Avsändarens visningsnamn är korrekt. Domänen är inte en snarlik felstavning. Angriparen förfalskar den verkliga domänen.

Kl. 08:15 bekräftar säkerhetsteamet den obekväma sanningen: SPF finns men är för brett, DKIM är endast aktiverat för den primära e-postplattformen, flera marknadsföringsverktyg skickar osignerad e-post, DMARC är fortfarande i övervakningsläge och ingen kan hitta den senaste granskningen av domänens MTA-STS-policy. Organisationen har ”e-postsäkerhet” i presentationsmaterial, men underlaget är utspritt i DNS-skärmbilder, leverantörsportaler, gamla Jira-ärenden och ett kalkylblad som ägs av någon som slutade förra året.

Kl. 10:30 frågar juristfunktionen om kunders personuppgifter kan vara berörda. Compliancefunktionen frågar om händelsen är relevant för NIS2-rapportering. En kund inom finansiella tjänster frågar om företaget kan visa IKT-riskkontroller som är anpassade till DORA. Internrevisionen frågar hur detta mappas mot ISO/IEC 27001:2022. Styrelsen ställer en enklare fråga: ”Varför kunde någon utge sig för att vara vi?”

Den frågan är skälet till att e-postautentisering 2026 inte längre är ett smalt DNS-ämne. DMARC, SPF, DKIM, MTA-STS och TLS-RPT är kontroller som producerar underlag. De minskar risken för phishing och domänförfalskning, men de skapar också de artefakter som revisorer förväntar sig: policybeslut, ägarskap, tekniska baslinjer, leverantörsansvar, loggar, övervakningsposter, undantag, ändringsgodkännanden och utlösare för incidentrespons.

Efterlevnadsfrågan är inte: ”Har vi DMARC?” Den är: ”Kan vi bevisa att e-postautentisering är styrd, övervakad, granskad och kopplad till risk?”

Underlagsluckan som revisorer fortsätter att hitta

Ett andra scenario är lika vanligt. Den externa revisionen pågår hos ett snabbväxande fintech-bolag. Revisorn går från verksamhetskontinuitet till incidenthantering och frågar informationssäkerhetschefen om business email compromise.

Informationssäkerhetschefen förklarar att företaget har anti-phishing-filter och kvartalsvis säkerhetsmedvetenhetsutbildning.

Revisorn nickar och frågar sedan efter något mer specifikt: ”Visa mig styrningen kring DMARC, SPF och DKIM. Jag behöver se ägarskap, ändringsposter, riskbedömning, övervakningsunderlag och hur detta kopplas till NIS2-cyberhygien och DORA:s ramverk för IKT-riskhantering.”

Det blir tyst i rummet.

Det tekniska teamet införde DMARC för flera månader sedan, men ISMS saknar policyreferens, ett centralt underlagspaket, koppling till riskregistret och en godkänd färdplan för tillämpning. Kontrollen kan finnas tekniskt, men den är osynlig för styrningen.

Det är underlagsluckan.

Ett moget program för e-postautentisering besvarar sex revisionsfrågor:

1. Vilka domäner och subdomäner ingår i omfattningen?
2. Vem äger varje domän, DNS-zon, e-postflöde och avsändartjänst?
3. Vilka system får skicka på organisationens vägnar?
4. Vilka autentiseringsmekanismer tillämpas, övervakas och granskas?
5. Hur godkänns undantag, hur accepteras risk och hur avvecklas undantagen?
6. Vilket underlag visar att kontrollen har fungerat över tid?

ISO/IEC 27001:2022 gör detta till en fråga för ledningssystemet. Klausulerna 4.1 till 4.4 kräver att organisationen förstår kontext, krav från intressenter, omfattningsgränser, gränssnitt och beroenden. E-postautentisering berör allt detta. Din domänregistrator kan vara en leverantör. DNS kan driftas i molninfrastruktur. Din CRM-lösning, löneplattform, faktureringslösning, leverantör för marknadsföringsautomatisering och kundsupportsystem kan alla skicka e-post med ditt varumärke.

Klausulerna 5.1 till 5.3 gör detta till en ledningsfråga. Högsta ledningen ska tilldela ansvar och integrera informationssäkerhet i verksamhetsprocesser. Ett DMARC-beslut från p=none till p=quarantine eller p=reject kan påverka kundkommunikation, ekonomimeddelanden, HR-introduktion, säljkampanjer och outsourcade leverantörer.

Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling, kontrollval och en tillämpbarhetsförklaring. Domänförfalskning bör behandlas som ett riskscenario, där SPF, DKIM, DMARC, MTA-STS och TLS-RPT väljs som del av riskbehandlingen där det är lämpligt. Klausul 8.1 kräver därefter operativ planering och styrning, inklusive styrning av externt tillhandahållna processer, produkter och tjänster som är relevanta för ISMS.

Vad varje kontroll för e-postautentisering bevisar

SPF, DKIM, DMARC, MTA-STS och TLS-RPT samverkar, men de bevisar olika saker.

SPF och DKIM är signaler för identitet och riktighet. DMARC är policylagret som omsätter dessa signaler i mottagaråtgärder. MTA-STS och TLS-RPT stödjer säker e-posttransport genom att bidra till att förhindra nedgraderingsattacker och risker kopplade till felkonfiguration.

För revisorer ligger det större värdet i upprepningsbart underlag. Aggregerade DMARC-rapporter visar vem som skickar som din domän. TLS-rapporter visar om krypterad leverans misslyckas. Ändringsärenden visar om styrning finns. Leverantörsposter visar om beroenden i leveranskedjan är kända.

Lägg först in domäner i tillgångsregistret

E-postautentisering kan inte styras om domäner inte behandlas som tillgångar.

SME-versionen av policy för tillgångshantering – SME policy för tillgångshantering – SME tar uttryckligen in domäner och e-postrelaterade identiteter i omfattningen:

”Digitala behörigheter och tjänster: domännamn, digitala certifikat, API-nycklar, e-postkonton, molninloggningar”

Från avsnittet ”Omfattning”, policyklausul 2.2.4.

För större organisationer tillämpar policy för tillgångshantering policy för tillgångshantering samma logik:

”Logiska tillgångar: domännamn, licenser, användarkonton, konfigurationsbaslinjer”

Från avsnittet ”Omfattning”, policyklausul 2.2.5.

Om domäner är tillgångar kan de ha ägare, kritikalitetsklassning, granskningscykler, leverantörsberoenden, ändringsstyrning och platser för underlag. Om de bara är DNS-poster är de normalt ostyrda tills något går sönder.

Ett revisionsklart domän- och e-postavsändarregister bör innehålla:

Detta register stödjer ISO/IEC 27001:2022 Annex A-kontroll A.5.9 Förteckning över information och andra tillhörande tillgångar, A.8.9 Konfigurationshantering, A.5.19 Informationssäkerhet i leverantörsrelationer och A.5.23 Informationssäkerhet vid användning av molntjänster. Det stödjer även NIST CSF 2.0-resultat för förteckningar över tillgångar, tjänster, leverantörer och kritikalitet.

Använd ändringshantering för beslut om DNS och e-postflöden

E-postautentisering brister när ändringshanteringen är svag. Ett säljteam lägger till en outreach-plattform. HR inför ett verktyg för kandidatuppföljning. Ekonomi byter faktureringsprogramvara. Marknad går över till en ny e-posttjänstleverantör. Varje verksamhetsbeslut skapar en ny avsändare.

Organisationens ändringshanteringspolicy ändringshanteringspolicy gör kravet på underlag tydligt:

”Alla ändringsbegäranden, granskningar, godkännanden och stödjande underlag ska registreras i det centraliserade systemet för ändringshantering.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

Ett starkt ändringsärende för e-postautentisering bör innehålla:

• Verksamhetsmässig motivering för den nya avsändaren.
• Berörd domän eller subdomän.
• Påverkan på SPF-include eller avsändande IP-adress.
• DKIM-selector och nyckelägarskap.
• Testresultat för DMARC-alignment.
• Påverkan på MTA-STS eller MX, om någon.
• Dataklassificering av skickade meddelanden.
• Referens till granskning av leverantörssäkerhet.
• Rollback-plan.
• Godkännande av domänägare och säkerhetsfunktion.
• Testunderlag efter införande.
• Granskningsdatum eller utgångsdatum för tillfälliga inställningar.

Detta är skillnaden mellan ”en DNS-administratör ändrade en post” och ”ISMS styrde en riskrelevant ändring.”

En praktisk 30-dagarsplan för underlag avseende DMARC, SPF, DKIM och MTA-STS

En informationssäkerhetschef behöver inte ett sex månader långt transformationsprojekt för att höja underlagsmognaden. En fokuserad 30-dagarssprint kan skapa en försvarbar baslinje.

Vecka 1: Kartlägg domäner, avsändare och ägarskap

Exportera alla domäner från registratorn och DNS-leverantören. Hämta e-postflödesdata från e-postgateway, CRM, helpdesk, marknadsföringsplattform, faktureringssystem och molnbaserade aviseringstjänster. Bygg domän- och avsändarregistret.

Ta även med parkerade domäner och defensiva registreringar. Parkerade domäner ignoreras ofta, men de kan fortfarande missbrukas om DMARC saknas eller är svagt.

Vecka 2: Åtgärda SPF- och DKIM-alignment

Granska SPF för alltför tillåtande mekanismer, inaktuella includes, dubbla leverantörer och risker kopplade till uppslagsgränser. För DKIM, identifiera varje avsändare som inte signerar e-post eller som signerar med en domän som inte uppnår DMARC-alignment.

Godkänn inte en SaaS-avsändare bara för att e-posten fungerar. Godkänn den därför att:

• Leverantören finns i avsändarregistret.
• SPF- och DKIM-konfigurationen är dokumenterad.
• DKIM-selectors finns i förteckningen.
• Nyckelägarskap och granskningsförväntningar är tydliga.
• Leverantörens säkerhetsdokumentation stödjer säker e-posthantering.
• Verksamhetsägaren accepterar eventuella tillfälliga undantag.

Det är här NIS2 och DORA blir praktiska. NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och underhåll, effektivitetsbedömning, cyberhygien, kryptografi, åtkomstkontroll och säker kommunikation. DORA Article 28 kräver att finansiella entiteter hanterar IKT-tredjepartsrisk som en del av ramverket för IKT-riskhantering, inklusive leverantörsgranskning, avtalsförväntningar, övervakning och exitplanering.

Om en marknadsföringsleverantör skickar oautentiserad e-post med din domän är det inte bara en marknadsföringsfråga. Det är leverantörsrisk, risk för varumärkesimitation och potentiell kundskada.

Vecka 3: För DMARC mot tillämpning

Övervakningsläge är användbart, men permanent p=none utan en godkänd färdplan är svagt underlag.

En försvarbar plan för DMARC-tillämpning bör innehålla:

• Granskning av aggregerade baslinjerapporter.
• Identifiering av legitima och illegitima källor.
• Åtgärdande av legitima källor som misslyckas.
• Verksamhetsvalidering av kritiska e-postflöden.
• Gradvis policyhöjning till pct=25, pct=50, pct=100.
• Övergång från p=none till p=quarantine.
• Övergång till p=reject när risk och verksamhetsberedskap tillåter det.
• Separat hantering av subdomäner med sp=.
• Undantagsregister med utgångsdatum.
• Ledningsgodkännande av kvarstående risk.

Detta stödjer ISO/IEC 27001:2022 Klausul 6.1.3 riskbehandling och Klausul 8.1 operativ planering och styrning. Det ger även internrevisionen ett tydligt spår: beslut, genomförande, övervakning, undantag, godkännande och granskning.

Vecka 4: Validera MTA-STS, TLS-RPT och övervakning

MTA-STS missas ofta eftersom det inte stoppar utgående varumärkesförfalskning på samma sätt som DMARC gör. Men det är mycket relevant för säker kommunikation och skydd av information under överföring. Det anger för kompatibla avsändande servrar att e-post till din domän ska levereras över TLS och validerar MX-identiteten.

Organisationens Policy för kryptografiska kontroller Policy för kryptografiska kontroller fastställer en tydlig baslinje för transportsäkerhet:

”Transportsäkerhet: TLS 1.2 eller högre (helst TLS 1.3)”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.5.

För små och medelstora företag omfattar Policy för kryptografiska kontroller – SME Policy för kryptografiska kontroller – SME uttryckligen e-postöverföring:

”Data som överförs via e-post, Företags-VPN och webbportaler”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.4.

Testning bör omfatta MX TLS-validering, tillgänglighet för MTA-STS-policyfil, HTTPS-certifikatens hälsostatus, granskning av TLS-RPT-rapporter och triageposter för fel.

Mappa e-postautentisering mot ISO/IEC 27001:2022 Annex A

Clarysecs Zenith Controls: vägledning för tvärgående efterlevnad Zenith Controls hjälper till att koppla tekniskt underlag till revisionsförväntningar över flera ramverk. Det är inte en separat uppsättning kontroller. Det är en mappnings- och revisionsguide för ISO/IEC 27001:2022-kontroller och relaterade standarder.

För ISO/IEC 27001:2022 Annex A-kontroll A.5.14 Informationsöverföring förklarar Zenith Controls relationen till kryptografi:

”Säker informationsöverföring bygger på kryptografiska kontroller enligt 8.24.”

Det är relationen mellan verksamhetens e-post, DKIM, MTA-STS och TLS. E-post är en kanal för informationsöverföring. DKIM stödjer meddelandets autenticitet och riktighet. MTA-STS och TLS stödjer transportskydd.

För Annex A-kontroll A.8.24 Användning av kryptografi kopplar Zenith Controls kryptografi till informationsöverföring, integritetsskydd, skydd av PII, klassificering och hantering av sårbarheter. För Annex A-kontrollerna A.8.15 Loggning och A.8.16 Övervakningsaktiviteter kopplar guiden loggar och övervakning till händelsehantering, bevisinsamling, granskning, analys och revisionsbarhet.

SME-versionen av Loggnings- och övervakningspolicy – SME Loggnings- och övervakningspolicy – SME anger:

”Loggning ska aktiveras och konfigureras där den finns tillgänglig”

Från avsnittet ”Styrningskrav”, policyklausul 5.5.1.1.

Organisationens Loggnings- och övervakningspolicy Loggnings- och övervakningspolicy omfattar:

”Extern kommunikation och utlösare för brandväggsregler”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.6.

För e-postautentisering bör extern kommunikation omfatta händelser i e-postgateway, behandling av aggregerade DMARC-rapporter, trender för DKIM-fel, misstänkt källinfrastruktur, TLS-RPT-fel och spoofingförsök som utlöser incidenttriage.

Zenith Blueprint: en revisors 30-stegs färdplan Zenith Blueprint placerar detta i praktisk kontrollvalidering. I fasen Controls in Action, steg 20, instrueras team att validera säkerheten i nätverkstjänster:

”Lista alla interna och externa nätverkstjänster (DNS, VPN, SMTP, DHCP, API-gateways osv.).

✓ Bekräfta för varje tjänst att den använder säkra protokoll (t.ex. DNSSEC, TLS 1.2+, SSH i stället för Telnet).
✓ Granska hur åtkomst till varje tjänst styrs (t.ex. IP-tillåtelselistor, autentisering, certifikat).
✓ Om tjänsten hanteras av tredje part (t.ex. DNS, SD-WAN, driftad VPN), granska säkerhetsklausulerna i SLA:t eller leverantörsavtalet. Uppdatera ert tjänsteregister och ange var säkerhetsansvaret ligger, internt eller externt.”

Tillämpat på e-post blir detta en arbetsplan för DNS, SMTP, TLS, driftade e-postgateways, leverantörsavsändare och ansvarsgränser.

Tvärgående efterlevnadsmappning: ett underlagspaket, många krav

Samma underlagspaket kan stödja ISO/IEC 27001:2022, NIS2, DORA, GDPR och NIST CSF 2.0 om det struktureras korrekt.

NIS2 är särskilt relevant för väsentliga och viktiga entiteter samt för vissa kategorier inom digital infrastruktur och digitala leverantörer. Article 20 gör cybersäkerhetsstyrning till ett ansvar för ledningsorganet, medan Article 21 fastställer baslinjen för riskhantering. Underlag för e-postautentisering hjälper till att visa att säker kommunikation, leverantörsrelationer, incidenthantering, effektivitetsbedömning och cyberhygien är operativa, inte teoretiska.

För finansiella entiteter har DORA tillämpats sedan den 17 januari 2025. Articles 5 and 6 kräver ansvarsskyldighet hos ledningsorganet och ett dokumenterat ramverk för IKT-riskhantering. Article 17 kräver processer för att upptäcka, hantera, registrera, klassificera, eskalera och åtgärda IKT-relaterade incidenter. Article 28 gör IKT-tredjepartsriskhantering till ett formellt ansvar. E-postleverantörer, marknadsföringsplattformar, system för betalningsaviseringar och verktyg för kundkommunikation kan alla bli en del av denna IKT-beroendekedja.

För GDPR är nyckelfrågan om e-post används för att behandla personuppgifter. Article 5 omfattar riktighet, konfidentialitet och ansvarsskyldighet. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder. Om fakturor, HR-meddelanden, kontobesked, supportärenden eller introduktionsmejl innehåller personuppgifter blir e-postautentisering och transportsäkerhet en del av underlaget för säkerhet i behandlingen.

Incidentrespons: när rapporter blir tidiga varningar

Aggregerade DMARC-rapporter är inte bara underlag för efterlevnad. De är tidiga varningsdata. En kraftig ökning av misslyckad autentisering från okänd infrastruktur kan indikera aktiv spoofing, skugg-IT, felkonfiguration hos leverantör eller en komprometterad avsändare.

Enligt NIS2 Article 23 ska väsentliga och viktiga entiteter anmäla betydande incidenter utan onödigt dröjsmål, med stegvis rapportering som omfattar tidig varning, incidentanmälan och slutrapportering. Alla spoofingförsök är inte rapporteringspliktiga, men organisationen måste kunna bedöma allvarlighetsgrad, operativ störning, ekonomisk förlust, gränsöverskridande påverkan och skada för mottagare.

Enligt DORA Article 17 ska finansiella entiteter definiera och införa en process för hantering av IKT-relaterade incidenter, registrera incidenter och betydande cyberhot, identifiera rotorsaker, använda tidiga varningsindikatorer, klassificera efter allvarlighetsgrad och tjänstekritikalitet, tilldela roller, definiera kommunikation och eskalera större incidenter. DORA Article 19 behandlar därefter rapportering av större IKT-relaterade incidenter.

För GDPR är frågan om händelsen orsakade oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller åtkomst till personuppgifter. Ett förfalskat e-postmeddelande som lurar kunder att lämna personuppgifter till en angripare kan utlösa en bedömning av personuppgiftsincident, även om interna system inte har komprometterats.

Organisationens Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning förklarar varför disciplinerat underlag är viktigt:

”Att generera försvarbart underlag och ett revisionsspår till stöd för regulatoriska förfrågningar, rättsprocesser eller förfrågningar om säkerhetsförsäkran från kunder.”

Från avsnittet ”Mål”, policyklausul 3.4.

SME-versionen av Policy för revision och regelefterlevnadsövervakning – SME Policy för revision och regelefterlevnadsövervakning – SME lägger till ett krav på underlagets kvalitet:

”Metadata (t.ex. vem som samlade in dem, när och från vilket system) ska dokumenteras.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.3.

En DMARC-utredningsfil bör därför dokumentera rapportkälla, insamlingstidpunkt, analytiker, berörda domäner, misstänkta avsändar-IP-adresser, autentiseringsresultat, affärskonsekvensanalys, fattade beslut och godkännande av stängning.

Vad revisorer kommer att fråga efter

Olika revisorer använder olika språk, men underlaget överlappar.

Förvänta dig praktiska frågor:

• Visa DMARC-rapporterna för det senaste kvartalet.
• Visa hur de granskades.
• Visa undantaget för den här avsändaren som misslyckas.
• Visa vem som godkände denna SPF-ändring.
• Visa om DKIM-selectors finns i förteckning och granskas.
• Visa hur MTA-STS testas efter ändringar i e-postgateway.
• Visa hur spoofinghändelser går in i incidenttriage.
• Visa hur leverantörsavsändare tas bort när avtal upphör.

En kort internrevisionschecklista för 2026

Använd denna checklista som utgångspunkt för internrevision, kontrolltestning eller en granskning av underlag för e-postautentisering.

• Alla domäner och subdomäner finns i tillgångsregistret.
• Parkerade och defensiva domäner har DMARC-täckning.
• Varje behörig avsändare har en verksamhetsägare och teknisk ägare.
• SPF-poster granskas för inaktuella includes och alltför brett omfång.
• DKIM är aktiverat för legitima avsändare där det stöds.
• DKIM-selectors finns i förteckning och granskas.
• DMARC är infört för rotdomäner och relevanta subdomäner.
• DMARC har en färdplan för tillämpning, inte tidsobestämd övervakning.
• Aggregerade DMARC-rapporter granskas enligt en definierad frekvens.
• MTA-STS är konfigurerat för inkommande e-postdomäner där det är tillämpligt.
• TLS-RPT-rapporter samlas in och triageras.
• Ändringar av e-postautentisering följer ändringshantering.
• Leverantörsintroduktion omfattar krav på e-postsändning.
• Avveckling av leverantörer tar bort SPF-includes, DKIM-selectors och sändningsbehörigheter.
• Undantag har riskägare, utgångsdatum och kompenserande kontroller.
• Kraftiga ökningar av spoofing och autentiseringsfel matas in i incidentrespons.
• Underlaget innehåller metadata, källa, datum, insamlare och system.
• Ledningen får periodiska mätetal och riskuppdateringar.

Zenith Blueprint, fasen Riskhantering, steg 14, rekommenderar att regulatoriska mappningstabeller skapas för tillämpliga skyldigheter:

”För varje regelverk, om tillämpligt, kan ni skapa en enkel mappningstabell (exempelvis som en bilaga i en rapport) som listar regelverkets centrala säkerhetskrav och motsvarande kontroller/policyer i ert ISMS. Detta är inte obligatoriskt i ISO 27001, men det är en användbar intern övning för att säkerställa att inget fallit mellan stolarna. Det imponerar också på revisorer/bedömare att ni inte hanterar säkerhet i ett vakuum, utan är medvetna om den rättsliga kontexten.”

För e-postautentisering blir den tabellen bryggan mellan teknisk DNS-verklighet och försäkran på styrelsenivå.

Gör e-postautentisering till revisionsklart underlag

Dina kunder kanske aldrig frågar om din SPF-post har perfekt syntax. De kommer att fråga om du kan skydda ditt varumärke, minska phishingrisk, säkra kommunikation, hantera leverantörer och bevisa att dina kontroller fungerar.

Clarysec hjälper organisationer att omvandla e-postautentisering från sköra tekniska inställningar till ett revisionsklart kontrollsystem. Det praktiska nästa steget är en fokuserad granskning av underlag för e-postautentisering:

1. Bygg domän- och avsändarregistret.
2. Mappa status för SPF, DKIM, DMARC, MTA-STS och TLS-RPT.
3. Identifiera leverantörer, skuggavsändare och undantag.
4. Skapa en färdplan för DMARC-tillämpning.
5. Validera underlag för ändringshantering, loggning och incidentrespons.
6. Koppla underlaget till ISO/IEC 27001:2022, NIS2, DORA, GDPR och NIST CSF 2.0.
7. Förbered ett revisionsklart underlagspaket med Zenith Blueprint, Zenith Controls och relevanta Clarysec-policyer.

Om din organisation förbereder sig för ISO/IEC 27001:2022-certifiering, NIS2-beredskap, DORA-säkerhetsförsäkran, GDPR-granskningar av ansvarsskyldighet eller kunders säkerhetsfrågeformulär, börja med de kontroller som angripare missbrukar mest synligt: era domäner, era avsändare och er tillitskedja för e-post.

Ladda ned Zenith Blueprint, använd Zenith Controls för tvärgående efterlevnadsmappning och genomför en 30-dagars granskning av underlag för e-postautentisering innan nästa spoofingincident eller revisionsbegäran tvingar fram samtalet.