Styring af PII-adgang for ISO 27701:2025 og GDPR

Den eksterne revisors spørgsmål hang i luften og lød umiddelbart enkelt.

“Kan du vise mig loggen over gennemgang af jeres supportteams adgang til produktions-PII for det seneste kvartal?”

For Anya, CISO hos Medtelligence, en hurtigt voksende sundhedsteknologisk SaaS-leverandør, var dette sandhedens øjeblik. Medtelligence fungerer som PII-databehandler for hospitaler og behandler følsomme patientdata på en cloudplatform. Virksomheden havde stærk autentifikation, definerede roller og et modent udviklingsteam. Men revisoren spurgte ikke, om der fandtes en loginfunktion. Han bad om bevis for, at adgang til personoplysninger blev styret over tid.

Han ville se, hvem der kunne tilgå produktions-PII, hvorfor de havde adgang, hvornår adgangen var godkendt, om den fortsat var nødvendig, om supportaktivitet blev logget, og om unødvendige rettigheder var blevet fjernet.

Anya åbnede IAM-konsollen. Der var supportteknikere, databaseadministratorer, en integrationsservicekonto, en leverandør af managed services, to nødroller til break-glass-adgang og en tidligere kontrahent, som stadig lå i en gruppe, fordi offboarding-ticketen var blevet lukket, før adgangsrettigheden blev fjernet. HR viste, at personen var fratrådt seks uger tidligere. Regnearket for gennemgang af adgangsrettigheder stod som “afventer”. SIEM havde logfiler, men ingen havde kortlagt, hvilke hændelser der dokumenterede adgang til PII.

Det er her, styring af databeskyttelse bliver konkret.

Efter GDPR skal personoplysninger behandles med integritet og fortrolighed og beskyttes mod uautoriseret eller ulovlig behandling, hændeligt tab, tilintetgørelse eller beskadigelse gennem passende tekniske og organisatoriske foranstaltninger. GDPR gør også ansvarlighed eksplicit: den dataansvarlige skal kunne dokumentere efterlevelse. ISO/IEC 27701:2025 omsætter denne ansvarlighed til et ledelsessystem for databeskyttelse, eller PIMS, hvor adgang til PII ikke længere er en teknisk eftertanke. Det bliver en styret livscyklus på tværs af roller, databehandlere, cloudplatforme, medarbejdere, privilegerede administratorer, logfiler, gennemgange, kontrakter og bevismateriale.

For mange organisationer er problemet ikke, at de mangler adgangsstyring. Problemet er, at de ikke konsekvent kan dokumentere styring af PII-adgang på tværs af ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 og COBIT 2019.

Styring af PII-adgang er ikke bare IAM

Et traditionelt IAM-program spørger: “Kan de rigtige brugere tilgå de rigtige systemer?”

Et modent ISO/IEC 27701:2025 PIMS stiller sværere spørgsmål:

• Hvilke systemer behandler PII?
• Hvilke roller kræver adgang til hvilke kategorier af PII?
• Handler organisationen som PII-dataansvarlig, PII-databehandler, fælles dataansvarlig eller underdatabehandler?
• Er adgangen begrænset af formål, dokumenteret forretningsbehov og princippet om mindst privilegium?
• Bliver privilegerede handlinger logget og gennemgået?
• Kan organisationen dokumentere, at adgang for databehandlere og underdatabehandlere er kontraktligt reguleret?
• Indgår cloud-supportveje, tenant-isolering, eksporter og administrative handlinger i bevismaterialet?
• Bliver adgangsbeslutninger gennemgået efter onboarding, rolleændring, hændelse, offboarding og væsentlig systemændring?

