DMARC-bevismateriale for ISO 27001, NIS2, DORA og GDPR

Det starter med, at en økonomidirektør videresender en e-mail til CISO kl. 07:42.

“Har vi sendt denne?”

Beskeden ser perfekt ud. Samme logo, samme sidefod, samme tone som faktureringsteamet. Den hævder, at bankoplysningerne er ændret. Det viste afsendernavn er korrekt. Domænet er ikke en næsten identisk stavevariant. Angriberen spoofer det rigtige domæne.

Kl. 08:15 bekræfter sikkerhedsteamet den ubehagelige sandhed: SPF findes, men er defineret for bredt, DKIM er kun aktiveret for den primære e-mailplatform, flere marketingværktøjer sender usigneret mail, DMARC står stadig i overvågningstilstand, og ingen kan finde den seneste gennemgang af domænets MTA-STS-politik. Organisationen har “e-mailsikkerhed” i præsentationsmateriale, men bevismaterialet er spredt på DNS-skærmbilleder, leverandørportaler, gamle Jira-sager og et regneark, der ejes af en person, som fratrådte sidste år.

Kl. 10:30 spørger juridisk afdeling, om kunders personoplysninger kan være berørt. Compliance spørger, om hændelsen er relevant for NIS2-rapportering. En kunde i den finansielle sektor spørger, om virksomheden kan dokumentere DORA-tilpassede kontroller for IKT-risiko. Intern revision spørger, hvordan dette kortlægges til ISO/IEC 27001:2022. Bestyrelsen stiller et mere enkelt spørgsmål: “Hvorfor kunne nogen udgive sig for at være os?”

Det spørgsmål er årsagen til, at e-mailautentifikation i 2026 ikke længere er et snævert DNS-emne. DMARC, SPF, DKIM, MTA-STS og TLS-RPT er kontroller, der producerer bevismateriale. De reducerer risikoen for phishing og domænespoofing, men de skaber også de artefakter, revisorer forventer: politikbeslutninger, ejerskab, tekniske baselines, leverandøransvarlighed, logfiler, overvågningsregistreringer, undtagelser, ændringsgodkendelser og udløsere for hændelseshåndtering.

Efterlevelsesproblemet er ikke: “Har vi DMARC?” Det er: “Kan vi dokumentere, at e-mailautentifikation er styret, overvåget, gennemgået og knyttet til risiko?”

Beviskløften, som revisorer bliver ved med at finde

Et andet scenarie er lige så almindeligt. Den eksterne revision er i gang hos en hurtigt voksende fintech-virksomhed. Revisoren går fra forretningskontinuitet til hændelsesstyring og spørger CISO om kompromittering af forretnings-e-mail.

CISO forklarer, at virksomheden har phishingfiltre og kvartalsvis træning i sikkerhedsbevidsthed.

Revisoren nikker og beder derefter om noget mere konkret: “Vis mig styringen af DMARC, SPF og DKIM. Jeg skal se ejerskab, ændringsregistreringer, risikovurdering, overvågningsbevismateriale, og hvordan dette hænger sammen med NIS2-cyberhygiejne og DORA-rammen for styring af IKT-risici.”

Rummet bliver stille.

Det tekniske team implementerede DMARC for flere måneder siden, men ISMS’et har ingen politikreference, ingen central bevispakke, ingen forbindelse til risikoregisteret og ingen godkendt køreplan for håndhævelse. Kontrollen kan teknisk set være på plads, men den er usynlig for governance.

Det er beviskløften.

Et modent program for e-mailautentifikation besvarer seks revisionsspørgsmål:

1. Hvilke domæner og underdomæner er omfattet?
2. Hvem ejer hvert domæne, hver DNS-zone, hvert mailflow og hver afsendertjeneste?
3. Hvilke systemer må sende på vegne af organisationen?
4. Hvilke autentifikationsmekanismer håndhæves, overvåges og gennemgås?
5. Hvordan godkendes undtagelser, hvordan accepteres risiko, og hvordan udfases undtagelser?
6. Hvilket bevismateriale dokumenterer, at kontrollen har fungeret over tid?

ISO/IEC 27001:2022 gør dette til et spørgsmål om ledelsessystemet. Klausul 4.1 til 4.4 kræver, at organisationen forstår kontekst, krav fra interessenter, omfangsafgrænsning, grænseflader og afhængigheder. E-mailautentifikation berører dem alle. Din domæneregistrator kan være en leverandør. DNS kan være hostet i cloudinfrastruktur. Dit CRM, din lønplatform, dit faktureringsværktøj, din marketingautomatiseringsudbyder og dit kundesupportsystem kan alle sende e-mail med dit brand.

