Databeskyttelsesrisikovurdering for ISO 27701 og GDPR

Mandagsmødet føltes velkendt for Maria, CISO i en hurtigt voksende healthtech-virksomhed.

Den administrerende direktør ønskede ét samlet dashboard, der viste virksomhedens GDPR-risikoeksponering, før virksomheden lancerede sin AI-drevne platform til patientanalyse. Den nye databeskyttelsesansvarlige, David, havde en fortegnelse over behandlingsaktiviteter, eller RoPA, fordelt på 50 faner. Engineering havde sikret cloudmiljøet. Produktteamet var klar til release. Leverandøren beskrev sin underdatabehandlerstack som “enterprise-grade”.

Men ét spørgsmål standsede mødet.

“Hvad er vores faktiske risiko, og kan vi dokumentere over for enterprise-kunder, at vi har den under kontrol?”

RoPA’en viste, hvad virksomheden behandlede. Sikkerhedsrisikoregisteret viste infrastrukturrisici. Enkelte DPIA’er lå i separate dokumenter. Leverandørgennemgange lå i indkøbsmapper. Ingen kunne vise én sporbar beslutningskæde fra behandlingsaktivitet til databeskyttelsesrisiko, DPIA-beslutning, behandlingsplan, kontrolkortlægning, godkendelse af restrisiko og gennemgangsdato.

Det er det hul, mange organisationer møder, når de bevæger sig mod ISO/IEC 27701:2025 og GDPR-ansvarlighed. De har privatlivsmeddelelser, leverandørspørgeskemaer, RoPA-poster, datakortlægninger, DPIA-skabeloner og ISO/IEC 27001:2022-kontroller. Det, de ofte mangler, er det operationelle lag, der forbinder dem.

Et modent Privacy Information Management System, eller PIMS, behandler ikke databeskyttelsesrisikovurdering som et juridisk sidedokument. Det behandler den som en gentagelig beslutningsarbejdsgang: identificér behandling, screen risiko, afgør om der er behov for en DPIA, vælg kontroller, tildel ansvarlige, godkend restrisiko, overvåg udløsende forhold, og opbevar revisionsbevis.

Det er her, Clarysecs politikpakker, Zenith Blueprint og Zenith Controls hjælper teams med at gå fra frakoblede regneark til en forsvarlig risikomotor for databeskyttelse.

Databeskyttelsesrisikovurdering er det manglende operationelle lag

GDPR-ansvarlighed reduceres ofte til “at have dokumentation”. Dokumentation er vigtig, men Article 5(2) går videre. Den dataansvarlige er ansvarlig for og skal kunne dokumentere overholdelse af principperne i Article 5(1), herunder lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning, integritet og fortrolighed.

Det kræver mere end en RoPA. Organisationen skal kunne forklare, hvorfor en behandlingsaktivitet er acceptabel, hvilke risici den skaber for fysiske personer, hvilke kontroller der reducerer disse risici, hvem der ejer beslutningen, og hvornår den skal gennemgås.

ISO/IEC 27701:2025 styrker denne forventning ved at indlejre databeskyttelsesstyring i et administreret PIMS. I praksis skal databeskyttelsesrisikovurdering forbinde seks operationelle objekter:

1. Fortegnelse over PII-behandling eller RoPA.
2. Dokumentation for behandlingsgrundlag og formål.
3. Screening af databeskyttelsesrisiko og DPIA-beslutning.
4. Risikobehandling og kontroludvælgelse.
5. Styring af leverandører, databehandlere og underdatabehandlere.
6. Revisionsbevis opbevaret i ISMS og PIMS.

Clarysec gør denne kobling eksplicit. I Enterprise Politik for databeskyttelsesrisikovurdering og DPIA udløses processen, før behandlingen begynder:

[Begge] Procesejeren/forretningsejeren SKAL igangsætte screening af databeskyttelsesrisiko i REG04, før ny eller væsentligt ændret PII-behandling registreret i REG02 påbegyndes.

