DMARC-bewijsmateriaal voor ISO 27001, NIS2, DORA en GDPR

Het begint met een financieel directeur die om 07:42 een e-mail doorstuurt naar de CISO.

“Hebben wij dit verzonden?”

Het bericht ziet er perfect uit. Hetzelfde logo, dezelfde footer, dezelfde toon als het facturatieteam. Er staat in dat de bankgegevens zijn gewijzigd. De weergavenaam van de afzender klopt. Het domein is geen lookalike met een typfout. De aanvaller spooft het echte domein.

Om 08:15 bevestigt het beveiligingsteam de ongemakkelijke waarheid: SPF bestaat, maar is te ruim geconfigureerd; DKIM is alleen ingeschakeld voor het primaire e-mailplatform; meerdere marketingtools verzenden niet-ondertekende e-mail; DMARC staat nog steeds in monitoringmodus; en niemand kan de laatste beoordeling van het MTA-STS-beleid van het domein vinden. De organisatie heeft “e-mailbeveiliging” in een slide deck staan, maar het bewijsmateriaal is verspreid over DNS-screenshots, leveranciersportalen, oude Jira-tickets en een spreadsheet van iemand die vorig jaar is vertrokken.

Om 10:30 vraagt de juridische afdeling of er mogelijk persoonsgegevens van klanten bij betrokken zijn. Compliance vraagt of dit relevant is voor NIS2-rapportage. Een klant uit de financiële sector vraagt of het bedrijf DORA-conforme ICT-risicobeheersmaatregelen kan aantonen. Internal audit vraagt hoe dit zich verhoudt tot ISO/IEC 27001:2022. De raad van bestuur stelt een eenvoudigere vraag: “Waarom kon iemand zich als ons voordoen?”

Die vraag is waarom e-mailauthenticatie in 2026 geen nicheonderwerp voor DNS meer is. DMARC, SPF, DKIM, MTA-STS en TLS-RPT zijn beheersmaatregelen die bewijsmateriaal genereren. Ze verlagen het risico op phishing en domeinspoofing, maar creëren ook de artefacten die auditors verwachten: beleidsbesluiten, eigenaarschap, technische baselines, leveranciersverantwoording, logboeken, monitoringregistraties, uitzonderingen, wijzigingsgoedkeuringen en triggers voor incidentrespons.

Het complianceprobleem is niet: “Hebben we DMARC?” Het is: “Kunnen we aantonen dat e-mailauthenticatie wordt bestuurd, gemonitord, beoordeeld en gekoppeld aan risico?”

Het bewijsgat dat auditors blijven aantreffen

Een tweede scenario komt net zo vaak voor. De externe audit loopt bij een snelgroeiend fintechbedrijf. De auditor gaat van bedrijfscontinuïteit naar incidentbeheer en vraagt de CISO naar business email compromise.

De CISO legt uit dat het bedrijf antiphishingfilters en elk kwartaal beveiligingsbewustzijnstraining heeft.

De auditor knikt en vraagt vervolgens iets specifieker: “Laat mij de governance rond DMARC, SPF en DKIM zien. Ik moet eigenaarschap, wijzigingsregistraties, risicobeoordeling, monitoringbewijsmateriaal en de koppeling met NIS2-cyberhygiëne en het DORA ICT-risicobeheerkader zien.”

Het wordt stil in de kamer.

Het technische team heeft DMARC maanden geleden geïmplementeerd, maar het ISMS bevat geen beleidsverwijzing, geen centraal bewijspakket, geen koppeling met het risicoregister en geen goedgekeurde routekaart voor handhaving. De beheersmaatregel kan technisch bestaan, maar is onzichtbaar voor governance.

Dat is het bewijsgat.

Een volwassen programma voor e-mailauthenticatie beantwoordt zes auditvragen:

1. Welke domeinen en subdomeinen vallen binnen de scope?
2. Wie is eigenaar van elk domein, elke DNS-zone, elke mailflow en elke verzenddienst?
3. Welke systemen mogen namens de organisatie verzenden?
4. Welke authenticatiemechanismen worden afgedwongen, gemonitord en beoordeeld?
5. Hoe worden uitzonderingen goedgekeurd, risico’s geaccepteerd en uitzonderingen beëindigd?
6. Welk bewijsmateriaal toont aan dat de beheersmaatregel in de tijd heeft gewerkt?

ISO/IEC 27001:2022 maakt dit tot een managementsysteemvraagstuk. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie de context, eisen van belanghebbenden, scopegrenzen, interfaces en afhankelijkheden begrijpt. E-mailauthenticatie raakt ze allemaal. Uw domeinregistrar kan een leverancier zijn. DNS kan in cloudinfrastructuur worden gehost. Uw CRM, salarisplatform, facturatietool, marketingautomatiseringsprovider en klantenservicesysteem kunnen allemaal e-mail verzenden met uw merkidentiteit.

Clausules 5.1 tot en met 5.3 maken dit tot een leiderschapsvraagstuk. Het topmanagement moet verantwoordelijkheden toewijzen en informatiebeveiliging integreren in bedrijfsprocessen. Een DMARC-besluit van p=none naar p=quarantine of p=reject kan impact hebben op klantcommunicatie, financiële meldingen, HR-onboarding, verkoopcampagnes en uitbestede providers.

Clausules 6.1.1 tot en met 6.1.3 vereisen risicobeoordeling, risicobehandeling, selectie van beheersmaatregelen en een Verklaring van Toepasselijkheid. Domeinspoofing moet worden behandeld als een risicoscenario, waarbij SPF, DKIM, DMARC, MTA-STS en TLS-RPT waar passend als onderdeel van de behandeling worden geselecteerd. Clausule 8.1 vereist vervolgens operationele planning en beheersing, inclusief beheersing van extern geleverde processen, producten en diensten die relevant zijn voor het ISMS.

Wat elke beheersmaatregel voor e-mailauthenticatie aantoont

SPF, DKIM, DMARC, MTA-STS en TLS-RPT werken samen, maar tonen verschillende zaken aan.

SPF en DKIM zijn signalen voor identiteit en integriteit. DMARC is de beleidslaag die deze signalen omzet in acties bij ontvangers. MTA-STS en TLS-RPT ondersteunen veilig e-mailtransport door downgrade- en misconfiguratierisico’s te helpen voorkomen.

Voor auditors ligt de diepere waarde in herhaalbaar bewijsmateriaal. Geaggregeerde DMARC-rapporten tonen wie als uw domein verzendt. TLS-rapporten tonen of versleutelde aflevering faalt. Wijzigingstickets tonen of governance bestaat. Leveranciersregistraties tonen of afhankelijkheden in de toeleveringsketen bekend zijn.

Neem domeinen eerst op in het assetregister

E-mailauthenticatie kan niet worden beheerst als domeinen niet als assets worden behandeld.

De mkb-versie van het Beleid voor assetmanagement Beleid voor assetmanagement - mkb brengt domeinen en e-mailgerelateerde identiteiten expliciet binnen de scope:

“Digitale referenties en diensten: domeinnamen, digitale certificaten, API-sleutels, e-mailaccounts, cloudlogins”

Uit sectie “Scope”, beleidsclausule 2.2.4.

Voor grotere organisaties past het enterprise Beleid voor assetmanagement Beleid voor assetmanagement dezelfde logica toe:

“Logische assets: domeinnamen, licenties, gebruikersaccounts, configuratiebaselines”

Uit sectie “Scope”, beleidsclausule 2.2.5.

Als domeinen assets zijn, kunnen ze eigenaren, criticaliteitsclassificaties, beoordelingscycli, leveranciersafhankelijkheden, wijzigingsbeheersing en locaties voor bewijsmateriaal hebben. Als het slechts DNS-records zijn, blijven ze meestal onbeheerd totdat er iets misgaat.

Een auditgereed domein- en e-mailverzendregister moet het volgende bevatten:

Dit register ondersteunt ISO/IEC 27001:2022 Annex A-beheersmaatregel A.5.9 Inventaris van informatie en andere bijbehorende assets, A.8.9 Configuratiebeheer, A.5.19 Informatiebeveiliging in leveranciersrelaties en A.5.23 Informatiebeveiliging voor het gebruik van clouddiensten. Het ondersteunt ook NIST CSF 2.0-inventarisresultaten voor assets, diensten, leveranciers en criticaliteit.

Gebruik wijzigingsbeheer voor DNS- en mailflowbesluiten

E-mailauthenticatie faalt wanneer wijzigingsbeheer zwak is. Een verkoopteam voegt een outreachplatform toe. HR neemt een tool voor kandidaatopvolging in gebruik. Finance wijzigt facturatiesoftware. Marketing stapt over naar een nieuwe e-mailserviceprovider. Elke zakelijke beslissing creëert een nieuwe afzender.

Het enterprise Wijzigingsbeheerbeleid Wijzigingsbeheerbeleid maakt de eis voor bewijsmateriaal expliciet:

“Alle wijzigingsverzoeken, beoordelingen, goedkeuringen en ondersteunend bewijsmateriaal moeten worden geregistreerd in het centrale wijzigingsbeheersysteem.”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.

Een sterk wijzigingsticket voor e-mailauthenticatie moet het volgende bevatten:

• Zakelijke rechtvaardiging voor de nieuwe afzender.
• Betrokken domein of subdomein.
• Impact van SPF-include of verzendend IP-adres.
• DKIM-selector en sleuteleigenaarschap.
• Testresultaat voor DMARC-alignment.
• Impact op MTA-STS of MX, indien van toepassing.
• Gegevensclassificatie van verzonden berichten.
• Verwijzing naar leveranciersbeveiligingsbeoordeling.
• Rollbackplan.
• Goedkeuring door domeineigenaar en security.
• Testbewijsmateriaal na implementatie.
• Beoordelingsdatum of vervaldatum voor tijdelijke instellingen.

Dit is het verschil tussen “een DNS-beheerder heeft een record gewijzigd” en “het ISMS heeft een risicorelevante wijziging beheerst.”

Een praktisch 30-dagenplan voor DMARC-, SPF-, DKIM- en MTA-STS-bewijsmateriaal

Een CISO heeft geen transformatieproject van zes maanden nodig om de volwassenheid van bewijsmateriaal te verbeteren. Een gerichte sprint van 30 dagen kan een verdedigbare baseline opleveren.

Week 1: Inventariseer domeinen, afzenders en eigenaarschap

Exporteer alle domeinen uit de registrar en DNS-provider. Haal mailflowgegevens op uit de e-mailgateway, CRM, helpdesk, het marketingplatform, facturatiesysteem en cloudnotificatiediensten. Bouw het domein- en verzendregister op.

Neem ook geparkeerde domeinen en defensieve registraties op. Geparkeerde domeinen worden vaak genegeerd, maar kunnen nog steeds worden misbruikt als DMARC ontbreekt of zwak is.

Week 2: Herstel SPF- en DKIM-alignment

Beoordeel SPF op te ruime mechanismen, verouderde includes, dubbele providers en risico’s rond lookup-limieten. Identificeer voor DKIM elke afzender die e-mail niet ondertekent of ondertekent met een domein dat niet met DMARC zal alignen.

Keur een SaaS-afzender niet goed alleen omdat e-mail werkt. Keur deze goed omdat:

• De leverancier is opgenomen in het verzendregister.
• SPF- en DKIM-configuratie zijn gedocumenteerd.
• DKIM-selectors zijn geïnventariseerd.
• Sleuteleigenaarschap en beoordelingsverwachtingen duidelijk zijn.
• Leveranciersbeveiligingsdocumentatie veilige e-mailverwerking ondersteunt.
• De bedrijfseigenaar elke tijdelijke uitzondering accepteert.

Hier worden NIS2 en DORA praktisch. NIS2 Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en onderhoud, beoordeling van doeltreffendheid, cyberhygiëne, cryptografie, toegangscontrole en beveiligde communicatie. DORA Article 28 vereist dat financiële entiteiten ICT-risico’s van derde partijen beheren als onderdeel van het ICT-risicobeheerkader, inclusief due diligence, contractuele verwachtingen, monitoring en exitplanning.

