⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

ISO/IEC 27701:2025-overgangsplan for GDPR-tilpasset PIMS

Igor Petreski

Bestyrelsesspørgsmålet, der afslører et hul i databeskyttelsesbeviset

Anya, CISO i en hurtigt voksende FinTech-virksomhed, stirrede på dagsordenen til bestyrelsesmødet. Mellem omsætningsprognoser og markedsudvidelse lå punktet, der havde optaget hele hendes uge: GDPR-efterlevelse og revisionsberedskab til ISO/IEC 27701:2025.

Virksomheden havde et GDPR-program. Der var en DPO, privatlivsmeddelelser, databehandleraftaler, en DPIA-skabelon og en proces for anmodninger fra registrerede. Salg havde allerede fortalt enterprise-kunder, at virksomheden bevægede sig mod et ISO/IEC 27701:2025 Privacy Information Management System, eller PIMS. Produktorganisationen forberedte en AI-understøttet analysefunktion, der skulle behandle kundebrugeres adfærd, supportsager, faktureringsmetadata og kontoaktivitet. En stor EU-kunde havde bedt om dokumentation for, at forpligtelser som dataansvarlig og databehandler blev styret særskilt.

Den ubehagelige sandhed var ikke, at databeskyttelsesdokumentationen manglede. Problemet var bevismaterialet.

Fortegnelsen over behandlingsaktiviteter viste ikke konsekvent behandlingsgrundlag, opbevaring, afhængigheder til underdatabehandlere, internationale overførsler, eller om virksomheden handlede som dataansvarlig eller databehandler for hvert behandlingsformål. Leverandørgennemgange fokuserede på sikkerhed, men ikke tilstrækkeligt på databeskyttelsesinstrukser, sletning, bistand ved brud, revisionsrettigheder og krav om videreførelse til underdatabehandlere. Engineering havde sikkerhedsgennemgange, men databeskyttelse gennem design blev ikke altid udløst, når en funktion ændrede behandlingsformålet. Intern revision testede GDPR på et overordnet niveau, men kunne ikke altid spore en forpligtelse til en ansvarlig, en kontrol, et register, en test og en beslutning fra ledelsens gennemgang.

Det er den reelle overgangsudfordring ved ISO/IEC 27701:2025. Det er ikke kun et certificeringsprojekt. Det er en modenhedstest: Kan organisationen drive databeskyttelse som et styret system og ikke som en mappe med juridiske dokumenter?

For GDPR-drevne organisationer er svaret at udvide ISO/IEC 27001:2022-ledelsessystemet for informationssikkerhed til et ledelsessystem for databeskyttelse, der integrerer PIMS-omfang, fortegnelser over behandlingsaktiviteter, risikovurdering vedrørende databeskyttelse, DPIA’er, leverandørstyring, håndtering af brud, kontrolkortlægning, intern revision og løbende forbedring.

Hvorfor fragmenteret GDPR-efterlevelse bryder sammen under revisionspres

Mange organisationer behandler efterlevelse af databeskyttelseskrav som et særskilt arbejdsområde adskilt fra informationssikkerhed. Jura styrer kontrakter. IT styrer kryptering. Indkøb styrer leverandører. DPO’en besvarer indsigtsanmodninger. Produktteams lancerer funktioner. Sikkerhed håndterer hændelser. Hver funktion kan udføre værdifuldt arbejde, men uden én samlet driftsmodel bliver bevismateriale for databeskyttelse fragmenteret.

Det skaber fire tilbagevendende problemer.

For det første dublerer teams indsatsen. Risikovurderinger for sikkerhed og databeskyttelse kan bruge forskellige metoder, forskellige scoringsmodeller og forskellige ansvarlige.

For det andet opstår der huller i tredjepartstjenester, cloudkonfigurationer, analysepipelines, supportværktøjer og nye udviklingsprojekter, fordi ingen har et fuldstændigt overblik over PII-flows.

For det tredje bliver assurance over for bestyrelse og kunder vanskelig. En samling af usammenhængende politikker dokumenterer ikke, at databeskyttelsesforpligtelser er implementeret, overvåget og forbedret.

For det fjerde konvergerer moderne regulatoriske forventninger. GDPR forventer ansvarlighed og bevismateriale. NIS2 forventer governance, risikostyring, håndtering af hændelser, adgangsstyring, aktivstyring og sikkerhed i forsyningskæden. DORA forventer, at finansielle enheder styrer IKT-risiko, hændelser, robusthedstest, tredjepartskontrakter og exitstrategier. Et silo-opdelt databeskyttelsesprogram kan ikke effektivt understøtte dem alle.

