DLP 2026: ISO 27001 för GDPR, NIS2 och DORA

Det börjar med ett kalkylblad.

Klockan 08:17 en måndag exporterar en kundansvarig 14 000 företagskontakter från CRM-systemet för att förbereda en förnyelsekampanj. Klockan 08:24 bifogas kalkylbladet i ett e-postmeddelande. Klockan 08:26 skickas e-postmeddelandet till ett personligt Gmail-konto eftersom medarbetaren vill arbeta under en tågresa. Klockan 08:31 laddas samma fil upp till en icke-godkänd AI-tjänst för anteckningar för att ”rensa dubbletter”.

Ingenting ser ännu ut som en incident. Det finns ingen ransomware-notis, ingen signalering från skadlig kod, inget komprometterat administratörskonto och inget offentligt läckage. Men för CISO, regelefterlevnadsansvarig och dataskyddsombud har den verkliga frågan redan uppstått: kan organisationen visa att denna dataförflyttning var tillåten, klassificerad, loggad, krypterad, motiverad och möjlig att återkalla?

Samma scenario utspelar sig i finansiella tjänster varje vecka. En utvecklare försöker ladda upp Q1_Investor_Projections_DRAFT.xlsx till personlig molnlagring eftersom VPN-anslutningen är långsam. En försäljningschef exporterar en kundlista till en konsumentinriktad samarbetsapp. En supportanalytiker klistrar in kundregister i ett icke-godkänt AI-verktyg. I varje fall kan avsikten vara bekvämlighet snarare än illvilja, men risken är densamma. Känsliga data har passerat, eller nästan passerat, en gräns som organisationen inte kontrollerar.

Det är det moderna DLP-problemet. DLP är inte längre bara en regel i en e-postgateway eller en agent för slutpunktssäkerhet. Under 2026 är effektivt skydd mot dataläckage ett styrt kontrollsystem med robust revisionsunderlag över SaaS, molnlagring, slutpunkter, mobila enheter, leverantörer, API:er, utvecklingsmiljöer, exporter från säkerhetskopior, samarbetsverktyg och mänskliga genvägar.

GDPR Article 32 förutsätter lämpliga tekniska och organisatoriska åtgärder för säkerhet vid behandling. NIS2 Article 21 kräver riskbaserade cybersäkerhetsåtgärder, inklusive cyberhygien, åtkomstkontroll, hantering av tillgångar, säkerhet i leveranskedjan, incidenthantering, kryptering och effektivitetsprovning. DORA kräver att finansiella entiteter hanterar IKT-risk genom styrning, detektering, respons, återhämtning, testning, tredjepartstillsyn och revisionsbarhet. ISO/IEC 27001:2022 ger ledningssystemets ryggrad för att göra dessa skyldigheter operativa, mätbara och granskningsbara.

Misstaget många organisationer gör är att köpa ett DLP-verktyg innan de har definierat vad ”förlust” innebär. Clarysecs arbetssätt börjar tidigare: klassificera data, definiera tillåtna överföringar, tillämpa policyn, övervaka undantag, förbereda responsunderlag och koppla allt till ISMS.

Som Zenith Blueprint: An Auditor’s 30-Step Roadmap beskriver i fasen Controls in Action, Step 19, Technological Controls I:

Skydd mot dataläckage handlar om att stoppa obehörigt eller oavsiktligt röjande av känslig information, oavsett om den lämnar organisationen via e-post, molnuppladdningar, portabla lagringsmedier eller till och med en kvarglömd utskrift. Kontroll 8.12 hanterar behovet av att övervaka, begränsa och reagera på data som lämnar organisationens betrodda gränser, oavsett om det sker digitalt, fysiskt eller genom mänskligt agerande. Zenith Blueprint

Den meningen är kärnan i DLP under 2026: övervaka, begränsa och reagera.

Varför DLP nu är en efterlevnadsfråga på styrelsenivå

Styrelsen frågar normalt inte om ett DLP-reguljärt uttryck detekterar nationella ID-nummer. Den frågar om organisationen kan skydda kundernas förtroende, fortsätta bedriva verksamhet, undvika regulatorisk exponering och visa rimlig säkerhet när något går fel.

