DLP i 2026: ISO 27001 for GDPR, NIS2 og DORA

Det starter med et regneark.

Kl. 08:17 en mandag eksporterer en kundeansvarlig 14.000 virksomhedskontakter fra CRM-systemet for at forberede en fornyelseskampagne. Kl. 08:24 vedhæftes regnearket til en e-mail. Kl. 08:26 sendes e-mailen til en personlig Gmail-konto, fordi medarbejderen vil arbejde under en togrejse. Kl. 08:31 uploades den samme fil til en ikke-godkendt AI-notattjeneste for at “rydde op i dubletter”.

Endnu ligner intet et brud. Der er ingen ransomware-note, intet malware-beacon, ingen kompromitteret administratorkonto og intet offentligt datalæk. Men for CISO’en, den complianceansvarlige og databeskyttelsesrådgiveren (DPO) er det afgørende spørgsmål allerede opstået: Kan organisationen dokumentere, at denne dataflytning var tilladt, klassificeret, logget, krypteret, begrundet og reversibel?

Det samme scenarie udspiller sig hver uge i finansielle tjenester. En udvikler forsøger at uploade Q1_Investor_Projections_DRAFT.xlsx til et personligt cloudlager, fordi VPN-forbindelsen er langsom. En salgschef eksporterer en kundeliste til en forbrugerrettet samarbejdsapp. En supportanalytiker indsætter kunderegistre i et ikke-godkendt AI-værktøj. I hvert tilfælde kan hensigten være bekvemmelighed snarere end ondsindet adfærd, men risikoen er den samme. Følsomme data har krydset, eller næsten krydset, en grænse, som organisationen ikke kontrollerer.

Det er den moderne udfordring med Data Loss Prevention. DLP er ikke længere blot en regel i en e-mailgateway eller en endpoint-agent. I 2026 er effektiv Data Loss Prevention et styret kontrolsystem med understøttende revisionsdokumentation på tværs af SaaS, cloudlagring, endpoints, mobile enheder, leverandører, API’er, udviklingsmiljøer, backupexporter, samarbejdsværktøjer og menneskelige smutveje.

GDPR Article 32 forventer passende tekniske og organisatoriske foranstaltninger for behandlingssikkerhed. NIS2 Article 21 forventer risikobaserede cybersikkerhedsforanstaltninger, herunder cyberhygiejne, adgangsstyring, politik for aktivstyring, forsyningskædesikkerhed, hændelseshåndtering, kryptering og test af effektivitet. DORA forventer, at finansielle enheder styrer IKT-risiko gennem governance, detektion, respons, genopretning, test, tilsyn med tredjeparter og revisionsbarhed. ISO/IEC 27001:2022 leverer ledelsessystemets rygrad, så disse forpligtelser bliver operationelle, målbare og revisionsbare.

Den fejl, mange organisationer begår, er at købe et DLP-værktøj, før de definerer, hvad “tab” betyder. Clarysecs tilgang starter tidligere: klassificér data, definér tilladte overførsler, håndhæv politikken, overvåg undtagelser, forbered responsbevis og forbind det hele til ISMS’et.

Som Zenith Blueprint: En revisors 30-trins køreplan siger i fasen Kontroller i praksis, Step 19, Teknologiske kontroller I:

Forebyggelse af datalækage handler om at stoppe uautoriseret eller utilsigtet videregivelse af følsomme oplysninger, uanset om de slipper ud via e-mail, clouduploads, bærbare medier eller endda et glemt print. Control 8.12 adresserer behovet for at overvåge, begrænse og reagere på data, der forlader organisationens betroede grænser, uanset om det sker digitalt, fysisk eller menneskeligt. Zenith Blueprint

Den sætning er kernen i DLP i 2026: overvåg, begræns og reager.

Hvorfor DLP nu er et compliance-spørgsmål på bestyrelsesniveau

Bestyrelsen spørger normalt ikke, om et DLP-regex finder nationale ID-numre. Den spørger, om organisationen kan beskytte kundernes tillid, fortsætte driften, undgå regulatorisk eksponering og dokumentere rimelig sikkerhed, når noget går galt.

Det er her, GDPR, NIS2 og DORA mødes.

