Styring af PII efter ISO 27701:2025 og GDPR

Anmodningen landede i CISO’ens indbakke med vildledende enkelhed: “Project Wellness”. En hurtigt voksende fintech-virksomhed ønskede at analysere eksisterende kundetransaktionsdata for at levere personlige sparetips, produktanbefalinger og indsigt i churn-risiko. Marketing så kundeengagement. Produkt så innovation. Ledelsen så en konkurrencemæssig fordel.

CISO’en så en styringsmæssig landmine.

Transaktionsdataene var indsamlet til betalingsbehandling under et defineret formål og behandlingsgrundlag. Nu ønskede forretningen at viderebehandle dem til analyser af økonomisk trivsel, kampagnepersonalisering og prædiktiv scoring. For at fremskynde leverancen ønskede teamet også at sende et pseudonymiseret datasæt til en tredjepartsleverandør af AI-analyse.

Der var ingen angriber i netværket. Ingen database var lækket. Ingen hændelsessag blinkede rødt.

Alligevel er det præcis her, mange brud på ansvarlighedsprincippet i GDPR begynder.

Problemet er ikke, om organisationen har en privatlivsmeddelelse, en databeskyttelsesrådgiver (DPO), en fortegnelse over behandlingsgrundlag eller en opbevaringsplan. Det dybere spørgsmål er operationelt: Hvem godkender ny indsamling af PII, hvem bekræfter nødvendigheden, hvem definerer tilladt intern brug, hvem afgør, om viderebehandling er forenelig, hvem godkender videregivelse til en leverandør, og hvem kan dokumentere beslutningen bagefter?

Det er det kontrolhul, implementeringer af ISO/IEC 27701:2025 som ledelsessystem for databeskyttelse, eller PIMS, skal lukke. GDPR artikel 5 kræver, at personoplysninger behandles lovligt, rimeligt og gennemsigtigt, indsamles til specificerede, udtrykkelige og legitime formål, begrænses til det nødvendige, er nøjagtige, kun opbevares så længe som nødvendigt, beskyttes passende og håndteres under den dataansvarliges ansvarlighed. GDPR artikel 6 tilføjer logikken for behandlingsgrundlag og forenelighed ved viderebehandling. Men disse principper bliver først forsvarlige, når de omsættes til arbejdsgange, registre, godkendelser, adgangsregler, leverandørkontroller, overvågning og kontrolbevis.

Clarysecs tilgang er enkel: Behandl styring af indsamling, brug og videregivelse af PII som en kontrolleret driftsmodel, ikke som et juridisk notat. Modellen bygger på ISO/IEC 27001:2022 ISMS-rygraden, udvides med ISO/IEC 27701:2025 PIMS-roller og dokumenteres gennem Clarysec-politikker, registre, Zenith Blueprint: En revisors 30-trins køreplan og Zenith Controls: Vejledning til efterlevelse på tværs af regelsæt.

Hvorfor styring af PII fejler, selv når databeskyttelsesdokumenter findes

De fleste databeskyttelsesprogrammer fejler ikke, fordi ingen kender GDPR. De fejler, fordi beslutninger om databeskyttelse træffes i produktsager, e-mails om leverandøronboarding, regnearkseksporter, dashboard-eksperimenter og AI-piloter uden et gentageligt kontrolpunkt.

Et typisk mønster er velkendt:

1. Et team tilføjer et nyt felt til en tilmeldingsformular, fordi det forbedrer segmenteringen.
2. Ingen registrerer, hvorfor netop dette felt er nødvendigt.
3. Et andet team viderebehandler senere dataene til et andet formål.
4. En leverandør modtager en eksport under en bred serviceaftale.
5. Fortegnelsen over behandlingsaktiviteter opdateres efter lancering, hvis den overhovedet opdateres.
6. Under revision kan organisationen fremvise en privatlivsmeddelelse, men ikke beslutningsdokumentation.

GDPR artikel 4 og 5 definerer behandling bredt. Indsamling, registrering, opbevaring, brug, videregivelse, sletning og destruktion er alle omfattet. Artikel 5 gør også ansvarlighed eksplicit. Dataansvarlige skal kunne dokumentere efterlevelse af principperne.