Det är där GDPR, NIS2 och DORA möts.

GDPR gäller brett för automatiserad behandling av personuppgifter, inklusive personuppgiftsansvariga och personuppgiftsbiträden etablerade i EU samt organisationer utanför EU som erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende. GDPR definierar personuppgifter brett och omfattar åtgärder som insamling, lagring, användning, utlämnande, radering och förstöring. Obehörigt röjande av, eller obehörig åtkomst till, personuppgifter kan utgöra en personuppgiftsincident. GDPR Article 5 gör också ansvarsskyldigheten uttrycklig: organisationer ska inte bara följa principer som uppgiftsminimering, lagringsminimering, riktighet och konfidentialitet; de ska också kunna visa efterlevnad.

NIS2 utvidgar trycket bortom integritetsskydd. Direktivet gäller många väsentliga och viktiga entiteter, inklusive sektorer som bankverksamhet, finansmarknadsinfrastruktur, leverantörer av molntjänster, datacenterleverantörer, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, onlinemarknadsplatser, sökmotorer och sociala nätverksplattformar. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, säkerhetspolicyer för informationssystem, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, effektivitetsprovning, cyberhygien, utbildning, kryptografi, åtkomstkontroll, hantering av tillgångar och autentisering.

DORA gäller från den 17 januari 2025 och fungerar som finanssektorns särskilda regelverk för IKT-resiliens. För finansiella entiteter som omfattas behandlas DORA som den sektorsspecifika unionsrättsakten vid överlappning med NIS2. DORA för in DLP i IKT-riskhantering, incidentklassificering, dataförlust som påverkar tillgänglighet, autenticitet, riktighet eller konfidentialitet, testning av digital operativ resiliens, hantering av IKT-tredjeparter och avtalsstyrda kontroller.

DLP-frågan för 2026 är inte ”Äger vi ett verktyg?” Den är:

1. Vet vi vilken information som är känslig?
2. Vet vi var den lagras, behandlas och överförs?
3. Är tillåtna och förbjudna överföringsvägar definierade?
4. Är användare utbildade och tekniskt begränsade?
5. Är moln- och SaaS-flöden styrda?
6. Är loggarna tillräckliga för utredning?
7. Triageras larm och klassificeras incidenter snabbt?
8. Är leverantörer och outsourcade IKT-tjänster avtalsmässigt bundna?
9. Kan vi visa att kontrollerna fungerar?

ISO/IEC 27001:2022 lämpar sig väl för att besvara dessa frågor eftersom standarden kräver kontext, intressentkrav, riskbedömning, riskbehandling, mätbara mål, operativ styrning, dokumenterad information, leverantörskontroll, internrevision, ledningens genomgång och ständig förbättring. Den är inte en DLP-standard, men den gör DLP från en isolerad teknisk konfiguration till en styrd process i ledningssystemet.

ISO 27001-kontrollkedjan bakom effektiv DLP

Ett trovärdigt DLP-program byggs inte på en enda kontroll. Det byggs på en kedja.

Clarysecs Zenith Controls: The Cross-Compliance Guide mappar ISO/IEC 27002:2022-kontroll 8.12, Skydd mot dataläckage, som en förebyggande och upptäckande kontroll med fokus på konfidentialitet, anpassad till cybersäkerhetsbegreppen Protect och Detect, med informationsskydd som operativ förmåga och protection/defense som säkerhetsdomän. Zenith Controls

Det är viktigt eftersom revisorer förväntar sig både blockering och synlighet. En förebyggande DLP-regel utan larmgranskning är ofullständig. Ett arbetssätt som endast bygger på loggning, utan krav på blockering vid högrisköverföringar, är också svagt.

Samma guide mappar ISO/IEC 27002:2022-kontroll 5.12, Klassificering av information, som förebyggande, stödjande för konfidentialitet, riktighet och tillgänglighet, och anpassad till Identify. Den mappar kontroll 5.14, Informationsöverföring, som förebyggande, stödjande för konfidentialitet, riktighet och tillgänglighet, och anpassad till Protect, Asset Management och Information Protection.