Als een marketingprovider niet-geauthenticeerde e-mail verzendt met uw domein, is dat niet alleen een marketingprobleem. Het is leveranciersrisico, risico op merkimitatie en mogelijk schade voor klanten.

Week 3: Breng DMARC richting handhaving

Monitoringmodus is nuttig, maar permanent p=none zonder goedgekeurde routekaart is zwak bewijsmateriaal.

Een verdedigbaar DMARC-handhavingsplan moet het volgende bevatten:

• Beoordeling van geaggregeerde rapporten als baseline.
• Identificatie van legitieme en illegitieme bronnen.
• Herstel van legitieme bronnen die falen.
• Zakelijke validatie van kritieke mailstromen.
• Geleidelijke beleidsverhoging naar pct=25, pct=50, pct=100.
• Overgang van p=none naar p=quarantine.
• Overgang naar p=reject wanneer risico en bedrijfsparaatheid dit toelaten.
• Afzonderlijke behandeling voor subdomeinen met sp=.
• Uitzonderingenregister met vervaldatums.
• Goedkeuring door het management voor restrisico.

Dit ondersteunt ISO/IEC 27001:2022 Clause 6.1.3 risicobehandeling en Clause 8.1 operationele planning en beheersing. Het geeft internal audit ook een duidelijk spoor: besluit, implementatie, monitoring, uitzondering, goedkeuring en beoordeling.

Week 4: Valideer MTA-STS, TLS-RPT en monitoring

MTA-STS wordt vaak gemist omdat het outbound merkspoofing niet op dezelfde manier stopt als DMARC. Toch is het zeer relevant voor beveiligde communicatie en bescherming van informatie tijdens transport. Het vertelt compatibele verzendende servers dat e-mail naar uw domein via TLS moet worden afgeleverd en valideert de MX-identiteit.

Het enterprise Beleid voor cryptografische beheersmaatregelen Beleid voor cryptografische beheersmaatregelen stelt een duidelijke baseline voor transportbeveiliging vast:

“Transportbeveiliging: TLS 1.2 of hoger (bij voorkeur TLS 1.3)”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.5.

Voor mkb-organisaties omvat het Beleid voor cryptografische beheersmaatregelen voor het mkb Beleid voor cryptografische beheersmaatregelen - mkb expliciet e-mailtransmissie:

“Gegevens die via e-mail, bedrijfs-VPN’s en webportalen worden verzonden”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.4.

Testen moet MX TLS-validatie, beschikbaarheid van het MTA-STS-beleidsbestand, HTTPS-certificaatstatus, beoordeling van TLS-RPT-rapporten en triageregistraties voor fouten omvatten.

Map e-mailauthenticatie op ISO/IEC 27001:2022 Annex A

Clarysec’s Zenith Controls: de Cross-Compliance Guide Zenith Controls helpt technisch bewijsmateriaal te koppelen aan auditverwachtingen over raamwerken heen. Het is geen afzonderlijke set beheersmaatregelen. Het is een mapping- en auditgids voor ISO/IEC 27001:2022-beheersmaatregelen en gerelateerde normen.

Voor ISO/IEC 27001:2022 Annex A-beheersmaatregel A.5.14 Informatieoverdracht legt Zenith Controls de relatie met cryptografie uit:

“Veilige informatieoverdracht steunt op cryptografische beheersmaatregelen zoals beschreven in 8.24.”

Dat is de relatie tussen zakelijke e-mail, DKIM, MTA-STS en TLS. E-mail is een kanaal voor informatieoverdracht. DKIM ondersteunt authenticiteit en integriteit van berichten. MTA-STS en TLS ondersteunen transportbescherming.

Voor Annex A-beheersmaatregel A.8.24 Gebruik van cryptografie koppelt Zenith Controls cryptografie aan informatieoverdracht, privacy, bescherming van persoonsgegevens (PII), classificatie en kwetsbaarhedenbeheer. Voor Annex A-beheersmaatregelen A.8.15 Logging en A.8.16 Monitoringactiviteiten koppelt de gids logboeken en monitoring aan eventmanagement, bewijsverzameling, beoordeling, analyse en auditeerbaarheid.

