DMARC-auditointinäyttö ISO 27001-, NIS2-, DORA- ja GDPR-vaatimuksiin

Kaikki alkaa siitä, kun talousjohtaja välittää sähköpostin tietoturvajohtajalle klo 07.42.

“Lähetimmekö me tämän?”

Viesti näyttää täydelliseltä. Sama logo, sama alatunniste ja sama sävy kuin laskutustiimillä. Viestissä väitetään, että pankkitiedot ovat muuttuneet. Lähettäjän näyttönimi on oikein. Verkkotunnus ei ole kirjoitusvirheeseen perustuva jäljitelmä. Hyökkääjä väärentää organisaation oikean verkkotunnuksen.

Klo 08.15 tietoturvatiimi vahvistaa epämiellyttävän tosiasian: SPF on olemassa, mutta liian laaja, DKIM on käytössä vain ensisijaisessa sähköpostialustassa, useat markkinointityökalut lähettävät allekirjoittamatonta sähköpostia, DMARC on edelleen seurantatilassa, eikä kukaan löydä verkkotunnuksen MTA-STS-käytännön viimeisintä katselmointia. Organisaatiolla on diasarjassa maininta “sähköpostin tietoturvasta”, mutta todentava aineisto on hajallaan DNS-kuvakaappauksissa, toimittajaportaaleissa, vanhoissa Jira-tiketeissä ja taulukossa, jonka omistaja lähti organisaatiosta viime vuonna.

Klo 10.30 lakiasiat kysyy, voiko asiakkaiden henkilötietoja olla mukana tapahtumassa. Vaatimustenmukaisuudesta vastaava toiminto kysyy, liittyykö asia NIS2-raportointiin. Finanssialan asiakas kysyy, voiko yritys osoittaa DORA:n mukaiset ICT-riskienhallinnan kontrollit. Sisäinen tarkastus kysyy, miten tämä liittyy ISO/IEC 27001:2022 -standardiin. Hallitus kysyy yksinkertaisemman kysymyksen: “Miksi joku pystyi esiintymään meihin kuuluvana tahona?”

Tämän kysymyksen vuoksi sähköpostin todennus ei ole vuonna 2026 enää kapea DNS-aihe. DMARC, SPF, DKIM, MTA-STS ja TLS-RPT ovat näyttöä tuottavia hallintakeinoja. Ne vähentävät tietojenkalastelun ja verkkotunnuksen väärentämisen riskiä, mutta samalla ne tuottavat artefakteja, joita auditoijat odottavat: käytäntöpäätöksiä, omistajuutta, teknisiä perustasoja, toimittajien vastuiden osoitettavuutta, lokeja, valvontatallenteita, poikkeuksia, muutosten hyväksyntöjä ja herätteitä tietoturvapoikkeamien käsittelyyn.

Vaatimustenmukaisuuden ongelma ei ole: “Onko meillä DMARC?” Ongelma on: “Voimmeko osoittaa, että sähköpostin todennus on hallittu, valvottu, katselmoitu ja kytketty riskeihin?”

Näyttöaukko, jonka auditoijat löytävät toistuvasti

Toinen skenaario on yhtä tavallinen. Ulkoinen auditointi on käynnissä nopeasti kasvavassa fintech-yhtiössä. Auditoija siirtyy liiketoiminnan jatkuvuudesta poikkeamien hallintaan ja kysyy tietoturvajohtajalta yrityssähköpostin kaappauksen eli business email compromise -uhan hallinnasta.

Tietoturvajohtaja selittää, että yrityksellä on tietojenkalastelun torjuntasuodattimet ja neljännesvuosittainen tietoturvatietoisuuskoulutus.

Auditoija nyökkää ja pyytää sitten tarkempaa aineistoa: “Näytä minulle DMARCin, SPF:n ja DKIMin hallinnointi. Tarvitsen omistajuuden, muutostallenteet, riskien arvioinnin, valvontanäytön ja sen, miten tämä liittyy NIS2:n kyberhygieniaan ja DORA:n ICT-riskienhallinnan viitekehykseen.”

Huone hiljenee.