Den samme forudgående disciplin findes i Enterprise Politik for fortegnelse over PII-behandling og behandlingsgrundlag:

[Begge] Procesejeren/forretningsejeren SKAL igangsætte screening af databeskyttelsesrisiko og DPIA i REG04, før ny eller væsentligt ændret PII-behandling fortsætter.

Det forhindrer det klassiske fejlmønster: Produktet lanceres, RoPA’en opdateres senere, DPIA-spørgsmålet kommer for sent, og risikoregisteret modtager aldrig databeskyttelsesscenariet.

For dataansvarlige understøtter dette disciplin omkring behandlingsgrundlag efter GDPR Article 6, Article 25 om databeskyttelse gennem design og standardindstillinger, Article 32 om behandlingssikkerhed og Article 5 om ansvarlighed. For databehandlere understøtter det dokumenteret instruks, kundens assurance, kontraktlige afgrænsninger og gennemsigtighed om underdatabehandlere.

Start med den faktiske behandling, ikke en tom skabelon

En databeskyttelsesrisikovurdering fejler, når den begynder med en tom formular uden operationel kontekst. Det første spørgsmål bør ikke være: “Har vi brug for en DPIA?” Det bør være: “Hvilken behandling ændrer sig faktisk?”

For en SaaS-, fintech- eller healthtech-organisation kan ændringen omfatte:

• En ny datakategori, f.eks. adfærdsbaserede brugsdata, helbredsdata, biometriske signaler eller betalingsmetadata.
• Et nyt formål, f.eks. svigscoring, patientanalyse, AI-understøttet support, churn-forudsigelse eller personalisering.
• En ny modtager, databehandler eller underdatabehandler.
• En ny supportarbejdsgang eller adgangsvej på tværs af landegrænser.
• En ny opbevaringsperiode.
• En ny model, algoritme eller automatiseret anbefaling.
• En ny gruppe af registrerede, f.eks. mindreårige, medarbejdere, patienter eller økonomisk sårbare personer.

GDPR’s definitioner er brede. Personoplysninger omfatter identifikatorer, onlineidentifikatorer, lokaliseringsdata og forhold knyttet til identitet. Behandling omfatter indsamling, lagring, søgning, brug, videregivelse, begrænsning, sletning og destruktion. Et brud på persondatasikkerheden omfatter hændelig eller ulovlig destruktion, tab, ændring, uautoriseret videregivelse eller adgang.

Det betyder, at en arbejdsgang for databeskyttelsesrisiko skal indfange mere end, om databasen er krypteret. Den skal indfange, hvorfor behandlingen findes, om formålet er foreneligt, om behandlingsgrundlaget er gyldigt, om særlige kategorier af personoplysninger er involveret, om fysiske personer kan forstå behandlingen, og om sikkerhedsforanstaltningerne er proportionale.

For mindre teams giver SME Databeskyttelses- og privatlivspolitik udgangspunktet i punkt 5.2.1:

Databeskyttelseskoordinatoren skal vedligeholde et register over alle behandlingsaktiviteter vedrørende personoplysninger, herunder datakategorier, formål, behandlingsgrundlag og opbevaringsperioder

Det register er ikke papirarbejde. Det er inputmodellen for databeskyttelsesrisikovurdering. Uden datakategorier, formål, behandlingsgrundlag og opbevaringsperioder kan vurderingen ikke pålideligt evaluere formålsbegrænsning, dataminimering, opbevaringsbegrænsning, gennemsigtighed eller rimelighed.

Den samme SME-politik gør også risikogennemgang til en tilbagevendende forpligtelse i punkt 7.1.1:

Databeskyttelseskoordinatoren skal vurdere databeskyttelsesrisici årligt og ved større systemændringer

For virksomheder er styringskadencen stærkere. Enterprise Databeskyttelses- og privatlivspolitik fastslår:

Risikoregistre for databeskyttelse skal vedligeholdes i ISMS og gennemgås mindst kvartalsvist af databeskyttelsesrådgiveren (DPO) og CISO.

Det er her, integrationen mellem ISO/IEC 27701:2025 og ISO/IEC 27001:2022 bliver praktisk. Databeskyttelsesrisici begraves ikke i juridiske mapper. De gennemgås sammen med sikkerhedsrisici, leverandørrisici, hændelser, revisionsobservationer, behandlingsplaner og ledelsesrapportering.

Clarysecs REG02 til REG04-arbejdsgang

Den mest effektive proces for databeskyttelsesrisikovurdering er enkel nok til forretningsansvarlige og robust nok til revisorer. Clarysecs model bruger REG02 som fortegnelse over PII-behandling og REG04 som registrering af databeskyttelsesrisikovurdering og DPIA.

Politik for databeskyttelsesrisikovurdering og DPIA definerer det minimum af revisionsbevis, der kræves, før REG04 kan lukkes:

[Begge] Den databeskyttelsesansvarlige/PIMS-ansvarlige SKAL sikre, at hver REG04-vurdering registrerer risikovurdering, behandlingsbeslutning, ansvarlig, forfaldsdato, restrisiko, godkendelsesstatus og gennemgangsdato før lukning.

Denne sætning er den operationelle rygrad. En databeskyttelsesrisikovurdering er ikke lukket, fordi nogen har skrevet “lav risiko” i et kommentarfelt. Den er lukket, når registreringen indeholder vurdering, behandlingsbeslutning, ansvarlig, forfaldsdato, restrisiko, godkendelsesstatus og gennemgangsdato.

For SMV’er skaleres den samme disciplin ned. SME Politik for risikostyring fastslår:

Hver risikopost skal indeholde: beskrivelse, sandsynlighed, konsekvens, score, ansvarlig og behandlingsplan.

Princippet er proportionalitet, ikke uformel håndtering. Mindre organisationer kan bruge et enklere register, men hver risiko skal stadig have en beskrivelse, score, ansvarlig og behandlingsplan.

Brug ISO/IEC 27001:2022-risikomotoren til databeskyttelse

Databeskyttelsesrisiko bør ikke ligge uden for organisationens metode for risikostyring. ISO/IEC 27001:2022 indeholder allerede ledelsessystemets motor: kontekst, interessenter, omfang, lederskab, risikovurdering, behandling, operationel styring, dokumenteret information, præstationsevaluering og løbende forbedring.

Punkt 4.1 til 4.4 kræver, at organisationen forstår interne og eksterne forhold, interessentkrav, ISMS-omfang og ISMS-processer. For databeskyttelse omfatter interessenter kunder, registrerede, medarbejdere, tilsynsmyndigheder, databehandlere, underdatabehandlere, databeskyttelsesmyndigheder, relevante tilsyn i den finansielle sektor og kontraktkunder.

Punkt 6.1.2 kræver en proces for risikovurdering af informationssikkerhed. Punkt 6.1.3 kræver risikobehandling af informationssikkerhed, herunder valg af kontroller, udarbejdelse af en anvendelighedserklæring, formulering af en risikobehandlingsplan og indhentning af risikoejerens godkendelse af planen og restrisici. Punkt 8.2 og 8.3 kræver, at der gennemføres risikovurderinger og risikobehandlinger af informationssikkerhed med planlagte intervaller eller ved væsentlige ændringer, og at dokumenterede resultater opbevares.

Clarysecs Enterprise Politik for risikostyring følger denne struktur i punkt 5.1:

En formel risikostyringsproces skal vedligeholdes i overensstemmelse med ISO/IEC 27005 og ISO 31000 og omfatte risikoidentifikation, analyse, evaluering, behandling, overvågning og kommunikation.