GDPR finder bredt anvendelse på automatiseret behandling af personoplysninger, herunder på dataansvarlige og databehandlere etableret i EU samt organisationer uden for EU, der tilbyder varer eller tjenester til personer i EU eller overvåger deres adfærd. GDPR definerer personoplysninger bredt og omfatter aktiviteter såsom indsamling, opbevaring, brug, videregivelse, sletning og destruktion. Uautoriseret videregivelse af eller adgang til personoplysninger kan udgøre et brud på persondatasikkerheden. GDPR Article 5 gør også ansvarlighed eksplicit: Organisationer skal ikke blot følge principper som dataminimering, opbevaringsbegrænsning, integritet og fortrolighed; de skal også kunne dokumentere efterlevelse.

NIS2 udvider presset ud over databeskyttelse. Direktivet gælder for mange væsentlige og vigtige enheder, herunder sektorer som bankvirksomhed, finansielle markedsinfrastrukturer, cloud computing-tjenester, datacenterudbydere, managed service providers, managed security service providers, online markedspladser, søgemaskiner og sociale netværksplatforme. Article 21 kræver passende og proportionale tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, politikker for informationssystemers sikkerhed, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker udvikling, test af effektivitet, cyberhygiejne, træning, kryptografi, adgangsstyring, politik for aktivstyring og autentifikation.

DORA finder anvendelse fra 17. januar 2025 og fungerer som den finansielle sektors dedikerede regelsæt for IKT-robusthed. For finansielle enheder inden for anvendelsesområdet behandles DORA som den sektorspecifikke EU-retsakt ved overlappende NIS2-formål. DORA bringer DLP ind i styring af IKT-risiko, hændelsesklassificering, datatab, der påvirker tilgængelighed, autenticitet, integritet eller fortrolighed, test af digital operationel robusthed, IKT-tredjepartsstyring og kontraktuelle kontroller.

DLP-spørgsmålet i 2026 er ikke: “Har vi et værktøj?” Det er:

1. Ved vi, hvilke oplysninger der er følsomme?
2. Ved vi, hvor de opbevares, behandles og overføres?
3. Er tilladte og forbudte overførselsveje defineret?
4. Er brugere uddannet og teknisk begrænset?
5. Er cloud- og SaaS-veje underlagt styring?
6. Er logfiler tilstrækkelige til undersøgelse?
7. Bliver alarmer triageret, og bliver hændelser klassificeret hurtigt?
8. Er leverandører og outsourcede IKT-tjenester kontraktligt forpligtet?
9. Kan vi dokumentere, at kontrollerne fungerer?

ISO/IEC 27001:2022 er velegnet til at besvare disse spørgsmål, fordi standarden kræver kontekst, krav fra interessenter, risikovurdering, risikobehandling, målbare målsætninger, operationel styring, dokumenteret revisionsbevis, leverandørstyring, intern revision, ledelsens evaluering og løbende forbedring. Den er ikke en DLP-standard, men den gør DLP fra en isoleret teknologikonfiguration til en kontrolleret ledelsessystemproces.

ISO 27001-kontrolkæden bag effektiv DLP

Et troværdigt DLP-program bygges ikke på én kontrol. Det bygges på en kæde.

Clarysecs Zenith Controls: Tværgående guide til efterlevelse kortlægger ISO/IEC 27002:2022 control 8.12, Forebyggelse af datalækage, som en forebyggende og detekterende kontrol med fokus på fortrolighed, tilpasset cybersikkerhedskoncepterne Protect og Detect, med informationsbeskyttelse som operationel kapacitet og beskyttelse/forsvar som sikkerhedsdomæne. Zenith Controls

Det er vigtigt, fordi revisorer forventer både blokering og synlighed. En forebyggende DLP-regel uden gennemgang af alarmer er ufuldstændig. En tilgang, der alene baserer sig på logning uden håndhævelse for højrisikooverførsler, er også svag.

Den samme guide kortlægger ISO/IEC 27002:2022 control 5.12, Klassificering af information, som forebyggende, understøttende for fortrolighed, integritet og tilgængelighed og tilpasset Identify. Den kortlægger control 5.14, Overførsel af information, som forebyggende, understøttende for fortrolighed, integritet og tilgængelighed og tilpasset Protect, Asset Management og Information Protection.

I praksis ser DLP-kontrolkæden sådan ud:

Zenith Blueprint, Step 22, forklarer afhængigheden mellem aktivfortegnelse, klassificering og DLP:

Gennemgå jeres aktuelle aktivfortegnelse (5.9) for at sikre, at den omfatter både fysiske og logiske aktiver, ejere og klassificeringer. Knyt denne fortegnelse til jeres klassificeringsordning (5.12), og sørg for, at følsomme aktiver mærkes og beskyttes korrekt. Definér om nødvendigt opbevaring, backup eller isolering baseret på klassificering.

Derfor starter Clarysec sjældent en DLP-opgave med at finjustere regler. Vi starter med at afstemme aktiver, ejere, datatyper, klassificeringsmærkninger, overførselsveje og registreringer af revisionsbevis. Hvis organisationen ikke kan angive, hvilke datasæt der er fortrolige, regulerede, kundeejede, betalingsrelaterede eller forretningskritiske, kan et DLP-værktøj kun gætte.

De tre søjler i et moderne DLP-program

Et moderne DLP-program hviler på tre gensidigt forstærkende søjler: kend data, styr flowet og beskyt grænsen. Disse søjler gør ISO/IEC 27001:2022 praktisk anvendelig for efterlevelse af GDPR, NIS2 og DORA.

Søjle 1: Kend dine data med klassificering og mærkning

Du kan ikke beskytte det, du ikke forstår. ISO/IEC 27002:2022 controls 5.12 og 5.13 kræver, at organisationer klassificerer information og mærker den efter følsomhed og håndteringsbehov. Dette er ikke en papirøvelse. Det er fundamentet for automatiseret håndhævelse.

For SMV’er fastslår Politik for dataklassificering og mærkning:

Fortrolig: Kræver kryptering under overførsel og i hvile, begrænset adgang, eksplicit godkendelse til deling og sikker destruktion ved bortskaffelse. Politik for dataklassificering og mærkning - SMV

Dette citat fra afsnittet “Krav til implementering af politikken”, clause 6.3.3, giver DLP-programmet fire håndhævelige betingelser: kryptering, begrænset adgang, godkendelse til deling og sikker bortskaffelse.

I enterprise-miljøer er Politik for dataklassificering og mærkning endnu mere direkte. Fra afsnittet “Krav til implementering af politikken”, clause 6.2.6.2:

Blokering af transmission (f.eks. ekstern e-mail) for forkert mærkede følsomme data Politik for dataklassificering og mærkning

Og fra afsnittet “Håndhævelse og efterlevelse”, clause 8.3.2:

Automatiseret validering af klassificering ved hjælp af Data Loss Prevention (DLP) og discovery-værktøjer

Disse klausuler gør klassificering til en kontrol. En fil mærket Fortrolig kan udløse kryptering, blokere ekstern transmission, kræve godkendelse eller generere en sikkerhedsalarm. DLP bliver dermed håndhævelseslaget for en politik, som brugere, systemer og revisorer kan forstå.

Søjle 2: Styr flowet med sikker overførsel af information

Når data er klassificeret, skal organisationen styre, hvordan de bevæger sig. ISO/IEC 27002:2022 control 5.14, Overførsel af information, overses ofte, men det er her, mange DLP-svigt begynder.

Zenith Blueprint beskriver control 5.14 som behovet for at styre informationsflow, så overførsel er sikker, bevidst og i overensstemmelse med klassificering og forretningsformål. Det gælder e-mail, sikker fildeling, API’er, SaaS-integrationer, flytbare medier, trykte rapporter og leverandørportaler.

Fjernarbejde gør dette særligt vigtigt. Politik for fjernarbejde, afsnittet “Krav til implementering af politikken”, clause 6.3.1.3, kræver, at medarbejdere:

Kun bruger godkendte fildelingsløsninger (f.eks. M365, Google Workspace med kontroller for Data Loss Prevention (DLP)) Politik for fjernarbejde

For mobil og BYOD giver Politik for mobile enheder og BYOD, afsnittet “Krav til implementering af politikken”, clause 6.6.4, konkret endpoint-håndhævelse:

Politikker for Data Loss Prevention (DLP) skal blokere uautoriserede uploads, skærmoptagelser, adgang til udklipsholderen eller deling af data fra administrerede applikationer til personlige områder. Politik for mobile enheder og BYOD

