Dokazi o DMARC-u za ISO 27001, NIS2, DORA i GDPR

Sve počinje tako da financijski direktor u 07:42 proslijedi e-poruku CISO-u.

“Jesmo li mi ovo poslali?”

Poruka izgleda savršeno. Isti logotip, isto podnožje, isti ton kao kod tima za naplatu. Tvrdi da su se bankovni podaci promijenili. Prikazano ime pošiljatelja je ispravno. Domena nije tipografski slična kopija. Napadač lažira stvarnu domenu.

Do 08:15 sigurnosni tim potvrđuje neugodnu istinu: SPF postoji, ali je preširoko konfiguriran, DKIM je omogućen samo za glavnu platformu e-pošte, nekoliko marketinških alata šalje nepotpisane poruke, DMARC je još uvijek u načinu praćenja, a nitko ne može pronaći posljednji pregled MTA-STS politike domene. Organizacija ima “sigurnost e-pošte” u prezentaciji, ali dokazi su raspršeni po DNS snimkama zaslona, portalima dobavljača, starim Jira zahtjevima i proračunskoj tablici koju je vodila osoba koja je otišla prošle godine.

Do 10:30 pravna služba pita mogu li biti uključeni osobni podaci klijenata. Usklađenost pita je li događaj relevantan za izvješćivanje prema NIS2. Klijent iz sektora financijskih usluga pita može li društvo dokazati IKT kontrole rizika usklađene s DORA. Interna revizija pita kako se to mapira na ISO/IEC 27001:2022. Uprava postavlja jednostavnije pitanje: “Kako je netko mogao nastupiti lažno kao mi?”

Zbog tog pitanja autentifikacija e-pošte u 2026. više nije uska DNS tema. DMARC, SPF, DKIM, MTA-STS i TLS-RPT kontrole su koje stvaraju dokaze. Smanjuju rizik od phishinga i lažiranja domene, ali istodobno stvaraju artefakte koje revizori očekuju: odluke o politikama, vlasništvo, tehničke polazne osnove, odgovornost dobavljača, zapise dnevnika, zapise praćenja, iznimke, odobrenja promjena i okidače za odgovor na incidente.

Problem usklađenosti nije: “Imamo li DMARC?” Problem je: “Možemo li dokazati da se autentifikacijom e-pošte upravlja, da se prati, pregledava i povezuje s rizikom?”

Praznina u dokazima koju revizori stalno pronalaze

Drugi scenarij jednako je čest. Vanjska revizija je u tijeku u brzorastućem fintech društvu. Revizor prelazi s kontinuiteta poslovanja na upravljanje incidentima i pita CISO-a o kompromitaciji poslovne e-pošte.

CISO objašnjava da društvo ima filtre protiv phishinga i tromjesečnu obuku za podizanje sigurnosne svijesti.

Revizor kimne, a zatim traži nešto konkretnije: “Pokažite mi upravljanje DMARC-om, SPF-om i DKIM-om. Trebam vidjeti vlasništvo, zapise promjena, procjenu rizika, dokaze praćenja i kako se to povezuje s NIS2 kibernetičkom higijenom i DORA okvirom za upravljanje IKT rizicima.”

U sobi nastaje tišina.

Tehnički tim implementirao je DMARC prije nekoliko mjeseci, ali ISMS nema referencu na politiku, nema središnji paket dokaza, nema poveznicu s registrom rizika i nema odobren plan prijelaza na provedbu. Kontrola može tehnički postojati, ali može biti nevidljiva u sustavu upravljanja.

To je praznina u dokazima.

Zreo program autentifikacije e-pošte odgovara na šest revizijskih pitanja:

1. Koje su domene i poddomene u opsegu?
2. Tko je vlasnik svake domene, DNS zone, toka e-pošte i usluge slanja?
3. Koji sustavi smiju slati u ime organizacije?
4. Koji se mehanizmi autentifikacije provode, prate i pregledavaju?
5. Kako se iznimke odobravaju, kako se rizik prihvaća i kako se iznimke ukidaju?
6. Koji dokazi potvrđuju da je kontrola djelovala tijekom vremena?