Derfor er PII-sikkerhed og adgangsstyring en naturlig bro mellem ISO/IEC 27701:2025 og GDPR. GDPR fastlægger rammen for juridisk ansvarlighed. ISO/IEC 27701:2025 operationaliserer styring af databeskyttelse for dataansvarlige og databehandlere. ISO/IEC 27001:2022 leverer ISMS-motoren for risikostyring. ISO/IEC 27002:2022 leverer kontrolarkitekturen, herunder databeskyttelse og beskyttelse af PII, adgangsstyring, adgangsrettigheder, logning, cloudtjenester, leverandørrelationer, klassificering, sletning, maskering og kryptografi.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap placerer dette i fasen Kontroller i praksis. I trin 23, som dækker organisatoriske kontroller 5.19 til 5.37, beskrives ISO/IEC 27002:2022-kontrol 5.34, Privacy and Protection of PII, som et tillidsspørgsmål og ikke blot et dataspørgsmål:

Personhenførbare oplysninger (PII) er ikke bare endnu en datatype; de er en dybt følsom repræsentation af tillid. Navne, adresser, ID’er, helbredsoplysninger og finansielle oplysninger fortæller en historie om virkelige mennesker.

Det samme afsnit giver det praktiske fundament: beskyttelse af privatliv starter med databevidsthed. En organisation skal vide, hvilke PII den indsamler, hvor de findes, hvorfor de behandles, og hvem der kan tilgå dem.

Efterlevelsespres bag adgangsstyring til PII

Styring af PII-adgang er ikke længere et spørgsmål inden for ét enkelt framework. Organisationer som Medtelligence opererer i krydsfeltet mellem databeskyttelsesregulering, cybersikkerhedslovgivning, operationel robusthed, assurance over for kunder og sikkerhedscertificering.

GDPR Article 5 kræver, at personoplysninger behandles efter principperne om lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning, integritet og fortrolighed. Article 5(2) indfører ansvarlighed: den dataansvarlige er ansvarlig for og skal kunne dokumentere efterlevelse. Article 32 kræver derefter passende tekniske og organisatoriske foranstaltninger for behandlingssikkerhed.

NIS2 Article 21 kræver, at væsentlige og vigtige enheder træffer passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger til styring af cybersikkerhedsrisici. Minimumsområderne omfatter risikoanalyse, sikkerhedspolitikker, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, vurdering af effektivitet, cyberhygiejne og uddannelse, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver samt, hvor relevant, multifaktorautentifikation eller løbende autentifikation og sikker kommunikation. Article 20 placerer desuden ansvaret hos ledelsesorganer for at godkende og føre tilsyn med foranstaltninger til styring af cybersikkerhedsrisici.

DORA finder anvendelse fra 17. januar 2025 på en bred gruppe af finansielle enheder og etablerer et sektorspecifikt regime for operationel robusthed. Det dækker styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed, informationsdeling, IKT-tredjepartsrisiko og kontraktlige ordninger med IKT-tredjepartsudbydere. For finansielle enheder og IKT-tjenesteudbydere, der understøtter dem, er adgangsstyring ikke kun et databeskyttelsesspørgsmål. Det er en del af operationel robusthed.

ISO/IEC 27001:2022 samler disse forpligtelser i et risikobaseret ledelsessystem. Clauses 6.1.1 til 6.1.3 kræver, at organisationer håndterer risici og muligheder, definerer en proces for informationssikkerhedsrisikovurdering, identificerer risici for fortrolighed, integritet og tilgængelighed, evaluerer risici, vælger behandlingsmuligheder, fastlægger kontroller, sammenholder valgte kontroller med Annex A, dokumenterer Statement of Applicability, indhenter godkendelse fra risikoejeren og accepterer restrisici. Clauses 8.2 og 8.3 kræver risikovurderinger med planlagte intervaller eller efter væsentlige ændringer samt implementering af risikobehandlingsplanen med dokumenterede resultater.

For styring af PII betyder det, at adgangsstyring ikke er en isoleret IAM-indstilling. Det er en beslutning om risikobehandling. En rolle, der kan eksportere lønregistre, patientdata, betalingsoplysninger, identitetsdokumenter, lokationsdata eller kundesupporttransskriptioner, skal være begrundet i risikoregisteret, afspejlet i Statement of Applicability, håndhævet i IAM, logget i produktionsmiljøet, gennemgået periodisk og fjernet, når den ikke længere er påkrævet.