I praktiken ser DLP-kontrollkedjan ut så här:

Zenith Blueprint, Step 22, förklarar beroendet mellan tillgångsregister, klassificering och DLP:

Granska er nuvarande tillgångsförteckning (5.9) för att säkerställa att den omfattar både fysiska och logiska tillgångar, ägare och klassificeringar. Koppla denna förteckning till ert klassificeringsschema (5.12) och säkerställ att känsliga tillgångar är märkta och skyddas på rätt sätt. Definiera vid behov bevarande, säkerhetskopiering eller isolering baserat på klassificering.

Därför börjar Clarysec sällan ett DLP-uppdrag med att justera regler. Vi börjar med att stämma av tillgångar, ägare, datatyper, klassificeringsmärkningar, överföringsvägar och underlag. Om organisationen inte kan säga vilka dataset som är konfidentiella, reglerade, kundägda, betalningsrelaterade eller verksamhetskritiska kan ett DLP-verktyg bara gissa.

De tre pelarna i ett modernt DLP-program

Ett modernt DLP-program står på tre förstärkande pelare: förstå data, styra flödet och försvara gränsen. Dessa pelare gör ISO/IEC 27001:2022 praktiskt användbar för efterlevnad av GDPR, NIS2 och DORA.

Pelare 1: förstå era data genom klassificering och märkning

Ni kan inte skydda det ni inte förstår. ISO/IEC 27002:2022-kontrollerna 5.12 och 5.13 kräver att organisationer klassificerar information och märker den utifrån känslighet och hanteringskrav. Detta är inte en pappersövning. Det är grunden för automatiserad tillämpning.

För små och medelstora företag anger Data Classification and Labeling Policy:

Confidential: Kräver kryptering under överföring och i vila, begränsad åtkomst, uttryckligt godkännande för delning och säker förstöring vid avveckling. Data Classification and Labeling Policy - SME

Detta citat, från avsnittet ”Krav för genomförande av policyn”, klausul 6.3.3, ger DLP-programmet fyra villkor som kan tillämpas: kryptering, begränsad åtkomst, godkännande för delning och säker avveckling.

I företagsmiljöer är Data Classification and Labeling Policy ännu tydligare. Från avsnittet ”Krav för genomförande av policyn”, klausul 6.2.6.2:

Blockering av överföring, till exempel extern e-post, för felaktigt märkta känsliga data Data Classification and Labeling Policy

Och från avsnittet ”Efterlevnad och tillämpning”, klausul 8.3.2:

Automatiserad validering av klassificering med Data Loss Prevention (DLP) och verktyg för upptäckt

Dessa klausuler gör klassificering till en kontroll. En fil märkt Confidential kan utlösa kryptering, blockera extern överföring, kräva godkännande eller generera ett säkerhetslarm. DLP blir då det tillämpande lagret för en policy som användare, system och revisorer kan förstå.

Pelare 2: styr flödet med säker informationsöverföring

När data är klassificerade måste organisationen styra hur de rör sig. ISO/IEC 27002:2022-kontroll 5.14, Informationsöverföring, förbises ofta, men det är där många DLP-brister börjar.

Zenith Blueprint beskriver kontroll 5.14 som behovet av att styra informationsflöden så att överföring sker säkert, avsiktligt och i linje med klassificering och verksamhetssyfte. Detta gäller e-post, säker fildelning, API:er, SaaS-integrationer, flyttbara lagringsmedier, utskrivna rapporter och leverantörsportaler.

Distansarbete gör detta särskilt viktigt. Remote Work Policy, avsnittet ”Krav för genomförande av policyn”, klausul 6.3.1.3, kräver att anställda:

Endast använder godkända lösningar för fildelning, till exempel M365 eller Google Workspace med kontroller för Data Loss Prevention (DLP) Remote Work Policy

För mobila enheter och BYOD ger Mobile device and byod policy, avsnittet ”Krav för genomförande av policyn”, klausul 6.6.4, konkret tekniskt genomförande på slutpunkter:

Data Loss Prevention-policyer (DLP) ska blockera obehöriga uppladdningar, skärmbilder, åtkomst till urklipp eller datadelning från hanterade applikationer till personliga områden. Mobile device and byod policy

Detta är viktigt eftersom data inte bara lämnar via e-post. De lämnar via skärmbilder, synkronisering av urklipp, ohanterade webbläsarprofiler, personliga enheter, mobila delningsfunktioner, samarbetsinsticksprogram och AI-verktyg.

Molnstyrning är lika viktig. I SME-versionen av Cloud Usage Policy-sme, avsnittet ”Styrningskrav”, klausul 5.5, anges:

Skugg-IT, definierat som användning av icke-godkända molnverktyg, ska behandlas som en policyöverträdelse och granskas av GM och IT-leverantören för att fastställa risk och nödvändiga avhjälpande åtgärder. Cloud Usage Policy-sme - SME

För företagsorganisationer höjer Cloud Usage Policy, avsnittet ”Styrningskrav”, klausul 5.5, kraven på övervakning:

Informationssäkerhetsteamet ska regelbundet bedöma nätverkstrafik, DNS-aktivitet och loggar för att upptäcka otillåten användning av molntjänster (skugg-IT). Identifierade överträdelser ska utredas utan dröjsmål. Cloud Usage Policy

Skugg-IT är inte bara ett IT-irritationsmoment. Enligt GDPR kan det bli otillåtet röjande eller okontrollerad behandling. Enligt NIS2 är det en svaghet i cyberhygien och leveranskedja. Enligt DORA kan det bli en IKT-tredjepartsrisk och en fråga för incidentklassificering.

Pelare 3: försvara gränsen med DLP-teknik, policy och medvetenhet

ISO/IEC 27002:2022-kontroll 8.12, Skydd mot dataläckage, är den kontroll de flesta förknippar med DLP. Men i ett moget program är den sista försvarslinjen, inte den första.

Zenith Blueprint förklarar att DLP kräver ett angreppssätt i tre lager: teknik, policy och medvetenhet. Teknik omfattar endpoint-DLP, e-postsäkerhet, innehållsinspektion, säkerhet för molnåtkomst, SaaS-kontroller, webbläsarkontroller, utgående nätverksfiltrering och larmroutning. Policyn definierar vad verktygen ska tillämpa. Medvetenhet säkerställer att anställda förstår varför personlig e-post, konsumentmoln och icke-godkända AI-verktyg inte är godtagbara hanteringsmetoder för reglerad eller konfidentiell information.

Responsdelen är lika viktig som prevention. Zenith Blueprint, Step 19, anger:

Men DLP handlar inte bara om prevention, utan också om respons. Om ett potentiellt läckage upptäcks:

✓ Larm ska triageras snabbt, ✓ Loggning ska stödja forensisk analys, ✓ Incidenthanteringsplanen ska aktiveras utan dröjsmål.

Ett DLP-program som blockerar händelser men inte triagerar, utreder och lär av dem är inte revisionsredo. Det är bara delvis infört.

Från kalkylbladsläckage till respons med revisionsunderlag

Återgå till måndagsmorgonens kalkylblad.

I ett svagt program upptäcker organisationen uppladdningen tre veckor senare under en integritetsgranskning. Ingen vet vem som godkände exporten, om uppgifterna var personuppgifter, om särskilda kategorier av personuppgifter var inblandade, om AI-verktyget behöll filen eller om kunder måste underrättas.

I ett program utformat av Clarysec ser förloppet annorlunda ut.

Först märks CRM-exporten som Confidential eftersom den innehåller personuppgifter och kommersiell kundinformation. Därefter loggas exporthändelsen. Sedan upptäcker e-postgatewayen en konfidentiell bilaga på väg till en personlig e-postdomän och blockerar den om det inte finns ett godkänt undantag. Därefter utlöser uppladdningsförsöket till en icke-godkänd molntjänst ett larm om användning av otillåten molntjänst. Larmet triageras enligt incidenthanteringsproceduren. Slutligen fastställer säkerhetsteamet om faktiskt röjande skedde, om data var krypterade, om leverantören behandlade eller behöll dem, om GDPR:s kriterier för personuppgiftsincident är uppfyllda och om trösklar enligt NIS2 eller DORA gäller.