ISO/IEC 27001:2022 to čini pitanjem sustava upravljanja. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije kontekst, zahtjeve zainteresiranih strana, granice opsega, sučelja i ovisnosti. Autentifikacija e-pošte dotiče sve te elemente. Vaš registrar domene može biti dobavljač. DNS može biti hostiran u infrastrukturi u oblaku. Vaš CRM, platforma za obračun plaća, alat za fakturiranje, pružatelj marketinške automatizacije i sustav korisničke podrške mogu svi slati e-poštu koristeći vaš brend.

Točke 5.1 do 5.3 čine ovo pitanjem vodstva. Najviše rukovodstvo mora dodijeliti odgovornosti i integrirati informacijsku sigurnost u poslovne procese. DMARC odluka o prijelazu s p=none na p=quarantine ili p=reject može utjecati na komunikaciju s klijentima, financijske obavijesti, uvođenje zaposlenika u posao, prodajne kampanje i vanjske pružatelje usluga.

Točke 6.1.1 do 6.1.3 zahtijevaju procjenu rizika, obradu rizika, odabir kontrola i Izjavu o primjenjivosti. Lažiranje domene treba tretirati kao scenarij rizika, pri čemu se SPF, DKIM, DMARC, MTA-STS i TLS-RPT odabiru kao dio obrade rizika gdje je primjereno. Točka 8.1 zatim zahtijeva operativno planiranje i kontrolu, uključujući nadzor nad eksternaliziranim procesima, proizvodima i uslugama relevantnima za ISMS.

Što dokazuje svaka kontrola autentifikacije e-pošte

SPF, DKIM, DMARC, MTA-STS i TLS-RPT djeluju zajedno, ali dokazuju različite stvari.

SPF i DKIM signali su identiteta i cjelovitosti. DMARC je sloj politike koji te signale pretvara u radnju primatelja. MTA-STS i TLS-RPT podržavaju siguran prijenos e-pošte jer pomažu spriječiti rizike snižavanja razine zaštite i pogrešnih konfiguracija.

Za revizore je veća vrijednost u ponovljivim dokazima. Agregirana DMARC izvješća pokazuju tko šalje koristeći vašu domenu. TLS izvješća pokazuju neuspijeva li šifrirana isporuka. Zahtjevi za promjenu pokazuju postoji li upravljanje. Zapisi dobavljača pokazuju jesu li poznate ovisnosti opskrbnog lanca.

Najprije unesite domene u registar imovine

Autentifikacijom e-pošte ne može se upravljati ako se domene ne tretiraju kao imovina.

Politika upravljanja imovinom za MSP-ove Politika upravljanja imovinom - MSP izričito uključuje domene i identitete povezane s e-poštom u opseg:

“Digitalne vjerodajnice i usluge: nazivi domena, digitalni certifikati, API ključevi, računi e-pošte, prijave u oblak”

Iz odjeljka “Opseg”, točka politike 2.2.4.

Za veće organizacije, korporativna Politika upravljanja imovinom Politika upravljanja imovinom primjenjuje istu logiku:

“Logička imovina: nazivi domena, licence, korisnički računi, polazne konfiguracije”

Iz odjeljka “Opseg”, točka politike 2.2.5.

Ako su domene imovina, mogu imati vlasnike, ocjene kritičnosti, cikluse pregleda, ovisnosti o dobavljačima, kontrole promjena i lokacije dokaza. Ako su samo DNS zapisi, obično ostaju neupravljane dok se nešto ne pokvari.

Registar domena i slanja e-pošte spreman za reviziju trebao bi uključivati:

Ovaj registar podržava ISO/IEC 27001:2022 Annex A kontrolu A.5.9 Popis informacija i druge povezane imovine, A.8.9 upravljanje konfiguracijom, A.5.19 informacijsku sigurnost u odnosima s dobavljačima i A.5.23 informacijsku sigurnost pri korištenju usluga u oblaku. Podržava i ishode NIST CSF 2.0 za popis imovine, usluga, dobavljača i kritičnosti.