Den stærkere tilgang er at bygge ISO/IEC 27701:2025-overgangen på ISO/IEC 27001:2022 ISMS. ISO/IEC 27001:2022 leverer ledelsessystemstrukturen for kontekst, interessenter, omfang, risikovurdering, risikobehandling, mål, operationel planlægning, intern revision, ledelsens gennemgang, korrigerende handling og løbende forbedring. ISO/IEC 27002:2022 leverer kontrolfundamentet for retlige forpligtelser, aktivfortegnelse, leverandørrelationer, cloudtjenester, adgangsstyring, logning, overvågning, sletning, maskering samt privatliv og beskyttelse af personoplysninger (PII).

Overgangen skal besvare fem spørgsmål:

  1. Hvad er PIMS-omfanget, herunder roller som dataansvarlig, databehandler, fælles dataansvarlig og underdatabehandler?
  2. Hvilke behandlingsaktiviteter, datakategorier, formål, behandlingsgrundlag, modtagere, overførsler og opbevaringsregler er omfattet?
  3. Hvilke databeskyttelsesrisici kræver DPIA, behandling, godkendelse og accept af restrisiko?
  4. Hvilke politikker, kontroller, kontrakter, tekniske sikkerhedsforanstaltninger og registreringer dokumenterer GDPR-ansvarlighed?
  5. Hvordan skal intern revision og ledelsens gennemgang bekræfte, at PIMS fungerer og forbedres?

Fase 1: godkend PIMS-omfanget, før politikkerne omskrives

En stærk ISO/IEC 27701:2025-overgangsplan begynder ikke med at omskrive alle privatlivspolitikker. Den begynder med governance og omfang.

Det eksisterende ISMS-omfang er udgangspunktet, men PIMS-omfanget skal eksplicit identificere PII-behandling, forretningsenheder, tjenester, systemer, regioner, cloudmiljøer, leverandører og databeskyttelsesroller. Bestyrelsen eller øverste ledelse skal forstå, hvorfor overgangen er vigtig, især hvor kunder, tilsynsmyndigheder eller sektorforpligtelser som DORA afhænger af dokumenterbar databeskyttelses- og robusthedsdokumentation.

Clarysecs Privacy Information Management System Policy [PIMS-politik] gør godkendelse af omfang obligatorisk:

[Begge] Øverste ledelse SKAL godkende PIMS-omfanget i REG01 før den første PIMS-implementering og inden for 30 dage efter enhver væsentlig ændring.

For overgangsprogrammer, der bruger punktnummereringen fra Clarysecs politikbibliotek, er dette kerneforventningen i punkt 4.1.1. Det er vigtigt, fordi implicit databeskyttelsesomfang er en af de mest almindelige revisionssvagheder. Hvis en produktlinje, jurisdiktion, behandlingsrolle, leverandør, cloudregion eller forretningsproces ændres væsentligt, må PIMS-omfanget ikke være overladt til fortolkning.

Den samme politik omsætter også overgangen til et styret program:

[Begge] Privacy Lead / PIMS Manager SKAL registrere PIMS-implementeringsplanen i REG12 før PIMS-udrulning eller større PIMS-ændring.

REG12 er ikke administrativt overhead. Det er overgangens kontrolforum. Det skal vise, hvad der ændres, hvorfor det er vigtigt, hvem der ejer det, hvilket bevismateriale der kræves, hvilke risici der er åbne, og hvornår beredskabet skal testes.

Fase 2: etabler en registerstyret overgangsfortegnelse

For GDPR-ledelsessystemer for databeskyttelse bør den første praktiske leverance være en fortegnelse over bevismateriale, ikke en omskrivning af politikker. Clarysec bruger en registerstyret tilgang, fordi registre omsætter databeskyttelsesintentioner til revisionsbart bevismateriale.

PIMS-omfanget i REG01 kobles til behandlingsaktiviteter i REG02, kontrollernes anvendelighed i REG03, databeskyttelsesrisiko og DPIA-screening i REG04 samt implementeringsplanlægning i REG12.

Data Protection and Privacy Policy - SME [SMV-privatlivspolitik] fastsætter baselinen:

Koordinatoren for databeskyttelse skal vedligeholde et register over alle behandlingsaktiviteter med personoplysninger, herunder datakategorier, formål, behandlingsgrundlag og opbevaringsperioder

For større miljøer hæver Data Protection and Privacy Policy [P17 Databeskyttelses- og privatlivspolitik] styringsforventningen:

Organisationen skal vedligeholde en formel styringsramme for databeskyttelse, der er integreret i ledelsessystemet for informationssikkerhed (ISMS), for at håndhæve denne politik.

Denne integration er overgangsprincippet. En fortegnelse over behandlingsaktiviteter uden risikobehandling er et regneark. En DPIA uden kontrolejerskab er et juridisk notat. En databehandleraftale uden overvågning er en kontrakt i arkivet. ISO/IEC 27701:2025-overgangsarbejdet skal samle disse artefakter i ét styret PIMS.