SME-versionen av Logging and Monitoring Policy, avsnittet ”Styrningskrav”, klausul 5.4.3, anger exakt vad teamet ska kunna se:

Åtkomstloggar: filåtkomst, särskilt för känsliga data eller personuppgifter, behörighetsändringar och användning av delade resurser Logging and Monitoring Policy - SME

Den klausulen är liten men avgörande. Om filåtkomst, behörighetsändringar och användning av delade resurser inte loggas blir DLP-utredningen gissningsarbete.

Enligt NIS2 Article 23 kräver betydande incidenter stegvis rapportering: en tidig varning inom 24 timmar från det att organisationen fått kännedom om incidenten, en incidentanmälan inom 72 timmar och en slutrapport senast en månad efter incidentanmälan. Enligt DORA kräver Articles 17 to 19 att finansiella entiteter upptäcker, hanterar, klassificerar, registrerar, eskalerar och rapporterar större IKT-relaterade incidenter. Klassificeringen omfattar dataförlust som påverkar tillgänglighet, autenticitet, riktighet eller konfidentialitet, tillsammans med berörda kunder, varaktighet, geografisk spridning, kritikalitet och ekonomisk påverkan. Enligt GDPR kan obehörigt röjande av personuppgifter kräva incidentbedömning och, när trösklarna uppfylls, anmälan.

Ett DLP-larm är därför inte bara en säkerhetshändelse. Det kan bli en bedömning av personuppgiftsincident, ett NIS2-incidentflöde, en DORA-klassificering av IKT-incident, en utlösare för kundunderrättelse och ett paket med revisionsunderlag.

DLP-kontroller för GDPR Article 32

GDPR Article 32 översätts ofta till en lista över åtgärder: kryptering, konfidentialitet, riktighet, tillgänglighet, resiliens, testning och återställning. För DLP är nyckeln skydd över hela livscykeln.

Personuppgifter rör sig genom insamling, lagring, användning, överföring, utlämnande, bevarande och radering. GDPR Article 5 kräver uppgiftsminimering, ändamålsbegränsning, lagringsminimering, riktighet, konfidentialitet och ansvarsskyldighet. GDPR Article 6 kräver rättslig grund och förenlighet med ändamålet. GDPR Article 9 kräver striktare skyddsåtgärder för särskilda kategorier av personuppgifter.

DLP stödjer dessa skyldigheter när det är kopplat till dataklassificering, register över behandling, rättslig grund och godkända överföringsvägar.

Clarysecs Data Masking and Pseudonymization Policy-sme, avsnittet ”Syfte”, klausul 1.2, stödjer detta livscykelperspektiv:

Dessa tekniker är obligatoriska när skarpa data inte krävs, inklusive i utveckling, analys och scenarier med tredjepartstjänster, för att minska risken för exponering, missbruk eller incident. Data Masking and Pseudonymization Policy-sme - SME

Detta är en praktisk kontroll för GDPR Article 32. Om utvecklare, analytiker eller leverantörer inte behöver skarpa personuppgifter ska DLP inte vara den enda barriären. Maskering och pseudonymisering minskar konsekvensytan innan data över huvud taget rör sig.

En stark DLP-matris anpassad till dataskydd bör mappa typer av personuppgifter till klassificeringsmärkningar, rättslig grund, godkända system, godkända exportmetoder, krypteringskrav, DLP-regler, regler för bevarande och incidentutlösare. Den matrisen blir bryggan mellan dataskyddsstyrning och säkerhetsdrift.

NIS2-cyberhygien och DLP bortom dataskyddsteamet

NIS2 förändrar DLP-diskussionen eftersom direktivet ramar in läckage som en del av cyberhygien och resiliens, inte enbart integritetsskydd.

Article 20 kräver att ledningsorgan i väsentliga och viktiga entiteter godkänner cybersäkerhetsåtgärder för riskhantering, övervakar genomförandet och får cybersäkerhetsutbildning. Article 21 kräver lämpliga och proportionerliga åtgärder inom policy, incidenthantering, kontinuitet, leveranskedja, säker utveckling, effektivitetsprovning, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll och hantering av tillgångar. Article 25 uppmuntrar användning av relevanta europeiska och internationella standarder och tekniska specifikationer.