Klausul 5.1 til 5.3 gør dette til et ledelsesspørgsmål. Øverste ledelse skal tildele ansvar og integrere informationssikkerhed i forretningsprocesser. En DMARC-beslutning fra p=none til p=quarantine eller p=reject kan påvirke kundekommunikation, økonomimeddelelser, HR-onboarding, salgskampagner og outsourcede udbydere.

Klausul 6.1.1 til 6.1.3 kræver risikovurdering, risikobehandling, kontroludvælgelse og en anvendelseserklæring. Domænespoofing bør behandles som et risikoscenarie, hvor SPF, DKIM, DMARC, MTA-STS og TLS-RPT vælges som en del af risikobehandlingen, hvor det er relevant. Klausul 8.1 kræver derefter operationel planlægning og styring, herunder styring af eksternt leverede processer, produkter og tjenester, der er relevante for ISMS’et.

Hvad hver e-mailautentifikationskontrol dokumenterer

SPF, DKIM, DMARC, MTA-STS og TLS-RPT fungerer sammen, men de dokumenterer forskellige forhold.

SPF og DKIM er signaler for identitet og integritet. DMARC er politiklaget, der omsætter disse signaler til handling hos modtageren. MTA-STS og TLS-RPT understøtter sikker e-mailtransport ved at hjælpe med at forhindre nedgradering og risici ved fejlkonfiguration.

For revisorer ligger den dybere værdi i gentageligt bevismateriale. Aggregerede DMARC-rapporter viser, hvem der sender som dit domæne. TLS-rapporter viser, om krypteret levering fejler. Ændringssager viser, om der findes styring. Leverandørregistreringer viser, om afhængigheder i forsyningskæden er kendt.

Registrér først domæner i aktivregisteret

E-mailautentifikation kan ikke styres, hvis domæner ikke behandles som aktiver.

SMV-versionen Politik for styring af aktiver - SMV Politik for styring af aktiver - SMV medtager udtrykkeligt domæner og e-mailrelaterede identiteter i omfanget:

“Digitale legitimationsoplysninger og tjenester: domænenavne, digitale certifikater, API-nøgler, e-mailkonti, cloudlogins”

Fra afsnittet “Omfang”, politikklausul 2.2.4.

For større organisationer anvender enterprise-versionen Politik for styring af aktiver Politik for styring af aktiver samme logik:

“Logiske aktiver: domænenavne, licenser, brugerkonti, konfigurationsbaselines”

Fra afsnittet “Omfang”, politikklausul 2.2.5.

Hvis domæner er aktiver, kan de have ejere, kritikalitetsvurderinger, gennemgangscyklusser, leverandørafhængigheder, ændringskontroller og placeringer for bevismateriale. Hvis de blot er DNS-poster, er de normalt ustyrede, indtil noget går galt.

Et revisionsklart domæne- og afsenderregister bør omfatte:

Dette register understøtter ISO/IEC 27001:2022 Annex A control A.5.9 fortegnelse over information og andre tilknyttede aktiver, A.8.9 konfigurationsstyring, A.5.19 informationssikkerhed i leverandørrelationer og A.5.23 informationssikkerhed ved brug af cloudtjenester. Det understøtter også NIST CSF 2.0-resultater for fortegnelser over aktiver, tjenester, leverandører og kritikalitet.

Brug ændringsstyring til DNS- og mailflowbeslutninger

E-mailautentifikation går i stykker, når ændringsstyring er svag. Et salgsteam tilføjer en outreach-platform. HR tager et kandidatsporingsværktøj i brug. Økonomi skifter fakturasoftware. Marketing flytter til en ny e-mailserviceudbyder. Hver forretningsbeslutning skaber en ny afsender.

Enterprise-versionen Politik for ændringsstyring Politik for ændringsstyring gør kravet til bevismateriale eksplicit:

“Alle ændringsanmodninger, gennemgange, godkendelser og tilhørende bevismateriale skal registreres i det centraliserede ændringsstyringssystem.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

En stærk ændringssag for e-mailautentifikation bør omfatte:

• Forretningsmæssig begrundelse for den nye afsender.
• Berørt domæne eller underdomæne.
• Påvirkning fra SPF include eller afsender-IP.
• DKIM-selector og nøgleejerskab.
• Testresultat for DMARC-alignment.
• Påvirkning af MTA-STS eller MX, hvis relevant.
• Dataklassificering af sendte meddelelser.
• Reference til leverandørsikkerhedsgennemgang.
• Tilbagerulningsplan.
• Godkendelse fra domæneejer og sikkerhedsfunktion.
• Testbevismateriale efter implementering.
• Gennemgangsdato eller udløb for midlertidige indstillinger.

Det er forskellen mellem “en DNS-administrator ændrede en post” og “ISMS’et styrede en risikorelevant ændring.”

En praktisk 30-dages plan for bevismateriale for DMARC, SPF, DKIM og MTA-STS

En CISO behøver ikke et seks måneders transformationsprojekt for at forbedre bevismodenheden. Et fokuseret 30-dages sprint kan skabe en juridisk holdbar baseline.

Uge 1: Kortlæg domæner, afsendere og ejerskab

Eksportér alle domæner fra registratoren og DNS-udbyderen. Hent mailflowdata fra e-mailgateway, CRM, helpdesk, marketingplatform, faktureringssystem og cloudnotifikationstjenester. Opbyg domæne- og afsenderregisteret.

Medtag også parkerede domæner og defensive registreringer. Parkerede domæner bliver ofte overset, men de kan stadig misbruges, hvis DMARC mangler eller er svag.

Uge 2: Ret SPF- og DKIM-alignment

Gennemgå SPF for mekanismer med for brede tilladelser, forældede includes, dublerede udbydere og risici for at overskride opslaggrænser. For DKIM skal hver afsender identificeres, som ikke signerer mail, eller som signerer med et domæne, der ikke aligner med DMARC.

Godkend ikke en SaaS-afsender blot, fordi mailen virker. Godkend den, fordi:

• Leverandøren er opført i afsenderregisteret.
• SPF- og DKIM-konfigurationen er dokumenteret.
• DKIM-selectors er registreret i fortegnelsen.
• Nøgleejerskab og forventninger til gennemgang er tydelige.
• Leverandørens sikkerhedsdokumentation understøtter sikker mailhåndtering.
• Den forretningsansvarlige accepterer enhver midlertidig undtagelse.

Det er her, NIS2 og DORA bliver praktiske. NIS2 Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker anskaffelse og vedligeholdelse, vurdering af effektivitet, cyberhygiejne, kryptografi, adgangsstyring og sikker kommunikation. DORA Article 28 kræver, at finansielle enheder styrer IKT-tredjepartsrisici som led i rammeværket for styring af IKT-risici, herunder due diligence, kontraktlige forventninger, overvågning og exitplanlægning.

Hvis en marketingudbyder sender uautentificeret e-mail med dit domæne, er det ikke kun et marketingproblem. Det er leverandørrisiko, risiko for brandefterligning og potentielt skade for kunder.

Uge 3: Flyt DMARC mod håndhævelse

Overvågningstilstand er nyttig, men permanent p=none uden en godkendt køreplan er svagt bevismateriale.

En juridisk holdbar DMARC-håndhævelsesplan bør omfatte:

• Gennemgang af aggregerede baselinerapporter.
• Identifikation af legitime og illegitime kilder.
• Afhjælpning af legitime kilder, der fejler.
• Forretningsmæssig validering af kritiske mailstrømme.
• Gradvis politikforøgelse til pct=25, pct=50, pct=100.
• Overgang fra p=none til p=quarantine.
• Overgang til p=reject, når risiko og forretningsmæssig parathed tillader det.
• Særskilt håndtering af underdomæner med sp=.
• Undtagelsesregister med udløbsdatoer.
• Ledelsesgodkendelse af restrisiko.

Dette understøtter ISO/IEC 27001:2022 klausul 6.1.3 om risikobehandling og klausul 8.1 om operationel planlægning og styring. Det giver også intern revision et klart spor: beslutning, implementering, overvågning, undtagelse, godkendelse og gennemgang.

Uge 4: Validér MTA-STS, TLS-RPT og overvågning

MTA-STS overses ofte, fordi den ikke stopper udgående brandspoofing på samme måde som DMARC. Men den er meget relevant for sikker kommunikation og beskyttelse af oplysninger under overførsel. Den fortæller kompatible afsendende servere, at mail til dit domæne skal leveres via TLS, og validerer MX-identiteten.

