Revisionsklar beskyttelse af personoplysninger for GDPR, NIS2 og DORA
Alarmen landede i Sarahs indbakke kl. 22 en tirsdag aften.
Som CISO i en voksende FinTech SaaS-virksomhed var sene alarmer ikke usædvanlige. Denne var anderledes. En juniorudvikler havde eksponeret en stagingdatabase mod et offentligt endpoint under test af en ny analysefunktion. Databasen skulle have indeholdt testdata, men en nylig synkronisering fra produktion til staging havde fyldt den med reelle kundeoplysninger.
Hændelsen blev hurtigt inddæmmet. Derefter kom den næste opdagelse. Et migreringsregneark med navnet customer_users_final_v7.xlsx var blevet kopieret fra det samme datasæt. Det indeholdt navne, e-mailadresser, rolletilladelser, brugslogfiler, landefelter, supportnoter og fritekstkommentarer, som aldrig burde have indgået i en testarbejdsgang. Det var blevet kopieret til et fællesdrev, downloadet af en udvikler, vedhæftet en sag og glemt.
Ved midnat håndterede Sarah ikke længere en teknisk fejlkonfiguration. Hun håndterede et revisionsproblem.
Virksomheden var allerede certificeret efter ISO/IEC 27001:2022. Bestyrelsen efterspurgte GDPR-assurance før lancering på EU-markedet. Kunder inden for finansielle tjenester sendte DORA-due diligence-spørgeskemaer. Cloud- og managed service-relationer rejste NIS2-spørgsmål om forsyningskæden. Jura kunne forklare forpligtelserne. Engineering kunne pege på kryptering. Produktteamet havde ambitioner om databeskyttelse gennem design. Anvendelseserklæringen nævnte databeskyttelse og beskyttelse af PII.
Men ingen kunne vise, i én sporbar kæde, hvilke personoplysninger der fandtes, hvorfor de blev behandlet, hvem der kunne tilgå dem, hvor de var maskeret, hvilke leverandører der berørte dem, hvor længe de blev opbevaret, og hvordan en hændelse ville blive klassificeret efter GDPR, NIS2 eller DORA.
Det hul er netop grunden til, at ISO/IEC 27701:2025 og ISO/IEC 29151:2022 er vigtige. De er ikke blot databeskyttelsesmærkater. De hjælper organisationer med at omsætte løfter om databeskyttelse til revisionsklare kontroller for beskyttelse af personoplysninger. ISO/IEC 27701:2025 udvider et ISO/IEC 27001:2022-ledelsessystem for informationssikkerhed til styring af databeskyttelse. ISO/IEC 29151:2022 tilføjer praktisk vejledning i beskyttelse af personhenførbare oplysninger gennem hele deres livscyklus.
Clarysecs tilgang er at opbygge én evidensdrevet driftsmodel for databeskyttelse og sikkerhed, ikke adskilte efterlevelsessiloer. Modellen kombinerer Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls og Clarysec-politikker i ét sporbart system for GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, NIST-lignende assurance og COBIT 2019-styringsforventninger.
Hvorfor beskyttelse af personoplysninger nu er et revisionsspørgsmål på bestyrelsesniveau
Beskyttelse af personoplysninger blev tidligere behandlet som databeskyttelsesteamets ansvar. I dag er det et spørgsmål om tillid, robusthed og regulatorisk ansvar på bestyrelsesniveau.
GDPR er fortsat grundlaget for beskyttelse af personoplysninger i Europa og uden for Europa. Forordningen definerer personoplysninger, behandling, dataansvarlig, databehandler, modtager, tredjepart, samtykke og brud på persondatasikkerheden på måder, der påvirker SaaS-kontrakter, supportdrift, analyse, produkttelemetri, leverandørstyring og hændelseshåndtering. Principperne kræver lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. Revisionsmæssigt spørger GDPR ikke kun, om data er krypteret. Den spørger, om organisationen kan dokumentere, hvorfor data findes, og hvordan efterlevelse opnås.
NIS2 hæver barren for cybersikkerhedsledelse for væsentlige og vigtige enheder. Article 21 kræver foranstaltninger til cybersikkerhedsrisikostyring, herunder risikoanalyse, politikker for informationssystemers sikkerhed, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, håndtering af sårbarheder, vurdering af kontroleffektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring, autentifikation og sikker kommunikation. Article 23 tilføjer trinvis hændelsesrapportering, herunder en tidlig advarsel inden for 24 timer, underretning inden for 72 timer og en endelig rapport inden for én måned efter underretningen.
DORA ændrer samtalen for finansielle enheder og deres IKT-udbydere. Den finder anvendelse fra 17. januar 2025 og etablerer et harmoniseret regime for digital operationel robusthed, der omfatter styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, robusthedstest, IKT-tredjepartsrisiko, kontraktlige krav og tilsyn med kritiske IKT-tredjepartsudbydere. For mange finansielle enheder fungerer DORA som den sektorspecifikke EU-retsakt, hvor NIS2-ækvivalente forpligtelser overlapper. For SaaS- og IKT-leverandører, der betjener finansielle institutioner, opstår DORA-presset ofte gennem kontraktklausuler, kunderevisioner, krav til exitplanlægning, forpligtelser til hændelsesstøtte og robusthedstest.
ISO/IEC 27001:2022 udgør rygraden i ledelsessystemet. Den kræver kontekst, interessenter, omfang, ledelsens ansvar, politikker, roller, risikovurdering, risikobehandling, Anvendelseserklæring, intern audit, ledelsens gennemgang og løbende forbedring. Annex A omfatter kontroller, der er direkte relevante for beskyttelse af personoplysninger, herunder 5.34 Privacy and protection of PII, 5.18 Access rights, 8.11 Data masking, 5.23 Information security for use of cloud services, 8.15 Logging, 8.33 Test information, 8.24 Use of cryptography og 8.10 Information deletion.
Udfordringen er ikke, at organisationer mangler kontroller. Udfordringen er, at kontrollerne er fragmenterede. Databeskyttelsesregistre ligger hos jura. Gennemgang af adgangsrettigheder ligger hos IT. Maskeringsscripts ligger hos engineering. Leverandørkontrakter ligger hos indkøb. Bevismateriale ligger i tickets, skærmbilleder, regneark og e-mails.
ISO/IEC 27701:2025 og ISO/IEC 29151:2022 hjælper med at samle dette bevismateriale omkring styring af databeskyttelse og praksis for PII-beskyttelse. Clarysec omsætter denne struktur til en driftsmodel.
Fra ISMS til PIMS: den integrerede kontrolkæde for databeskyttelse
Et ISO/IEC 27001:2022 ISMS besvarer et centralt spørgsmål: Er informationssikkerhed styret, risikobaseret, implementeret, overvåget og forbedret?
Et Privacy Information Management System, eller PIMS, udvider spørgsmålet for personoplysninger: Bliver databeskyttelsesansvar, PII-behandlingsaktiviteter, databeskyttelsesrisici, forpligtelser for dataansvarlige og databehandlere, registreredes rettigheder og bevismateriale for databeskyttelseskontroller styret i det samme system?
ISO/IEC 27701:2025 udvider ISMS’et til databeskyttelsesstyring. ISO/IEC 29151:2022 supplerer det med praktisk vejledning i PII-beskyttelse, herunder begrænsning af indsamling, styring af videregivelse, anvendelse af maskering eller pseudonymisering, beskyttelse af overførsler, begrænsning af adgang og tilpasning af kontroller til databeskyttelsesrisiko.
| Lag | Primært spørgsmål | Typisk revisionsbevis |
|---|---|---|
| ISO/IEC 27001:2022 | Findes der et styret, risikobaseret ISMS med udvalgte og fungerende kontroller? | Omfang, interessenter, risikovurdering, risikobehandlingsplan, SoA, politikker, intern audit, ledelsens gennemgang |
| ISO/IEC 27701:2025 | Styres databeskyttelsesansvar, databeskyttelsesrisici og PII-behandlingsaktiviteter i ledelsessystemet? | Databeskyttelsesroller, register over behandlingsaktiviteter, procedurer for dataansvarlig og databehandler, databeskyttelsesrisikovurderinger, DPIA’er, proces for anmodninger fra registrerede |
| ISO/IEC 29151:2022 | Er praktiske foranstaltninger til PII-beskyttelse implementeret på tværs af datalivscyklussen? | PII-klassificering, adgangsbegrænsninger, maskering, pseudonymisering, opbevaringskontroller, sikkerhedsforanstaltninger ved overførsel, bevis for hændelser |
| GDPR | Kan organisationen dokumentere lovlig, rimelig, gennemsigtig, minimeret, sikker og ansvarlig behandling? | Registrering af behandlingsgrundlag, privatlivsmeddelelser, DPIA’er, proces for brud, databehandleraftaler, håndtering af rettigheder |
| NIS2 og DORA | Kan organisationen styre cybersikkerheds- og robusthedsrisici, herunder hændelser og leverandører? | Ledelsestilsyn, rammeværk for IKT-risiko, hændelsesklassificering, rapporteringsplaybooks, leverandørregistre, revisionsrettigheder, kontinuitetstest |
Denne lagdelte model forebygger den mest almindelige fejl i databeskyttelsesarbejde: at behandle PII som blot endnu en type følsomme data. PII medfører retlige, etiske, driftsmæssige, kontraktlige og omdømmemæssige forpligtelser. Det kræver en kontrolkæde, der starter med databevidsthed og ender med bevismateriale.
Start med databevidsthed, ikke krypteringsdiagrammer
Den mest almindelige databeskyttelsesfejl, Clarysec ser, er manglende kontekst. En virksomhed kan ikke beskytte personoplysninger, hvis den ikke ved, hvilke personoplysninger den har, hvor de befinder sig, hvilket formål de tjener, hvor længe de opbevares, eller hvem der kan tilgå dem.
Zenith Blueprint starter dette arbejde tidligt i risikostyringsfasen. I Step 9, Identifying Assets, Threats, and Vulnerabilities, instrueres organisationer i at registrere informationsaktiver i en fortegnelse og eksplicit markere personoplysninger:
“For hvert aktiv skal centrale oplysninger registreres: navn/beskrivelse, ejer, lokation og klassificering (følsomhed). Et aktiv kan f.eks. være ‘Kundedatabase – ejet af IT-afdelingen – hostet på AWS – indeholder personlige og finansielle data (høj følsomhed).’”
Den tilføjer også: “Sørg for, at aktiver med personoplysninger markeres (af hensyn til GDPR-relevans), og at kritiske serviceaktiver noteres (af hensyn til potentiel NIS2-anvendelse, hvis I er i en reguleret sektor).”
Dette er fundamentet for indførelse af ISO/IEC 27701:2025 og ISO/IEC 29151:2022. Den praktiske rækkefølge er enkel:
- Identificér systemer, datasæt, repositories, logfiler, rapporter, backups, supportværktøjer, udviklingsmiljøer og leverandører, der behandler PII.
- Tildel en ejer til hvert PII-aktiv.
- Klassificér PII efter følsomhed, forretningsformål, behandlingsgrundlag, behandlingsrolle og krav til opbevaring.
- Knyt hvert PII-aktiv til trusler, sårbarheder, risikoscenarier og regulatoriske forpligtelser.
- Vælg kontroller, tildel bevismateriale og overvåg udførelsen over tid.
Clarysec-politikker gør dette operationelt. SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME fastslår:
“Koordinatoren for databeskyttelse skal vedligeholde et register over alle behandlingsaktiviteter vedrørende personoplysninger, herunder datakategorier, formål, behandlingsgrundlag og opbevaringsperioder”
Fra afsnittet ‘Styringskrav’, politikklausul 5.2.1.
For enterprise-organisationer fastsætter Data Protection and Privacy Policy Data Protection and Privacy Policy en streng dataminimeringsregel:
“Kun data, der er nødvendige for et specifikt, legitimt forretningsformål, må indsamles og behandles.”
Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.2.1.
Disse klausuler omsætter GDPR-ansvarlighed til daglig drift. De understøtter også styring af databeskyttelse og PII-beskyttelse, fordi de tvinger organisationen til at definere, hvilke data der findes, hvorfor de findes, og om de er nødvendige.
De tre kontroller, der gør PII-beskyttelse reel
Tre ISO/IEC 27001:2022 Annex A-kontroller afgør ofte, om PII-beskyttelse kan forsvares ved revision: 5.34 Privacy and protection of PII, 8.11 Data masking og 5.18 Access rights.
5.34 Privacy and protection of PII
Kontrol 5.34 er governance-knudepunktet. I Zenith Controls behandles 5.34 som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, med Identify- og Protect-cybersikkerhedskoncepter samt operationelle kapabiliteter inden for informationsbeskyttelse og juridisk efterlevelse.
Zenith Controls tydeliggør afhængigheden:
“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 PII den har og hvor, hvilket er det første skridt til at beskytte dem.”
Kontrol 5.34 afhænger af 5.9 Inventory of information and other associated assets, fordi PII ikke kan beskyttes, hvis de ikke kan findes. Den hænger også sammen med 5.23 Information security for use of cloud services, fordi de fleste PII nu findes i cloudplatforme, SaaS-værktøjer, analysemiljøer og managed services.
For højrisikobehandling kræver enterprise-udgaven af Data Protection and Privacy Policy:
“Trusselmodellering og konsekvensanalyser vedrørende databeskyttelse (DPIA’er) er obligatoriske for højrisikobehandlingssystemer.”
Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.3.4.
Denne klausul er afgørende. Den gør databeskyttelse til en design- og risikostyringsaktivitet, ikke en juridisk gennemgang i sidste øjeblik.
8.11 Data masking
Kontrol 8.11 er det direkte svar på Sarahs eksponering af stagingdatabasen. Zenith Controls beskriver 8.11 som en forebyggende fortrolighedskontrol under informationsbeskyttelse. Den forbinder 8.11 med 5.12 Classification of information, fordi beslutninger om maskering afhænger af følsomhed, med 5.34, fordi maskering understøtter databeskyttelse, og med 8.33 Test information, fordi testmiljøer ikke bør eksponere reelle PII.
Data Masking and Pseudonymization Policy Data Masking and Pseudonymization Policy gør reglen eksplicit:
“Reelle personoplysninger må ikke anvendes i udviklings-, test- eller stagingmiljøer. I stedet skal der anvendes maskerede eller pseudonymiserede data, som skal genereres fra forhåndsgodkendte transformationsskabeloner.”
Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.3.
For SMV’er tilføjer Data Masking and Pseudonymization Policy-sme Data Masking and Pseudonymization Policy - SME et centralt krav til sikkerhed og bevismateriale:
“Adgang til nøgler skal være krypteret, adgangsstyret og logget.”
Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.2.1.3.
Det er vigtigt, fordi pseudonymisering kun reducerer risiko, når transformationslogik, nøgler og re-identifikationsveje er under kontrol.
5.18 Access rights
Kontrol 5.18 er den operationelle kerne i least privilege. Zenith Controls behandler den som forebyggende, knyttet til fortrolighed, integritet og tilgængelighed og placeret under identitets- og adgangsstyring. Den forbinder 5.18 med 5.15 Access control, 5.16 Identity management og 8.2 Privileged access rights.
SME Data Classification and Labeling Policy-sme Data Classification and Labeling Policy - SME fastslår:
“Adgang skal begrænses til specifikt autoriserede brugere med need-to-know.”
Fra afsnittet ‘Styringskrav’, politikklausul 5.2.1.
Enterprise-udgaven af Data Classification and Labeling Policy Data Classification and Labeling Policy tilføjer klassificeringsbaselinen:
“Alle informationsaktiver skal have en klart tildelt klassificering på tidspunktet for oprettelse eller onboarding. Hvis der ikke foreligger en eksplicit klassificering, skal aktiver som standard klassificeres som ‘Fortrolig’, indtil de er formelt gennemgået.”
Fra afsnittet ‘Styringskrav’, politikklausul 5.4.
Tilsammen udgør disse kontroller den praktiske kæde for PII-beskyttelse: kend PII, klassificér dem, begræns adgang, maskér dem hvor fuld identitet ikke er nødvendig, beskyt nøgler, log adgang og opbevar bevismateriale.
Opbyg sporbarhed gennem Anvendelseserklæringen
Et ledelsessystem for databeskyttelse bliver revisionsklart, når det kan dokumentere sporbarhed. Zenith Blueprint, risikostyringsfasen, Step 13, Risk Treatment Planning and Statement of Applicability, beskriver Anvendelseserklæringen som et brobyggende dokument:
“SoA’en er i praksis et brobyggende dokument: den forbinder jeres risikovurdering/-behandling med de faktiske kontroller, I har. Når I udfylder den, dobbelttjekker I også, om I har overset kontroller.”
Dette koncept er centralt for beredskab til ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 og DORA. Hver PII-kontrol skal kunne spores fra krav til risiko, fra risiko til kontrol, fra kontrol til ejer, fra ejer til bevismateriale og fra bevismateriale til gennemgang.
| Sporbarhedselement | Eksempel for PII i kundesupport | Forventet bevismateriale |
|---|---|---|
| PII-aktiv | Support-sagsstyringsplatform med kundenavne, e-mailadresser, logfiler og vedhæftede filer | Post i aktivregister, ejer, cloudlokation, klassificering |
| Behandlingsformål | Kundesupport og servicedialognostik | Register over behandlingsaktiviteter, behandlingsgrundlag, opbevaringsperiode |
| Risikoscenarie | Supportmedarbejder eller udvikler tilgår for omfattende kundedata | Post i risikoregister, sandsynlighed, konsekvens, ejer |
| Kontrolvalg | 5.34 PII-beskyttelse, 5.18 adgangsrettigheder, 8.11 maskering, 8.15 logning, 5.23 cloudstyring | SoA, adgangspolitik, maskeringsstandard, logningskonfiguration |
| Operationelt bevismateriale | Rollebaseret adgang, maskerede eksporter, kvartalsvis adgangsgennemgang, alarmering ved bulk-downloads | Registreringer af adgangsgennemgang, DLP-alarmer, logfiler, sagsbevismateriale |
| Regulatorisk kortlægning | GDPR-ansvarlighed og sikkerhed, NIS2-risikostyring, DORA IKT-risiko og leverandørkrav | Efterlevelsesmatrix, hændelsesplaybook, leverandørkontraktregister |
| Bevismateriale for gennemgang | Konstatering fra intern audit lukket, handling fra ledelsens gennemgang accepteret | Auditrapport, korrigerende handling, referat fra ledelsens gennemgang |
ISO/IEC 27005:2022 understøtter denne risikobaserede tilgang ved at fremhæve krav fra interessenter, fælles risikokriterier, ansvarlige risikoejere, gentagelig risikovurdering, risikobehandling, kontrolvalg, tilpasning til Anvendelseserklæringen, godkendelse af restrisiko, overvågning og løbende forbedring. PII-beskyttelse skal være en levende risikocyklus, ikke en engangsøvelse i GDPR-dokumentation.
Ret det risikable regneark og stagingdatabasen
Sarahs hændelse kan omsættes til en gentagelig kontrolpakke, hvis afhjælpningen håndteres systematisk.
| Trin | Handling | Clarysec-resultat for bevismateriale |
|---|---|---|
| 1 | Registrér stagingdatabasen og regnearket som PII-aktiver | Poster i aktivfortegnelse med ejer, lokation, klassificering, PII-kategorier, formål og opbevaring |
| 2 | Opdatér behandlingsaktiviteten | Registerpost, der viser datakategorier, behandlingsgrundlag, formål og opbevaringsperiode |
| 3 | Klassificér filerne og datasættene | Fortrolig eller højere klassificering anvendes som standard, indtil formel gennemgang er gennemført |
| 4 | Fjern reelle PII fra ikke-produktionsmiljø | Maskeret eller pseudonymiseret datasæt genereret fra godkendte transformationsskabeloner |
| 5 | Begræns og gennemgå adgang | Need-to-know-tilladelser, tilbagekaldelse af overdreven adgang, registrering af adgangsgennemgang |
| 6 | Beskyt transformationslogik og nøgler | Krypteret, adgangsstyret og logget nøgleadgang |
| 7 | Indsaml bevismateriale centralt | Aktivpost, risikopost, adgangsgennemgang, dokumentation for sletning, maskeringsgodkendelse og lukning af sag |
| 8 | Opdatér SoA og risikobehandlingsplan | Risikoscenarie knyttet til 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 og leverandørkontroller |
| 9 | Beslut, om en DPIA er påkrævet | DPIA eller dokumenteret begrundelse for beslutninger om højrisikobehandling |
| 10 | Registrér læringspunkter | Opdateret træning, regler for sikker udvikling, eksportkontroller, DLP-overvågning og vejledning om testdata |
Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy - SME fastslår:
“Alt bevismateriale skal opbevares i en central revisionsmappe.”
Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.2.1.
Information Security Policy Information Security Policy gør den bredere revisionsforventning eksplicit:
“Alle implementerede kontroller skal kunne revideres, være understøttet af dokumenterede procedurer og opbevaret bevismateriale for udførelsen.”
Fra afsnittet ‘Krav til implementering af politikken’, politikklausul 6.6.1.
Disse to klausuler er forskellen mellem at have en kontrol og at kunne dokumentere den.
Tværgående efterlevelseskortlægning for ét PII-kontrolsæt
PII-beskyttelse bliver lettere at forsvare, når den er kortlagt på tværs af rammeværker, før revisoren spørger.
| Tema for PII-beskyttelse | GDPR-relevans | Relevans for ISO/IEC 27001:2022, ISO/IEC 27701:2025 og ISO/IEC 29151:2022 | NIS2-relevans | DORA-relevans | NIST- og COBIT 2019-revisionsvinkel |
|---|---|---|---|---|---|
| PII-fortegnelse og register over behandlingsaktiviteter | Ansvarlighed, behandlingsgrundlag, formålsbegrænsning, opbevaringsbegrænsning | ISMS-kontekst, 5.9 aktivfortegnelse, styring af databeskyttelse, PII-beskyttelse | Asset management og risikoanalyse | Bevidsthed om IKT-aktiver og serviceafhængigheder | Bevis for Identify-funktionen og styring af informationsaktiver |
| Adgangsrettigheder og least privilege | Integritet og fortrolighed, adgang begrænset efter rolle | 5.15 adgangsstyring, 5.16 identitetsstyring, 5.18 adgangsrettigheder, 8.2 rettigheder til privilegeret adgang | Adgangsstyring, HR-sikkerhed, autentifikation | IKT-risikokontroller og tilsyn med privilegeret adgang | Håndhævelse af adgang, ejerskab, ansvar og overvågning |
| Maskering og pseudonymisering | Dataminimering, databeskyttelse gennem design, behandlingssikkerhed | 5.12 klassificering, 5.34 PII-beskyttelse, 8.11 datamaskering, 8.33 testinformation | Cyberhygiejne og sikker udvikling | Sikker test, reduktion af datatab, operationel robusthed | Test af tekniske sikkerhedsforanstaltninger og pålidelig kontroludførelse |
| Hændelsesklassificering og rapportering | Vurdering og underretning ved brud på persondatasikkerheden | Hændelsesplanlægning, vurdering af hændelser, respons, indsamling af bevismateriale | Tidlig advarsel inden for 24 timer, underretning inden for 72 timer, endelig rapport | Klassificering og rapportering af større IKT-relaterede hændelser | Eskaleringskriterier, beslutningslogfiler, rodårsag, afhjælpning |
| Leverandør- og cloudbehandling | Databehandlerforpligtelser, overførsler, kontrakter | 5.21 IKT-forsyningskæde, 5.23 cloudtjenester, 5.31 juridiske og kontraktlige krav | Sikkerhed i forsyningskæden | IKT-tredjepartsrisiko, revisionsrettigheder, exit og overgang | Tredjepartsstyring, assurance og ledelsens ansvar |
Her er Zenith Controls særlig nyttig. For 5.34 kortlægger den PII-beskyttelse til aktivfortegnelse, datamaskering og cloudstyring. For 8.11 kortlægger den maskering til klassificering, databeskyttelse og testinformation. For 5.18 kortlægger den adgangsrettigheder til adgangsstyring, identitetsstyring og privilegeret adgang. Disse relationer gør det muligt for et team at forklare ikke blot, at en kontrol findes, men hvorfor den findes, og hvilke tilstødende kontroller der skal fungere sammen med den.
Hvordan forskellige revisorer tester den samme PII-kontrol
En enkelt kontrol, f.eks. 8.11 Data masking, vil blive undersøgt forskelligt afhængigt af revisionsvinklen.
| Revisortype | Primært fokus | Forventet bevismateriale |
|---|---|---|
| ISO/IEC 27001:2022- og ISO/IEC 27701:2025-revisor | Integration mellem ISMS og PIMS, risikobehandling, SoA-nøjagtighed | Risikovurdering, SoA-post, maskeringspolitik, ændringsregistreringer, resultater fra intern audit |
| GDPR- eller databeskyttelsesmyndighedsgennemgang | Databeskyttelse gennem design, minimering, ansvarlighed | Register over behandlingsaktiviteter, behandlingsgrundlag, DPIA, bevismateriale for pseudonymisering, opbevaringslogik |
| NIS2-assessor | Sikker udvikling, hændelsesforebyggelse, governance | Procedure for sikker udvikling, udviklertræning, bevismateriale for hændelsesafhjælpning, gennemgang af kontroleffektivitet |
| DORA-kunde eller -revisor | Digital operationel robusthed og tredjepartsrisiko | Bevis for test af kritiske applikationer, leverandørkontraktklausuler, forpligtelser til hændelsesstøtte, planlægning af genopretning og exit |
| NIST-lignende eller COBIT 2019-gennemgang | Kontroldesign, udførelse, ejerskab, overvågning | Kontrolansvarlig, metrikker, repository for revisionsbevis, ledelsesrapportering, korrigerende handlinger |
En ISO/IEC 27001:2022-revisor starter med ledelsessystemlogik. Er PII omfattet af omfanget? Er krav fra interessenter identificeret? Vurderes databeskyttelsesrisici ud fra definerede kriterier? Er kontroller valgt gennem risikobehandling? Er SoA’en nøjagtig? Dækker interne audits og ledelsens gennemgang PII-relaterede kontroller?
En databeskyttelsesgennemgang starter med ansvarlighed. Hvilke personoplysninger behandles? Hvad er behandlingsgrundlaget? Er de registrerede informeret? Er behandlingen begrænset til et specifikt formål? Er højrisikoaktiviteter vurderet? Er databehandlere styret?
En NIS2-fokuseret assessor starter med governance og cybersikkerhedsrisikostyring. Godkender og fører ledelsen tilsyn med foranstaltninger? Er håndtering af hændelser, kontinuitet, leverandørsikkerhed, adgangsstyring, aktivstyring, sikker udvikling og vurdering af kontroleffektivitet integreret?
En DORA-kunde eller -revisor spørger, om styring af IKT-risiko er dokumenteret, bestyrelsesstyret, proportional og understøttet af kontrakter. Hvis PII behandles i tjenester, der understøtter finansielle enheder, kan man forvente spørgsmål om hændelsesassistance, lokationer for databehandling, genopretning, revisionsrettigheder, serviceniveauer, ophør og exit.
En COBIT 2019- eller ISACA-lignende reviewer tester styringsmæssig sammenhæng. Hvem ejer PII-risikoen? Hvilket styringsorgan modtager rapportering? Er ansvar tildelt? Overvåges leverandører? Spores afvigelser? Bruges metrikker til beslutningstagning? Er restrisiko formelt accepteret?
Én evidensmodel kan tilfredsstille alle disse vinkler, men kun hvis kontrolsystemet er designet til sporbarhed fra starten.
Almindelige revisionskonstateringer i programmer for PII-beskyttelse
Organisationer, der går efter beredskab til ISO/IEC 27701:2025 eller ISO/IEC 29151:2022 uden et integreret værktøjssæt, ser ofte de samme konstateringer.
| Konstatering | Hvorfor det er vigtigt | Clarysec-afhjælpning |
|---|---|---|
| PII-fortegnelsen udelader logfiler, backups, analyseeksporter eller vedhæftede filer i support | Skjulte PII kan ikke beskyttes eller slettes pålideligt | Udvid Step 9-aktivfortegnelsen og registeret over behandlingsaktiviteter til at omfatte alle PII-lokationer |
| Testmiljøer anvender produktionsdata | Reelle PII eksponeres, hvor de ikke er nødvendige | Håndhæv maskeringspolitikken og godkendte transformationsskabeloner |
| Gennemgang af adgangsrettigheder er generisk og fokuserer ikke på PII-repositories | Overdreven adgang forbliver uopdaget | Kortlæg 5.18 adgangsrettigheder til PII-aktivejere og bevismateriale for periodisk gennemgang |
| Behandlingsgrundlaget er dokumenteret, men ikke knyttet til systemer eller opbevaring | GDPR-ansvarlighed kan ikke dokumenteres | Tilføj felter for behandlingsgrundlag og opbevaring til registeret over behandlingsaktiviteter og aktivfortegnelsen |
| Leverandørkontrakter mangler datalokation, hændelsesassistance, revisionsrettigheder eller exitbestemmelser | Mangler i leverandørassurance efter DORA, NIS2 og GDPR består | Afstem leverandør-due diligence og kontrakter med IKT-tredjeparts- og cloudstyring |
| Hændelsesplaybooks skelner ikke mellem sikkerhedshændelser og brud på persondatasikkerheden | Rapporteringsfrister kan blive overskredet | Opbyg klassificeringstræer for rapporteringsudløsere efter GDPR, NIS2 og DORA |
| Bevismateriale er spredt på tickets, drev, skærmbilleder og e-mail | Revisionsberedskab svigter, selv hvor kontrollerne fungerer | Brug centrale revisionsmapper og standarder for navngivning af bevismateriale |
Disse konstateringer er ikke papirarbejdsproblemer. De er problemer i driftsmodellen. ISO/IEC 27701:2025 og ISO/IEC 29151:2022 løser dem ikke, medmindre databeskyttelsesstyring, sikkerhedskontroller og styring af bevismateriale er indlejret i normale arbejdsgange.
Hvad ledelsen bør spørge om før næste revision
Før organisationen går efter beredskab til ISO/IEC 27701:2025, implementering af ISO/IEC 29151:2022 eller en kundeassessment efter GDPR, NIS2 eller DORA, bør ledelsen stille ti direkte spørgsmål:
- Har vi et komplet register over PII-behandlingsaktiviteter, herunder datakategorier, formål, behandlingsgrundlag og opbevaring?
- Er PII-aktiver markeret i aktivfortegnelsen, herunder logfiler, backups, eksporter, analyseværktøjer og supportvedhæftninger?
- Tildeles dataklassificeringer ved oprettelse eller onboarding, hvor ikke-gennemgåede aktiver som standard klassificeres som Fortrolig?
- Kan vi dokumentere, at adgang til PII er begrænset til autoriserede brugere med need-to-know?
- Anvender udviklings-, test- og stagingmiljøer maskerede eller pseudonymiserede data i stedet for reelle personoplysninger?
- Er maskeringsskabeloner godkendt, og er nøgler beskyttet, adgangsstyret og logget?
- Forbinder SoA’en PII-risici med kontroller og regulatoriske forpligtelser?
- Gennemgås cloud- og leverandørkontrakter for datalokation, sikkerhed, hændelsesstøtte, revisionsrettigheder, genopretning og exit?
- Kan vores hændelsesproces klassificere brud på persondatasikkerheden efter GDPR, væsentlige hændelser efter NIS2 og større IKT-relaterede hændelser efter DORA?
- Opbevares bevismateriale centralt og på en måde, som en revisor kan følge?
Hvis svaret på et af disse spørgsmål er uklart, er organisationen endnu ikke revisionsklar.
Gør PII-beskyttelse dokumenterbar
Sarahs sene hændelse kunne have udviklet sig til et fragmenteret efterlevelseskapløb. I stedet kan den blive udgangspunktet for en stærkere driftsmodel: et ISO/IEC 27001:2022 ISMS udvidet til databeskyttelse gennem ISO/IEC 27701:2025, styrket af praksis fra ISO/IEC 29151:2022 og kortlagt til GDPR, NIS2, DORA, NIST-lignende assurance og COBIT 2019-styringsforventninger.
Det er den reelle værdi af revisionsklar PII-beskyttelse. Den afhænger ikke af at finde det rigtige regneark, før revisoren ankommer. Den afhænger af et system, der allerede ved, hvor PII er, hvorfor de findes, hvordan de beskyttes, hvem der er ansvarlig, hvilke leverandører der er involveret, og hvor bevismateriale findes.
Start med Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint for at strukturere implementeringen. Brug Zenith Controls: The Cross-Compliance Guide Zenith Controls til at kortlægge PII-beskyttelse på tværs af ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST-lignende assurance og COBIT 2019-styringsforventninger. Operationalisér arbejdet med Clarysec-politikker, herunder Data Protection and Privacy Policy Data Protection and Privacy Policy, Data Masking and Pseudonymization Policy Data Masking and Pseudonymization Policy, Data Classification and Labeling Policy Data Classification and Labeling Policy, Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy - SME og Information Security Policy Information Security Policy.
Hvis din næste kunderevision, GDPR-gennemgang, NIS2-beredskabsprojekt eller DORA-leverandørassessment nærmer sig, så vent ikke på, at et brud afslører hullerne. Download Clarysec-værktøjssættene, anmod om en demo, eller planlæg en vurdering af PII-beskyttelse, og opbyg et databeskyttelsesprogram, der ikke blot er compliant, men kan forsvares.
Frequently Asked Questions
About the Author
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
