Sikker mail: Datatilsynets krav, kryptering og beskyttelse mod phishing
Sikker mail handler om tre ting: at indholdet er krypteret, at afsenderen er ægte, og at medarbejderne kan spotte en phishing-mail. Se Datatilsynets krav, forskellen på TLS og end-to-end, og hvordan I sætter DMARC op.
E-mail er stadig den kanal, hvor de fleste organisationer sender kontrakter, lønsedler, helbredsattester og kandidatmapper. Det er også en af hackernes foretrukne kanaler til phishing og et sted, hvor personoplysninger ofte ender hos den forkerte modtager. Når nogen søger efter sikker mail, dækker ordet derfor over flere forskellige spørgsmål på én gang.
Nogle vil vide, hvad Datatilsynet kræver, når der står et CPR-nummer i en e-mail. Andre skal have styr på DMARC, fordi Gmail eller Outlook afviser deres nyhedsbreve. Og nogle skal lære kollegerne at genkende en phishing-mail.
Denne artikel samler de tre spor: Datatilsynets aktuelle vurdering (senest opdateret 17. oktober 2025), forskellen på TLS og end-to-end-kryptering, DMARC og phishing, og koblingen til GDPR artikel 32 og NIS2. Vi slutter med et regneeksempel og med det, teknikken ikke løser.
Det korte svar: hvornår er en e-mail sikker nok?
Sender I fortrolige eller følsomme personoplysninger over internettet, er det Datatilsynets udgangspunkt, at e-mailen skal krypteres, og at krypteringen som minimum skal være TLS 1.2. TLS beskytter forbindelsen mellem mailserverne, men ikke indholdet på serverne. Sender I mange CPR-numre eller helbredsoplysninger på én gang, kan TLS alene være for lidt, og så kræver sikker mail, at selve indholdet krypteres, fx med S/MIME eller en portal. Uanset hvad I sender, bør jeres domæne have SPF, DKIM og en DMARC-politik, så andre ikke kan sende phishing-mails i jeres navn. Teknik løser ikke fejlsendte e-mails, så procedurer og træning skal med.
Fire ting, der alle bliver kaldt sikker mail
Begrebet dækker over flere beskyttelser, der løser hver sit problem. Den hyppigste fejl er at tro, at én af dem dækker de andre. En e-mail kan være sendt over en krypteret forbindelse og stadig komme fra en falsk afsender, og en korrekt DMARC-opsætning siger intet om, hvorvidt indholdet kan læses undervejs.
| Beskyttelse | Hvad den beskytter | Hvad den ikke beskytter | Typisk krav fra |
|---|---|---|---|
| Transportkryptering (TLS) | Fortroligheden mellem to mailservere, mens e-mailen er undervejs | Indholdet på serverne, fejlsendte e-mails, falske afsendere | Datatilsynet (TLS 1.2 minimum), statens tekniske minimumskrav |
| Indholdskryptering (S/MIME, PGP, portal) | Selve beskeden og vedhæftningerne hele vejen til modtageren | Metadata som afsender, modtager og emnelinje (afhængigt af løsning) | Risikovurderingen efter GDPR art. 32, når TLS ikke er nok |
| Afsenderautentificering (SPF, DKIM, DMARC) | At e-mails fra jeres domæne er ægte og ikke ændret undervejs | Fortrolighed og domæner, der blot ligner jeres | Gmail og Outlook.com for storafsendere, staten (DMARC reject) |
| Offentlige kanaler (Digital Post, NemSMS) | Sikker kommunikation mellem myndigheder og borgere eller virksomheder | Kommunikation mellem to private virksomheder | Lov om Digital Post fra offentlige afsendere |
Datatilsynets krav til sikker mail med fortrolige og følsomme oplysninger
Fra anbefaling til krav
Offentlige myndigheder har skullet kryptere fortrolige og følsomme personoplysninger i e-mails sendt over internettet siden 2000. For private virksomheder var det fra 2008 kun en anbefaling. Den 23. juli 2018 meddelte Datatilsynet, at det med databeskyttelsesforordningens risikobaserede tilgang fremover normalt vil være en passende sikkerhedsforanstaltning for både offentlige og private at kryptere den slags e-mails. Over for private blev det håndhævet fra 1. januar 2019, jf. Datatilsynets nyhed om skærpet praksis.
Det juridiske grundlag er GDPR artikel 32 om behandlingssikkerhed. Artiklen kræver passende tekniske og organisatoriske foranstaltninger og nævner kryptering i stk. 1, litra a, som et eksempel. Datatilsynets praksis er tilsynets vurdering af, hvad der er passende for e-mail over internettet. Overtrædelser af artikel 32 kan efter artikel 83, stk. 4, straffes med bøde på op til 10 mio. EUR eller 2 % af den globale årsomsætning.
Hvilke oplysninger er omfattet?
Kravet gælder to grupper af oplysninger. Følsomme oplysninger er de særlige kategorier i GDPR artikel 9, fx helbred, fagforeningsmæssigt tilhørsforhold, etnisk oprindelse og seksuel orientering. Læs mere i vores artikel om hjemmel til behandling af følsomme personoplysninger.
Fortrolige oplysninger er ikke en kategori i forordningen, men et dansk begreb. Det dækker oplysninger, som efter almindelig opfattelse bør kunne holdes hemmelige, fx indtægts- og formueforhold, ansættelsesforhold og interne familieforhold. CPR-nummeret er en fortrolig oplysning og er særskilt reguleret i databeskyttelseslovens § 11. Oplysninger om strafbare forhold er reguleret i databeskyttelseslovens § 8 og bør behandles med samme forsigtighed.
Kravet gælder ikke alle personoplysninger. I december 2019 vurderede Datatilsynet, at biblioteker kan sende beskeder om bogreserveringer som almindelige e-mails, fordi risikoen for låneren er lille. Et navn og en mødetid i en kalenderinvitation er som udgangspunkt heller ikke fortroligt. Det er risikovurderingen, der afgør det.
TLS 1.2 er minimum, men ikke altid nok
På siden om sikker transmission i sit katalog over foranstaltninger, senest opdateret 17. oktober 2025, skriver Datatilsynet, at det som udgangspunkt vil være en passende sikkerhedsforanstaltning at anvende kryptering ved transmission af fortrolige og følsomme personoplysninger med e-mail via internettet, og at krypteringen som minimum skal være TLS 1.2.
Ordet "minimum" skal tages bogstaveligt. I afgørelsen om Silkeborg Kommune fra 25. november 2021 havde en medarbejder ved en fejl sendt en liste med CPR-numre og skoleoplysninger om 12.915 elever uden indholdskryptering. Datatilsynet udtalte alvorlig kritik og skrev, at TLS på transportlaget ikke i alle tilfælde er tilstrækkeligt, når der sendes mange fortrolige eller følsomme personoplysninger. Tilsynet bemærkede også, at kommunens TLS 1.1 på grund af kendte svagheder ikke var passende.
Jo flere registrerede og jo mere følsomme data, desto mere taler for at kryptere selve indholdet og ikke kun forbindelsen.
Det, Datatilsynet peger på i praksis
Katalogets konkrete tiltag er langt mere præcise end de fleste leverandørsider:
- Tvungen TLS ("forced encryption") betyder, at e-mailen ikke sendes, hvis modtagerserveren ikke kan etablere en stærk nok forbindelse. Opportunistisk TLS garanterer ikke fortroligheden.
- Krypteret vedhæftet fil er acceptabel, hvis krypteringen er stærk, adgangskoden ikke er svag eller genbrugt, og koden sendes ad en anden kanal, fx pr. telefon til et nummer, I kender i forvejen.
- Samtykke sænker ikke niveauet. Hverken den registrerede eller den dataansvarlige kan aftale et lavere sikkerhedsniveau, end risikovurderingen tilsiger, heller ikke hvis borgeren selv beder om at få oplysningerne i en almindelig e-mail.
- Ansvaret ophører ved modtagerens server. Når e-mailen er leveret til den mailudbyder, borgeren selv har valgt, er I som udgangspunkt ikke ansvarlige for den videre behandling hos udbyderen.
- Databehandleraftaler med mail- og driftsleverandører bør beskrive, hvordan data beskyttes og sendes videre. Se vores guide til databehandleraftalen.
For teknisk opsætning henviser Datatilsynet til Styrelsen for Samfundssikkerheds vejledning om sikker brug af TLS.
TLS eller end-to-end: hvilken krypteret mail har I brug for?
For de fleste organisationer er sikker mail i praksis TLS, fordi det sker automatisk i moderne mailsystemer. Forbindelsen mellem to servere krypteres via STARTTLS, som er beskrevet i RFC 3207. Beskeden ligger til gengæld ukrypteret på afsenderens og modtagerens servere, og hvis en server i kæden ikke understøtter TLS, falder opportunistisk TLS tilbage til klartekst uden at give besked.
End-to-end-kryptering betyder, at indholdet krypteres hos afsenderen og først kan læses hos modtageren. Det kræver, at modtageren har en nøgle, et certifikat eller adgang til en portal.
| Metode | Hvordan den virker | Styrke | Svaghed |
|---|---|---|---|
| Opportunistisk TLS | Krypterer forbindelsen, hvis modtageren tilbyder det | Kræver intet af brugerne | Kan falde tilbage til klartekst uden varsel |
| Tvungen TLS | Afviser afsendelse, hvis TLS 1.2 eller højere ikke kan etableres | Opfylder Datatilsynets minimum hver gang | Beskytter ikke indholdet på serverne |
| S/MIME | Krypterer og signerer med certifikater, fx fra MitID Erhverv | Indbygget i Outlook og Apple Mail, giver også signatur | Modtageren skal have et certifikat, nøgler skal forvaltes |
| PGP/OpenPGP | Krypterer med nøglepar, som parterne selv udveksler | Åben standard, stærk kryptering | Svært for ikke-tekniske brugere, sjældent i erhvervslivet |
| Sikker mailportal | Modtageren får et link og logger ind, fx med MitID eller engangskode | Virker over for alle modtagere, også borgere | Kræver en leverandør, som er jeres databehandler |
| Krypteret fil | Vedhæftning krypteres, koden sendes ad anden kanal | Billig og hurtig i enkeltsager | Afhænger af stærke koder og disciplin hver gang |
S/MIME og certifikater fra MitID Erhverv
Danske virksomheder kan udstede bruger- og organisationscertifikater (OCES3) i MitID Erhverv og bruge dem til at kryptere og signere e-mails. Brugercertifikater knyttes til den enkelte medarbejder, organisationscertifikater kan bruges til fælles postkasser. Vær opmærksom på, at MitID Erhverv skriver, at sikker e-mail ikke er aktivt understøttet, og at der ikke ydes support til opsætningen. I skal altså selv teste det i jeres mailklient. Offentlige certifikater kan slås op via MitID Erhvervs certifikatsøgning, hvis I skal sende en krypteret mail til en bestemt modtager.
Hvornår er en portal det rigtige valg?
Når modtagerne er borgere, kandidater eller kunder uden certifikat, er S/MIME sjældent realistisk, og en portal med login er det mest praktiske. Leverandøren er jeres databehandler, så der skal være en databehandleraftale og et løbende tilsyn.
Digital Post, NemSMS og sikre kanaler til borgere
I Danmark findes der offentlige kanaler, som mange forveksler med en sikker e-mail. Digital Post er den offentlige postkasse, som myndigheder bruger til at sende breve til borgere og virksomheder. Det blev obligatorisk for virksomheder i 2013 og for borgere i 2014, og den nuværende løsning gik i luften 21. marts 2022, oplyser Digitaliseringsstyrelsen. Virksomheder modtager Digital Post via MitID Erhverv.
Digital Post er en kanal fra det offentlige og ikke en sikker mail-løsning for private. En virksomhed kan ikke bruge den til at sende CPR-numre til en samarbejdspartner. NemSMS bruges af myndigheder til servicebeskeder, fx påmindelser om en hospitalsaftale, og er ikke tænkt som en kanal til fortroligt indhold.
For private virksomheder betyder det, at I selv skal vælge en sikker kanal, når I skriver til borgere. Datatilsynet bemærker i sit katalog, at I ikke må opfordre borgere til at sende data ad en mere usikker vej, end I selv ville vælge. Beder I en jobansøger om en straffeattest, bør I altså tilbyde en sikker upload og ikke bare skrive "send den på mail".
SPF, DKIM og DMARC: bevis for at jeres e-mails er ægte
Kryptering beskytter indholdet, autentificering beskytter afsenderen. Uden den kan enhver sende en e-mail, der ser ud til at komme fra jeres domæne.
- SPF (Sender Policy Framework) er en DNS-post, der angiver, hvilke servere der må sende e-mail for jeres domæne.
- DKIM (DomainKeys Identified Mail) tilføjer en digital signatur, så modtageren kan se, at e-mailen ikke er ændret undervejs.
- DMARC binder de to sammen, kræver at domænet i afsenderfeltet stemmer overens med SPF eller DKIM, og fortæller modtageren, hvad der skal ske med e-mails, der fejler. Politikken kan være none (kun overvåg), quarantine (læg i spam) eller reject (afvis).
DMARC er gået fra god praksis til et krav, hvis I sender i stor skala. Siden 1. februar 2024 har Google krævet SPF, DKIM, DMARC og TLS af afsendere, der sender mere end 5.000 e-mails om dagen til Gmail-adresser. Microsoft indførte fra 5. maj 2025 tilsvarende krav for afsendere med mere end 5.000 e-mails om dagen til Outlook.com, Hotmail og Live, og e-mails, der ikke opfylder kravene, afvises nu med en fejlkode. For begge er p=none nok til at opfylde kravet, men p=none beskytter ikke jeres domæne mod misbrug.
For statslige myndigheder er kravet skrappere. I de tekniske minimumskrav for statslige myndigheder (2024-udgaven, opdateret september 2025) skal alle myndighedens domæner have DMARC med politikken reject, SPF på alle hoved- og subdomæner og DKIM på de domæner, der sender e-mail. Kravene omfatter også TLS 1.2 som minimum, DNSSEC og DANE for indgående mailgateways. De gælder kun staten, men er et godt pejlemærke for alle andre.
| DMARC-fase | Politik | Hvad I gør | Hvornår I går videre |
|---|---|---|---|
| 1. Overblik | p=none med rapportadresse (rua) | Find alle systemer, der sender i jeres navn: CRM, løn, nyhedsbreve, helpdesk | Når alle legitime afsendere passerer SPF eller DKIM med alignment |
| 2. Stramning | p=quarantine, evt. med pct under 100 | Følg rapporterne og ret de sidste afsendere | Når der ikke længere dukker legitim post op i karantæne |
| 3. Håndhævelse | p=reject, også for subdomæner | Beskyt også domæner, der ikke sender e-mail, med en reject-politik | Løbende overvågning, når nye systemer tages i brug |
Vil I se, hvor I står i dag, kan I teste jeres domæne gratis på sikkerpånettet.dk, som scanner for bl.a. DMARC og krypteringsniveau.
Sådan genkender I en phishing-mail
Styrelsen for Samfundssikkerhed (SAMSIK) vurderer i trusselsvurderingen Cybertruslen mod Danmark 2025 fra november 2025, at truslen fra cyberkriminalitet er meget høj, og at det er meget sandsynligt, at hackere fortsat vil bruge phishing mod danske organisationer i de kommende år. Phishing er billigt, skalerbart og effektivt, og SAMSIK forventer, at kunstig intelligens gør beskederne sværere at genkende. Samme rapport henviser til, at andelen af danskere, der har været udsat for phishing via sms, steg fra 28 % i 2022 til 51 % i 2024.
Stavefejl og dårligt dansk er derfor ikke længere et pålideligt tegn. Træn i stedet medarbejderne i at se på den handling, e-mailen beder om.
| Tegn | Eksempel | Hvad medarbejderen gør |
|---|---|---|
| Hast eller autoritet | "Direktøren skal bruge overførslen inden kl. 14" | Ring op på et kendt nummer, aldrig nummeret i e-mailen |
| Ændrede betalingsoplysninger | "Vi har skiftet bank, brug dette kontonummer" | Verificér ad en anden kanal, før noget ændres i økonomisystemet |
| Login-link | "Din adgangskode udløber, log ind her" | Gå til tjenesten via bogmærke, ikke via linket |
| Domæne, der næsten passer | dot1egal.com i stedet for dotlegal.com | Hold musen over afsender og link, og læs domænet bagfra |
| Uventet vedhæftning eller QR-kode | "Se vedhæftede faktura" fra en ukendt leverandør | Åbn ikke, brug rapportknappen i mailklienten |
Den form for phishing, der koster mest, er ofte direktørsvindel, også kaldet business e-mail compromise (BEC), hvor der hverken er et link eller en vedhæftning, kun en overbevisende anmodning. Her hjælper kun faste procedurer for betalinger og en kultur, hvor det er i orden at ringe og tjekke. Læs mere i vores artikler om anti-phishing og awareness-træning, og se SAMSIKs råd på sikkerdigital.dk.
Har en medarbejder klikket og indtastet sin adgangskode, skal adgangskoden skiftes, sessioner lukkes og videresendelsesregler i postkassen kontrolleres. Har angriberen haft adgang til personoplysninger, er det et brud på persondatasikkerheden, som skal vurderes og som udgangspunkt anmeldes til Datatilsynet inden for 72 timer efter GDPR artikel 33.
NIS2 og ISO 27001: e-mail som en del af kryptografipolitikken
For organisationer omfattet af NIS2 er e-mail ikke kun et GDPR-spørgsmål. Den danske NIS 2-lov (lov nr. 434 af 6. maj 2025), der trådte i kraft 1. juli 2025, gennemfører direktivets artikel 21, stk. 2, i lovens § 6, stk. 1. Tre af de ti minimumsforanstaltninger rammer e-mail direkte:
- § 6, stk. 1, nr. 8 (direktivets litra h): politikker og procedurer vedrørende brug af kryptografi og, hvor det er relevant, kryptering.
- § 6, stk. 1, nr. 10 (litra j): multifaktorautentificering og sikret tale-, video- og tekstkommunikation, hvor det er relevant.
- § 6, stk. 1, nr. 7 (litra g): grundlæggende cyberhygiejne og cybersikkerhedsuddannelse, hvor phishing-træning er et naturligt element.
NIS2 kræver altså ikke en bestemt teknologi, men en dokumenteret politik for, hvornår og hvordan I krypterer. For udbydere af digitale tjenester som cloud, datacentre og administrerede tjenester præciserer gennemførelsesforordning (EU) 2024/2690 kravene til kryptografi yderligere. Overtrædelser kan for væsentlige enheder give bøder på op til 10 mio. EUR eller 2 % af den globale omsætning, for vigtige enheder op til 7 mio. EUR eller 1,4 %. Læs mere i vores NIS2-overblik.
I ISO/IEC 27001:2022 (udgivet i Danmark som DS/EN ISO/IEC 27001:2023) svarer det til Annex A-kontrol 8.24 om brug af kryptografi og 5.14 om overførsel af information.
| Foranstaltning | GDPR | NIS 2-loven | ISO 27001:2022 Annex A |
|---|---|---|---|
| TLS 1.2 eller højere, tvungen TLS | Art. 32, stk. 1, litra a | § 6, stk. 1, nr. 8 | 8.24, 5.14 |
| Indholdskryptering af følsomme data | Art. 32, stk. 1, litra a | § 6, stk. 1, nr. 8 og 10 | 8.24, 5.14 |
| SPF, DKIM og DMARC | Art. 32, stk. 1, litra b (integritet) | § 6, stk. 1, nr. 7 og 10 | 8.20, 8.21, 5.14 |
| MFA på postkasser | Art. 32, stk. 1, litra b | § 6, stk. 1, nr. 10 | 8.5 |
| Phishing-træning | Art. 32, stk. 1 (organisatoriske foranstaltninger) | § 6, stk. 1, nr. 7 | 6.3 |
| Politik for hvad der må sendes | Art. 24 og 32 | § 6, stk. 1, nr. 1 og 8 | 5.1, 5.10, 5.14 |
Mappingen er vores egen læsning af kilderne. Den er ment som et udgangspunkt for jeres egen vurdering, ikke som en officiel krydsreference.
Sådan sender I sikker mail i syv trin
- Kortlæg hvad der sendes. Find de processer, hvor fortrolige og følsomme oplysninger sendes pr. e-mail: HR, løn, rekruttering, kundeservice, sagsbehandling. Jeres fortegnelse over behandlingsaktiviteter er et godt sted at starte.
- Lav en risikovurdering. Vurdér mængde, type og antal registrerede pr. forsendelse, som Datatilsynet beskriver det. Se vores guide til GDPR-risikovurdering.
- Sæt tvungen TLS 1.2 eller højere op over for faste samarbejdspartnere, og tjek at ældre versioner er slået fra.
- Vælg en løsning til indholdskryptering til de forsendelser, hvor TLS ikke er nok: S/MIME over for partnere med certifikat, en portal over for borgere.
- Gør det sikre valg til standard. Datatilsynet peger på, at det kan være nødvendigt at bruge en fast metode med høj sikkerhed ved alle forsendelser, hvis det er for svært for medarbejderne at vælge rigtigt hver gang.
- Indfør SPF, DKIM og DMARC og bevæg jer fra p=none til p=reject efter en plan.
- Skriv reglerne ned og træn dem. En kort e-mailpolitik, en procedure for fejlsendte e-mails og årlig phishing-træning. Genbesøg det hele én gang om året.
Regneeksempel: krypteret e-mail i et rekrutteringsfirma
Kystlinjen Rekruttering A/S og Mette Holm er fiktive. Vi har opfundet dem til denne artikel, og de er hverken kunder eller en case.
Kystlinjen Rekruttering har 140 ansatte og sender omkring 2.000 e-mails om ugen til kunder og kandidater. Mette Holm er compliance-ansvarlig og skal sikre, at opsætningen lever op til Datatilsynets praksis.
Hun starter med at trække en stikprøve på én uge. 120 e-mails, altså 6 %, indeholder fortrolige eller følsomme oplysninger: kandidatmapper med CPR-nummer, lønforventninger og i nogle tilfælde helbredsoplysninger fra testforløb. Af de 120 går 80 til 12 faste kundedomæner, og 40 går til kandidater på Gmail, Hotmail og lignende.
Hendes løsning på sikker mail har tre dele. Over for de 12 kundedomæner sætter it-afdelingen tvungen TLS 1.2 op, så en e-mail ikke sendes, hvis forbindelsen ikke kan krypteres. Kandidaterne får oplysninger gennem en sikker mailportal med login, fordi de ikke har certifikater, og fordi en krypteret zip-fil med kode pr. sms kræver for meget disciplin 40 gange om ugen. Kandidatmapper med helbredsoplysninger sendes altid via portalen, også til kunder, fordi Silkeborg-afgørelsen viser, at TLS alene ikke altid rækker ved særlige kategorier.
Samtidig starter hun DMARC med p=none. Rapporterne viser syv systemer, der sender i virksomhedens navn, og to af dem fejler DKIM. Efter seks uger er de rettet, i uge otte går domænet på p=quarantine, og i uge 14 på p=reject.
Resultatet er ikke, at alle 2.000 e-mails om ugen krypteres end-to-end. Det er, at de 120, der betyder noget, har en fast og dokumenteret vej, og at ingen kan sende en falsk faktura fra Kystlinjens domæne. Havde Kystlinjen kun haft faste erhvervskunder, kunne tvungen TLS og S/MIME have været nok. Løsningen følger modtagerne og datatyperne.
Det, kryptering og DMARC ikke løser
Kryptering er ikke en garanti mod brud. Det største problem i Datatilsynets statistik er ikke aflytning, men e-mails til den forkerte modtager. I årsberetningen for 2022 skyldtes 5.066 anmeldte brud fejlagtig fremsendelse af oplysninger, og 3.945 af dem handlede om oplysninger sendt til en forkert modtager. En perfekt krypteret e-mail til den forkerte person er stadig et brud.
Her hjælper andre foranstaltninger: at slå auto-complete fra for eksterne adresser, som Datatilsynet anbefaler i sin vejledning om auto-complete, en forsinkelse på udgående e-mails, og data loss prevention, der advarer, når en e-mail med CPR-numre er på vej ud.
Der er flere begrænsninger. End-to-end-kryptering kan gøre det sværere for jeres egne filtre at scanne for malware. Kryptering af indholdet skjuler ikke altid, hvem der skriver med hvem, og det kan i sig selv være fortroligt, fx hvis modtageren er et misbrugscenter. DMARC stopper ikke phishing-mails fra domæner, der blot ligner jeres. Og har en angriber overtaget en postkasse, er alle e-mails ægte i teknisk forstand. Derfor hører MFA, logning og træning med.
Den mest effektive foranstaltning er ofte at lade være med at sende oplysningerne. Kan CPR-nummeret erstattes af et kandidatnummer, falder behovet for kryptering. Datatilsynet nævner selv dataminimering og pseudonymisering som måder at mindske risikoen på.
Sådan understøtter .legal arbejdet med e-mailsikkerhed
Den tekniske opsætning af sikker mail, altså TLS, S/MIME og DMARC, sker i jeres mailsystem, ikke i .legal. Det, .legal hjælper med, er det, der skal dokumenteres omkring den: risikovurderingen, politikken og opfølgningen.
I informationssikkerhedsmodulet kan I registrere jeres mailsystem som et aktiv, knytte risici og kontroller til det og dokumentere, hvilke foranstaltninger der er valgt og hvorfor. Med Frameworks kan den samme kontrol, fx jeres kryptografipolitik, mappes til både GDPR artikel 32, NIS 2-lovens § 6 og ISO 27001 Annex A 8.24, så I ikke dokumenterer den tre gange. Og i compliance-årshjulet kan I lægge den årlige gennemgang af DMARC-rapporter, certifikatfornyelse og phishing-træning ind som faste opgaver med en ansvarlig.
Leverandøren af jeres sikre mailportal er en databehandler, og tilsynet med den kan køres gennem vendor management-modulet. Vil I se, hvordan det ser ud i praksis, kan I booke en demo.
.legal compliance platform
Sikr din e-mailkommunikation med .legal
-
Dokumenter e-mail-sikkerhedspolitikker og -protokoller
-
Spor implementering af SPF, DKIM og DMARC
-
Overvåg overholdelse af sikkerhedsstandarder
-
Administrer leverandørvurderinger for e-mail-sikkerhed
.jpeg?width=131&height=26&name=right_people_logo%20(1).jpeg){kind=small}
.jpg?width=58&height=26&name=Praktiserende%20L%C3%A6gers%20Organisation%20(1).jpg){kind=small}
.jpg?width=108&height=26&name=finans%20danmark%20(1).jpg){kind=small}
.jpg?width=89&height=26&name=klasselotteri%20(1).jpg){kind=small}
.png?width=34&height=26&name=bws_shipping_rgb%20-%20Kopi%20(2).png){kind=small}
.jpeg?width=135&height=26&name=AH%20industries%20(1).jpeg){kind=small}
.jpg?width=225&height=26&name=KAUFMANN%20(1).jpg){kind=small}