Det er vigtigt, fordi data ikke kun forlader organisationen via e-mail. De forlader den via skærmbilleder, synkronisering af udklipsholder, ikke-administrerede browserprofiler, personlige drev, mobile delefunktioner, samarbejdsplugins og AI-værktøjer.

Cloudstyring er lige så vigtig. I SMV-versionen Politik for brug af cloudtjenester-sme, afsnittet “Styringskrav”, clause 5.5:

Skygge-IT, defineret som brug af ikke-godkendte cloudværktøjer, skal behandles som en politikovertrædelse og gennemgås af direktøren og IT-leverandøren for at fastlægge risiko og nødvendige afhjælpende foranstaltninger. Politik for brug af cloudtjenester-sme - SMV

For enterprise-organisationer hæver Politik for brug af cloudtjenester, afsnittet “Styringskrav”, clause 5.5, kravet til overvågning:

Informationssikkerhedsteamet skal rutinemæssigt vurdere netværkstrafik, DNS-aktivitet og logfiler for at opdage uautoriseret brug af cloudtjenester (skygge-IT). Konstaterede overtrædelser skal undersøges omgående. Politik for brug af cloudtjenester

Skygge-IT er ikke blot et IT-irritationsmoment. Under GDPR kan det blive ulovlig videregivelse eller ukontrolleret behandling. Under NIS2 er det en svaghed i cyberhygiejne og forsyningskæden. Under DORA kan det blive en IKT-tredjepartsrisiko og et spørgsmål om hændelsesklassificering.

Søjle 3: Beskyt grænsen med DLP-teknologi, politik og bevidsthed

ISO/IEC 27002:2022 control 8.12, Forebyggelse af datalækage, er den kontrol, de fleste forbinder med DLP. Men i et modent program er den sidste forsvarslinje, ikke den første.

Zenith Blueprint forklarer, at DLP kræver en trelaget tilgang: teknologi, politik og bevidsthed. Teknologi omfatter endpoint-DLP, e-mailsikkerhed, indholdsinspektion, sikkerhed for cloudadgang, SaaS-kontroller, browserkontroller, filtrering af udgående netværkstrafik og alarmrouting. Politikken definerer, hvad værktøjerne håndhæver. Bevidsthed sikrer, at medarbejdere forstår, hvorfor personlig e-mail, forbrugerrettet cloudlagring og ikke-godkendte AI-værktøjer ikke er acceptable håndteringsmetoder for regulerede eller fortrolige oplysninger.

Responskomponenten er lige så vigtig som forebyggelse. Zenith Blueprint, Step 19, siger:

Men DLP handler ikke kun om forebyggelse; det handler også om respons. Hvis et potentielt læk opdages:

✓ Alarmer bør triageres hurtigt, ✓ Logning bør understøtte forensisk analyse, ✓ Hændelseshåndteringsplanen skal aktiveres uden forsinkelse.

Et DLP-program, der blokerer hændelser, men ikke triagerer, undersøger og lærer af dem, er ikke revisionsklart. Det er kun delvist implementeret.

Fra regnearkslæk til revisionsklar respons

Vend tilbage til mandag morgen-regnearket.

I et svagt program opdager organisationen uploadet tre uger senere under en databeskyttelsesgennemgang. Ingen ved, hvem der godkendte eksporten, om dataene var personoplysninger, om særlige kategorier af personoplysninger var involveret, om AI-værktøjet beholdt filen, eller om kunder skal underrettes.

I et program designet af Clarysec ser forløbet anderledes ud.

Først mærkes CRM-eksporten som Fortrolig, fordi den indeholder personoplysninger og kommercielle kundeoplysninger. Dernæst logges eksporthændelsen. For det tredje opdager e-mailgatewayen en fortrolig vedhæftet fil sendt til et personligt e-maildomæne og blokerer den, medmindre der findes en godkendt undtagelse. For det fjerde udløser forsøget på upload til en ikke-godkendt cloudtjeneste en alarm om brug af cloudtjenester. For det femte triageres alarmen i forhold til hændelseshåndteringsproceduren. For det sjette vurderer sikkerhedsteamet, om der faktisk skete videregivelse, om dataene var krypterede, om udbyderen behandlede eller opbevarede dem, om GDPR-kriterierne for brud er opfyldt, og om NIS2- eller DORA-tærskler for hændelser finder anvendelse.