Tekninen tiimi otti DMARCin käyttöön kuukausia sitten, mutta tietoturvallisuuden hallintajärjestelmässä (ISMS) ei ole politiikkaviittausta, keskitettyä näyttöpakettia, yhteyttä riskirekisteriin eikä hyväksyttyä toimeenpanon etenemissuunnitelmaa. Hallintakeino voi olla teknisesti olemassa, mutta hallinnoinnin näkökulmasta se on näkymätön.

Tämä on näyttöaukko.

Kypsä sähköpostin todennusohjelma vastaa kuuteen auditointikysymykseen:

1. Mitkä verkkotunnukset ja aliverkkotunnukset kuuluvat soveltamisalaan?
2. Kuka omistaa kunkin verkkotunnuksen, DNS-vyöhykkeen, sähköpostivirran ja lähetyspalvelun?
3. Mitkä järjestelmät saavat lähettää organisaation puolesta?
4. Mitkä todennusmekanismit ovat käytössä, valvonnassa ja katselmoinnin piirissä?
5. Miten poikkeukset hyväksytään, riski hyväksytään ja poikkeukset poistetaan käytöstä?
6. Mikä näyttö osoittaa, että hallintakeino on toiminut ajan kuluessa?

ISO/IEC 27001:2022 tekee tästä hallintajärjestelmäkysymyksen. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmien vaatimukset, soveltamisalan rajat, rajapinnat ja riippuvuudet. Sähköpostin todennus koskettaa niitä kaikkia. Verkkotunnusrekisteröijä voi olla toimittaja. DNS voi olla isännöitynä pilvi-infrastruktuurissa. CRM, palkanlaskenta-alusta, laskutustyökalu, markkinoinnin automaatiopalveluntarjoaja ja asiakastukijärjestelmä voivat kaikki lähettää sähköpostia brändisi nimissä.

Kohdat 5.1–5.3 tekevät tästä johtamiskysymyksen. Ylimmän johdon tulee osoittaa vastuut ja integroida tietoturvallisuus liiketoimintaprosesseihin. DMARC-päätös siirtymisestä asetuksesta p=none asetukseen p=quarantine tai p=reject voi vaikuttaa asiakasviestintään, taloushallinnon ilmoituksiin, HR-perehdytykseen, myyntikampanjoihin ja ulkoistettuihin palveluntarjoajiin.

Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, hallintakeinojen valintaa ja soveltuvuuslausuntoa. Verkkotunnuksen väärentäminen tulee käsitellä riskiskenaariona, jossa SPF, DKIM, DMARC, MTA-STS ja TLS-RPT valitaan tarvittaessa osaksi riskien käsittelyä. Kohta 8.1 puolestaan edellyttää operatiivista suunnittelua ja ohjausta, mukaan lukien ISMS:n kannalta merkityksellisten ulkoisesti tuotettujen prosessien, tuotteiden ja palvelujen hallinta.

Mitä kukin sähköpostin todennuksen hallintakeino osoittaa

SPF, DKIM, DMARC, MTA-STS ja TLS-RPT toimivat yhdessä, mutta ne osoittavat eri asioita.

SPF ja DKIM ovat identiteetti- ja eheysindikaattoreita. DMARC on käytäntökerros, joka muuntaa nämä indikaattorit vastaanottajan toiminnaksi. MTA-STS ja TLS-RPT tukevat sähköpostin turvallista siirtoa ehkäisemällä salauksen heikentämisen ja virheellisten määritysten riskejä.

Auditoijille syvempi arvo on toistettava näyttö. DMARC-koontiraportit osoittavat, kuka lähettää verkkotunnuksesi nimissä. TLS-raportit osoittavat, epäonnistuuko salattu toimitus. Muutostiketit osoittavat, onko hallinnointi olemassa. Toimittajatallenteet osoittavat, tunnetaanko toimitusketjuriippuvuudet.

Vie verkkotunnukset ensin omaisuusrekisteriin

Sähköpostin todennusta ei voi hallita, jos verkkotunnuksia ei käsitellä omaisuuserinä.

Pk-yrityksille tarkoitettu omaisuudenhallintapolitiikka Omaisuudenhallintapolitiikka - SME sisällyttää verkkotunnukset ja sähköpostiin liittyvät identiteetit nimenomaisesti soveltamisalaan:

“Digitaaliset tunnistetiedot ja palvelut: verkkotunnukset, digitaaliset varmenteet, API-avaimet, sähköpostitilit, pilvikirjautumiset”

Kohdasta “Soveltamisala”, politiikan kohta 2.2.4.

Suuremmille organisaatioille yritystason omaisuudenhallintapolitiikka Omaisuudenhallintapolitiikka soveltaa samaa logiikkaa:

“Loogiset omaisuuserät: verkkotunnukset, lisenssit, käyttäjätilit, peruskonfiguraatiot”

Kohdasta “Soveltamisala”, politiikan kohta 2.2.5.

Jos verkkotunnukset ovat omaisuuseriä, niillä voi olla omistajat, kriittisyysluokitukset, katselmointisyklit, toimittajariippuvuudet, muutoksenhallinta ja todentavan aineiston sijainnit. Jos ne ovat vain DNS-merkintöjä, ne jäävät yleensä hallinnoimatta, kunnes jokin rikkoutuu.

Auditointivalmiin verkkotunnus- ja sähköpostin lähetysrekisterin tulee sisältää:

Tämä rekisteri tukee ISO/IEC 27001:2022 liitteen A hallintakeinoa A.5.9 Tietojen ja muiden niihin liittyvien omaisuuserien luettelo, A.8.9 Konfiguraationhallinta, A.5.19 Tietoturva toimittajasuhteissa ja A.5.23 Tietoturva pilvipalvelujen käytössä. Se tukee myös NIST CSF 2.0:n inventaariotuloksia omaisuuseristä, palveluista, toimittajista ja kriittisyydestä.

Käytä muutoksenhallintaa DNS- ja sähköpostivirtapäätöksiin

Sähköpostin todennus rikkoutuu, kun muutoksenhallinta on heikkoa. Myyntitiimi lisää myynnin kontaktointialustan. HR ottaa käyttöön hakijaseurantatyökalun. Taloushallinto vaihtaa laskutusohjelmistoa. Markkinointi siirtyy uuteen sähköpostipalveluntarjoajaan. Jokainen liiketoimintapäätös luo uuden lähettäjän.

Yritystason muutoksenhallintapolitiikka Muutoksenhallintapolitiikka tekee näyttövaatimuksesta nimenomaisen:

“Kaikki muutospyynnöt, katselmoinnit, hyväksynnät ja niitä tukeva todentava aineisto on kirjattava keskitettyyn muutoksenhallintajärjestelmään.”

Kohdasta “Politiikan toteutusvaatimukset”, politiikan kohta 6.1.1.

Vahvan sähköpostin todennusta koskevan muutostiketin tulee sisältää:

• Liiketoimintaperuste uudelle lähettäjälle.
• Vaikutuksen kohteena oleva verkkotunnus tai aliverkkotunnus.
• SPF include -määrityksen tai lähettävän IP-osoitteen vaikutus.
• DKIM-selektori ja avainten omistajuus.
• DMARC-kohdistuksen testitulos.
• Mahdollinen MTA-STS- tai MX-vaikutus.
• Lähetettävien viestien tietoluokitus.
• Viittaus toimittajaturvallisuuden katselmointiin.
• Palautussuunnitelma.
• Verkkotunnuksen omistajan ja tietoturvan hyväksyntä.
• Toteutuksen jälkeinen testinäyttö.
• Tilapäisten asetusten katselmointipäivä tai voimassaolon päättyminen.

Tämä erottaa tilanteen “DNS-ylläpitäjä muutti tietuetta” tilanteesta “ISMS hallitsi riskirelevanttia muutosta”.

Käytännön 30 päivän suunnitelma DMARC-, SPF-, DKIM- ja MTA-STS-näytölle

Tietoturvajohtaja ei tarvitse kuuden kuukauden muutoshanketta parantaakseen näytön kypsyystasoa. Kohdennettu 30 päivän sprintti voi tuottaa puolustettavissa olevan perustason.

Viikko 1: Tunnista verkkotunnukset, lähettäjät ja omistajuus