Koristite upravljanje promjenama za odluke o DNS-u i tokovima e-pošte

Autentifikacija e-pošte zakazuje kada je upravljanje promjenama slabo. Prodajni tim dodaje platformu za kontaktiranje potencijalnih klijenata. HR uvodi alat za praćenje kandidata. Financije mijenjaju softver za fakturiranje. Marketing prelazi na novog pružatelja usluge e-pošte. Svaka poslovna odluka stvara novog pošiljatelja.

Korporativna Politika upravljanja promjenama Politika upravljanja promjenama izričito postavlja zahtjev za dokazima:

“Svi zahtjevi za promjenu, pregledi, odobrenja i pripadajući dokazi moraju se evidentirati u centraliziranom Sustavu upravljanja promjenama.”

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.1.1.

Kvalitetan zahtjev za promjenu autentifikacije e-pošte trebao bi uključivati:

• Poslovno obrazloženje za novog pošiljatelja.
• Zahvaćenu domenu ili poddomenu.
• Utjecaj SPF include zapisa ili IP adrese za slanje.
• DKIM selektor i vlasništvo nad ključem.
• Rezultat testa DMARC usklađivanja.
• Utjecaj na MTA-STS ili MX, ako postoji.
• Klasifikaciju podataka u poslanim porukama.
• Referencu na sigurnosni pregled dobavljača.
• Plan povrata.
• Odobrenje vlasnika domene i sigurnosnog tima.
• Dokaze testiranja nakon implementacije.
• Datum pregleda ili isteka za privremene postavke.

To je razlika između “DNS administrator je promijenio zapis” i “ISMS je kontrolirao promjenu relevantnu za rizik.”

Praktičan 30-dnevni plan za dokaze o DMARC-u, SPF-u, DKIM-u i MTA-STS-u

CISO-u nije potreban šestomjesečni transformacijski projekt za poboljšanje zrelosti dokaza. Usmjereni 30-dnevni sprint može proizvesti dokazivu polaznu osnovu.

1. tjedan: otkrijte domene, pošiljatelje i vlasništvo

Izvezite sve domene od registrara i DNS pružatelja. Izvucite podatke o tokovima e-pošte iz pristupnika e-pošte, CRM-a, službe za korisničku podršku, marketinške platforme, sustava naplate i usluga obavješćivanja u oblaku. Izradite registar domena i slanja.

Uključite i parkirane domene i obrambene registracije. Parkirane domene često se zanemaruju, ali se i dalje mogu zloupotrijebiti ako DMARC nedostaje ili je slab.

2. tjedan: ispravite SPF i DKIM usklađivanje

Pregledajte SPF radi preširokih mehanizama, zastarjelih include zapisa, dupliciranih pružatelja i rizika od prekoračenja ograničenja DNS pretraživanja. Za DKIM identificirajte svakog pošiljatelja koji ne potpisuje e-poštu ili potpisuje domenom koja se neće uskladiti s DMARC-om.

Nemojte odobriti SaaS pošiljatelja samo zato što e-pošta radi. Odobrite ga zato što:

• Dobavljač je naveden u registru slanja.
• SPF i DKIM konfiguracija su dokumentirane.
• DKIM selektori su popisani.
• Vlasništvo nad ključevima i očekivanja pregleda su jasni.
• Sigurnosna dokumentacija dobavljača podržava sigurno postupanje s e-poštom.
• Poslovni vlasnik prihvaća svaku privremenu iznimku.

Ovdje NIS2 i DORA postaju praktični. NIS2 Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, kontinuitet poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu i održavanje, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, kontrolu pristupa i sigurne komunikacije. DORA Article 28 zahtijeva od financijskih subjekata da upravljaju IKT rizikom trećih strana kao dijelom okvira za upravljanje IKT rizicima, uključujući dubinsku analizu dobavljača, ugovorna očekivanja, praćenje i izlazno planiranje.