Enterprise-versionen Politik for kryptografiske kontroller Politik for kryptografiske kontroller fastsætter en klar baseline for transportsikkerhed:

“Transportsikkerhed: TLS 1.2 eller højere (helst TLS 1.3)”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.5.

For SMV’er omfatter Politik for kryptografiske kontroller - SMV Politik for kryptografiske kontroller - SMV udtrykkeligt e-mailtransmission:

“Data transmitteret via e-mail, virksomheds-VPN’er og webportaler”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.4.

Test bør omfatte MX TLS-validering, tilgængelighed af MTA-STS-politikfil, HTTPS-certifikaters tilstand, gennemgang af TLS-RPT-rapporter og triageregistreringer for fejl.

Kortlæg e-mailautentifikation til ISO/IEC 27001:2022 Annex A

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls hjælper med at forbinde teknisk bevismateriale med revisionsforventninger på tværs af rammeværker. Det er ikke et særskilt kontrolsæt. Det er en kortlægnings- og revisionsvejledning for ISO/IEC 27001:2022-kontroller og relaterede standarder.

For ISO/IEC 27001:2022 Annex A control A.5.14 informationsoverførsel forklarer Zenith Controls relationen til kryptografi:

“Sikker informationsoverførsel afhænger af kryptografiske kontroller som beskrevet i 8.24.”

Det er relationen mellem forretnings-e-mail, DKIM, MTA-STS og TLS. E-mail er en kanal til informationsoverførsel. DKIM understøtter meddelelsers autenticitet og integritet. MTA-STS og TLS understøtter transportbeskyttelse.

For Annex A control A.8.24 brug af kryptografi knytter Zenith Controls kryptografi til informationsoverførsel, privatliv, beskyttelse af personhenførbare oplysninger (PII), klassificering og sårbarhedsstyring. For Annex A controls A.8.15 logning og A.8.16 overvågningsaktiviteter forbinder vejledningen logfiler og overvågning med hændelsesstyring, indsamling af bevismateriale, gennemgang, analyse og revisionsbarhed.

SMV-versionen Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV fastslår:

“Logning skal aktiveres og konfigureres, hvor det er tilgængeligt”

Fra afsnittet “Styringskrav”, politikklausul 5.5.1.1.

Enterprise-versionen Lognings- og overvågningspolitik Lognings- og overvågningspolitik omfatter:

“Ekstern kommunikation og udløsere for firewallregler”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.6.

For e-mailautentifikation bør ekstern kommunikation omfatte hændelser fra mailgateways, behandling af aggregerede DMARC-rapporter, tendenser for DKIM-fejl, mistænkelig kildeinfrastruktur, TLS-RPT-fejl og spoofingforsøg, der udløser hændelsestriage.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint omsætter dette til praktisk kontrolvalidering. I fasen Kontroller i praksis, trin 20, instruerer den teams i at validere sikkerheden for netværkstjenester:

“Oplist alle interne og eksterne netværkstjenester (DNS, VPN, SMTP, DHCP, API-gateways osv.).

✓ Bekræft for hver enkelt, at de anvender sikre protokoller (f.eks. DNSSEC, TLS 1.2+, SSH i stedet for Telnet).
✓ Gennemgå, hvordan adgang til hver tjeneste styres (f.eks. IP-whitelisting, autentifikation, certifikater).
✓ Hvis de administreres af tredjeparter (f.eks. DNS, SD-WAN, hosted VPN), skal sikkerhedsklausulerne i SLA’en eller leverandørkontrakten gennemgås. Opdater jeres serviceregister, og notér, hvor sikkerhedsansvaret ligger, internt eller eksternt.”

Anvendt på e-mail bliver dette en arbejdsplan for DNS, SMTP, TLS, hostede mailgateways, leverandørafsendere og ansvarsgrænser.

Kortlægning på tværs af compliance: én bevispakke, mange forpligtelser

Den samme bevispakke kan understøtte ISO/IEC 27001:2022, NIS2, DORA, GDPR og NIST CSF 2.0, hvis den struktureres korrekt.

NIS2 er særligt relevant for væsentlige og vigtige enheder samt for visse kategorier af digital infrastruktur og digitale udbydere. Article 20 gør cybersikkerhedsstyring til et ansvar for ledelsesorganet, mens Article 21 fastlægger baseline for risikostyring. Bevismateriale for e-mailautentifikation hjælper med at dokumentere, at sikker kommunikation, leverandørrelationer, hændelseshåndtering, vurdering af effektivitet og cyberhygiejne er operationelle og ikke blot teoretiske.