OvergangselementBevismateriale, der skal indsamlesClarysec-artefakt
PIMS-omfangForretningsenheder, systemer, regioner, behandlingsroller, udelukkelser, afhængighederREG01 PIMS-omfang
BehandlingsaktiviteterFormål, behandlingsgrundlag, datakategorier, registrerede, opbevaring, modtagere, overførslerREG02 Fortegnelse over behandlingsaktiviteter
Kontrollernes anvendelighedInkluderede kontroller, udelukkede kontroller, implementeringsstatus, begrundelseREG03 PIMS-kontrolanvendelighed
DPIA-udløsereHøjrisikobehandling, nye formål, særlige kategorier af personoplysninger, overvågning, automatiserede afgørelserREG04 Databeskyttelsesrisiko og DPIA-screening
OvergangsplanAnsvarlige, milepæle, revisionsplan, input til ledelsens gennemgang, afhjælpende foranstaltningerREG12 PIMS-implementeringsplan

Denne fortegnelse understøtter også en NIST Cybersecurity Framework 2.0-tilgang med Current Profile og Target Profile. Current Profile dokumenterer eksisterende databeskyttelsesprocesser, kontroller og bevismateriale. Target Profile definerer det ønskede PIMS tilpasset ISO/IEC 27701:2025. Afstanden mellem dem bliver overgangsbackloggen.

Fase 3: kortlæg GDPR-ansvarlighed ind i PIMS

GDPR-ansvarlighed er rygraden i bevismateriale for databeskyttelse. GDPR gælder for behandling i forbindelse med en etablering i EU og kan også gælde for dataansvarlige eller databehandlere uden for EU, der tilbyder varer eller tjenester til personer i EU eller overvåger deres adfærd. GDPR definerer personoplysninger bredt, herunder direkte og indirekte identifikatorer. Forordningen skelner mellem dataansvarlige og databehandlere og definerer et brud på persondatasikkerheden som et brud på sikkerheden, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger.

For overgangsplanlægning er det centrale, at GDPR ikke opfyldes ved at sige: “vi har sikkerhedskontroller.” Article 5 kræver lovlig, rimelig og gennemsigtig behandling, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning, integritet og fortrolighed samt dokumenterbar ansvarlighed. Article 6 kræver et behandlingsgrundlag. Article 9 tilføjer strengere betingelser for særlige kategorier af personoplysninger. Article 25 kræver databeskyttelse gennem design og standardindstillinger. Article 28 kræver databehandlerstyring. Article 32 kræver behandlingssikkerhed.

Clarysecs Legal and Regulatory Compliance Policy - SME [SMV-politik for juridisk og regulatorisk efterlevelse] giver mindre organisationer et enkelt udgangspunkt:

Direktøren skal vedligeholde et enkelt, struktureret efterlevelsesregister, der angiver:

Den virksomhedsdækkende Legal and Regulatory Compliance Policy [P37 Politik for juridisk og regulatorisk efterlevelse] er mere eksplicit:

Alle juridiske og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ansvarlige i ledelsessystemet for informationssikkerhed (ISMS).

Den sætning er forskellen mellem uformel GDPR-efterlevelse og revisionsklar databeskyttelsesstyring. Enhver væsentlig GDPR-forpligtelse bør kortlægges til en politik, en kontrol, en ansvarlig, et registerfelt og en kilde til bevismateriale.

GDPR-forpligtelsesområdePIMS-overgangsbevismaterialeOperationel ansvarlig
Behandlingsgrundlag og formålsbegrænsningREG02-behandlingsregistrering med formål, behandlingsgrundlag, rolle og gennemgangsdatoPrivacy Lead og procesejer
Databeskyttelse gennem design og standardindstillingerTjekliste for ændringsmodtagelse, DPIA-screening, arkitekturgennemgang, godkendelsesregistreringProduktejer og sikkerhedsarkitekt
DatabehandlerstyringDatabehandleraftale, leverandørrisikovurdering, underdatabehandlerliste, revisionsrettigheder, klausul om bistand ved brudIndkøb og Jura
Registreredes rettighederAnmodningslog, registrering af identitetsverifikation, dokumentation for opfyldelse, undtagelsesbeslutningerDatabeskyttelsesdrift
Håndtering af brud på persondatasikkerhedenHændelsesregistrering, alvorlighedsvurdering, beslutning om underretning, læringspunkterHændelsesansvarlig og DPO
Opbevaring og sletningOpbevaringsplan, dokumentation for sletning, godkendelse af undtagelseDataejer og IT-drift