Det betyder, at revisionsspørgsmålet ikke kun er: “Har I en politik?” Det er: “Vis mig, hvordan dette konkrete dataelement blev godkendt, hvorfor det var nødvendigt, hvordan det blev brugt, hvem der modtog det, og hvilke kontroller der forhindrede misbrug.”

Clarysec P17 Databeskyttelses- og privatlivspolitik fastlægger tydeligt forventningen til livscyklussen:

Den formaliserer virksomhedens ansvar efter internationale standarder og regulatoriske rammer og sikrer, at personoplysninger (PII) indsamles, behandles, opbevares, deles og bortskaffes lovligt, sikkert og gennemsigtigt.

For SMV’er omsætter Clarysec Databeskyttelses- og privatlivspolitik - SME samme princip til en pragmatisk driftsregel:

Personoplysninger må kun indsamles, hvor det er nødvendigt til et legitimt, lovligt eller kontraktligt formål

Og for minimering:

Kun det nødvendige minimum af personoplysninger må indsamles og opbevares

Disse udsagn er kun stærke, når de håndhæves, før behandlingen starter. Ellers forbliver de databeskyttelsessprog uden operationelt bevis.

Kontrolmålet: Stop ukontrolleret behandling ved tre kontrolpunkter

Et stærkt PIMS skal styre beslutninger om PII på tre tidspunkter: før indsamling, før brug og før videregivelse.

Før indsamling skal organisationen vide, hvad den ønsker at indsamle, fra hvem, gennem hvilken kanal, til hvilket formål, under hvilket behandlingsgrundlag, og hvorfor hvert felt er nødvendigt.

Før brug skal organisationen definere regler for tilladt intern brug. Support, kundesucces, marketing, svigforebyggelse, økonomi og udvikling har sjældent brug for samme synlighed eller samme tilladelse til at handle på PII.

Før videregivelse skal organisationen vide, hvem modtageren er, hvilken rolle modtageren har, hvorfor videregivelse er nødvendig, hvor behandlingen finder sted, hvilke PII-kategorier der deles, hvor ofte deling sker, og hvilket hjemmelsgrundlag der tillader delingen.

Clarysec PII09 Politik for indsamling, brug, videregivelse og deling af PII er designet til dette styringslag. Den bruger PIMS-rollemærkning, især rollen som dataansvarlig, fordi beslutninger om indsamling, brug og videregivelse normalt ligger hos den organisation, der fastlægger formål og hjælpemidler.

For begrænsning af indsamling kræver PII09 Politik for indsamling, brug, videregivelse og deling af PII:

[Dataansvarlig] Procesejer / forretningsejer SKAL registrere indsamlingsformål, kilde eller kanal, PII-kategorier, kategorier af registrerede og minimumsdataelementer i REG02, før en ny indsamlingsaktivitet eller væsentlig ændring af indsamling påbegyndes.

Derefter gør den minimering testbar:

[Dataansvarlig] Procesejer / forretningsejer SKAL registrere en nødvendighedsbegrundelse i REG02 for hvert PII-dataelement, før elementet indsamles.

Kravet om “hvert PII-dataelement” er forskellen mellem en generisk fortegnelse over behandlingsaktiviteter og bevis for ansvarlighed på feltniveau.

For intern brug kræver den samme politik:

[Dataansvarlig] Procesejer / forretningsejer SKAL registrere godkendte regler for intern brug for hver behandlingsaktivitet i REG02, før brugen påbegyndes.

For viderebehandling:

[Dataansvarlig] Procesejer / forretningsejer SKAL registrere en forenelighedsvurdering ved viderebehandling i REG02, før PII anvendes til et formål, der ikke allerede er godkendt for behandlingsaktiviteten.

Og for ekstern videregivelse:

[Dataansvarlig] Leverandør-/indkøbsansvarlig SKAL registrere modtagerens identitet, modtagerens rolle, videregivelsesformål, PII-kategorier, delingsfrekvens, behandlingslokation og hjemmelsgrundlag i REG08, før tilbagevendende ekstern deling påbegyndes.

Disse klausuler skaber et klart svar, når ledelsen spørger, om forretningen kan innovere hurtigt: Ja, hvis beslutningen består en dokumenteret styringsarbejdsgang, og kontrollerne svarer til godkendelsen.

REG02 og REG08: Clarysecs kæde fra politik til kontrol