For databeskyttelse skal risikokriterierne omfatte konsekvens for fysiske personer, ikke kun forretningsmæssig konsekvens. Et lavt økonomisk tab kan stadig være en høj databeskyttelseskonsekvens, hvis behandlingen omfatter særlige kategorier af personoplysninger, sårbare personer, profilering, uigennemsigtighed, ulovlig opbevaring, manglende mulighed for at udøve rettigheder eller ikke-materiel skade.

Clarysecs Zenith Blueprint: En revisors 30-trins køreplan forklarer dette i risikostyringsfasen, trin 10:

Når konsekvens defineres, er det fornuftigt at relatere niveauerne til jeres konkrete forretningsskala. For eksempel: “Væsentlig økonomisk konsekvens = tab > $100k” (tilpas til jeres kontekst). Overvej også regulatorisk konsekvens: eksempelvis kan et brud på persondatasikkerheden automatisk være “Væsentlig” eller “Alvorlig” på grund af GDPR-bøder og underretningskrav, selv om det direkte økonomiske tab er uklart.

Denne vejledning er især vigtig for AI-analyse, helbredsdata, finansiel profilering, medarbejderovervågning og kundescoring. Skaden kan være juridisk, omdømmemæssig, diskriminerende, driftsmæssig, kontraktlig eller personlig.

Et praktisk eksempel: AI-baseret patientanalyse

Vend tilbage til Maria og David. Deres healthtech-platform skal behandle særlige kategorier af helbredsdata efter GDPR Article 9. Den vil bruge patienthistorik, aftaledata, klinikernotater og modeloutput til at generere risikoindsigter.

Med Zenith Blueprint begynder de med trin 9, hvor aktiver, trusler og sårbarheder identificeres:

For hvert aktiv registreres centrale oplysninger: navn/beskrivelse, ejer, lokation og klassificering (følsomhed). Et aktiv kan f.eks. være “Kundedatabase – ejet af IT-afdelingen – hostet på AWS – indeholder personoplysninger og finansielle data (høj følsomhed).”

Det samme trin tilføjer databeskyttelsesvinklen:

Sørg for, at aktiver med personoplysninger markeres (af hensyn til GDPR- relevans), og at kritiske serviceaktiver noteres (af hensyn til mulig NIS2-anvendelse, hvis I er i en reguleret sektor).

Marias team identificerer AI Patient Analytics Platform, patientdatabasen, data warehouse, pipeline til modeltræning, klinikerdashboard, cloudlagring, identitetsudbyder, revisionslogfiler, support-sagsplatform og tredjeparts analyseværktøj. Hvert aktiv får en ejer, lokation, klassificering og PII-relation.

Derefter definerer de risikoscenarier. Ét er uautoriseret adgang til helbredsjournaler. Et andet er utilsigtet videregivelse via analyseeksporter. Et tredje er bias i AI-modellen forårsaget af skæve træningsdata, som fører til urimelig eller diskriminerende patientrisikoscoring.

Trin 11 i Zenith Blueprint forklarer risikoregisterets rolle:

Risikoregisteret er typisk et regneark (vores skabelon “Risk Register and SoA Builder.xlsx” har en dedikeret fane til dette). Det fungerer som hovedloggen over risici.

En databeskyttelsesrisikopost for scenariet med bias i AI-modellen kan se sådan ud:

Denne post gør det, som det gamle regneark ikke kunne. Den forbinder en behandlingsaktivitet med et aktiv, en trussel, en sårbarhed, risiko for fysiske personer, ansvarlig, score, behandlingsplan og beviskæde.

Fordi behandlingen er højrisiko og omfatter særlige kategorier af personoplysninger, er DPIA’en ikke en separat eftertanke. Den bliver det dybere vurderingstrin for en risiko, der allerede er registreret i systemet. Enterprise Databeskyttelses- og privatlivspolitik fastslår:

Alle væsentlige ændringer af systemer eller processer, der involverer personhenførbare oplysninger (PII), skal kræve en dokumenteret konsekvensanalyse vedrørende databeskyttelse (DPIA), gennemgået af databeskyttelsesrådgiveren (DPO).