DLP bidrar direkt till dessa områden:

Network Security Policy-sme, avsnittet ”Mål”, klausul 3.4, gör exfiltrationsmålet uttryckligt:

Förhindra spridning av skadlig kod och dataexfiltration via nätverkskanaler Network Security Policy-sme - SME

För NIS2 ger denna typ av mål revisorer en direkt testväg: visa utgående filtrering, DNS-övervakning, proxyloggar, slutpunktslarm, blockerade uppladdningsförsök och utredningsärenden.

Zenith Blueprint, Step 23, lägger till en molnspecifik åtgärd som nu är avgörande för digitala leverantörer och IKT-leverantörer som omfattas av NIS2:

Lista alla molntjänster som för närvarande används (5.23), inklusive känd skugg-IT. Identifiera vem som godkände dem och om leverantörsgranskning genomfördes. Ta fram en lättviktig utvärderingschecklista som omfattar datalagringsplats, åtkomstmodell, loggning och kryptering. För framtida tjänster ska checklistan integreras i upphandlings- eller IT-introduktionsprocessen.

Många organisationer misslyckas här. De har en ISMS-omfattning och ett leverantörsregister, men inte en verklig lista över SaaS-verktyg där anställda flyttar reglerade data eller kunddata. DLP utan upptäckt av molntjänster är blint.

DORA IKT-risk: DLP för finansiella entiteter och leverantörer

För finansiella entiteter måste DLP passa in i DORA:s ramverk för IKT-riskhantering.

DORA Article 5 kräver ett internt styrnings- och kontrollramverk för IKT-riskhantering. Ledningsorganet förblir ansvarigt för IKT-risk, policyer som bevarar datas tillgänglighet, autenticitet, riktighet och konfidentialitet, tydliga IKT-roller, strategi för digital operativ resiliens, IKT-risktolerans, kontinuitets- och respons-/återställningsplaner, revisionsplaner, resurser, tredjepartspolicy och rapporteringskanaler.

Article 6 kräver ett dokumenterat ramverk för IKT-riskhantering som omfattar strategier, policyer, rutiner, IKT-protokoll och verktyg för att skydda information och IKT-tillgångar. Article 9 behandlar skydd och förebyggande åtgärder. Articles 11 to 14 lägger till kontinuitet, respons, återhämtning, säkerhetskopiering, återställning, kontroller av dataintegritet, erfarenhetsåterföring, medvetenhetsutbildning och kriskommunikation.

DLP passar in i detta ramverk som en förmåga för skydd, detektering, respons och testning.

DORA gör också tredjepartsrisk ofrånkomlig. Articles 28 to 30 kräver hantering av IKT-tredjepartsrisk, register över avtal för IKT-tjänster, leverantörsgranskning före avtal, avtalskrav, revisions- och inspektionsrättigheter, uppsägningsrättigheter, exitstrategier, tjänstebeskrivningar, platser för behandling och lagring av data, dataåtkomst, återställning och återlämning, incidentstöd, samarbete med myndigheter, säkerhetsåtgärder och villkor för underleverantörer.

För ett fintechbolag eller en bank kan DLP inte stanna vid gränsen för Microsoft 365 eller Google Workspace. Det måste omfatta betalningsförmedlare, leverantörer för identitetsverifiering, CRM-plattformar, datalager, molninfrastruktur, outsourcade supportdeskar, leverantörer av hanterade tjänster och kritiska SaaS-integrationer.

Detta är särskilt viktigt när DORA fungerar som den sektorsspecifika unionsrättsakten för överlappande NIS2-skyldigheter. Kontrollerna måste fortfarande finnas. Rapporterings- och tillsynsvägen kan skilja sig åt.

En 90-minuters sprint för DLP-regler

Clarysec använder en praktisk sprint med kunder som behöver snabba framsteg utan att låtsas att ett fullständigt DLP-program kan byggas på ett enda möte. Målet är att införa en DLP-kontroll med högt värde från policy till underlag.