I Clarysec-implementeringer er REG02 ikke en passiv fortegnelse over behandlingsaktiviteter. Det er beslutningsregisteret for indsamlingsformål, behandlingsgrundlag, PII-kategorier, nødvendighed, regler for intern brug, kobling til opbevaringsplan og forenelighed ved viderebehandling.

REG08 er kontrolregisteret for videregivelse og deling. Det er særligt vigtigt for leverandører, partnere, koncernselskaber, myndigheder, underdatabehandlere, integrationer og tilbagevendende eksporter.

Sammen skaber de en kæde fra politik til kontrol, som kan testes af databeskyttelses-, sikkerheds-, indkøbs- og revisionsteams.

Denne model passer naturligt til ISO/IEC 27001:2022. Klausul 4 til 10 kræver, at organisationen forstår kontekst, interessentkrav, omfang, ledelsesansvar, risikovurdering, risikobehandling, operationel styring, præstationsevaluering og forbedring. Databeskyttelsesforpligtelser efter GDPR og ISO/IEC 27701:2025 bliver en del af ledelsessystemet i stedet for en separat databeskyttelsesø.

ISO/IEC 27002:2022 understøtter også driftsmodellen. Kontrol 5.31, juridiske, lovgivningsmæssige, regulatoriske og kontraktlige krav, forankrer GDPR og sektorspecifikke forpligtelser. Kontrol 5.34, privatliv og beskyttelse af PII, adresserer databeskyttelsesspecifik beskyttelse. Kontrol 5.9, fortegnelse over information og andre tilknyttede aktiver, understøtter databevidsthed. Kontrol 5.12 og 5.13 understøtter klassificering og mærkning. Kontrol 5.14 styrer informationsoverførsel. Kontrol 5.19 til 5.23 dækker leverandørrelationer, leverandøraftaler, IKT-forsyningskæden, overvågning af leverandørtjenester og cloudtjenester. Kontrol 8.11 understøtter datamaskering, 8.12 understøtter forebyggelse af datalækage, 8.15 logning, 8.16 overvågningsaktiviteter og 8.24 brug af kryptografi.

Zenith Blueprint placerer disse kontroller i et implementeringsforløb. I fasen Kontroller i praksis dækker trin 23 organisatoriske kontroller 5.19 til 5.37, herunder kontrol 5.34 for privatliv og beskyttelse af PII. Blueprint forklarer:

I dagens datadrevne verden er personhenførbare oplysninger ikke blot endnu en datatype; de er en dybt følsom repræsentation af tillid. Navne, adresser, ID’er, helbredsoplysninger, finansielle detaljer – disse data fortæller en historie om virkelige mennesker.

Derefter angiver den den operationelle baseline:

Grundlaget for denne kontrol er databevidsthed. Organisationen skal vide, hvilke PII den indsamler, hvor de befinder sig, hvorfor de behandles, og hvem der kan tilgå dem.

Det er det, REG02 og REG08 leverer, når de behandles som levende styringsregistre.

Praktisk eksempel: Godkendelse af Project Wellness uden at miste kontrollen

Vend tilbage til fintech-scenariet. Forretningen ønsker at analysere kundetransaktionsdata for at levere personlige anbefalinger om økonomisk trivsel. Marketing ønsker at bruge outputtet til kampagner. Produkt ønsker at opbygge churn- og engagementsscorer. En tredjeparts AI-analyseplatform skal behandle en del af datasættet.

Sådan ville Clarysec styre anmodningen.

Trin 1: Opret eller opdater REG02-behandlingsaktiviteten

Procesejeren åbner REG02 og registrerer behandlingsaktiviteten, før arbejdet begynder.

Det centrale er timingen. REG02 opdateres, før ny behandling begynder, ikke efter at funktionen allerede er i drift.

Trin 2: Registrer nødvendighedsbegrundelser på feltniveau

Marketing beder indledningsvist om fem års fuld transaktionshistorik, herunder forretningsnavne, præcise tidsstempler, kortmetadata og kundeprofilattributter. Styringsteamet udfordrer hvert felt.

Dette er dataminimering som bevis, ikke som ambition. Forretningen får stadig nyttige analyser, men datasættet begrænses til det, der er nødvendigt for det godkendte formål.