For høj restrisiko hos en dataansvarlig tilføjer Politik for databeskyttelsesrisikovurdering og DPIA:

[Dataansvarlig] Øverste ledelse SKAL godkende accept af høj restrisiko vedrørende databeskyttelse i REG04, før højrisikobehandling som dataansvarlig begynder eller fortsætter.

Lanceringsbeslutningen har nu sporbarhed: hvad der ændrede sig, hvad der blev vurderet, hvilke risici der blev identificeret, hvilke kontroller der blev valgt, hvem der ejer behandlingen, hvem der godkendte restrisikoen, og hvornår beslutningen skal gennemgås.

Fra risici til kontroller med Zenith Controls

Databeskyttelsesrisikovurdering har kun værdi, hvis den fører til kontrolbeslutninger. Clarysecs Zenith Controls: vejledningen til kortlægning på tværs af efterlevelseskrav er en cross-compliance guide, der kortlægger ISO/IEC 27001:2022- og ISO/IEC 27002:2022-kontroller til relaterede krav på tværs af rammeværker. Det er ikke et separat sæt kontroller. Den hjælper teams med at forstå, hvordan kontrolbevis understøtter flere forpligtelser.

For databeskyttelsesrisikovurdering fremhæver Zenith Controls tre centrale ISO/IEC 27002:2022-kontroller:

Kontrol 5.34 understøtter også GDPR Article 25 og Article 32, NIS2 Article 21 om risikostyringsforanstaltninger for cybersikkerhed, DORA’s forventninger til styring af IKT-risiko og NIST CSF 2.0-resultater såsom GV.OC-03 for juridiske, regulatoriske, kontraktlige, privatlivs- og borgerrettighedsforpligtelser samt PR.DS-01 for beskyttelse af data i hvile.

Trin 13 i Zenith Blueprint forbinder disse beslutninger med anvendelighedserklæringen:

Krydsreferér regler: Hvis bestemte kontroller implementeres specifikt for at overholde GDPR, NIS2 eller DORA, kan I notere det enten i risikoregisteret (som en del af begrundelsen for risikokonsekvensen) eller i SoA-noterne.

Det er sådan, en databeskyttelsesobservation bliver til en ISMS- og PIMS-kontrolbeslutning, ikke blot en juridisk kommentar.

Leverandør- og databehandlerrisiko skal vurderes før godkendelse

Mange databeskyttelsesfejl starter i leverandørstyring. En databehandler tilføjer en ny underdatabehandler. En supportleverandør får adgang til produktionsmiljøet. En analyseplatform lagrer hændelsesdata i en ny region. Indkøb underskriver kontrakten, før databeskyttelsesfunktionen ser risikoen.

Clarysecs Enterprise Politik for styring af databehandlere, underdatabehandlere og tredjepartsdatabeskyttelse forhindrer dette ved at forbinde leverandørgennemgang, REG04 og tredjepartsregisteret:

[Begge] Den databeskyttelsesansvarlige/PIMS-ansvarlige SKAL udløse screening af databeskyttelsesrisiko og DPIA i REG04 for højrisiko-databehandlerforhold og væsentlige ændringer i databeskyttelsesforhold hos tredjeparter før godkendelse, med REG04-referencen registreret i REG08.

For SMV’er fastlægger Politik for tredjeparts- og leverandørsikkerhed kravet om gennemgang før engagement:

Før engagement skal hver leverandør gennemgås for potentielle risici. Denne gennemgang skal omfatte:

Det operationelle budskab er klart. Leverandørrisiko vurderes før godkendelse, ikke efter underskrift.