Steg 1: välj en datatyp och en överföringsväg

Välj ”kunders personuppgifter som exporteras från CRM och skickas externt via e-post”. Börja inte med varje lagringsplats, land och datatyp.

Steg 2: bekräfta klassificering och märkning

Använd klassificeringspolicyn för att bekräfta att exporten är Confidential. I ett litet eller medelstort företag kräver klausul 6.3.3 kryptering, begränsad åtkomst, uttryckligt godkännande för delning och säker förstöring. I en företagsmiljö stödjer Data Classification and Labeling Policy blockering av överföring för felaktigt märkta känsliga data och automatiserad validering med DLP och verktyg för upptäckt.

Steg 3: definiera det tillåtna överföringsmönstret

Tillåtet: CRM-export skickas till en godkänd kunddomän med krypterad e-post eller en godkänd säker fildelningsplattform, med verksamhetsmässig motivering.

Inte tillåtet: personlig e-post, publika fildelningslänkar, icke-godkända AI-verktyg och ohanterad molnlagring.

Detta ligger i linje med Zenith Blueprint, Step 22, som anger:

Om ”Confidential” information inte får lämna företaget utan kryptering ska e-postsystem tillämpa krypteringspolicyer eller blockera extern överföring.

Steg 4: konfigurera den minsta DLP-regeln

Konfigurera e-post- eller samarbetsplattformen så att den upptäcker den konfidentiella märkningen, personuppgiftsmönstret eller namngivningskonventionen för exportfiler. Börja med övervakning om falska positiva resultat förväntas och gå sedan över till blockering för personliga domäner och icke-godkända mottagare.

Steg 5: aktivera loggning och larmroutning

Säkerställ att loggar fångar filåtkomst, behörighetsändringar och användning av delade resurser, enligt kraven i Logging and Monitoring Policy - SME. Routa larm till ärendekön med allvarlighetsgrad, datatyp, avsändare, mottagare, filnamn, vidtagen åtgärd och granskare.

Steg 6: testa tre scenarier

Testa en godkänd krypterad överföring till en kund, en blockerad överföring till personlig e-post och ett uppladdningsförsök till en icke-godkänd molndomän som endast genererar larm.

Steg 7: bevara underlag

Spara referensen till policyklausulen, skärmbild av DLP-regeln, testresultat, larmärende, granskarens beslut och ledningens godkännande. Lägg till kontrollen i riskbehandlingsplanen och Statement of Applicability.

I ISO/IEC 27001:2022-termer kopplar denna övning samman klausul 6.1.2 riskbedömning, klausul 6.1.3 riskbehandling, klausul 8 operativ planering och styrning, Annex A-kontroller för informationsöverföring, skydd mot dataläckage, loggning, övervakning, leverantörs- och molnkontroller samt klausul 9 utvärdering av prestanda.

Cross-compliance-mappning: ett DLP-program, flera skyldigheter

Styrkan i Clarysecs arbetssätt är att det undviker separata kontrollstackar för GDPR, NIS2, DORA, NIST och COBIT. Ett väl utformat DLP-program kan uppfylla flera förväntningar om underlaget struktureras korrekt.

NIST CSF 2.0 är användbart som kommunikationslager. Funktionen GOVERN stödjer uppföljning av rättsliga, regulatoriska och avtalsmässiga krav, riskaptit, policytillämpning, roller och tillsyn. Metoden Profiles hjälper organisationer att avgränsa nuvarande och önskat säkerhetsläge, dokumentera luckor och genomföra en åtgärdsplan. Funktionerna RESPOND och RECOVER stödjer begränsning av DLP-incidenter, rotorsaksanalys, bevarande av underlag och återställning.

COBIT 2019 tillför ett styrningsperspektiv. En COBIT-orienterad revisor kommer att fråga om DLP-målen är anpassade till organisationens mål, om ägarskapet är tydligt, om prestandaindikatorer finns, om riskaptit är definierad och om ledningen får meningsfull rapportering.

Hur revisorer testar ert DLP-program