SMV-versionen af Lognings- og overvågningspolitik, afsnittet “Styringskrav”, clause 5.4.3, fortæller teamet præcist, hvad der skal være synligt:

Adgangslogfiler: Filadgang (særligt for følsomme data eller personoplysninger), ændringer i tilladelser, brug af delte ressourcer Lognings- og overvågningspolitik - SMV

Den klausul er kort, men afgørende. Hvis filadgang, ændringer i tilladelser og brug af delte ressourcer ikke logges, bliver DLP-undersøgelsen gætværk.

Efter NIS2 Article 23 kræver væsentlige hændelser trinvis rapportering: en tidlig advarsel inden for 24 timer efter, at organisationen er blevet bekendt med hændelsen, en hændelsesunderretning inden for 72 timer og en slutrapport senest én måned efter hændelsesunderretningen. Efter DORA kræver Articles 17 til 19, at finansielle enheder detekterer, håndterer, klassificerer, registrerer, eskalerer og rapporterer større IKT-relaterede hændelser. Klassificering omfatter datatab, der påvirker tilgængelighed, autenticitet, integritet eller fortrolighed, sammen med berørte kunder, varighed, geografisk udbredelse, kritikalitet og økonomisk påvirkning. Efter GDPR kan uautoriseret videregivelse af personoplysninger kræve vurdering af brud og, hvor tærsklerne er opfyldt, underretning.

En DLP-alarm er derfor ikke blot en sikkerhedshændelse. Den kan blive en vurdering af brud på persondatasikkerheden, et NIS2-hændelsesflow, en DORA-klassificering af IKT-hændelse, en udløser for kundeunderretning og en pakke med revisionsbevis.

DLP-kontroller for GDPR Article 32

GDPR Article 32 omsættes ofte til en liste over foranstaltninger: kryptering, fortrolighed, integritet, tilgængelighed, robusthed, test og gendannelse. For DLP er nøglen beskyttelse gennem hele livscyklussen.

Personoplysninger bevæger sig gennem indsamling, opbevaring, brug, overførsel, videregivelse, opbevaring og sletning. GDPR Article 5 kræver dataminimering, formålsbegrænsning, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. GDPR Article 6 kræver behandlingsgrundlag og forenelighed med formålet. GDPR Article 9 kræver skærpede sikkerhedsforanstaltninger for særlige kategorier af personoplysninger.

DLP understøtter disse forpligtelser, når det forbindes med dataklassificering, registreringer over lovlig behandling og godkendte overførselsveje.

Clarysecs Politik for datamaskering og pseudonymisering-sme, afsnittet “Formål”, clause 1.2, understøtter denne livscyklustilgang:

Disse teknikker er obligatoriske, hvor driftsdata ikke er nødvendige, herunder i udvikling, analyse og tredjepartsservicescenarier, for at reducere risikoen for eksponering, misbrug eller brud. Politik for datamaskering og pseudonymisering-sme - SMV

Dette er en praktisk GDPR Article 32-kontrol. Hvis udviklere, analytikere eller leverandører ikke har brug for driftsdata med personoplysninger, bør DLP ikke være den eneste barriere. Maskering og pseudonymisering reducerer konsekvensomfanget, før data overhovedet flyttes.

En stærk DLP-matrix, der er tilpasset databeskyttelse, bør kortlægge typer af personoplysninger til klassificeringsmærkninger, behandlingsgrundlag, godkendte systemer, godkendte eksportmetoder, krypteringskrav, DLP-regler, opbevaringsregler og hændelsesudløsere. Den matrix bliver broen mellem databeskyttelsesstyring og sikkerhedsdrift.

NIS2-cyberhygiejne og DLP ud over databeskyttelsesteamet

NIS2 ændrer DLP-samtalen, fordi direktivet betragter lækage som en del af cyberhygiejne og robusthed, ikke kun databeskyttelse.

Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager cybersikkerhedstræning. Article 21 kræver passende og proportionale foranstaltninger på tværs af politik, hændelseshåndtering, kontinuitet, forsyningskæde, sikker udvikling, test af effektivitet, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring og politik for aktivstyring. Article 25 tilskynder til brug af relevante europæiske og internationale standarder og tekniske specifikationer.