Vie kaikki verkkotunnukset rekisteröijältä ja DNS-palveluntarjoajalta. Kerää sähköpostivirran tiedot sähköpostiyhdyskäytävästä, CRM:stä, tukipalvelusta, markkinointialustasta, laskutusjärjestelmästä ja pilvi-ilmoituspalveluista. Rakenna verkkotunnus- ja lähettäjärekisteri.

Sisällytä myös pysäköidyt verkkotunnukset ja suojaavat rekisteröinnit. Pysäköidyt verkkotunnukset jätetään usein huomiotta, mutta niitä voidaan silti väärinkäyttää, jos DMARC puuttuu tai on heikko.

Viikko 2: Korjaa SPF- ja DKIM-kohdistus

Katselmoi SPF liian sallivien mekanismien, vanhentuneiden include-määritysten, päällekkäisten palveluntarjoajien ja kyselyrajariskien varalta. DKIMin osalta tunnista jokainen lähettäjä, joka ei allekirjoita sähköpostia tai allekirjoittaa verkkotunnuksella, joka ei kohdistu DMARCiin.

Älä hyväksy SaaS-lähettäjää vain siksi, että sähköposti toimii. Hyväksy se siksi, että:

• Toimittaja on kirjattu lähettäjärekisteriin.
• SPF- ja DKIM-konfiguraatio on dokumentoitu.
• DKIM-selektorit on inventoitu.
• Avainten omistajuus ja katselmointiodotukset ovat selkeät.
• Toimittajan tietoturvadokumentaatio tukee turvallista sähköpostin käsittelyä.
• Liiketoimintavastaava hyväksyy mahdollisen tilapäisen poikkeuksen.

Tässä NIS2 ja DORA muuttuvat käytännöksi. NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta ja ylläpito, vaikuttavuuden arviointi, kyberhygienia, kryptografia, pääsynhallinta ja turvallinen viestintä. DORA Article 28 edellyttää, että finanssialan toimijat hallitsevat ICT-toimittajariskiä osana ICT-riskienhallinnan viitekehystä, mukaan lukien toimittajien ennakkoarviointi, sopimukselliset odotukset, valvonta ja irtautumissuunnittelu.

Jos markkinointipalveluntarjoaja lähettää todentamatonta sähköpostia verkkotunnuksellasi, kyse ei ole vain markkinointiasiasta. Kyse on toimittajariskistä, brändin väärinkäyttöön perustuvasta esiintymisriskistä ja mahdollisesti asiakkaisiin kohdistuvasta haitasta.

Viikko 3: Siirrä DMARC kohti toimeenpanoa

Seurantatila on hyödyllinen, mutta pysyvä p=none ilman hyväksyttyä etenemissuunnitelmaa on heikkoa näyttöä.

Puolustettavissa olevan DMARC-toimeenpanosuunnitelman tulee sisältää:

• Perustason koontiraporttien katselmointi.
• Oikeutettujen ja luvattomien lähteiden tunnistaminen.
• Oikeutettujen mutta epäonnistuvien lähteiden korjaavat toimenpiteet.
• Kriittisten sähköpostivirtojen liiketoimintavalidointi.
• Käytännön asteittainen nosto arvoihin pct=25, pct=50, pct=100.
• Siirtymä asetuksesta p=none asetukseen p=quarantine.
• Siirtymä asetukseen p=reject, kun riski ja liiketoiminnan valmius sen sallivat.
• Aliverkkotunnusten erillinen käsittely asetuksella sp=.
• Poikkeusrekisteri, jossa on voimassaolon päättymispäivät.
• Johdon hyväksyntä jäännösriskille.

Tämä tukee ISO/IEC 27001:2022 kohdan 6.1.3 mukaista riskien käsittelyä ja kohdan 8.1 mukaista operatiivista suunnittelua ja ohjausta. Se antaa myös sisäiselle tarkastukselle selkeän jäljen: päätös, toteutus, valvonta, poikkeus, hyväksyntä ja katselmointi.

Viikko 4: Validoi MTA-STS, TLS-RPT ja valvonta

MTA-STS jää usein huomaamatta, koska se ei pysäytä lähtevän sähköpostin brändiväärentämistä samalla tavalla kuin DMARC. Se on kuitenkin erittäin merkityksellinen turvallisen viestinnän ja siirrettävien tietojen suojaamisen kannalta. Se kertoo yhteensopiville lähettäville palvelimille, että sähköposti verkkotunnukseesi tulee toimittaa TLS:n yli, ja validoi MX-identiteetin.