Trin 3: Klassificer og mærk datasættet

Datasættet klassificeres efter Clarysec Politik for dataklassificering og mærkning. SME-versionen kræver:

Ekstern deling skal være udtrykkeligt godkendt og logget.

Virksomhedsversionen af Politik for dataklassificering og mærkning tilføjer en sikkerhedsforanstaltning for følsomme oplysninger:

Må kun deles eksternt under en fortrolighedsaftale eller tilsvarende kontraktlige sikkerhedsforanstaltninger

I praksis kan Project Wellness-datasættet ikke bare eksporteres uformelt til en AI-platform. Det kræver en godkendt registrering af videregivelse, kontraktlige sikkerhedsforanstaltninger, tekniske kontroller for overførsel og logfiler.

Zenith Blueprint forklarer i trin 22 for kontrol 5.12, klassificering af information, hvorfor dette er vigtigt:

Enhver informationssikkerhedskontrol, der nogensinde er skrevet – adgangsbegrænsning, kryptering, backup, overvågning eller bortskaffelse – forudsætter én ting: at organisationen ved, hvad den beskytter.

Uden klassificering bliver adgangsbegrænsninger, kryptering, DLP og opbevaringsregler gætværk.

Trin 4: Definer regler for intern brug før produktionsrelease

Procesejeren registrerer godkendte regler for intern brug i REG02. Det er her, formålsglidning ofte stoppes.

Et forsvarligt regelsæt kan angive:

• Produkt må bruge aggregerede målinger for anbefalingernes performance.
• Kundesupport må se, om en anbefaling er blevet vist til en kunde, når en supportanmodning håndteres.
• Marketing må ikke bruge wellness-scorer på individniveau til kampagnesegmentering, medmindre en forenelighedsvurdering ved viderebehandling er gennemført.
• Økonomi må ikke tilgå detaljerede wellness-analyser, medmindre der findes et særskilt godkendt formål.
• Udviklere må ikke bruge produktionsdata med PII i testmiljøer.
• Evaluering af AI-modeller skal bruge maskerede, pseudonymiserede eller aggregerede datasæt, hvor det er muligt.

De sidste to regler kobler til ISO/IEC 27002:2022 kontrol 8.11, datamaskering. Zenith Blueprint, trin 19, beskriver datamaskering som en praktisk metode til at forhindre unødig eksponering i testmiljøer, træningsdatasæt, analyseplatforme, tredjepartsintegrationer og CI/CD-testpipelines.

Trin 5: Gennemfør forenelighedsvurderingen ved viderebehandling

Marketing beder senere om at bruge wellness-scorer til målrettede kampagner. Det er et nyt formål. Efter PII09 Politik for indsamling, brug, videregivelse og deling af PII klausul 4.3.1 skal forretningsejeren registrere en forenelighedsvurdering i REG02, før den nye brug begynder.

Vurderingen bør omfatte:

• Om markedsføring baseret på økonomisk trivsel er forenelig med det oprindelige behandlingsformål.
• Hvad kunderne fik oplyst ved indsamlingen og i privatlivsmeddelelsen.
• Om inferenser udledt af transaktioner kan være følsomme eller uventede.
• Om den nye brug kan skabe pres, udelukkelse eller urimelig profilering.
• Om sikkerhedsforanstaltninger som aggregering, fravalg, pseudonymisering eller segmentering på kontoniveau reducerer risikoen.
• Om behandlingsgrundlaget fortsat er gyldigt.
• Om opdateringer af gennemsigtighedsoplysninger eller samtykkemekanismer er nødvendige.

Resultatet kan være godkendelse, godkendelse med sikkerhedsforanstaltninger eller afvisning. Værdien er, at beslutningen dokumenteres, før brugen begynder.

Trin 6: Godkend ekstern videregivelse gennem REG08

Hvis AI-analyseleverandøren skal modtage data, registrerer den leverandør- eller indkøbsansvarlige følgende i REG08:

Clarysec Politik for tredjeparts- og leverandørsikkerhed - SME understøtter minimeret leverandøradgang:

Leverandører må kun tildeles adgang til de minimumssystemer og data, der er nødvendige for at udføre deres funktion.

Dette er databeskyttelsesminimering anvendt på leverandøradgang og videregivelse.

Trin 7: Tilføj teknisk håndhævelse