Clarysecs kontrolmodel: fra privatlivsløfte til bevismateriale

Clarysec behandler styring af PII-adgang som en beviskæde. Kæden starter med datafortegnelse og rolledefinition, fortsætter gennem adgangsgodkendelse og håndhævelse og slutter med overvågning, gennemgang, tilbagekaldelse og revisionsklare registreringer.

I Zenith Controls: The Cross-Compliance Guide ligger emnet primært omkring tre ISO/IEC 27002:2022-kontroller:

Revisorer accepterer sjældent “vi bruger IAM” som bevismateriale. De forventer at se, hvordan IAM-beslutninger hænger sammen med databeskyttelsesforpligtelser, systemejerskab, dataklassificering, forretningsbehov, risikobehandling, frekvens for adgangsgennemgang, logningsomfang og leverandørkontrakter.

Clarysecs Politik for PII-sikkerhed og adgangsstyring fastlægger baseline i PIMS-sprog:

[Begge] Systemejeren / applikationsansvarlig SKAL begrænse adgang til PII til godkendte roller og godkendte brugere, der er registreret eller sporbare i REG02 eller REG12, før adgang aktiveres.

Fra afsnit “4.2 Baseline for adgangsstyring”, politikklausul 4.2.1.

Markeringen “[Begge]” betyder, at kontrollen gælder, uanset om organisationen handler som PII-dataansvarlig eller PII-databehandler. Den sondring er vigtig. Dataansvarlige undlader ofte at definere formålsbaserede adgangsregler. Databehandlere undlader ofte at dokumentere, at adgang er begrænset til kundens instrukser, godkendte supportveje og kontraktligt autoriseret personale.

Den samme politik skærper kravene for følsomme PII eller PII med højt konsekvensniveau:

[Begge] Systemejeren / applikationsansvarlig SKAL gennemgå brugeradgang til systemer, der behandler PII med højt konsekvensniveau eller følsomme PII, mindst kvartalsvist og registrere resultatet af gennemgangen i REG12.

Fra afsnit “4.2 Baseline for adgangsstyring”, politikklausul 4.2.3.

Det er her, et PIMS bliver revisionsbart. Gennemgangen af adgangsrettigheder er ikke blot en e-mail fra en leder. Det er en registrering i REG12, knyttet til et system, en datakategori, en rolle, en ejer, et gennemgangsresultat og en afhjælpende foranstaltning.

Politikgrundlag: mindst privilegium, forretningsbehov og standardafvisning

Effektiv styring begynder med regler, der kan håndhæves. Før Anya kunne vise revisoren en log over adgangsgennemgang, skulle hun vise, at kravet om gennemgang af adgangsrettigheder var formelt etableret.

Clarysecs SME Politik for adgangsstyring - SME fastlægger princippet:

Denne politik håndhæver princippet om mindst privilegium og kræver, at adgang begrænses til det minimum, der er nødvendigt for at udføre arbejdsfunktioner.

Fra afsnit “Formål”, politikklausul 1.3.

SME Databeskyttelses- og privatlivspolitik - SME knytter adgang til forretningsbehov:

Brugeradgang til personoplysninger skal begrænses til roller med et dokumenteret forretningsbehov.

Fra afsnit “Styringskrav”, politikklausul 5.3.2.

For større organisationer udtrykker Databeskyttelses- og privatlivspolitik kontrolforventningen som et systemkrav:

Alle systemer skal som standard håndhæve adgang efter princippet om mindst privilegium.

Fra afsnit “Krav til implementering af politikken”, politikklausul 6.3.1.

Sondringen er vigtig. En mindre virksomhed kan have behov for en let, men eksplicit registrering af forretningsbehov. En større organisation har behov for håndhævelse på systemniveau, periodisk gennemgang, funktionsadskillelse, styring af privilegeret adgang og bevismateriale bevaret til intern revision, assurance over for kunder, regulatoriske forespørgsler og undersøgelse af brud.

Livscyklussen for PII-adgang: godkendelse, brug, gennemgang og tilbagekaldelse