Yritystason kryptografisten hallintakeinojen politiikka Kryptografisten hallintakeinojen politiikka asettaa selkeän siirron suojaamisen perustason:

“Siirron suojaaminen: TLS 1.2 tai uudempi (mieluiten TLS 1.3)”

Kohdasta “Politiikan toteutusvaatimukset”, politiikan kohta 6.1.1.5.

Pk-yrityksille tarkoitettu kryptografisten hallintakeinojen politiikka Kryptografisten hallintakeinojen politiikka - SME sisällyttää sähköpostin siirron nimenomaisesti:

“Sähköpostin, yritys-VPN:n ja verkkoportaalien kautta siirrettävät tiedot”

Kohdasta “Politiikan toteutusvaatimukset”, politiikan kohta 6.1.1.4.

Testauksen tulee sisältää MX TLS -validointi, MTA-STS-käytäntötiedoston saatavuus, HTTPS-varmenteen tila, TLS-RPT-raporttien katselmointi sekä vikojen luokittelu- ja priorisointitallenteet.

Kartoita sähköpostin todennus ISO/IEC 27001:2022 liitteeseen A

Clarysecin Zenith Controls: The Cross-Compliance Guide Zenith Controls auttaa yhdistämään teknisen näytön auditointiodotuksiin eri viitekehyksissä. Se ei ole erillinen kontrollijoukko. Se on kartoitus- ja auditointiopas ISO/IEC 27001:2022 -hallintakeinoihin ja niihin liittyviin standardeihin.

ISO/IEC 27001:2022 liitteen A hallintakeinon A.5.14 Tiedonsiirto osalta Zenith Controls selittää suhteen kryptografiaan:

“Turvallinen tiedonsiirto perustuu kryptografisiin hallintakeinoihin, jotka on kuvattu kohdassa 8.24.”

Tämä on liiketoimintasähköpostin, DKIMin, MTA-STS:n ja TLS:n välinen yhteys. Sähköposti on tiedonsiirtokanava. DKIM tukee viestin aitoutta ja eheyttä. MTA-STS ja TLS tukevat siirron suojaamista.

Liitteen A hallintakeinon A.8.24 Kryptografian käyttö osalta Zenith Controls kytkee kryptografian tiedonsiirtoon, tietosuojaan, PII:n suojaamiseen, luokitteluun ja haavoittuvuuksien hallintaan. Liitteen A hallintakeinojen A.8.15 Lokitus ja A.8.16 Seurantatoiminnot osalta opas yhdistää lokit ja seurannan tapahtumien hallintaan, todentavan aineiston keräämiseen, katselmointiin, analyysiin ja auditoitavuuteen.

Pk-yrityksille tarkoitettu lokitus- ja valvontapolitiikka Lokitus- ja valvontapolitiikka - SME toteaa:

“Lokitus on otettava käyttöön ja konfiguroitava, kun se on saatavilla”

Kohdasta “Hallinnointivaatimukset”, politiikan kohta 5.5.1.1.

Yritystason lokitus- ja valvontapolitiikka Lokitus- ja valvontapolitiikka sisältää:

“Ulkoisen viestinnän ja palomuurisääntöjen herätteet”

Kohdasta “Politiikan toteutusvaatimukset”, politiikan kohta 6.1.1.6.

Sähköpostin todennuksessa ulkoisen viestinnän tulee sisältää sähköpostiyhdyskäytävän tapahtumat, DMARC-koontiraporttien käsittely, DKIM-epäonnistumisten trendit, epäilyttävä lähdeinfrastruktuuri, TLS-RPT-epäonnistumiset ja väärentämisyritykset, jotka käynnistävät poikkeamien luokittelun ja priorisoinnin.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint sijoittaa tämän käytännön kontrollien validointiin. “Kontrollit käytännössä” -vaiheen vaiheessa 20 se ohjeistaa tiimejä validoimaan verkkopalvelujen turvallisuuden:

“Luetteloi kaikki sisäiset ja ulkoiset verkkopalvelut (DNS, VPN, SMTP, DHCP, API-yhdyskäytävät jne.).