Bevismateriale for dataansvarlig og databehandler skal adskilles. En dataansvarlig skal dokumentere behandlingsgrundlag, gennemsigtighed, håndtering af rettigheder, formålsbeslutninger og opbevaring. En databehandler skal dokumentere behandling efter dokumenterede instrukser, styring af underdatabehandlere, bistand til den dataansvarlige, sikkerhedsforanstaltninger, støtte til anmeldelse og underretning ved brud samt returnering eller sletning ved tjenestens ophør. Hvis organisationen optræder i begge roller, er én generisk bevismodel ikke tilstrækkelig.

Fase 4: brug SoA som bro for databeskyttelseskontroller

En almindelig overgangsfejl er at oprette et selvstændigt PIMS-kontrolregneark, mens ISMS-anvendelighedserklæringen forbliver uændret. Det skaber to konkurrerende kontroluniverser.

ISO/IEC 27001:2022 kræver, at risikobehandlingsbeslutninger afspejles i anvendelighedserklæringen. Clarysecs Risk Management Policy [Politik for risikostyring] fastslår:

En anvendelighedserklæring (SoA) skal afspejle alle behandlingsbeslutninger og skal opdateres, når kontroldækningen ændres.

Ved ISO/IEC 27701:2025-overgangen bliver SoA broen mellem ISMS og PIMS. Hvis en DPIA eller risikobehandling vedrørende databeskyttelse tilføjer kryptering, datamaskering, sletningskontroller, samtykkemekanismer, leverandør-due diligence for databehandlere, adgangsbegrænsninger eller overvågning af DSAR-arbejdsgange, skal SoA og REG03 afspejle beslutningen.

Zenith Blueprint: An Auditor’s 30-Step Roadmap [Zenith Blueprint] forstærker dette i trin 6:

✓ Yderligere kontroller: Er der kontroller uden for Annex A, som I bør medtage? ISO 27001
tillader, at andre kontroller tilføjes i SoA. For eksempel kan I medtage
overholdelse af NIST CSF eller specifikke databeskyttelseskontroller fra ISO 27701.

Tving ikke databeskyttelsesforpligtelser ind i kontroller, der ikke passer. Tilføj databeskyttelsesspecifikke kontroller, hvor det er nødvendigt, men styr dem gennem samme model for risikobehandling, ejerskab, implementeringsstatus, bevismateriale og revision.

ISO/IEC 27002:2022-kontrollerne, der forankrer overgangen

I Zenith Controls: The Cross-Compliance Guide [Zenith Controls] er to ISO/IEC 27002:2022-kontroller centrale for ISO/IEC 27701:2025-overgangen: 5.31 Juridiske, lovbestemte, regulatoriske og kontraktlige krav samt 5.34 Privatliv og beskyttelse af personoplysninger (PII).

Kontrol 5.31 er efterlevelseshubben. Den understøtter identifikation, dokumentation, ejerskab og gennemgang af juridiske, regulatoriske, lovbestemte og kontraktlige krav. Den kobler naturligt til GDPR-ansvarlighed, NIS2-styring, DORA-forpligtelser vedrørende IKT-risiko, kunders databeskyttelsesklausuler og forpligtelser vedrørende cloudbehandling.

Kontrol 5.34 er det operationelle databeskyttelsesanker. Zenith Controls forklarer afhængigheden tydeligt:

En fortegnelse over informationsaktiver (5.9) bør omfatte PII-databeholdninger (kundedatabaser, HR-filer). Dette understøtter 5.34 ved at sikre, at organisationen ved, hvilke personoplysninger (PII) den har og hvor, hvilket er første skridt til at beskytte dem.

Kontrolkrydsreferencen bør bruges som en praktisk designtjekliste.

ISO/IEC 27002:2022-kontrolOvergangsrelevans for GDPR PIMS
5.9 Fortegnelse over information og andre tilknyttede aktiverIdentificerer PII-repositorier, systemer, ejere og dataflows
5.12 Klassificering af informationMærker PII og særlige kategorier af personoplysninger, så stærkere kontroller anvendes
5.14 InformationsoverførselKontrollerer intern og ekstern overførsel af personoplysninger
5.15 AdgangsstyringHåndhæver need-to-know-adgang til PII
5.16 IdentitetsstyringSikrer, at identiteter med adgang til PII er styrede og sporbare
5.19 Informationssikkerhed i leverandørrelationerUnderstøtter databeskyttelse hos leverandører, databehandlerassurance og tredjepartsovervågning
5.20 Håndtering af informationssikkerhed i leverandøraftalerIndarbejder sikkerheds- og databeskyttelseskrav i kontrakter
5.21 Styring af informationssikkerhed i IKT-forsyningskædenUnderstøtter styring af underdatabehandlere og IKT-afhængigheder
5.23 Informationssikkerhed ved brug af cloudtjenesterSikrer, at cloududbydere opfylder forventninger til databeskyttelse, lokation, sletning og kontrakter
5.31 Juridiske, lovbestemte, regulatoriske og kontraktlige kravKortlægger GDPR-, DORA-, NIS2-, kunde- og kontraktlige forpligtelser
5.33 Beskyttelse af registreringerUnderstøtter opbevaring, integritet og beskyttelse af registreret bevismateriale
5.34 Privatliv og beskyttelse af PIIForankrer databeskyttelseskontroller på tværs af PII-livscyklussen
5.35 Uafhængig gennemgang af informationssikkerhedUnderstøtter intern revision og ekstern assurance
5.36 Overholdelse af politikker, regler og standarder for informationssikkerhedTester, om databeskyttelseskontroller følges
5.8 Informationssikkerhed i projektledelseIndarbejder databeskyttelse og sikkerhed i projektstyring
8.10 Sletning af informationUnderstøtter opbevaringsbegrænsning og sletteforpligtelser
8.11 DatamaskeringBeskytter PII i ikke-produktionsmiljøer og analysebrugsscenarier
8.15 LogningLeverer bevismateriale for adgang og aktivitet, der involverer PII
8.16 OvervågningsaktiviteterDetekterer mistænkelig aktivitet og understøtter undersøgelse af hændelser
8.32 ÆndringsstyringSikrer, at påvirkning af databeskyttelse gennemgås før produktionsændringer