Den mest almindelige fejl ved PII-adgang er ikke den oprindelige godkendelse. Det er, at adgangen består for længe.

Zenith Blueprint forklarer i fasen Kontroller i praksis, trin 22, ISO/IEC 27002:2022-kontrol 5.18, Access Rights, på denne måde:

Kontrol 5.18 sikrer, at adgangsrettigheder ikke kun tildeles korrekt, men også gennemgås, justeres og tilbagekaldes på en kontrolleret og sporbar måde.

Den beskriver derefter velkendte scenarier: en nyansat får adgang, skifter rolle og beholder gamle rettigheder; en tidligere administrator fratræder, men et token forbliver aktivt; en kontrahentkonto udløber på papiret, men ikke i IAM. Det er netop disse svagheder, der bliver til GDPR-sikkerhedshændelser, når PII er involveret.

Clarysecs SME Politik for styring af brugerkonti og privilegier - SME fastlægger en baseline-kadence:

En gennemgang af alle brugerkonti og privilegier skal udføres hver sjette måned.

Fra afsnit “Krav til implementering af politikken”, politikklausul 6.4.1.

For større miljøer strammer Politik for styring af brugerkonti og privilegier styringsrytmen:

Kvartalsvise gennemgange af alle brugerkonti og tilknyttede privilegier skal gennemføres af IT-sikkerhed i samarbejde med afdelingsledere.

Fra afsnit “Krav til implementering af politikken”, politikklausul 6.5.1.

En praktisk livscyklus for PII-adgang bør omfatte:

1. Klassificér systemet og PII-kategorierne.
2. Definér godkendte roller og dokumenteret forretningsbehov.
3. Kortlæg roller til behandlingsformål.
4. Godkend adgang før aktivering.
5. Håndhæv princippet om mindst privilegium, funktionsadskillelse og stærk autentifikation.
6. Log autentifikation, adgang, eksport, konfiguration og privilegerede handlinger.
7. Gennemgå adgang efter en risikobaseret kadence.
8. Fjern adgang ved rolleændring, fratrædelse, projektlukning, kontraktudløb eller kundens instruks.
9. Bevar bevismateriale i PIMS-registeret og revisionssporet.

Dette er ikke bureaukrati. Det er sådan, en organisation dokumenterer, at PII-adgang er styret gennem design, som standard og med bevismateriale.

Et praktisk eksempel: den kvartalsvise gennemgang af PII-adgang

Anyas revision lykkedes, da hun flyttede samtalen fra politikerklæringer til bevismateriale.

Først henviste hun til Politik for PII-sikkerhed og adgangsstyring, klausul 4.2.3, som krævede kvartalsvis gennemgang af adgang til PII med højt konsekvensniveau eller følsomme PII og registrering af gennemgangsresultatet i REG12.

Derefter gennemgik hun det foregående kvartal med revisoren:

• IT genererede en liste over alle brugere, grupper, privilegerede roller, servicekonti, leverandørkonti, break-glass-roller og supportrettigheder til produktionsdatabasen med patientdata.
• Listen blev sendt til den applikationsansvarlige, Head of Customer Success, som ejede supportteamets driftsmæssige behov.
• Den applikationsansvarlige gennemgik listen linje for linje i forhold til aktuel rolle, ansvar for kundesupport og behandlingsformål.
• To supportagenter, der havde skiftet team, blev markeret til tilbagekaldelse.
• Der blev oprettet en ticket i IT-service management-systemet, knyttet til adgangsgennemgangen, tildelt en SLA og lukket efter tilbagekaldelsen.
• REG12 blev opdateret med gennemgangsregistreringen, godkenderen, undtagelser, afhjælpningsticket, lukningsbevismateriale og næste gennemgangsdato.

Resultatet var en lukket beviskæde. Anya sagde ikke blot, at Medtelligence brugte princippet om mindst privilegium. Hun viste politikkravet, ansvarlig ejer, adgangsliste, gennemgangsbeslutning, korrigerende handling og gennemført tilbagekaldelse.

Det er forskellen mellem adgangsstyring og styring af adgang.