Ako pružatelj marketinških usluga šalje neautentificiranu e-poštu koristeći vašu domenu, to nije samo marketinško pitanje. To je rizik dobavljača, rizik lažnog predstavljanja brenda i potencijalna šteta za klijente.

3. tjedan: pomaknite DMARC prema provedbi

Način praćenja je koristan, ali trajni p=none bez odobrenog plana implementacije slab je dokaz.

Dokaziv plan provedbe DMARC-a trebao bi uključivati:

• Pregled polaznih agregiranih izvješća.
• Identifikaciju legitimnih i nelegitimnih izvora.
• Otklanjanje nedostataka legitimnih izvora koji ne prolaze provjeru.
• Poslovnu provjeru kritičnih tokova e-pošte.
• Postupno povećanje politike na pct=25, pct=50, pct=100.
• Prijelaz s p=none na p=quarantine.
• Prijelaz na p=reject kada rizik i poslovna spremnost to dopuštaju.
• Zasebno postupanje s poddomenama putem sp=.
• Registar iznimki s datumima isteka.
• Odobrenje uprave za preostali rizik.

To podržava ISO/IEC 27001:2022 točku 6.1.3 obrada rizika i točku 8.1 operativno planiranje i kontrolu. Također daje internoj reviziji jasan trag: odluka, implementacija, praćenje, iznimka, odobrenje i pregled.

4. tjedan: provjerite MTA-STS, TLS-RPT i praćenje

MTA-STS se često propušta jer ne zaustavlja lažiranje brenda u odlaznoj e-pošti na isti način kao DMARC. Međutim, vrlo je relevantan za sigurne komunikacije i zaštitu informacija u prijenosu. Kompatibilnim poslužiteljima koji šalju e-poštu govori da se pošta prema vašoj domeni mora isporučivati putem TLS-a i provjerava MX identitet.

Korporativna Politika kriptografskih kontrola Politika kriptografskih kontrola postavlja jasnu polaznu osnovu sigurnosti prijenosa:

“Sigurnost prijenosa: TLS 1.2 ili noviji (po mogućnosti TLS 1.3)”

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.1.1.5.

Za MSP-ove, Politika kriptografskih kontrola za MSP-ove Politika kriptografskih kontrola - MSP izričito uključuje prijenos e-poštom:

“Podaci koji se prenose e-poštom, korporativnim VPN-ovima i web portalima”

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.1.1.4.

Testiranje treba uključivati MX TLS provjeru, dostupnost MTA-STS datoteke politike, ispravnost HTTPS certifikata, pregled TLS-RPT izvješća i zapise trijaže za neuspjehe.

Mapirajte autentifikaciju e-pošte na ISO/IEC 27001:2022 Annex A

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls pomaže povezati tehničke dokaze s revizijskim očekivanjima kroz različite okvire. To nije zaseban skup kontrola. To je vodič za mapiranje i reviziju kontrola ISO/IEC 27001:2022 i povezanih standarda.

Za ISO/IEC 27001:2022 Annex A kontrolu A.5.14 Prijenos informacija, Zenith Controls objašnjava odnos prema kriptografiji:

“Siguran prijenos informacija oslanja se na kriptografske kontrole kako je detaljno opisano u 8.24.”

To je odnos između poslovne e-pošte, DKIM-a, MTA-STS-a i TLS-a. E-pošta je kanal prijenosa informacija. DKIM podržava autentičnost i cjelovitost poruke. MTA-STS i TLS podržavaju zaštitu prijenosa.

Za Annex A kontrolu A.8.24 Uporaba kriptografije, Zenith Controls povezuje kriptografiju s prijenosom informacija, privatnošću, zaštitom osobnih podataka (PII), klasifikacijom i upravljanjem ranjivostima. Za Annex A kontrole A.8.15 Zapisivanje događaja i A.8.16 Aktivnosti praćenja, vodič povezuje zapise dnevnika i praćenje s upravljanjem događajima, prikupljanjem dokaza, pregledom, analizom i revizibilnošću.