De mkb-versie van het Beleid voor logging en monitoring Beleid voor logging en monitoring - mkb stelt:

“Logging moet worden ingeschakeld en geconfigureerd waar beschikbaar”

Uit sectie “Governancevereisten”, beleidsclausule 5.5.1.1.

Het enterprise Beleid voor logging en monitoring Beleid voor logging en monitoring omvat:

“Externe communicatie en triggers voor firewallregels”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.6.

Voor e-mailauthenticatie moet externe communicatie mailgatewaygebeurtenissen, verwerking van geaggregeerde DMARC-rapporten, trends in DKIM-fouten, verdachte broninfrastructuur, TLS-RPT-fouten en spoofingpogingen omvatten die incidenttriage triggeren.

De Zenith Blueprint: een 30-stappenroadmap voor auditors Zenith Blueprint plaatst dit in praktische validatie van beheersmaatregelen. In de fase Controls in Action, Step 20, instrueert deze teams om de beveiliging van netwerkdiensten te valideren:

“Maak een overzicht van alle interne en externe netwerkdiensten (DNS, VPN, SMTP, DHCP, API-gateways, enz.).

✓ Bevestig voor elke dienst dat deze beveiligde protocollen gebruikt (bijv. DNSSEC, TLS 1.2+, SSH in plaats van Telnet).
✓ Beoordeel hoe toegang tot elke dienst wordt beheerst (bijv. IP-whitelists, authenticatie, certificaten).
✓ Als diensten door derden worden beheerd (bijv. DNS, SD-WAN, gehoste VPN), beoordeel dan de beveiligingsclausules in de SLA of het leverancierscontract. Werk uw serviceregister bij en leg vast waar beveiligingsverantwoordelijkheden liggen: intern of extern.”

Toegepast op e-mail wordt dit een werkplan voor DNS, SMTP, TLS, gehoste mailgateways, leveranciersafzenders en verantwoordelijkheidsgrenzen.

Cross-compliance mapping: één bewijspakket, veel verplichtingen

Hetzelfde bewijspakket kan ISO/IEC 27001:2022, NIS2, DORA, GDPR en NIST CSF 2.0 ondersteunen als het goed is gestructureerd.

NIS2 is vooral relevant voor essentiële en belangrijke entiteiten, en voor bepaalde categorieën digitale infrastructuur en digitale aanbieders. Article 20 maakt cyberbeveiligingsgovernance tot een verantwoordelijkheid van het bestuursorgaan, terwijl Article 21 de baseline voor risicobeheer vaststelt. Bewijsmateriaal voor e-mailauthenticatie helpt aantonen dat beveiligde communicatie, leveranciersrelaties, incidentafhandeling, beoordeling van doeltreffendheid en cyberhygiëne operationeel zijn, niet theoretisch.

Voor financiële entiteiten geldt DORA sinds 17 januari 2025. Articles 5 en 6 vereisen verantwoordingsplicht van het bestuursorgaan en een gedocumenteerd ICT-risicobeheerkader. Article 17 vereist processen om ICT-gerelateerde incidenten te detecteren, beheren, registreren, classificeren, escaleren en remediëren. Article 28 maakt ICT-risicobeheer voor derde partijen een formele verantwoordelijkheid. E-mailproviders, marketingplatformen, systemen voor betalingsmeldingen en tools voor klantcommunicatie kunnen allemaal onderdeel worden van die ICT-afhankelijkheidsketen.

Voor GDPR is de kernvraag of e-mail wordt gebruikt om persoonsgegevens te verwerken. Article 5 omvat integriteit, vertrouwelijkheid en verantwoordingsplicht. Article 32 vereist passende technische en organisatorische maatregelen. Als facturen, HR-berichten, accountmeldingen, supporttickets of onboarding-e-mails persoonsgegevens bevatten, worden e-mailauthenticatie en transportbeveiliging onderdeel van het bewijsmateriaal voor beveiliging van de verwerking.