Leverandør- og databehandleradgang: blindvinklen i PIMS-revisioner

Mange risici for uautoriseret adgang opstår via support, outsourcing, integrationspartnere, leverandører af managed services og underdatabehandlere. En databehandler kan have fjernadgang til kunders produktionsdata. En cloududbyder kan stille supportadgangsveje til rådighed. En underdatabehandler kan vedligeholde et søgeindeks med kundeidentifikatorer. En managed security service provider kan tilgå logfiler, der indeholder personoplysninger.

Efter GDPR skal dataansvarlige anvende databehandlere, der giver tilstrækkelige garantier. Efter ISO/IEC 27701:2025 skal styring af databehandlere og underdatabehandlere operationaliseres gennem dokumenterede instrukser, kontraktkontroller, assurance og overvågning. ISO/IEC 27002:2022 understøtter dette gennem kontroller for leverandørrelationer, herunder 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements og 5.21 Managing information security in the ICT supply chain.

Zenith Blueprint, fasen Kontroller i praksis, trin 23, opsummerer områder for bevismateriale i leverandøraftaler, herunder:

✓ Ansvar for adgangsstyring, såsom hvem der kan tilgå jeres data, hvordan legitimationsoplysninger administreres, og hvilken overvågning der er etableret;

Det omfatter også fortrolighedsforpligtelser, tekniske og organisatoriske foranstaltninger, tidsfrister for hændelsesrapportering, revisionsrettigheder, kontroller for underleverandører og deaktivering af konti ved kontraktophør.

Clarysecs Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse omsætter dette til PIMS-bevismateriale på den dataansvarliges side:

[Dataansvarlig] Privacy Lead / PIMS-ansvarlig SKAL verificere, at felterne for databehandlerens kontraktkontroller i REG08 omfatter behandlingsomfang, varighed, formål, PII-kategorier, kategorier af registrerede, fortrolighed, sikkerhed, godkendelse af underdatabehandlere, bistand, revision eller assurance, tilbagelevering, sletning og ophør før godkendelse.

Fra afsnit “4.3 Kontraktkontroller og dokumenterede instrukser”, politikklausul 4.3.2.

Leverandøradgang kontrolleres også direkte i Clarysecs SME- og enterprise-leverandørpolitikker. SME Politik for tredjeparts- og leverandørsikkerhed - SME angiver:

Leverandører må kun tildeles adgang til de minimumssystemer og data, der kræves for at udføre deres funktion.

Fra afsnit “Krav til implementering af politikken”, politikklausul 6.2.1.

Enterprise Politik for tredjeparts- og leverandørsikkerhed tilføjer RBAC, gennemgang og princippet om mindst privilegium:

Leverandørpersonale skal være omfattet af rollebaseret adgangskontrol (RBAC), periodisk gennemgang af adgangsrettigheder og håndhævelse af princippet om mindst privilegium.

Fra afsnit “Krav til implementering af politikken”, politikklausul 6.3.1.

Hvis leverandøradgang kan nå PII, hører den hjemme i PIMS. Den bør fremgå af kontraktkontroller, adgangsgodkendelser, IAM-grupper, logningsomfang, gennemgangsregistreringer, offboarding-registreringer, hændelsesplaybooks og revisionsbevismateriale.

Cloudadgang til PII: delt ansvar er ikke delt ansvarlighed

Styring af cloudadgang til PII er et område, hvor organisationer ofte overvurderer udbyderen og undervurderer deres eget ansvar. Cloududbyderen kan sikre infrastrukturen, men kunden styrer stadig identiteter, roller, tenant-konfiguration, supportadgang, logfiler, krypteringsindstillinger, eksportrettigheder og beredskab for hændelseshåndtering.

Zenith Blueprint, fasen Kontroller i praksis, trin 23, formulerer det klart i sin vejledning om cloudtjenester:

Cloududbydere sikrer infrastrukturen, men I er stadig ansvarlige for jeres data, jeres konfigurationer, jeres adgangspolitikker og jeres beredskab for hændelseshåndtering.