Politika zapisivanja događaja i praćenja za MSP-ove Politika zapisivanja događaja i praćenja - MSP navodi:

“Zapisivanje događaja mora biti omogućeno i konfigurirano gdje je dostupno”

Iz odjeljka “Zahtjevi upravljanja”, točka politike 5.5.1.1.

Korporativna Politika zapisivanja događaja i praćenja Politika zapisivanja događaja i praćenja uključuje:

“Vanjske komunikacije i okidači pravila vatrozida”

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.1.1.6.

Za autentifikaciju e-pošte, vanjske komunikacije trebaju uključivati događaje pristupnika e-pošte, obradu agregiranih DMARC izvješća, trendove DKIM neuspjeha, sumnjivu izvornu infrastrukturu, TLS-RPT neuspjehe i pokušaje lažiranja koji pokreću trijažu incidenata.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint stavlja to u praktičnu validaciju kontrola. U fazi Kontrole u praksi, korak 20, upućuje timove da provjere sigurnost mrežnih usluga:

“Navedite sve interne i vanjske mrežne usluge (DNS, VPN, SMTP, DHCP, API pristupnici itd.).

✓ Za svaku potvrdite da koristi sigurne protokole (npr. DNSSEC, TLS 1.2+, SSH umjesto Telnet).
✓ Pregledajte kako se kontrolira pristup svakoj usluzi (npr. IP popisi dopuštenih, autentifikacija, certifikati).
✓ Ako njima upravljaju treće strane (npr. DNS, SD-WAN, hostirani VPN), pregledajte sigurnosne odredbe u SLA-u ili ugovoru s dobavljačem. Ažurirajte Registar usluga i zabilježite gdje se nalaze sigurnosne odgovornosti, interno ili eksterno.”

Primijenjeno na e-poštu, to postaje plan rada za DNS, SMTP, TLS, hostirane pristupnike e-pošte, dobavljače pošiljatelje i granice odgovornosti.

Mapiranje za više okvira usklađenosti: jedan paket dokaza, mnogo obveza

Isti paket dokaza može podržati ISO/IEC 27001:2022, NIS2, DORA, GDPR i NIST CSF 2.0 ako je pravilno strukturiran.

NIS2 je posebno relevantan za ključne i važne subjekte te za određene kategorije digitalne infrastrukture i digitalnih pružatelja. Article 20 postavlja upravljanje kibernetičkom sigurnošću kao odgovornost upravljačkog tijela, dok Article 21 uspostavlja polaznu osnovu upravljanja rizicima. Dokazi o autentifikaciji e-pošte pomažu pokazati da su sigurne komunikacije, odnosi s dobavljačima, postupanje s incidentima, procjena učinkovitosti i kibernetička higijena operativni, a ne samo teorijski.

Za financijske subjekte DORA se primjenjuje od 17. siječnja 2025. Articles 5 i 6 zahtijevaju odgovornost upravljačkog tijela i dokumentiran okvir za upravljanje IKT rizicima. Article 17 zahtijeva procese za otkrivanje, upravljanje, evidentiranje, klasifikaciju, eskalaciju i otklanjanje posljedica IKT incidenata. Article 28 čini upravljanje IKT rizicima trećih strana formalnom odgovornošću. Pružatelji e-pošte, marketinške platforme, sustavi obavješćivanja o plaćanju i alati za komunikaciju s klijentima mogu postati dio tog lanca IKT ovisnosti.

Za GDPR je ključno pitanje koristi li se e-pošta za obradu osobnih podataka. Article 5 uključuje cjelovitost, povjerljivost i odgovornost. Article 32 zahtijeva odgovarajuće tehničke i organizacijske mjere. Ako računi, HR poruke, obavijesti o računima, tiketi podrške ili uvodne e-poruke sadrže osobne podatke, autentifikacija e-pošte i sigurnost prijenosa postaju dio dokaza o sigurnosti obrade.