Styringsregistreringer skal understøttes af tekniske kontroller. For Project Wellness vil Clarysec typisk anbefale DLP-regler for eksporter, rollebaserede adgangsbegrænsninger, logning af adgangs- og overførselshændelser, maskerede datasæt til udvikling, kryptering under overførsel og ved lagring, gennemgang af leverandøradgang, sikkerhedsmæssig due diligence af cloudtjenester og periodisk stikprøvekontrol af REG02 og REG08 mod faktisk systemadfærd.

Det er sådan ISO/IEC 27701:2025 og GDPR’s ansvarlighed bliver til operationelt bevis.

Kontrolkortlægning: Fra databeskyttelsesbeslutning til sikkerhedshåndhævelse

Styring af PII er ikke én isoleret kontrol. Det er en relation mellem databeskyttelseskrav, sikkerhedskontroller, leverandørstyring og revisionsbevis.

Zenith Controls behandler ISO/IEC 27002:2022 kontrol 5.34, privatliv og beskyttelse af PII, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, med Identify- og Protect-cybersikkerhedskoncepter og operationelle kapaciteter inden for informationsbeskyttelse samt juridisk efterlevelse og compliance.

For 5.34 kortlægger Zenith Controls det omgivende kontroløkosystem, herunder fortegnelse, klassificering, overførsel, adgang, identitet, cloud, leverandørsikkerhed, maskering, forebyggelse af lækage, logning, overvågning og kryptografi.

For maskering anfører Zenith Controls:

Datamaskering (8.11) er en teknik, der ofte bruges til at beskytte PII i ikke-produktionsmiljøer eller ved deling af data. Den understøtter direkte 5.34 ved at reducere eksponeringen af reelle personoplysninger og dermed sænke privatlivsrisikoen.

For forebyggelse af datalækage forklarer vejledningen den praktiske afgrænsning:

DLP spiller en direkte rolle i beskyttelsen af personoplysninger. Kontrol 8.12 håndhæver grænser for, hvordan PII kan tilgås, deles eller flyttes, og sikrer, at personoplysninger ikke kan lækkes via uautoriserede kanaler.

En revisor, der tester styring af videregivelse, kan derfor ikke kun bede om REG08, men også om DLP-politikker, logfiler for blokerede overførsler, kontroller for udgående e-mail, begrænsninger for clouddeling, krypteringskrav, registreringer af leverandøradgang og dokumentation for godkendte undtagelser.

Værdi på tværs af efterlevelseskrav: GDPR, ISO 27701, NIS2, DORA, NIST og COBIT

Styring af indsamling, brug og videregivelse af PII er drevet af databeskyttelse, men bevismaterialet understøtter bredere forpligtelser vedrørende cybersikkerhed, robusthed og governance.

GDPR artikel 2 og 3 definerer et bredt materielt og territorialt anvendelsesområde, som kan omfatte SaaS, fintech og digitale tjenesteudbydere uden for EU, når de betjener eller overvåger personer i EU. Artikel 5 kræver formålsbegrænsning, dataminimering, nøjagtighed, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. Artikel 6 kræver behandlingsgrundlag og forenelighedsvurdering ved viderebehandling. Artikel 9 tilføjer strengere betingelser for særlige kategorier af personoplysninger, hvilket er relevant, hvor profilering, helbredsrelaterede data, biometrisk onboarding eller følsomme attributter indgår.

NIS2 artikel 21 kræver, at væsentlige og vigtige enheder implementerer forholdsmæssige tekniske, driftsmæssige og organisatoriske risikostyringsforanstaltninger. Minimumsområderne omfatter risikoanalyse, sikkerhedspolitikker for informationssystemer, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, kontroleffektivitet, træning, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring og autentifikation.

DORA kræver, at finansielle enheder opretholder en ramme for styring af IKT-risiko, ledelsesorganets ansvarlighed, identifikation af IKT-aktiver og afhængigheder, beskyttelses- og forebyggelseskontroller, detektion, respons, genopretning, backup, læring, hændelsesstyring, test og styring af IKT-tredjepartsrisiko. Den kræver også informationsregistre for IKT-servicekontrakter, due diligence, revisionsrettigheder, sikkerhedskrav og exitstrategier.