Den advarer også:

I cloudmiljøer er synligheden kun delvis, medmindre den bevidst designes. I skal konfigurere logning, håndhæve kryptering, definere identitetsroller og overvåge aktivitet via native værktøjer eller tredjepartsintegrationer. Det er ikke en infrastrukturopgave; det er et ISMS-krav.

Clarysecs Politik for brug af cloudtjenester omsætter dette til et enterprise-adgangskrav:

Alle cloudtjenester skal håndhæve identitetsbaseret adgangsstyring i overensstemmelse med princippet om mindst privilegium.

Fra afsnit “Krav til implementering af politikken”, politikklausul 6.2.1.

For organisationer, der handler som databehandlere i cloudmiljøer, definerer Clarysecs Cloud PII Processor Policy en mere specifik PIMS-gennemgangsforpligtelse:

[Databehandler] Informationssikkerhedsansvarlig SKAL gennemgå privilegeret cloudadgang, supportadgang, kunders PII-adgang og logningsdækning i REG12 mindst kvartalsvist.

Fra afsnit “4.2 Cloudkonfiguration, tenant-isolering, adgang og logning”, politikklausul 4.2.4.

Den klausul er særligt relevant for SaaS-virksomheder, cloud-hostede platforme, administrerede datatjenester og B2B-databehandlere.

Styring af cloudadgang til PII er ikke fuldstændig, medmindre cloud-native logfiler, IAM-politikker, servicekonti, privilegerede roller, kundesupportværktøjer, API-nøgler og dataeksportfunktioner gennemgås samlet.

Logning og overvågning: PII-styringens hukommelse

Et PIMS-program for adgangsstyring uden logfiler er et løfte uden hukommelse.

Politik for PII-sikkerhed og adgangsstyring kræver, at logningsomfanget defineres før produktionsbrug eller væsentlig ændring:

[Begge] Systemejeren / applikationsansvarlig SKAL definere PII-logningsomfanget for autentifikationshændelser, adgangshændelser, privilegerede handlinger, PII-eksportaktivitet og væsentlige konfigurationsændringer i REG12 før produktionsbrug eller væsentlig ændring.

Fra afsnit “4.6 Logning og overvågning”, politikklausul 4.6.1.

SME Lognings- og overvågningspolitik - SME gør indholdet af adgangslogfiler eksplicit:

Adgangslogfiler: filadgang (særligt for følsomme data eller personoplysninger), ændringer i tilladelser, brug af delte ressourcer

Fra afsnit “Styringskrav”, politikklausul 5.4.3.

Enterprise Lognings- og overvågningspolitik fokuserer på anvendelighed ved revision:

ISMS-registeret for revisionsspor skal registrere tilgængeligheden af logdata til revisioner, undersøgelser og regulatoriske gennemgange.

Fra afsnit “Styringskrav”, politikklausul 5.4.

Dette er kritisk, fordi bevismateriale for databeskyttelse ofte skal besvare hændelsesbaserede spørgsmål:

• Hvem tilgik PII?
• Var adgangen autoriseret?
• Var adgangen knyttet til en supportticket, juridisk anmodning, driftsopgave eller kundens instruks?
• Blev data eksporteret, kopieret, ændret eller slettet?
• Blev privilegeret adgang brugt?
• Blev rettigheder ændret før eller efter adgangen?
• Indikerede aktiviteten en sikkerhedshændelse eller et brud på persondatasikkerheden?

Logfiler er ikke kun for SOC. De er PIMS-bevismateriale, assurance-dokumentation over for kunder, bevismateriale for databehandlerassurance og bevismateriale for hændelseshåndtering.

Kortlægning på tværs af efterlevelseskrav: én adgangsmodel, mange perspektiver

En svaghed i gennemgange af PII-adgang er aldrig kun én konstatering. Den kan blive til et GDPR-ansvarlighedsproblem, en ISO/IEC 27701:2025 PIMS-svaghed, en ISO/IEC 27001:2022-afvigelse, et NIS2-styringssvigt, en DORA-bekymring om robusthed, et NIST CSF 2.0-styringshul eller et COBIT 2019-procesmodenhedsproblem.