Odgovor na incidente: kada izvješća postaju rano upozorenje

Agregirana DMARC izvješća nisu samo dokazi usklađenosti. Ona su podaci ranog upozorenja. Nagli porast neuspjele autentifikacije s nepoznate infrastrukture može upućivati na aktivno lažiranje, neodobreni IT, pogrešnu konfiguraciju dobavljača ili kompromitiranog pošiljatelja.

Prema NIS2 Article 23, ključni i važni subjekti moraju prijaviti značajne incidente bez nepotrebnog odgađanja, uz fazno izvješćivanje koje uključuje rano upozorenje, prijavu incidenta i završno izvješće. Nije svaki pokušaj lažiranja prijavljiv, ali organizacija mora moći procijeniti ozbiljnost, operativni poremećaj, financijski gubitak, prekogranični učinak i štetu za primatelje.

Prema DORA Article 17, financijski subjekti moraju definirati i implementirati proces upravljanja IKT incidentima, evidentirati incidente i značajne kibernetičke prijetnje, identificirati temeljne uzroke, koristiti pokazatelje ranog upozorenja, klasificirati prema ozbiljnosti i kritičnosti usluge, dodijeliti uloge, definirati komunikacije i eskalirati veće incidente. DORA Article 19 zatim uređuje izvješćivanje o većim IKT incidentima.

Za GDPR pitanje je je li događaj uzrokovao slučajno ili nezakonito uništenje, gubitak, izmjenu, neovlašteno otkrivanje ili pristup osobnim podacima. Lažirana e-pošta koja navede klijente da napadaču predaju osobne podatke može pokrenuti procjenu povrede podataka, čak i ako interni sustavi nisu kompromitirani.

Korporativna Politika praćenja revizije i usklađenosti Politika praćenja revizije i usklađenosti objašnjava zašto su disciplinirani dokazi važni:

“Za stvaranje dokazivih dokaza i revizijskog traga za potrebe upita regulatornih tijela, pravnih postupaka ili zahtjeva klijenata za pružanje potvrda.”

Iz odjeljka “Ciljevi”, točka politike 3.4.

Politika praćenja revizije i usklađenosti za MSP-ove Politika praćenja revizije i usklađenosti - MSP dodaje zahtjev kvalitete dokaza:

“Metapodaci (npr. tko ih je prikupio, kada i iz kojeg sustava) moraju biti dokumentirani.”

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.2.3.

DMARC istražni spis stoga treba dokumentirati izvor izvješća, vrijeme prikupljanja, analitičara, zahvaćene domene, sumnjive IP adrese pošiljatelja, rezultate autentifikacije, procjenu utjecaja na poslovanje, donesene odluke i odobrenje zatvaranja.

Što će revizori tražiti

Različiti revizori koriste različit jezik, ali dokazi se preklapaju.

Očekujte praktična pitanja:

• Pokažite DMARC izvješća za posljednje tromjesečje.
• Pokažite kako su pregledana.
• Pokažite iznimku za ovog pošiljatelja koji ne prolazi provjeru.
• Pokažite tko je odobrio ovu SPF promjenu.
• Pokažite jesu li DKIM selektori popisani i pregledani.
• Pokažite kako se MTA-STS testira nakon promjena pristupnika e-pošte.
• Pokažite kako događaji lažiranja ulaze u trijažu incidenata.
• Pokažite kako se pošiljatelji dobavljača uklanjaju pri prestanku ugovora.

Sažeti kontrolni popis interne revizije za 2026.

Koristite ovaj kontrolni popis kao početnu točku za internu reviziju, testiranje kontrola ili Pregled dokaza autentifikacije e-pošte.