NIST Cybersecurity Framework 2.0 giver et samlende styringssprog. GOVERN-funktionen forventer, at juridiske, regulatoriske og kontraktlige krav, herunder databeskyttelsesforpligtelser, forstås og styres. Den dækker også risikostrategi, roller, politikker, tilsyn og styring af leverandørrisiko.

COBIT 2019-revisorer ser efter styringsmål, beslutningsrettigheder, ansvarlighed, procesejerskab, resultatindikatorer og assurance-dokumentation. For styring af PII betyder det, at databeskyttelseskrav skal indlejres i virksomhedens governance og ikke håndteres som en sideproces.

Hvordan revisorer tester det samme styringslag

En stærk PIMS-implementering bør kunne modstå forskellige revisionsstile.

En ISO/IEC 27001:2022- og ISO/IEC 27701:2025-revisor starter med omfang, interessenter, juridiske og kontraktlige krav, risikovurdering, Anvendelighedserklæring, operationel planlægning og dokumenteret bevis. Revisoren kan udtage stikprøver af behandlingsaktiviteter fra REG02 og teste, om kontroller som 5.34, 5.12, 5.14, 5.19 til 5.23, 8.11, 8.12, 8.15, 8.16 og 8.24 er implementeret og overvåget.

En GDPR-fokuseret revisor eller tilsynsmyndighed tester ansvarlighed. De kan begynde med en privatlivsmeddelelse, klage, anmodning fra registreret eller leverandørvideregivelse og derefter spore bagud. Hvorfor blev disse data indsamlet? Hvilket behandlingsgrundlag gjaldt? Var formålet specificeret? Var den senere brug forenelig? Var modtageren autoriseret? Blev de registrerede informeret? Blev registreringerne opdateret, før behandlingen begyndte?

En DORA-tilsynsførende vil, hvor det er relevant, fokusere på IKT-understøttede forretningsfunktioner, IKT-tredjepartsudbydere, kontraktklausuler, revisionsrettigheder, databeskyttelse, hændelseskommunikation, robusthedstest og exitplanlægning. Hvis kunders PII deles med en kritisk analyse- eller cloududbyder, bliver REG08, leverandør-due diligence og kontraktkontroller centralt bevismateriale.

En NIST CSF-assessor vil rammesætte spørgsmålet gennem styringsresultater. Styres juridiske og regulatoriske krav? Er roller og ansvar tydelige? Vedligeholdes og håndhæves politikker? Styres leverandørrisici? Fungerer resultaterne for databeskyttelse, overvågning og respons?

En COBIT- eller ISACA-inspireret revisor vil spørge, om beslutningsrettigheder er defineret, om forretningsejere accepterer privatlivsrisiko, om kontroludførelse måles, om undtagelser spores, og om ledelsen modtager meningsfuld rapportering.

Almindelige faldgruber, som Clarysec ser i implementeringer

Den første faldgrube er at behandle fortegnelsen over behandlingsaktiviteter som en dokumentationsøvelse i stedet for et godkendelsespunkt. Hvis REG02 opdateres efter lancering, kan den ikke dokumentere forudgående styring.

Den anden er upræcist formålssprog. “Analyse”, “serviceforbedring” eller “kundeindsigt” er sjældent specifikt nok til at styre intern brug eller viderebehandling.

Den tredje er manglende nødvendighed på feltniveau. Dataminimering kan ikke dokumenteres ved at sige, at hvert felt er nyttigt. Forretningen skal forklare, hvorfor hvert felt er nødvendigt for det godkendte formål.

Den fjerde er ukontrolleret viderebehandling. Data indsamlet til kontoadministration bliver stille og roligt til salgsintelligens, derefter marketingsegmentering og derefter AI-træning. Hver ændring af formål kræver forenelighedsanalyse og i nogle tilfælde et nyt behandlingsgrundlag eller en opdatering af gennemsigtighedsoplysninger.

Den femte er svag styring af videregivelse. Leverandørlister er ikke det samme som registreringer af videregivelse. REG08 binder modtager, rolle, formål, PII-kategorier, lokation, frekvens og hjemmelsgrundlag sammen i ét godkendelsesspor.