En mere detaljeret kontrolkrydsning viser, hvordan én proces for styring af PII-adgang understøtter flere krav:

Værdien af Zenith Controls er, at teams kan kortlægge disse perspektiver tilbage til det samme kontrolbevismateriale i stedet for at vedligeholde adskilte efterlevelsessiloer.

Gennemfør en 45-minutters evidenssprint om PII-adgang

En nyttig måde at teste revisionsberedskab på er at vælge ét system med højt konsekvensniveau, f.eks. en kundesupportplatform, et HR-system, en betalingsportal, en patientportal, en data lake eller en SaaS-produktionsdatabase, og gennemføre en fokuseret evidenssprint.

Trin 1: Definér konteksten for PII-behandling

Registrér i REG12:

• Systemnavn og ejer
• PII-kategorier
• Kategorier af registrerede
• Rolle som dataansvarlig eller databehandler
• Behandlingsformål
• Indikator for PII med højt konsekvensniveau eller følsomme PII
• Cloud-, leverandør- og underdatabehandlerafhængigheder

Hvis systemet involverer en databehandler, skal REG08-felterne for kontraktkontroller verificeres ved hjælp af Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse. Godkendelsen bør dække behandlingsomfang, varighed, formål, PII-kategorier, kategorier af registrerede, fortrolighed, sikkerhed, godkendelse af underdatabehandlere, bistand, revision eller assurance, tilbagelevering, sletning og ophør.

Trin 2: Udtræk adgangslisten

Eksportér alle brugere, grupper, privilegerede roller, servicekonti, supportroller, break-glass-konti, API-nøgler og leverandørkonti. Sammenhold hver adgangsrettighed med godkendte roller.

Trin 3: Bekræft mindst privilegium og formålsafstemning

Brug baseline fra Politik for PII-sikkerhed og adgangsstyring: adgang skal begrænses til godkendte roller og godkendte brugere, der er registreret eller sporbare i REG02 eller REG12 før aktivering. Hvis en bruger ikke kan spores til rolle, formål og godkendelse, er konstateringen ikke “manglende dokumentation”. Konstateringen er “PII-adgang er ikke dokumenterbart autoriseret.”

Trin 4: Verificér logningsomfang

Bekræft, at logfiler registrerer autentifikation, adgangshændelser, privilegerede handlinger, PII-eksportaktivitet og væsentlige konfigurationsændringer. Bekræft derefter, hvor logfiler opbevares, hvor længe de opbevares, hvem der kan tilgå dem, og om de er registreret i ISMS-registeret for revisionsspor til revisioner, undersøgelser og regulatoriske gennemgange.

Trin 5: Luk sløjfen

For hver undtagelse skal risikoejer, umiddelbar inddæmningshandling, permanent afhjælpning, måldato, påkrævet bevismateriale, beslutning om restrisiko og behov for vurdering af brud registreres.

Denne ene øvelse afslører som regel den reelle modenhed i styring af PII-adgang. Stærke organisationer kan svare hurtigt. Svage organisationer opdager, at databeskyttelsespolitik, IAM-konfiguration, databehandlerkontrakter, cloudlogning og revisionsbevismateriale ikke hænger sammen.

Almindelige revisionskonstateringer i styring af PII-adgang

De fleste konstateringer er forudsigelige. De opstår, når databeskyttelse, sikkerhed, jura, IT og leverandører hver især kontrollerer en del af historien, men ingen ejer den samlede livscyklus for PII-adgang.

Almindelige konstateringer omfatter:

• PII-systemer er ikke fuldt opført i PIMS-fortegnelsen.
• Adgangsroller er teknisk defineret, men ikke kortlagt til behandlingsformål.
• Følsomme PII er tilgængelige via brede driftsgrupper.
• Kvartalsvise gennemgange omfatter medarbejdere, men ikke servicekonti, API-nøgler eller leverandørbrugere.
• Cloud-supportadgang er mulig, men gennemgås ikke som PII-adgang.
• Logfiler findes, men dokumenterer ikke PII-adgang, eksport eller privilegeret aktivitet.
• Databehandlerkontrakter indeholder generiske fortrolighedsklausuler, men ikke specifikke kontroller for adgangsstyring, revision, underdatabehandlere, tilbagelevering, sletning eller ophør.
• Tidligere medarbejdere eller kontrahenter bevarer adgang via delte grupper eller ikke-administrerede tokens.
• Adgang til data warehouse er bredere end adgang til kildeapplikationen.
• Break-glass-konti findes uden gennemgang efter brug.
• Impersonering i kundesupport logges ikke med ticket-kontekst.
• Statement of Applicability omfatter adgangskontroller, men bevismaterialet viser ikke PII-specifik implementering.

Hver af disse konstateringer kan blive til et GDPR-ansvarlighedsproblem, et assurance-forhold over for kunder, en NIS2- eller DORA-styringssvaghed eller en ISO/IEC 27001:2022-afvigelse afhængigt af omfanget.

Sådan ser en moden praksis ud

En moden driftsmodel er ikke afhængig af heroiske kvartalsvise oprydninger. Den indlejrer styring af PII-adgang i den normale drift.

For det første har organisationen databevidsthed. Den ved, hvor PII findes, hvorfor de behandles, hvilken PIMS-rolle der gælder, og hvilke systemer, leverandører, cloudtjenester, logfiler, backups og eksporter der er omfattet.

For det andet er adgang rollebaseret og formålsafstemt. Rettigheder defineres ud fra godkendte roller, dokumenteret forretningsbehov, behandlingsformål og princippet om mindst privilegium.

For det tredje håndhæves kontroller teknisk. IAM, RBAC, styring af privilegeret adgang, MFA, betinget adgang, tenant-kontroller, kryptering og miljøadskillelse håndhæver politikkens forventninger.

For det fjerde er overvågning bevidst designet. Organisationen kan rekonstruere autentifikation, adgang, eksport, privilegerede handlinger, supportadgang og konfigurationsændringer, der påvirker PII.

For det femte er gennemgange risikobaserede og dokumenterede. PII med højt konsekvensniveau gennemgås mindst kvartalsvist. Leverandør- og cloud-supportadgang indgår. Undtagelser følges til lukning.

For det sjette kan bevismateriale genbruges. De samme registreringer understøtter GDPR-ansvarlighed, drift af ISO/IEC 27701:2025 PIMS, ISO/IEC 27001:2022-risikobehandling, NIS2-foranstaltninger til risikostyring, DORA-styring af IKT-risiko, NIST CSF 2.0 GOVERN-resultater og COBIT 2019-ledelsesassurance.

Det er forskellen mellem adgangsstyring som indstilling og styring af adgang som system.

Gør PII-adgang til revisionsklart bevismateriale

Hvis jeres næste revision, kundegennemgang eller regulatoriske forespørgsel begyndte i morgen med “vis mig, hvem der kan tilgå PII”, ville jeres team så kunne fremlægge bevismateriale på få minutter, eller ville det begynde at afstemme regneark?

Clarysec kan hjælpe jer med at lukke dette hul.

Start med Politik for PII-sikkerhed og adgangsstyring, afstem forpligtelser for databehandlere og cloud gennem Politik for styring af databehandlere, underdatabehandlere og tredjeparter vedrørende databeskyttelse og Cloud PII Processor Policy, og brug derefter Zenith Blueprint: An Auditor’s 30-Step Roadmap til at implementere kontroller i den rigtige rækkefølge. Brug til sidst Zenith Controls: The Cross-Compliance Guide til at kortlægge bevismateriale for PII-adgang på tværs af ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 og COBIT 2019.

Det hurtigste praktiske næste skridt er enkelt: vælg ét PII-system med højt konsekvensniveau, udfyld REG12, eksportér adgangslisten, verificér logningsomfanget, og gennemfør en gennemgang i kvartalsformat. På én session ved I, om jeres styring af PII-adgang er revisionsklar eller kun politikklar.