Dette understøtter også NIS2 og DORA. NIS2 Article 21 kræver sikkerhed i forsyningskæden som en del af risikostyringsforanstaltninger for cybersikkerhed. DORA Articles 28 to 30 kræver, at finansielle enheder styrer IKT-tredjepartsrisiko, gennemfører vurderinger før kontraktindgåelse, opretholder kontraktlige sikkerhedsforanstaltninger, forstår underleverandørrisiko, overvåger afhængigheder og planlægger exit for kritiske eller vigtige funktioner.

Hvis en leverandør berører PII eller understøtter behandling, der er kritisk for databeskyttelse, bør risikoregistreringen for databeskyttelse vise leverandøren, behandlingsrollen, datalokation, afhængighed af underdatabehandlere, kontraktlige sikkerhedsforanstaltninger, hændelsesforpligtelser, opbevaringsregler, overvågningstilgang og exitplan.

Én arbejdsgang, mange efterlevelsesresultater

Fordelen ved en integreret PIMS-arbejdsgang er, at det samme revisionsbevis understøtter flere rammeværker uden dobbeltarbejde.

NIST CSF 2.0 er særligt nyttig til ledelseskommunikation. Funktionen GOVERN dækker organisatorisk kontekst, risikostyringsstrategi, politik, roller, tilsyn og risiko i forsyningskæden. Dens organisationsprofiler hjælper med at omsætte aktuelle og ønskede resultater til en prioriteret handlingsplan, f.eks. et risikoregister eller en handlings- og milepælsplan (POA&M).

For organisationer, der er omfattet af NIS2, DORA eller sektorspecifikke regler, understøtter revisionsbevis for databeskyttelsesrisiko også cybersikkerhedsstyring, leverandørtilsyn, hændelsesberedskab og robusthedsrapportering.

Risikobehandling vedrørende databeskyttelse er bredere end kryptering

Kryptering er vigtig, men den kan ikke rette op på et ugyldigt behandlingsgrundlag, overdreven indsamling, ikke-oplyst profilering, urimelig behandling, ulovlig opbevaring eller en databehandler, der handler uden for instruksen.

SME Databeskyttelses- og privatlivspolitik fastslår:

Kontroller skal implementeres for at reducere identificerede risici, herunder kryptering, anonymisering, sikker bortskaffelse og adgangsbegrænsninger

Det er stærke eksempler, men behandlingen skal passe til scenariet. En risikobehandlingsplan for databeskyttelse kan omfatte indsnævring af behandlingsformålet, fjernelse af unødvendige datakategorier, aggregering eller pseudonymisering af data, opdatering af privatlivsmeddelelser, ændring af behandlingsgrundlag hvor relevant, begrænsning af opbevaring, begrænsning af adgang, tilføjelse af logning, opdatering af kontrakter, gennemførelse af en DPIA, udsættelse af lancering eller afvisning af behandling, der fortsat er uacceptabel.

Enterprise Politik for risikostyring understøtter behandlingsplanlægning for risici over toleranceniveau:

Alle risici, der klassificeres over toleranceniveauet, skal have en tilknyttet risikobehandlingsplan, som angiver:

I praksis betyder det, at høj databeskyttelsesrisiko ikke kan accepteres stiltiende. Den skal behandles, overføres hvor relevant, undgås eller formelt accepteres af den rette ansvarlige ejer.

Udløsende forhold for gennemgang holder vurderingen ajour

En databeskyttelsesrisikovurdering, der aldrig genbesøges, bliver forældet revisionsbevis. ISO/IEC 27001:2022 punkt 8.2 og 8.3 kræver risikovurdering og behandling med planlagte intervaller eller ved væsentlige ændringer. GDPR-ansvarlighed forudsætter aktuelle beslutninger. ISO/IEC 27701:2025 afhænger af overvågning og løbende forbedring.

En REG04-vurdering bør genåbnes, når formålet ændres, nye datakategorier tilføjes, særlige kategorier af personoplysninger bliver involveret, behandlingsgrundlaget ændres, en databehandler eller underdatabehandler ændres, lagring flyttes til en ny region, opbevaringsperioder ændres, logik for profilering ændres, et brud eller en nærved-hændelse opstår, kundekontrakter ændres, eller en ny NIS2-, DORA- eller sektorspecifik forpligtelse finder anvendelse.