Her bliver databeskyttelse operationel. For hver højrisikobehandlingsaktivitet bør I spørge: Hvilke aktiver indeholder PII, hvordan er de klassificeret, hvem kan få adgang, hvor overføres de til, hvilke cloudtjenester behandler dem, hvilken opbevaringsregel gælder, hvilken overvågning detekterer misbrug, og hvilket bevismateriale dokumenterer, at kontrollerne fungerer?

Eksempel på arbejdsgang: onboarding af en AI-understøttet analysefunktion

Tilbage til Anyas FinTech. Produktteamet ønsker at lancere en AI-understøttet analysefunktion, der behandler brugeridentifikatorer, kontoaktivitet, supportmetadata, faktureringsmetadata og adfærdssignaler. Nogle enterprise-kunder kan bruge outputtet til overvågning af medarbejdere, hvilket øger databeskyttelsesrisikoen.

En PIMS-overgangsarbejdsgang bør håndtere lanceringen som en kontrolleret databeskyttelseshændelse.

Trin 1: opdater REG02 for behandlingsroller og formål

Procesejeren opretter eller opdaterer behandlingsregistreringen. Obligatoriske felter omfatter formål, datakategorier, kategorier af registrerede, behandlingsgrundlag eller databehandlerinstruks, opbevaringsperiode, systemer, leverandører, modtagere, overførsler og rollekontekst.

Hvis virksomheden er databehandler for kundeanalyser, skal REG02 vise behandling efter kundens instruks. Hvis den også bruger aggregerede data til at forbedre sit eget produkt, kan dette særskilte formål gøre virksomheden til dataansvarlig for viderebehandling. Registreringen må ikke udviske rollerne.

Trin 2: gennemfør REG04-screening

Clarysecs Privacy Risk Assessment and DPIA Policy [Politik for risikovurdering vedrørende databeskyttelse og DPIA] kræver:

[Begge] Procesejeren / virksomhedsejeren SKAL gennemføre baseline-REG04-screening for alle aktive REG02-behandlingsaktiviteter inden for PIMS-omfanget senest 30 arbejdsdage efter godkendelse eller udvidelse af PIMS-omfanget.

Screeningen bør identificere overvågning, profilering, særlige kategorier, sårbare personer, ny teknologi, behandling i stort omfang, grænseoverskridende overførsler eller ændret formål. Hvis tærsklerne er opfyldt, udløses en DPIA.

Trin 3: udfør DPIA’en og fastlæg behandling

P17 Databeskyttelses- og privatlivspolitik kræver:

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

I Clarysec-biblioteket er dette knyttet til punkt 5.6. DPIA’en bør vurdere risici såsom overdreven indsamling, uklart formål, re-identifikation, uautoriseret adgang for kundeadministratorer, uklar opbevaring og eksponering via underdatabehandlere. Behandlinger kan omfatte minimering på feltniveau, pseudonymisering, kundekonfigurationskontroller, standarder for opbevaring, stærkere revisionslogning, opdateringer af databehandleraftaler, produktmeddelelser og begrænsninger på modeltræning.

Trin 4: opdater REG03 og SoA

PIMS-politikken kræver:

[Begge] Privacy Lead / PIMS Manager SKAL vedligeholde REG03 med inkluderede kontroller, udelukkede kontroller, implementeringsstatus og begrundelse årligt og inden for 30 dage efter hver ændring i risikobehandling vedrørende databeskyttelse.

Hvis DPIA’en tilføjer maskering for ikke-produktionsanalyse, logning af administratoradgang, sletningskontroller, leverandørklausuler eller sikkerhedsforanstaltninger for kundekonfiguration, skal REG03 og SoA opdateres.