✓ Varmista jokaisen osalta, että niissä käytetään turvallisia protokollia (esim. DNSSEC, TLS 1.2+, SSH Telnetin sijaan).
✓ Katselmoi, miten pääsy kuhunkin palveluun on hallittu (esim. IP-sallittujen luettelot, todennus, varmenteet).
✓ Jos kolmannet osapuolet hallinnoivat palvelua (esim. DNS, SD-WAN, isännöity VPN), katselmoi SLA:n tai toimittajasopimuksen tietoturvalausekkeet. Päivitä palvelurekisteri ja merkitse, missä tietoturvavastuut sijaitsevat, sisäisesti vai ulkoisesti.”

Sähköpostiin sovellettuna tästä tulee työsuunnitelma DNS:lle, SMTP:lle, TLS:lle, isännöidyille sähköpostiyhdyskäytäville, toimittajalähettäjille ja vastuurajoille.

Monivaatimuskartoitus: yksi näyttöpaketti, monta velvoitetta

Sama näyttöpaketti voi tukea ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR- ja NIST CSF 2.0 -vaatimuksia, jos se on jäsennelty oikein.

NIS2 on erityisen merkityksellinen keskeisille ja tärkeille toimijoille sekä tietyille digitaalisen infrastruktuurin ja digitaalisten palveluntarjoajien luokille. Article 20 tekee kyberturvallisuuden hallinnosta johdon vastuun, kun taas Article 21 määrittää riskienhallinnan perustason. Sähköpostin todennuksen näyttö auttaa osoittamaan, että turvallinen viestintä, toimittajasuhteet, poikkeamien käsittely, vaikuttavuuden arviointi ja kyberhygienia ovat operatiivisia eivätkä teoreettisia.

Finanssialan toimijoihin DORA:a on sovellettu 17. tammikuuta 2025 alkaen. Articles 5 ja 6 edellyttävät johdon vastuun osoittamista ja dokumentoitua ICT-riskienhallinnan viitekehystä. Article 17 edellyttää prosesseja ICT:hen liittyvien poikkeamien havaitsemiseen, hallintaan, kirjaamiseen, luokitteluun, eskalointiin ja korjaamiseen. Article 28 tekee ICT-toimittajariskien hallinnasta muodollisen vastuun. Sähköpostipalveluntarjoajat, markkinointialustat, maksuilmoitusjärjestelmät ja asiakasviestintätyökalut voivat kaikki tulla osaksi tätä ICT-riippuvuusketjua.

GDPR:n osalta keskeinen kysymys on, käytetäänkö sähköpostia henkilötietojen käsittelyyn. Article 5 sisältää eheyden, luottamuksellisuuden ja osoitusvelvollisuuden. Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä. Jos laskut, HR-viestit, tili-ilmoitukset, tukitiketit tai perehdytyssähköpostit sisältävät henkilötietoja, sähköpostin todennuksesta ja siirron suojaamisesta tulee osa käsittelyn turvallisuuden näyttöä.

Tietoturvapoikkeamien hallinta: kun raporteista tulee varhainen varoitus

DMARC-koontiraportit eivät ole pelkästään vaatimustenmukaisuusnäyttöä. Ne ovat varhaisen varoituksen dataa. Epäonnistuneiden todennusten piikki tuntemattomasta infrastruktuurista voi viitata aktiiviseen väärentämiseen, varjo-IT:hen, toimittajan virheelliseen konfiguraatioon tai vaarantuneeseen lähettäjään.

NIS2 Article 23:n mukaan keskeisten ja tärkeiden toimijoiden on ilmoitettava merkittävistä poikkeamista ilman aiheetonta viivytystä vaiheistetulla raportoinnilla, johon sisältyvät varhainen varoitus, poikkeamailmoitus ja loppuraportti. Kaikki väärentämisyritykset eivät ole ilmoitettavia, mutta organisaation on kyettävä arvioimaan vakavuus, toiminnan häiriö, taloudellinen menetys, rajat ylittävä vaikutus ja vastaanottajille aiheutuva haitta.