• Sve domene i poddomene navedene su u registru imovine.
• Parkirane i obrambene domene pokrivene su DMARC-om.
• Svaki ovlašteni pošiljatelj ima poslovnog vlasnika i tehničkog vlasnika.
• SPF zapisi pregledavaju se radi zastarjelih include zapisa i preširokog opsega.
• DKIM je omogućen za legitimne pošiljatelje gdje je podržan.
• DKIM selektori su popisani i pregledani.
• DMARC je implementiran za korijenske domene i relevantne poddomene.
• DMARC ima plan provedbe, a ne neodređeno praćenje.
• Agregirana DMARC izvješća pregledavaju se prema definiranoj učestalosti.
• MTA-STS je konfiguriran za domene dolazne e-pošte gdje je primjenjivo.
• TLS-RPT izvješća se prikupljaju i trijažiraju.
• Promjene autentifikacije e-pošte slijede upravljanje promjenama.
• Uvođenje dobavljača uključuje zahtjeve za slanje e-pošte.
• Izlazni proces dobavljača uklanja SPF include zapise, DKIM selektore i dozvole za slanje.
• Iznimke imaju vlasnike rizika, datume isteka i kompenzacijske kontrole.
• Nagli porasti lažiranja i neuspjesi autentifikacije ulaze u odgovor na incidente.
• Dokazi uključuju metapodatke, izvor, datum, osobu koja ih je prikupila i sustav.
• Uprava prima periodične metrike i ažuriranja rizika.

Zenith Blueprint, faza upravljanja rizicima, korak 14, preporučuje izradu tablica regulatornog mapiranja za primjenjive obveze:

“Za svaku regulativu, ako je primjenjivo, možete izraditi jednostavnu tablicu mapiranja (može biti dodatak izvješću) koja navodi ključne sigurnosne zahtjeve regulative i odgovarajuće kontrole/politike u vašem ISMS-u. To nije obvezno u ISO 27001, ali je korisna interna vježba kako bi se osiguralo da ništa nije promaknulo. Također ostavlja dobar dojam na revizore/procjenitelje jer pokazuje da sigurnošću ne upravljate u vakuumu, nego uz svijest o pravnom kontekstu.”

Za autentifikaciju e-pošte ta tablica postaje most između tehničke DNS stvarnosti i potvrde na razini uprave.

Pretvorite autentifikaciju e-pošte u dokaze spremne za reviziju

Vaši klijenti možda nikada neće pitati ima li vaš SPF zapis savršenu sintaksu. Pitat će možete li zaštititi svoj brend, smanjiti rizik od phishinga, osigurati komunikacije, upravljati dobavljačima i dokazati da vaše kontrole djeluju.

Clarysec pomaže organizacijama pretvoriti autentifikaciju e-pošte iz krhkih tehničkih postavki u kontrolni sustav spreman za reviziju. Praktičan sljedeći korak je usmjereni Pregled dokaza autentifikacije e-pošte:

1. Izradite registar domena i slanja.
2. Mapirajte status SPF-a, DKIM-a, DMARC-a, MTA-STS-a i TLS-RPT-a.
3. Identificirajte dobavljače, neodobrene pošiljatelje i iznimke.
4. Izradite plan provedbe DMARC-a.
5. Provjerite dokaze upravljanja promjenama, zapisivanja događaja i odgovora na incidente.
6. Povežite dokaze s ISO/IEC 27001:2022, NIS2, DORA, GDPR i NIST CSF 2.0.
7. Pripremite paket dokaza spreman za revizora koristeći Zenith Blueprint, Zenith Controls i relevantne Clarysec politike.

Ako se vaša organizacija priprema za certifikaciju prema ISO/IEC 27001:2022, spremnost za NIS2, potvrde usklađenosti s DORA, GDPR preglede odgovornosti ili sigurnosne upitnike klijenata, krenite od kontrola koje napadači najvidljivije zlorabe: vaših domena, vaših pošiljatelja i vašeg lanca povjerenja e-pošte.

Preuzmite Zenith Blueprint, koristite Zenith Controls za mapiranje za više okvira usklađenosti i provedite 30-dnevni Pregled dokaza autentifikacije e-pošte prije nego što sljedeći incident lažiranja ili revizijski zahtjev nametne razgovor.