Den sjette er manglende teknisk håndhævelse. Politikker kan sige, at PII ikke må forlade godkendte kanaler, men e-mail, eksporter, fællesdrev og analyseværktøjer tillader det ofte. Det er her, ISO/IEC 27002:2022-kontrollerne 5.14, 8.12, 8.15, 8.16 og 8.24 bliver afgørende.

En praktisk 30-dages startplan

Organisationer behøver ikke at koge havet. Start med én højrisiko-behandlingsaktivitet, helst en der involverer kundeprofilering, AI-analyse, følsomme attributter, grænseoverskridende overførsel eller en tredjepartsplatform.

I den første uge identificeres behandlingsaktivitet, ejer, PII-kategorier, systemer, leverandører og aktuelt formål. Bekræft, om aktiviteten allerede er repræsenteret i REG02, og om videregivelse er repræsenteret i REG08.

I den anden uge færdiggøres nødvendighedsbegrundelser på feltniveau. Udfordr overflødige dataelementer. Bekræft klassificering og mærkning. Identificer, om maskering, aggregering eller pseudonymisering kan reducere risikoen.

I den tredje uge defineres regler for intern brug, og eventuelle forenelighedsvurderinger ved viderebehandling gennemføres. Beslut, om privatlivsmeddelelser, vurderinger af behandlingsgrundlag eller kontroller for registreredes rettigheder skal opdateres.

I den fjerde uge valideres registreringer af ekstern videregivelse, leverandøradgang, kontraktlige sikkerhedsforanstaltninger, databehandleraftalevilkår, overførselskontroller, logning, DLP og sletteforpligtelser. Udtag derefter stikprøver af faktisk systemadfærd mod godkendelserne.

Efter 30 dage bør ledelsen have en konkret bevispakke: REG02, REG08, klassificeringsregistreringer, adgangsmatricer, DLP- og logningsbevis, leverandør-due diligence, kontraktlige sikkerhedsforanstaltninger, forenelighedsvurderinger og åbne afhjælpende foranstaltninger.

Fra politik til bevis

Styring af indsamling, brug og videregivelse af PII er dér, hvor databeskyttelse bliver reel. Det er forskellen mellem at sige “vi overholder GDPR” og at dokumentere, at hver beslutning om indsamling, brug, viderebehandling og videregivelse blev kontrolleret, før behandlingen fandt sted.

Clarysecs værktøjssæt giver databeskyttelses-, sikkerheds- og compliance-teams en praktisk vej:

• Brug PII09 Politik for indsamling, brug, videregivelse og deling af PII til at definere obligatoriske godkendelsespunkter.
• Brug P17 Databeskyttelses- og privatlivspolitik eller Databeskyttelses- og privatlivspolitik - SME til at forankre lovlig, rimelig, gennemsigtig og minimeret behandling.
• Brug Politik for dataklassificering og mærkning og Politik for tredjeparts- og leverandørsikkerhed - SME til at styre klassificering, deling og leverandøradgang.
• Følg Zenith Blueprint: En revisors 30-trins køreplan for at implementere kontrolmiljøet i den rigtige rækkefølge.
• Brug Zenith Controls: Vejledning til efterlevelse på tværs af regelsæt til at forstå, hvordan ISO/IEC 27002:2022-kontroller som 5.34, 5.12, 5.14, 8.11 og 8.12 understøtter GDPR, NIS2, DORA, NIST og revisionsforventninger.

Hvis jeres næste revision, kundes due diligence-anmodning eller bestyrelsesgennemgang spørger, hvordan I styrer, hvilke PII der indsamles, hvordan de bruges, og hvornår de videregives, skal I ikke nøjes med politikerklæringer.

Start med én højrisikoaktivitet. Opbyg REG02-registreringen. Begrund hvert dataelement. Definer regler for intern brug. Gennemfør forenelighedsvurderingen ved viderebehandling. Opret REG08-registreringen af videregivelse. Test derefter, om adgang, DLP, maskering, logning, kryptering og leverandørkontroller matcher beslutningen.

Det er sådan ISO/IEC 27701:2025 og GDPR’s ansvarlighed bliver til bevismateriale.

Udforsk Clarysec PIMS-værktøjssættet, start med PII09 Politik for indsamling, brug, videregivelse og deling af PII, og brug Zenith Blueprint til at omsætte databeskyttelsesstyring fra politikhensigt til revisionsklart bevismateriale.