DLP bidrager direkte til disse områder:

Politik for netværkssikkerhed-sme, afsnittet “Mål”, clause 3.4, gør målet om eksfiltrering eksplicit:

Forhindr spredning af malware og dataeksfiltrering gennem netværkskanaler Politik for netværkssikkerhed-sme - SMV

For NIS2 giver denne type mål revisorer en direkte testvej: vis filtrering af udgående trafik, DNS-overvågning, proxylogfiler, endpoint-alarmer, blokerede uploadforsøg og undersøgelsessager.

Zenith Blueprint, Step 23, tilføjer en cloudspecifik handling, som nu er afgørende for digitale udbydere og IKT-udbydere omfattet af NIS2:

Oplist alle cloudtjenester, der aktuelt anvendes (5.23), herunder kendt skygge-IT. Identificér, hvem der godkendte dem, og om der blev udført due diligence. Udarbejd en let evalueringscheckliste, der dækker datalokation, adgangsmodel, logning og kryptering. For fremtidige tjenester skal det sikres, at checklisten integreres i indkøbs- eller IT-onboardingprocessen.

Mange organisationer fejler her. De har et ISMS-omfang og et leverandørregister, men ikke en reel liste over SaaS-værktøjer, hvor medarbejdere flytter regulerede data eller kundedata. DLP uden cloud discovery er blind.

DORA IKT-risiko: DLP for finansielle enheder og udbydere

For finansielle enheder skal DLP passe ind i DORA’s rammeværk for styring af IKT-risiko.

DORA Article 5 kræver et internt governance- og kontrolrammeværk for styring af IKT-risiko. Ledelsesorganet forbliver ansvarligt for IKT-risiko, politikker, der bevarer datas tilgængelighed, autenticitet, integritet og fortrolighed, klare IKT-roller, strategi for digital operationel robusthed, IKT-risikotolerance, kontinuitets- og respons-/genopretningsplaner, revisionsplaner, ressourcer, tredjepartspolitik og rapporteringskanaler.

Article 6 kræver et dokumenteret rammeværk for styring af IKT-risiko, der omfatter strategier, politikker, procedurer, IKT-protokoller og værktøjer til at beskytte information og IKT-aktiver. Article 9 omhandler beskyttelse og forebyggelse. Articles 11 til 14 tilføjer kontinuitet, respons, genopretning, backup, gendannelse, kontroller af dataintegritet, erfaringer, awareness-træning og krisekommunikation.

DLP passer ind i dette rammeværk som en kapacitet til beskyttelse, detektion, respons og test.

DORA gør også tredjepartsrisiko uundgåelig. Articles 28 til 30 kræver styring af IKT-tredjepartsrisiko, registre over IKT-servicekontrakter, prækontraktuel due diligence, kontraktlige krav, revisions- og inspektionsrettigheder, ophørsrettigheder, exitstrategier, servicebeskrivelser, lokationer for databehandling og -opbevaring, dataadgang, genopretning og tilbagelevering, bistand ved hændelser, samarbejde med myndigheder, sikkerhedsforanstaltninger og betingelser for underleverandører.

For en fintech eller bank kan DLP ikke stoppe ved grænsen til Microsoft 365 eller Google Workspace. Det skal dække betalingsprocessorer, udbydere af identitetsverifikation, CRM-platforme, data warehouses, cloudinfrastruktur, outsourcede supportdesks, managed service providers og kritiske SaaS-integrationer.

Dette er særligt vigtigt, hvor DORA fungerer som den sektorspecifikke EU-retsakt for overlappende NIS2-forpligtelser. Kontrollerne skal stadig findes. Rapportering og tilsynsvej kan være forskellig.

Et 90-minutters DLP-regelsprint

Clarysec bruger et praktisk sprint med kunder, der har brug for hurtig fremdrift uden at foregive, at et fuldt DLP-program kan bygges på ét møde. Målet er at implementere én DLP-kontrol med høj værdi fra politik til revisionsbevis.

Step 1: Vælg én datatype og én overførselsvej

Vælg “kunders personoplysninger eksporteret fra CRM og sendt eksternt via e-mail”. Start ikke med alle datadepoter, lande og datatyper.