DORA Article 17:n mukaan finanssialan toimijoiden on määriteltävä ja toteutettava ICT:hen liittyvien poikkeamien hallintaprosessi, kirjattava poikkeamat ja merkittävät kyberuhat, tunnistettava juurisyyt, käytettävä varhaisen varoituksen indikaattoreita, luokiteltava poikkeamat vakavuuden ja palvelun kriittisyyden perusteella, osoitettava roolit, määriteltävä viestintä ja eskaloitava merkittävät poikkeamat. DORA Article 19 käsittelee tämän jälkeen merkittävien ICT:hen liittyvien poikkeamien raportointia.

GDPR:n osalta kysymys on, aiheuttiko tapahtuma henkilötietojen vahingossa tapahtuneen tai lainvastaisen tuhoamisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai luvattoman pääsyn henkilötietoihin. Väärennetty sähköposti, joka saa asiakkaat luovuttamaan henkilötietoja hyökkääjälle, voi käynnistää henkilötietojen tietoturvaloukkauksen arvioinnin, vaikka sisäiset järjestelmät eivät olisi vaarantuneet.

Yritystason auditointi- ja vaatimustenmukaisuuden seurantapolitiikka Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka selittää, miksi kurinalainen näyttö on tärkeää:

“Tuottaa puolustettavissa olevaa todentavaa aineistoa ja auditointijäljen viranomaistiedustelujen, oikeudellisten menettelyjen tai asiakkaiden varmentamispyyntöjen tueksi.”

Kohdasta “Tavoitteet”, politiikan kohta 3.4.

Pk-yrityksille tarkoitettu auditointi- ja vaatimustenmukaisuuden seurantapolitiikka Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - SME lisää näytön laatua koskevan vaatimuksen:

“Metatiedot (esim. kuka keräsi aineiston, milloin ja mistä järjestelmästä) on dokumentoitava.”

Kohdasta “Politiikan toteutusvaatimukset”, politiikan kohta 6.2.3.

DMARC-tutkintatiedoston tulee siksi dokumentoida raportin lähde, keräysaika, analyytikko, vaikutuksen kohteena olevat verkkotunnukset, epäillyt lähettäjä-IP-osoitteet, todennustulokset, liiketoimintavaikutusten arviointi, tehdyt päätökset ja sulkemisen hyväksyntä.

Mitä auditoijat pyytävät

Eri auditoijat käyttävät eri kieltä, mutta näyttö on pitkälti päällekkäistä.

Odota käytännön kysymyksiä:

• Näytä viimeisen vuosineljänneksen DMARC-raportit.
• Näytä, miten ne katselmoitiin.
• Näytä tämän epäonnistuvan lähettäjän poikkeus.
• Näytä, kuka hyväksyi tämän SPF-muutoksen.
• Näytä, onko DKIM-selektorit inventoitu ja katselmoitu.
• Näytä, miten MTA-STS testataan sähköpostiyhdyskäytävän muutosten jälkeen.
• Näytä, miten väärentämistapahtumat siirtyvät poikkeamien luokittelu- ja priorisointiprosessiin.
• Näytä, miten toimittajalähettäjät poistetaan sopimuksen päättyessä.

Tiivis sisäisen tarkastuksen tarkistuslista vuodelle 2026

Käytä tätä tarkistuslistaa lähtökohtana sisäiselle tarkastukselle, kontrollien testaukselle tai sähköpostin todennuksen todentavan aineiston katselmoinnille.