Incidentrespons: wanneer rapporten vroegtijdige waarschuwingen worden

Geaggregeerde DMARC-rapporten zijn niet alleen compliancebewijsmateriaal. Het zijn vroegtijdige waarschuwingsgegevens. Een piek in mislukte authenticatie vanaf onbekende infrastructuur kan wijzen op actieve spoofing, shadow IT, leveranciersmisconfiguratie of een gecompromitteerde afzender.

Onder NIS2 Article 23 moeten essentiële en belangrijke entiteiten significante incidenten zonder onnodige vertraging melden, via gefaseerde rapportage met vroegtijdige waarschuwing, incidentmelding en eindrapportage. Niet elke spoofingpoging is meldingsplichtig, maar de organisatie moet ernst, operationele verstoring, financieel verlies, grensoverschrijdende impact en schade voor ontvangers kunnen beoordelen.

Onder DORA Article 17 moeten financiële entiteiten een beheerproces voor ICT-gerelateerde incidenten definiëren en implementeren, incidenten en significante cyberdreigingen registreren, oorzaken identificeren, vroegtijdige waarschuwingsindicatoren gebruiken, classificeren naar ernst en servicecriticaliteit, rollen toewijzen, communicatie definiëren en majeure incidenten escaleren. DORA Article 19 behandelt vervolgens de rapportage van majeure ICT-gerelateerde incidenten.

Voor GDPR is de vraag of de gebeurtenis heeft geleid tot accidentele of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of toegang tot persoonsgegevens. Een gespoofte e-mail die klanten ertoe brengt persoonsgegevens aan een aanvaller te verstrekken, kan een beoordeling van een inbreuk in verband met persoonsgegevens triggeren, zelfs als interne systemen niet zijn gecompromitteerd.

Het enterprise Beleid voor audit en compliancemonitoring Beleid voor audit en compliancemonitoring legt uit waarom gedisciplineerd bewijsmateriaal van belang is:

“Het genereren van verdedigbaar bewijsmateriaal en een audittrail ter ondersteuning van verzoeken van toezichthouders, gerechtelijke procedures of klantassuranceverzoeken.”

Uit sectie “Doelstellingen”, beleidsclausule 3.4.

De mkb-versie van het Beleid voor audit en compliancemonitoring Beleid voor audit en compliancemonitoring - mkb voegt een kwaliteitseis voor bewijsmateriaal toe:

“Metadata (bijv. wie het heeft verzameld, wanneer en uit welk systeem) moeten worden gedocumenteerd.”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.3.

Een DMARC-onderzoeksdossier moet daarom de rapportbron, verzameltijd, analist, betrokken domeinen, vermoedelijke afzender-IP’s, authenticatieresultaten, business-impactanalyse, genomen besluiten en goedkeuring van afsluiting documenteren.

Waar auditors om zullen vragen

Verschillende auditors gebruiken verschillende taal, maar het bewijsmateriaal overlapt.

Verwacht praktische vragen:

• Toon de DMARC-rapporten van het laatste kwartaal.
• Toon hoe deze zijn beoordeeld.
• Toon de uitzondering voor deze falende afzender.
• Toon wie deze SPF-wijziging heeft goedgekeurd.
• Toon of DKIM-selectors zijn geïnventariseerd en beoordeeld.
• Toon hoe MTA-STS wordt getest na wijzigingen in de mailgateway.
• Toon hoe spoofinggebeurtenissen in incidenttriage terechtkomen.
• Toon hoe leveranciersafzenders worden verwijderd bij contractbeëindiging.

Een beknopte interne-auditchecklist voor 2026

Gebruik deze checklist als startpunt voor internal audit, toetsing van beheersmaatregelen of een Email Authentication Evidence Review.