Trin 5: dokumentér databeskyttelse gennem design

SMV-privatlivspolitikken beskriver princippet enkelt:

Databeskyttelse gennem design og standardindstillinger skal håndhæves i alle nye systemer og tjenester

Bevismaterialet bør omfatte DPIA’en, arkitekturgennemgangen, beslutningen om dataminimering, adgangsmodellen, logningskonfigurationen, opbevaringsindstillingen, testresultater, frigivelsesgodkendelse og gennemgang efter lancering. Det omsætter funktionslanceringen til genanvendeligt PIMS-bevismateriale.

Styring af databeskyttelse hos leverandører i en DORA- og NIS2-verden

Styring af databeskyttelse hos leverandører er der, hvor mange overgange fejler. GDPR Article 28 kræver, at dataansvarlige kun anvender databehandlere, der stiller tilstrækkelige garantier, og at databehandlerforpligtelser indgår i skriftlige kontrakter. DORA Articles 28 to 30 kræver, at finansielle enheder styrer IKT-tredjepartsrisiko, vedligeholder registre over kontraktlige aftaler, gennemfører due diligence, medtager revisionsrettigheder og exitvilkår, styrer underleverandører og adresserer kritiske eller vigtige funktioner. NIS2 Article 21 kræver sikkerhedsforanstaltninger i forsyningskæden, herunder hensyntagen til leverandørsårbarheder, cybersikkerhedspraksis og sikre udviklingsprocedurer.

ISO/IEC 27002:2022-kontrol 5.19, informationssikkerhed i leverandørrelationer, er det operationelle anker. Zenith Controls kortlægger dette område til leverandøraftaler, sikkerhed i IKT-forsyningskæden, informationsoverførsel, overvågning af efterlevelse, acceptabel brug, GDPR-databehandlerforpligtelser, NIS2-cybersikkerhed i forsyningskæden, DORA IKT-tredjepartsrisiko, NIST-leverandørstyring og COBIT-leverandørstyring.

LeverandørkategoriNødvendigt databeskyttelsesbevismateriale
Databehandler, der håndterer kunders PIIDatabehandleraftale, instrukser, tekniske og organisatoriske foranstaltninger, underdatabehandlerliste, støtte til underretning ved brud, revisionsrettigheder
Underdatabehandler i SaaS-leverancekædenKrav om videreførelse, lokation, overførselsgrundlag, sletteforpligtelse, underretning om ændringer
CloududbyderRegionsvalg, kryptering, adgangskontroller, hændelsesbistand, vilkår for sletning og returnering
Udbyder af supportværktøjAdgangsbegrænsning, redigering af tickets, opbevaring, logning, fortrolighed for supportpersonale
Analyse- eller AI-udbyderFormålsbegrænsning, begrænsning af modeltræning, pseudonymisering, fravalg eller konfigurationskontroller

For DORA-regulerede finansielle enheder skal dette bevismateriale kobles til IKT-tredjepartsregistre og vurderinger af kritiske eller vigtige funktioner. For NIS2-enheder understøtter de samme leverandørregistreringer styring af forsyningskæderisiko. For NIST CSF 2.0 stemmer leverandørstyring overens med GOVERN-funktionen, især resultater for styring af forsyningskæderisiko. For COBIT 2019 stemmer leverandørstyring overens med mål såsom APO10 Managed Vendors og DSS-relaterede operationelle leverandørkontroller.

Hændelses- og brudberedskab skal integreres

Overgangsplaner for databeskyttelse fokuserer ofte for meget på dokumentation og for lidt på håndtering af brud. Det er risikabelt, fordi GDPR, NIS2 og DORA alle forventer disciplinerede hændelsesprocesser, selv om tærskler og rapporteringsfrister er forskellige.

GDPR kræver vurdering af, om en sikkerhedshændelse har medført et brud på persondatasikkerheden, og om anmeldelse til tilsynsmyndigheden eller underretning af berørte personer er påkrævet. NIS2 fastsætter trinvis rapportering for væsentlige hændelser, herunder tidlig varsling inden for 24 timer, underretning inden for 72 timer og en endelig rapport inden for én måned. DORA kræver, at finansielle enheder detekterer, styrer, klassificerer, registrerer, underretter om, reagerer på og lærer af IKT-relaterede hændelser med trinvis rapportering for større hændelser.