• Kaikki verkkotunnukset ja aliverkkotunnukset on kirjattu omaisuusrekisteriin.
• Pysäköidyillä ja suojaavilla verkkotunnuksilla on DMARC-kattavuus.
• Jokaisella valtuutetulla lähettäjällä on liiketoimintavastaava ja tekninen omistaja.
• SPF-tietueet katselmoidaan vanhentuneiden include-määritysten ja liiallisen laajuuden varalta.
• DKIM on käytössä oikeutetuille lähettäjille, kun sitä tuetaan.
• DKIM-selektorit on inventoitu ja katselmoitu.
• DMARC on otettu käyttöön juuriverkkotunnuksille ja asiaankuuluville aliverkkotunnuksille.
• DMARCilla on toimeenpanon etenemissuunnitelma, ei määrittelemätöntä jatkuvaa seurantaa.
• DMARC-koontiraportit katselmoidaan määritellyllä aikataululla.
• MTA-STS on konfiguroitu saapuvan sähköpostin verkkotunnuksille soveltuvin osin.
• TLS-RPT-raportit kerätään ja luokitellaan.
• Sähköpostin todennusta koskevat muutokset noudattavat muutoksenhallintaa.
• Toimittajien käyttöönotto sisältää sähköpostin lähettämistä koskevat vaatimukset.
• Toimittajien poistumismenettely poistaa SPF include -määritykset, DKIM-selektorit ja lähetysoikeudet.
• Poikkeuksilla on riskinomistajat, voimassaolon päättymispäivät ja korvaavat kontrollit.
• Väärentämispiikit ja todennuksen epäonnistumiset syötetään tietoturvapoikkeamien hallintaan.
• Näyttö sisältää metatiedot, lähteen, päivämäärän, kerääjän ja järjestelmän.
• Johto saa säännölliset mittarit ja riskipäivitykset.

Zenith Blueprint, Riskienhallinta-vaihe, vaihe 14, suosittelee sääntelykartoitustaulukoiden laatimista soveltuville velvoitteille:

“Jokaisesta säädöksestä voi tarvittaessa laatia yksinkertaisen kartoitustaulukon (esimerkiksi raportin liitteeksi), jossa luetellaan säädöksen keskeiset tietoturvavaatimukset ja niitä vastaavat ISMS:n hallintakeinot/politiikat. Tämä ei ole pakollista ISO 27001:ssä, mutta se on hyödyllinen sisäinen harjoitus sen varmistamiseksi, ettei mikään jää väliin. Se myös osoittaa auditoijille/arvioijille, ettei tietoturvaa hallita tyhjiössä vaan oikeudellinen toimintaympäristö tunnetaan.”

Sähköpostin todennuksessa tästä taulukosta tulee silta teknisen DNS-todellisuuden ja hallitustason varmuuden välille.

Muuta sähköpostin todennus auditointivalmiiksi näytöksi

Asiakkaasi eivät välttämättä koskaan kysy, onko SPF-tietueesi syntaksi täydellinen. He kysyvät, pystytkö suojaamaan brändisi, vähentämään tietojenkalasteluriskiä, turvaamaan viestinnän, hallitsemaan toimittajia ja osoittamaan, että kontrollisi toimivat.

Clarysec auttaa organisaatioita muuttamaan sähköpostin todennuksen hauraista teknisistä asetuksista auditointivalmiiksi kontrollijärjestelmäksi. Käytännön seuraava askel on kohdennettu sähköpostin todennuksen todentavan aineiston katselmointi:

1. Rakenna verkkotunnus- ja lähettäjärekisteri.
2. Kartoita SPF:n, DKIMin, DMARCin, MTA-STS:n ja TLS-RPT:n tila.
3. Tunnista toimittajat, varjolähettäjät ja poikkeukset.
4. Luo DMARC-toimeenpanon etenemissuunnitelma.
5. Validoi muutoksenhallinnan, lokituksen ja tietoturvapoikkeamien hallinnan näyttö.
6. Kytke näyttö ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR- ja NIST CSF 2.0 -vaatimuksiin.
7. Valmistele auditoijalle valmis näyttöpaketti hyödyntämällä Zenith Blueprint -opasta, Zenith Controls -opasta ja asiaankuuluvia Clarysec-politiikkoja.

Jos organisaatiosi valmistautuu ISO/IEC 27001:2022 -sertifiointiin, NIS2-valmiuteen, DORA-varmennukseen, GDPR:n osoitusvelvollisuuskatselmointeihin tai asiakkaiden tietoturvakyselyihin, aloita hallintakeinoista, joita hyökkääjät väärinkäyttävät näkyvimmin: verkkotunnuksistasi, lähettäjistäsi ja sähköpostin luottamusketjusta.

Lataa Zenith Blueprint, käytä Zenith Controls -opasta monivaatimuskartoitukseen ja toteuta 30 päivän sähköpostin todennuksen todentavan aineiston katselmointi ennen kuin seuraava väärentämispoikkeama tai auditointipyyntö pakottaa keskustelun käyntiin.