For finansielle enheder har DORA været gældende siden 17. januar 2025. Articles 5 og 6 kræver ansvarlighed hos ledelsesorganet og et dokumenteret rammeværk for styring af IKT-risici. Article 17 kræver processer til at detektere, håndtere, registrere, klassificere, eskalere og afhjælpe IKT-relaterede hændelser. Article 28 gør styring af IKT-tredjepartsrisiko til et formelt ansvar. E-mailudbydere, marketingplatforme, systemer til betalingsnotifikationer og kundekommunikationsværktøjer kan alle blive en del af denne IKT-afhængighedskæde.

For GDPR er hovedspørgsmålet, om e-mail bruges til at behandle personoplysninger. Article 5 omfatter integritet, fortrolighed og ansvarlighed. Article 32 kræver passende tekniske og organisatoriske foranstaltninger. Hvis fakturaer, HR-meddelelser, kontonotifikationer, supportsager eller onboarding-e-mails indeholder personoplysninger, bliver e-mailautentifikation og transportsikkerhed en del af bevismaterialet for behandlingssikkerhed.

Hændelseshåndtering: når rapporter bliver tidlige advarsler

Aggregerede DMARC-rapporter er ikke kun bevismateriale for efterlevelse. De er tidlige advarselsdata. En stigning i fejlet autentifikation fra ukendt infrastruktur kan indikere aktiv spoofing, shadow IT, leverandørfejlkonfiguration eller en kompromitteret afsender.

Efter NIS2 Article 23 skal væsentlige og vigtige enheder underrette om væsentlige hændelser uden unødig forsinkelse ved hjælp af trinvis rapportering, der omfatter tidlig advarsel, hændelsesunderretning og endelig rapportering. Ikke alle spoofingforsøg er rapporteringspligtige, men organisationen skal kunne vurdere alvorlighed, driftsforstyrrelse, økonomisk tab, grænseoverskridende påvirkning og skade for modtagere.

Efter DORA Article 17 skal finansielle enheder definere og implementere en proces for styring af IKT-relaterede hændelser, registrere hændelser og væsentlige cybertrusler, identificere rodårsager, bruge tidlige advarselsindikatorer, klassificere efter alvorlighed og tjenestekritikalitet, tildele roller, definere kommunikation og eskalere større hændelser. DORA Article 19 omhandler derefter rapportering af større IKT-relaterede hændelser.

For GDPR er spørgsmålet, om hændelsen har medført hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger. En spoofet e-mail, der narer kunder til at indsende personoplysninger til en angriber, kan udløse en vurdering af brud på persondatasikkerheden, selv hvis interne systemer ikke er kompromitteret.

Enterprise-versionen Politik for revision og overvågning af efterlevelse Politik for revision og overvågning af efterlevelse forklarer, hvorfor disciplineret bevismateriale er vigtigt:

“At generere juridisk holdbart bevismateriale og et revisionsspor til støtte for regulatoriske forespørgsler, retssager eller anmodninger fra kunder om dokumentation.”

Fra afsnittet “Mål”, politikklausul 3.4.

SMV-versionen Politik for revision og overvågning af efterlevelse - SMV Politik for revision og overvågning af efterlevelse - SMV tilføjer et krav til beviskvalitet:

“Metadata (f.eks. hvem der indsamlede det, hvornår og fra hvilket system) skal dokumenteres.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.3.

En DMARC-undersøgelsesfil bør derfor dokumentere rapportkilde, indsamlingstidspunkt, analytiker, berørte domæner, formodede afsender-IP’er, autentifikationsresultater, konsekvensvurdering for forretningen, trufne beslutninger og godkendelse af lukning.

Hvad revisorer vil bede om

Forskellige revisorer bruger forskelligt sprog, men bevismaterialet overlapper.

Forvent praktiske spørgsmål:

• Vis DMARC-rapporterne for det seneste kvartal.
• Vis, hvordan de blev gennemgået.
• Vis undtagelsen for denne afsender, der fejler.
• Vis, hvem der godkendte denne SPF-ændring.
• Vis, om DKIM-selectors er registreret i fortegnelsen og gennemgået.
• Vis, hvordan MTA-STS testes efter ændringer i mailgateway.
• Vis, hvordan spoofinghændelser går ind i hændelsestriage.
• Vis, hvordan leverandørafsendere fjernes ved kontraktophør.