DLP-revisioner handlar sällan om en enda skärmbild. Olika revisionsbakgrunder ger olika förväntningar på underlag.

Ett starkt DLP-revisionspaket omfattar omfattnings- och riskbeskrivning, klassificeringsschema, godkända överföringsmetoder, DLP-regler, godkända undantag, loggningsdesign, procedur för larmtriage, beslutsträd för incidentrapportering, leverantörs- och molnförteckning, testresultat och åtgärdsunderlag.

Vanliga DLP-brister under 2026

De vanligaste DLP-bristerna är operativa, inte exotiska.

För det första är klassificering frivillig eller inkonsekvent. Märkningar finns i policyn, men användare tillämpar dem inte, system genomdriver dem inte och lagringsplatser innehåller åratal av omärkta känsliga filer.

För det andra körs DLP permanent i endast-larm-läge. Endast larm är användbart under intrimning, men en högrisköverföring av konfidentiella kunddata till personlig e-post bör till slut blockeras om det inte finns ett godkänt undantag.

För det tredje behandlas skugg-IT som ett IT-irritationsmoment snarare än en dataskyddsrisk. Cloud Usage Policy och Cloud Usage Policy-sme är utformade för att göra icke-godkända molnverktyg synliga, granskningsbara och möjliga att åtgärda.

För det fjärde är loggarna inte tillräckliga för utredning. Om säkerhetsteamet inte kan återskapa vem som kom åt, delade, laddade ned, laddade upp eller ändrade behörigheter kan organisationen inte med säkerhet bedöma rapporteringsskyldigheter enligt GDPR, NIS2 eller DORA.

För det femte ligger leverantörer utanför DLP-modellen. DORA Articles 28 to 30 gör detta särskilt farligt för finansiella entiteter, men problemet påverkar alla sektorer. Avtal bör definiera datalagringsplatser, åtkomst, återställning, återlämning, incidentstöd, säkerhetsåtgärder, underleverantörer och revisionsrätt.

För det sjätte omfattar incidentrespons inte DLP-scenarier. Ett felskickat e-postmeddelande, en obehörig SaaS-uppladdning eller ett massuttag från CRM bör ha en åtgärdsplan, allvarlighetskriterier och en beslutsväg för notifiering.

Slutligen glömmer organisationer fysiska och mänskliga kanaler. Zenith Blueprint påminner oss om att DLP omfattar rent skrivbord-beteende, säker dokumentförstöring, låsta utskriftsköer, revisionsloggar för skrivare och medarbetarmedvetenhet. Ett DLP-program som ignorerar papper, skärmbilder och samtal är ofullständigt.

Bygg ett DLP-program som revisorer kan lita på

Om ert DLP-program i dag är en verktygskonfiguration är 2026 året då det bör bli ett styrt kontrollsystem med robust revisionsunderlag.

Börja med tre praktiska åtgärder:

1. Välj era tre viktigaste känsliga datatyper, till exempel kunders personuppgifter, betalningsdata och källkod.
2. Mappa var de rör sig, inklusive e-post, SaaS, molnlagring, slutpunkter, API:er, leverantörer och utvecklingsmiljöer.
3. Bygg en genomförbar DLP-regel per datatyp, kopplad till policy, loggning, incidentrespons och bevarande av underlag.

Clarysec kan hjälpa er att accelerera detta genom Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls och policyer som är färdiga att anpassa, såsom Data Classification and Labeling Policy Data Classification and Labeling Policy, Remote Work Policy Remote Work Policy, Cloud Usage Policy Cloud Usage Policy, Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME och Mobile device and byod policy Mobile device and byod policy.

Målet är inte att stoppa varje fil från att röra sig. Målet är att göra säkra förflyttningar till standard, riskfyllda förflyttningar synliga, förbjudna förflyttningar blockerade och varje undantag ansvarssatt.

Ladda ned Clarysecs verktygslådor, granska ert DLP-underlag och boka en beredskapsbedömning för att se om era nuvarande kontroller klarar granskning enligt GDPR Article 32, NIS2-förväntningar på cyberhygien och DORA-granskning av IKT-risk.