HændelsesbevismaterialeGDPR-formålNIS2- eller DORA-formål
Registrering af hændelsesklassificeringAfgør, om der er sket et brud på persondatasikkerhedenAfgør klassificering som væsentlig eller større IKT-hændelse
Vurdering af datapåvirkningIdentificerer berørte registrerede og risiko for rettigheder og frihedsrettighederUnderstøtter rapportering af alvorlighed og påvirkning
TidslinjelogDokumenterer tidspunkt for kendskab, eskalering, beslutninger og underretningsfristerUnderstøtter trinvis rapportering og kommunikation med tilsynsmyndigheder
RodårsagsanalyseUnderstøtter afhjælpning og ansvarlighedUnderstøtter endelig rapportering og forbedring af robusthed
LæringspunkterOpdaterer DPIA’er, kontroller, træning og leverandørtilsynFøder test, revision og ledelsens gennemgang

NIST CSF 2.0 understøtter denne cyklus gennem resultaterne Detect, Respond, Recover og Govern. Overgangsteamet bør sikre, at beslutninger om brud på persondatasikkerheden er indlejret i arbejdsgangen for sikkerhedshændelser og ikke håndteres som en løsrevet juridisk eftertanke.

Én køreplan, mange efterlevelsesresultater

ISO/IEC 27701:2025-overgangen bliver mere værdifuld, når den reducerer dobbelt efterlevelsesarbejde. Zenith Blueprint, trin 14, anbefaler krydshenvisning mellem GDPR, NIS2 og DORA, så organisationer kan vise, at risikobehandling og kontroller opfylder flere forpligtelser:

For hver regulering kan I, hvis relevant, oprette en enkel kortlægningstabel (eventuelt som
bilag i en rapport), der angiver reguleringens centrale sikkerhedskrav og de
tilsvarende kontroller/politikker i jeres ISMS.

For overgangsplanlægning vedrørende databeskyttelse bør kortlægningen være praktisk og evidensbaseret.

RammeværkHvad auditorer eller vurderingsparter forventerPIMS-overgangsrespons
GDPRAnsvarlighed, behandlingsgrundlag, DPIA’er, databehandlerstyring, håndtering af brud, understøttelse af rettighederREG02, REG04, DPIA-registreringer, databehandleraftaleregister, beslutningslogfiler for brud, DSAR-bevismateriale
NIS2Risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, adgangsstyring, aktivstyringISMS-risikoregister, leverandørniveauer, hændelsesarbejdsgang, adgangsgennemgange, aktivfortegnelse
DORAIKT-risikostyringsramme, hændelsesrapportering, robusthedstest, IKT-tredjepartsrisiko, kontraktlige klausulerIKT-afhængighedsregister, kortlægning af kritiske leverandører, hændelsesrapporter, testbevismateriale, exitplaner
NIST CSF 2.0Styring, juridiske og databeskyttelsesforpligtelser, risikoprofiler, leverandørrisiko, hændelses- og genopretningsresultaterCurrent og Target Profiles, efterlevelseskortlægning, leverandørovervågning, respons- og genopretningsbevismateriale
COBIT 2019Styring af databeskyttelsesprogram, overvågning af efterlevelse, leverandøraftaler, operationelle databeskyttelseskontrollerBestyrelsesrapportering, efterlevelsesregister, APO- og DSS-tilpasset bevismateriale, interne revisionskonstateringer

I Zenith Controls understøtter ISO/IEC 27002:2022-kontrol 5.31 juridisk og regulatorisk sporbarhed på tværs af GDPR-ansvarlighed, DORA-efterlevelsesforpligtelser, NIS2-styringsforventninger, NIST CSF 2.0 GV.OC-03 og COBIT-overvågning af ekstern efterlevelse. Kontrol 5.34 understøtter GDPR Articles 25 og 32, beskyttelse gennem PII-livscyklussen, forventninger til PII-behandling i cloudtjenester og sikkerhedskontroller med fokus på databeskyttelse.

Resultatet er ikke en forsimplet “én kontrol er lig én lov”-model. Det er en forsvarlig bevismodel, hvor ét veldesignet kontrolsæt understøtter flere assurance-behov.

Hvordan auditorer vil teste overgangen

En stærk overgangsplan forudser revisionsteknikker.

En ISO-ledelsessystemauditor vil begynde med omfang, interessenter, juridiske krav, risici, mål, operationelle kontroller, interne revisioner, ledelsens gennemgange, afvigelser og forbedring. Auditoren vil verificere, om PIMS-omfanget er godkendt, om databeskyttelsesforpligtelser indgår i efterlevelsesregisteret, om kontroller er begrundet i SoA, og om implementeringsbevismaterialet svarer til det angivne omfang.

En databeskyttelsesauditor vil udtage stikprøver af behandlingsregistreringer, DPIA’er, DSAR’er, beslutninger om brud, databehandlerkontrakter, opbevaringskontroller og projektonboarding. Auditoren vil ikke acceptere politikhensigt, hvor operationelt bevismateriale mangler.

En NIST-tilpasset vurderingspart vil se efter styring, juridiske og kontraktlige forpligtelser, målprofiler, leverandørrisiko, overvågning, respons og genopretningsbevismateriale.