Step 2: Bekræft klassificering og mærkning

Brug klassificeringspolitikken til at bekræfte, at denne eksport er Fortrolig. I en SMV kræver clause 6.3.3 kryptering, begrænset adgang, eksplicit godkendelse til deling og sikker destruktion. I en enterprise-organisation understøtter Politik for dataklassificering og mærkning blokering af transmission for forkert mærkede følsomme data og automatiseret validering ved hjælp af DLP og discovery-værktøjer.

Step 3: Definér det tilladte overførselsmønster

Tilladt: CRM-eksport sendt til et godkendt kundedomæne ved hjælp af krypteret e-mail eller en godkendt sikker fildelingsplatform, med forretningsmæssig begrundelse.

Ikke tilladt: personlig e-mail, offentlige fildelingslinks, ikke-godkendte AI-værktøjer og ikke-administrerede cloudlagre.

Dette er i overensstemmelse med Zenith Blueprint, Step 22, hvor der står:

Hvis “Fortrolig” information ikke må forlade virksomheden uden kryptering, skal e-mailsystemer håndhæve krypteringspolitikker eller blokere ekstern transmission.

Step 4: Konfigurér den mindste DLP-regel

Konfigurér e-mail- eller samarbejdsplatformen til at opdage den fortrolige mærkning, mønstre for personoplysninger eller navnekonventionen for eksportfilen. Start med overvågning, hvis der forventes falske positiver, og gå derefter videre til blokering for personlige domæner og ikke-godkendte modtagere.

Step 5: Aktivér logning og alarmrouting

Sørg for, at logfiler registrerer filadgang, ændringer i tilladelser og brug af delte ressourcer, som krævet af Lognings- og overvågningspolitik - SMV. Rout alarmer til sagskøen med alvorlighed, datatype, afsender, modtager, filnavn, udført handling og gennemgangsansvarlig.

Step 6: Test tre scenarier

Test en godkendt krypteret overførsel til en kunde, en blokeret overførsel til personlig e-mail og et uploadforsøg til et ikke-godkendt clouddomæne, der kun udløser alarm.

Step 7: Bevar revisionsbevis

Gem reference til politik-klausul, screenshot af DLP-regel, testresultater, alarmsag, gennemgangsansvarliges beslutning og ledelsesgodkendelse. Tilføj kontrollen til risikobehandlingsplanen og anvendelighedserklæringen.

I ISO/IEC 27001:2022-termer forbinder denne øvelse Clause 6.1.2 risikovurdering, Clause 6.1.3 risikobehandling, Clause 8 operationel planlægning og styring, Annex A overførsel af information, forebyggelse af datalækage, logning, overvågning, leverandør- og cloudkontroller samt Clause 9 evaluering af performance.

Kortlægning på tværs af krav: Ét DLP-program, flere forpligtelser

Styrken i Clarysecs tilgang er, at den undgår at bygge separate kontrolstakke for GDPR, NIS2, DORA, NIST og COBIT. Ét veludformet DLP-program kan opfylde flere forventninger, hvis revisionsbeviset struktureres korrekt.

NIST CSF 2.0 er nyttigt som kommunikationslag. Funktionen GOVERN understøtter sporing af juridiske, regulatoriske og kontraktlige krav, risikovillighed, håndhævelse af politikker, roller og tilsyn. Dens Profiles-metode hjælper organisationer med at afgrænse nuværende og ønsket sikkerhedstilstand, dokumentere huller og implementere en handlingsplan. Funktionerne RESPOND og RECOVER understøtter inddæmning af DLP-hændelser, rodårsagsanalyse, bevaring af revisionsbevis og gendannelse.

COBIT 2019 tilføjer et governance-perspektiv. En COBIT-orienteret revisor vil spørge, om DLP-mål er tilpasset virksomhedens mål, om ejerskab er klart, om resultatindikatorer findes, om risikovillighed er defineret, og om ledelsen modtager meningsfuld rapportering.

Hvordan revisorer vil teste dit DLP-program

DLP-revisioner handler sjældent om ét screenshot. Forskellige revisionsbaggrunde giver forskellige forventninger til revisionsbevis.