• Alle domeinen en subdomeinen staan in het assetregister.
• Geparkeerde en defensieve domeinen hebben DMARC-dekking.
• Elke geautoriseerde afzender heeft een bedrijfseigenaar en technisch eigenaar.
• SPF-records worden beoordeeld op verouderde includes en te ruime scope.
• DKIM is ingeschakeld voor legitieme afzenders waar dit wordt ondersteund.
• DKIM-selectors zijn geïnventariseerd en worden beoordeeld.
• DMARC is uitgerold voor rootdomeinen en relevante subdomeinen.
• DMARC heeft een routekaart voor handhaving, geen monitoring voor onbepaalde tijd.
• Geaggregeerde DMARC-rapporten worden volgens een vast ritme beoordeeld.
• MTA-STS is geconfigureerd voor inkomende maildomeinen waar van toepassing.
• TLS-RPT-rapporten worden verzameld en getriageerd.
• Wijzigingen in e-mailauthenticatie volgen wijzigingsbeheer.
• Leveranciersonboarding omvat vereisten voor e-mailverzending.
• Offboarding van leveranciers verwijdert SPF-includes, DKIM-selectors en verzendrechten.
• Uitzonderingen hebben risico-eigenaren, vervaldatums en compenserende beheersmaatregelen.
• Spoofingpieken en authenticatiefouten voeden incidentrespons.
• Bewijsmateriaal bevat metadata, bron, datum, verzamelaar en systeem.
• Management ontvangt periodieke metrieken en risico-updates.

De Zenith Blueprint, fase Risicobeheer, Step 14, beveelt aan om mappingtabellen voor regelgeving op te stellen voor toepasselijke verplichtingen:

“Voor elke regelgeving kunt u, indien van toepassing, een eenvoudige mappingtabel maken (bijvoorbeeld als bijlage bij een rapport) met de belangrijkste beveiligingseisen van de regelgeving en de bijbehorende beheersmaatregelen/beleidslijnen in uw ISMS. Dit is niet verplicht in ISO 27001, maar het is een nuttige interne oefening om te zorgen dat niets tussen wal en schip valt. Het maakt ook indruk op auditors/assessors omdat u beveiliging niet in een vacuüm beheert, maar zich bewust bent van de juridische context.”

Voor e-mailauthenticatie wordt die tabel de brug tussen de technische DNS-realiteit en assurance op bestuursniveau.

Zet e-mailauthenticatie om in auditgereed bewijsmateriaal

Uw klanten vragen misschien nooit of uw SPF-record syntactisch perfect is. Ze zullen vragen of u uw merk kunt beschermen, phishingrisico kunt verlagen, communicatie kunt beveiligen, leveranciers kunt beheren en kunt aantonen dat uw beheersmaatregelen werken.

Clarysec helpt organisaties e-mailauthenticatie om te zetten van kwetsbare technische instellingen naar een auditgereed beheersingssysteem. De praktische volgende stap is een gerichte Email Authentication Evidence Review:

1. Bouw het domein- en verzendregister op.
2. Breng de status van SPF, DKIM, DMARC, MTA-STS en TLS-RPT in kaart.
3. Identificeer leveranciers, shadow-afzenders en uitzonderingen.
4. Maak een routekaart voor DMARC-handhaving.
5. Valideer bewijsmateriaal voor wijzigingsbeheer, logging en incidentrespons.
6. Koppel bewijsmateriaal aan ISO/IEC 27001:2022, NIS2, DORA, GDPR en NIST CSF 2.0.
7. Bereid een bewijspakket voor auditors voor met Zenith Blueprint, Zenith Controls en de relevante Clarysec-beleidsdocumenten.

Als uw organisatie zich voorbereidt op ISO/IEC 27001:2022-certificering, NIS2-gereedheid, DORA-assurance, GDPR-verantwoordingsbeoordelingen of beveiligingsvragenlijsten van klanten, begin dan met de beheersmaatregelen die aanvallers het zichtbaarst misbruiken: uw domeinen, uw afzenders en uw e-mailvertrouwensketen.

Download de Zenith Blueprint, gebruik Zenith Controls voor cross-compliance mapping en voer een 30-daagse Email Authentication Evidence Review uit voordat het volgende spoofingincident of auditverzoek het gesprek afdwingt.