En COBIT 2019-auditor vil fokusere på bestyrelsestilsyn, efterlevelsesrapportering, leverandørstyring, roller og ansvar, og om databeskyttelsesrisiko styres på tværs af informationslivscyklussen.

Clarysecs PIMS Monitoring, Audit and Improvement Policy [PIMS-politik for overvågning, revision og forbedring] gør revisionsprogrammet obligatorisk:

[Alle] Intern revision / compliance-gennemgangsansvarlig SKAL udarbejde et risikobaseret internt PIMS-revisionsprogram i REG12 årligt før den første planlagte PIMS-revisionscyklus.

Audit and Compliance Monitoring Policy [Politik for revision og overvågning af efterlevelse] anvender samme disciplin på ISMS-niveau:

En risikobaseret revisionsplan skal udarbejdes og godkendes årligt under hensyntagen til:

For mindre organisationer holder Audit and Compliance Monitoring Policy - SME [SMV-politik for revision og overvågning af efterlevelse] revisionsplanlægningen fokuseret:

Planen skal identificere centrale systemer og politikker, der skal gennemgås, med fokus på:

Under overgangen bør den første interne revision ikke teste alt. Den bør teste de største overgangsrisici: ufuldstændige behandlingsregistreringer, manglende DPIA-udløsere, svage leverandørklausuler om databeskyttelse, uprøvede beslutninger om brud, uklare roller som dataansvarlig og databehandler samt uoverensstemmelser i SoA.

En praktisk 90-dages ISO/IEC 27701:2025-overgangskøreplan

En realistisk køreplan bør være kort nok til at kunne gennemføres og struktureret nok til at skabe bevismateriale.

TidslinjeOvergangsmålCentrale output
Dag 1 til 15Etabler omfang og governanceREG01-godkendelse, sponsor, rollekort, opdatering af efterlevelsesregister, REG12-overgangsplan
Dag 16 til 35Etabler baseline for databeskyttelsesbevismaterialeOprydning i REG02, datakategorier, formål, behandlingsgrundlag, opbevaring, systemer, leverandører, overførsler
Dag 36 til 55Gennemfør databeskyttelsesrisiko- og DPIA-screeningREG04-screening, DPIA-udløsere, risikobehandlingsbeslutninger, godkendelser af restrisiko
Dag 56 til 70Opdater kontroller, kontrakter og sikkerhedsforanstaltningerREG03-opdatering, SoA-opdatering, afhjælpning af databehandleraftaler, adgang, sletning, maskering, logning, cloudkontroller
Dag 71 til 85Test bevismateriale gennem intern revisionStikprøverevision af én dataansvarlig proces, én databehandlertjeneste, én leverandør, én DPIA, én DSAR, ét brudscenarie
Dag 86 til 90Afhold ledelsens gennemgang og beslut beredskabGennemgangshandlinger, leverandørforhold, hændelser, revisionskonstateringer, databeskyttelsesmål, beslutning om ekstern vurdering

90-dagesmålet betyder ikke, at alle afhjælpningstiltag vil være lukket. Det betyder, at ledelsen bør have et godkendt omfang, en troværdig baseline for bevismateriale, prioriteret risikobehandling, fokuserede revisionsresultater og en ledelsesbeslutning om beredskab.

Gør overgangen evidensbaseret

Organisationer, der lykkes med ISO/IEC 27701:2025-overgangen, er ikke dem med den længste privatlivspolitik. Det er dem, der kan dokumentere, hvordan databeskyttelsesforpligtelser bevæger sig fra lov til omfang, fra omfang til behandlingsregistreringer, fra behandlingsregistreringer til risikovurdering, fra risikovurdering til kontroller, fra kontroller til bevismateriale og fra bevismateriale til forbedring.

Clarysec hjælper teams med at gøre denne overgang praktisk. Vores PIMS-politiksæt, GDPR-kortlægninger, bevisregistre for dataansvarlige og databehandlere, DPIA-arbejdsgange, skabeloner til styring af databeskyttelse hos leverandører, materialer til håndtering af brud, dagsordener for ledelsens gennemgang, Zenith Blueprint og Zenith Controls giver CISO’er, DPO’er, compliance-ansvarlige, auditorer og virksomhedsejere en struktureret vej fra databeskyttelsesintention til revisionsklar drift.

Hvis jeres organisation forbereder sig på ISO/IEC 27701:2025, så begynd i denne uge med tre handlinger: godkend PIMS-overgangsomfanget i REG01, udfyld REG02 for jeres tjeneste med højeste risiko, og gennemfør den første REG04-screening. Brug derefter Clarysec til at omsætte dette bevismateriale til en komplet GDPR-tilpasset PIMS-overgangskøreplan, klar til kunder, auditorer, tilsynsmyndigheder og bestyrelsen.

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article