En stærk DLP-revisionspakke omfatter scope- og risikoerklæring, klassificeringsordning, godkendte overførselsmetoder, DLP-regler, godkendelser af undtagelser, logningsdesign, alarmtriageprocedure, beslutningstræ for hændelsesrapportering, leverandør- og cloudfortegnelse, testresultater og afhjælpningsregistreringer.

Almindelige DLP-svigt i 2026

De mest almindelige DLP-svigt er operationelle, ikke eksotiske.

For det første er klassificering valgfri eller inkonsistent. Mærkninger findes i politikken, men brugere anvender dem ikke, systemer håndhæver dem ikke, og datadepoter indeholder flere års umærkede følsomme filer.

For det andet implementeres DLP permanent i alarm-only-tilstand. Alarm-only er nyttigt under finjustering, men en højrisikooverførsel af fortrolige kundedata til personlig e-mail skal til sidst blokeres, medmindre der findes en godkendt undtagelse.

For det tredje behandles skygge-IT som et IT-irritationsmoment snarere end en databeskyttelsesrisiko. Politik for brug af cloudtjenester og Politik for brug af cloudtjenester-sme er designet til at gøre ikke-godkendte cloudværktøjer synlige, gennemgåelige og mulige at afhjælpe.

For det fjerde er logfiler ikke tilstrækkelige til undersøgelse. Hvis sikkerhedsteamet ikke kan rekonstruere, hvem der tilgik, delte, downloadede, uploadede eller ændrede tilladelser, kan organisationen ikke med sikkerhed vurdere rapporteringsforpligtelser efter GDPR, NIS2 eller DORA.

For det femte er leverandører uden for DLP-modellen. DORA Articles 28 til 30 gør dette særligt farligt for finansielle enheder, men problemet påvirker alle sektorer. Kontrakter bør definere datalokationer, adgang, genopretning, tilbagelevering, bistand ved hændelser, sikkerhedsforanstaltninger, underleverandører og revisionsrettigheder.

For det sjette omfatter hændelseshåndtering ikke DLP-scenarier. En fejlrettet e-mail, et uautoriseret SaaS-upload eller en masseeksport fra CRM bør have en playbook, alvorlighedskriterier og en beslutningsvej for underretning.

Endelig glemmer organisationer fysiske og menneskelige kanaler. Zenith Blueprint minder os om, at DLP omfatter clean desk-adfærd, sikker makulering, låste printkøer, printerrevisionslogfiler og medarbejderbevidsthed. Et DLP-program, der ignorerer papir, skærmbilleder og samtaler, er ufuldstændigt.

Byg et DLP-program, revisorer kan have tillid til

Hvis dit DLP-program i dag er en værktøjskonfiguration, er 2026 året, hvor det skal gøres til et styret kontrolsystem med solidt revisionsbevis.

Start med tre praktiske handlinger:

1. Vælg jeres tre vigtigste følsomme datatyper, f.eks. kunders personoplysninger, betalingsdata og kildekode.
2. Kortlæg, hvor de bevæger sig, herunder e-mail, SaaS, cloudlagring, endpoints, API’er, leverandører og udviklingsmiljøer.
3. Byg én håndhævelig DLP-regel pr. datatype, knyttet til politik, logning, hændelseshåndtering og opbevaring af revisionsbevis.

Clarysec kan hjælpe jer med at accelerere dette gennem Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint, Zenith Controls: Tværgående guide til efterlevelse Zenith Controls og politikker, der er klar til tilpasning, såsom Politik for dataklassificering og mærkning Politik for dataklassificering og mærkning, Politik for fjernarbejde Politik for fjernarbejde, Politik for brug af cloudtjenester Politik for brug af cloudtjenester, Lognings- og overvågningspolitik-sme Lognings- og overvågningspolitik - SMV og Politik for mobile enheder og BYOD Politik for mobile enheder og BYOD.

Målet er ikke at forhindre, at alle filer flyttes. Målet er at gøre sikker bevægelse til standarden, risikofyldt bevægelse synlig, forbudt bevægelse blokeret og hver undtagelse ansvarliggjort.

Download Clarysec-værktøjspakkerne, gennemgå jeres DLP-pakke med revisionsbevis, og book en beredskabsvurdering for at se, om jeres nuværende kontroller kan modstå granskning efter GDPR Article 32, NIS2-forventninger til cyberhygiejne og DORA-gennemgang af IKT-risiko.