En kort intern revisionstjekliste for 2026

Brug denne tjekliste som udgangspunkt for intern revision, kontroltest eller en gennemgang af bevismateriale for e-mailautentifikation.

• Alle domæner og underdomæner er opført i aktivregisteret.
• Parkerede og defensive domæner har DMARC-dækning.
• Hver godkendt afsender har en forretningsansvarlig og en teknisk ansvarlig.
• SPF-registreringer gennemgås for forældede includes og for bredt omfang.
• DKIM er aktiveret for legitime afsendere, hvor det understøttes.
• DKIM-selectors er registreret i fortegnelsen og gennemgås.
• DMARC er udrullet for roddomæner og relevante underdomæner.
• DMARC har en køreplan for håndhævelse, ikke tidsubegrænset overvågning.
• Aggregerede DMARC-rapporter gennemgås efter en defineret frekvens.
• MTA-STS er konfigureret for indgående maildomæner, hvor det er relevant.
• TLS-RPT-rapporter indsamles og triageres.
• Ændringer i e-mailautentifikation følger ændringsstyring.
• Leverandøronboarding omfatter krav til e-mailafsendelse.
• Leverandøroffboarding fjerner SPF-includes, DKIM-selectors og afsendertilladelser.
• Undtagelser har risikoejere, udløbsdatoer og kompenserende kontroller.
• Stigninger i spoofing og autentifikationsfejl føder ind i hændelseshåndtering.
• Bevismateriale omfatter metadata, kilde, dato, indsamler og system.
• Ledelsen modtager periodiske metrikker og risikoopdateringer.

Zenith Blueprint, fasen Risikostyring, trin 14, anbefaler at oprette regulatoriske kortlægningstabeller for relevante forpligtelser:

“For hver regulering kan du, hvis relevant, oprette en enkel kortlægningstabel (eventuelt som bilag i en rapport), der oplister reguleringens centrale sikkerhedskrav og de tilsvarende kontroller/politikker i dit ISMS. Dette er ikke obligatorisk i ISO 27001, men det er en nyttig intern øvelse for at sikre, at intet falder mellem stolene. Det imponerer også revisorer/vurderingsparter, at I ikke styrer sikkerhed i et vakuum, men er opmærksomme på den juridiske kontekst.”

For e-mailautentifikation bliver denne tabel broen mellem den tekniske DNS-virkelighed og sikkerhed på bestyrelsesniveau.

Omsæt e-mailautentifikation til revisionsklart bevismateriale

Dine kunder spørger måske aldrig, om din SPF-registrering har perfekt syntaks. De vil spørge, om du kan beskytte dit brand, reducere phishingrisiko, sikre kommunikation, styre leverandører og dokumentere, at dine kontroller virker.

Clarysec hjælper organisationer med at omsætte e-mailautentifikation fra skrøbelige tekniske indstillinger til et revisionsklart kontrolsystem. Det praktiske næste skridt er en fokuseret gennemgang af bevismateriale for e-mailautentifikation:

1. Opbyg domæne- og afsenderregisteret.
2. Kortlæg status for SPF, DKIM, DMARC, MTA-STS og TLS-RPT.
3. Identificér leverandører, skyggeafsendere og undtagelser.
4. Opret en køreplan for DMARC-håndhævelse.
5. Validér bevismateriale for ændringsstyring, logning og hændelseshåndtering.
6. Knyt bevismateriale til ISO/IEC 27001:2022, NIS2, DORA, GDPR og NIST CSF 2.0.
7. Forbered en revisionsklar bevispakke ved hjælp af Zenith Blueprint, Zenith Controls og de relevante Clarysec-politikker.

Hvis din organisation forbereder sig på ISO/IEC 27001:2022-certificering, NIS2-parathed, DORA-assurance, GDPR-ansvarlighedsgennemgange eller kunders sikkerhedsspørgeskemaer, så start med de kontroller, angribere misbruger mest synligt: dine domæner, dine afsendere og din e-mailtillidskæde.

Download Zenith Blueprint, brug Zenith Controls til kortlægning på tværs af compliance, og gennemfør en 30-dages gennemgang af bevismateriale for e-mailautentifikation, før den næste spoofinghændelse eller revisionsanmodning tvinger samtalen frem.