Hændelsesprocesser bør føres tilbage til arbejdsgangen for databeskyttelsesrisiko. NIS2 Article 23 fastlægger trinvis rapportering af væsentlige hændelser. DORA Articles 17 to 20 kræver registrering, klassificering, eskalering, kommunikation, rodårsagsanalyse og forbedring af IKT-relaterede hændelser. GDPR-forpligtelser ved brud på persondatasikkerheden kan også blive udløst. Hvis en hændelse afdækker svage adgangskontroller, overdreven opbevaring, uklar leverandørunderretning eller mangelfulde kundeinstrukser, skal REG04 opdateres.

Hvad revisorer forventer at se

En stærk arbejdsgang for databeskyttelsesrisiko bør kunne modstå flere assurance-perspektiver.

Enterprise Databeskyttelses- og privatlivspolitik kræver også intern revisionsaktivitet:

En intern revision af efterlevelse vedrørende databeskyttelse skal gennemføres årligt eller ved større organisatoriske eller regulatoriske ændringer. Revisionens omfang skal omfatte:

Det skaber en ledelsesmæssig feedbacksløjfe. Er REG02-registreringer komplette? Er REG04-screeninger rettidige? Udføres DPIA’er, når det kræves? Er høje restrisici godkendt? Registreres leverandørændringer? Lukkes behandlingsplaner? Er privatlivsmeddelelser afstemt med den faktiske behandling?

Tjekliste til dit næste møde om ændringer i databeskyttelse

Brug denne tjekliste, før en ny behandlingsaktivitet, produktfunktion, leverandør, model eller supportarbejdsgang sættes i drift.

Denne tjekliste erstatter ikke politikken. Den er en praktisk måde at operationalisere politik i møder om produkt, indkøb, engineering, efterlevelse, jura og ledelse.

Gør ansvarlighed for databeskyttelse til et fungerende system

ISO/IEC 27701:2025 og GDPR-ansvarlighed kræver mere end dokumenter. De kræver et fungerende system, der forbinder behandlingsregistreringer, behandlingsgrundlag, databeskyttelsesrisiko, DPIA-beslutninger, leverandører, kontroller, ansvarlige, godkendelser og revisionsbevis.

Start med risikostyringsfasen i Zenith Blueprint, især trin 9 til 13. Brug Risk Register and SoA Builder til at forbinde aktiver, trusler, sårbarheder, databeskyttelsesrisici, behandlingsbeslutninger og kontrolreferencer. Brug derefter Zenith Controls til at kortlægge PII-beskyttelse, aktivfortegnelse og leverandørsikkerhed til assurance-forventninger i GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 og COBIT 19.

Afstem de operationelle politikker, der gør arbejdsgangen håndhævelig: Politik for databeskyttelsesrisikovurdering og DPIA, Politik for fortegnelse over PII-behandling og behandlingsgrundlag, Politik for styring af databehandlere, underdatabehandlere og tredjepartsdatabeskyttelse, Politik for risikostyring og Databeskyttelses- og privatlivspolitik. Mindre teams kan også bruge Clarysecs SME-politikker, mens større organisationer kan strukturere styringen gennem Enterprise-politikker.

Hvis dit team lancerer ny behandling, skifter leverandører, forbereder sig på ISO/IEC 27701:2025 eller forsøger at gøre revisionsbevis for GDPR-ansvarlighed gentageligt, så start med én aktiv behandlingsaktivitet. Åbn REG02, gennemfør REG04-screening, kortlæg risiciene til kontroller, tildel behandlingsansvarlige, og gennemgå restrisiko med den rette beslutningstager.

Det er i denne ene arbejdsgang, at databeskyttelsesstyring bliver operationel.