RoPA-kortlægning af dataflow for GDPR, NIS2 og DORA

Klokken er 09:10 en tirsdag, og CISO’en, DPO’en, den indkøbsansvarlige og driftsdirektøren sidder i samme videomøde, men ser ikke på det samme dokumentationsgrundlag.

DPO’en har en fortegnelse over behandlingsaktiviteter (RoPA), der oplister kunde-onboarding, lønudbetaling til medarbejdere, supporttickets og marketinganalyse. CISO’en har en aktivfortegnelse for cloud. Indkøb har leverandørkontrakter. Drift har et regneark for forretningskontinuitet. Finans har DORA Register of Information. Ingen kan besvare tilsynsmyndighedens mest grundlæggende sammenhængende spørgsmål:

Hvis denne betalingsonboarding-tjeneste fejler, hvilke systemer, leverandører, datakategorier, underdatabehandlere, grænseoverskridende dataoverførsler og kritiske forretningsfunktioner påvirkes så?

Det spørgsmål er den reelle efterlevelsestest i 2026.

GDPR kræver fortsat ansvarlige fortegnelser efter Article 30. NIS2 har gjort cybersikkerhed til et spørgsmål om ansvarlighed for ledelsesorganet hos væsentlige og vigtige enheder. DORA kræver, at finansielle enheder dokumenterer IKT-afhængigheder, kritiske eller vigtige funktioner, IKT-tredjepartsarrangementer, klassificering af hændelser og robusthedstest. ISO/IEC 27001:2022 giver ledelsessystemstrukturen til at holde det hele sammen, men kun hvis RoPA og kortlægning af dataflow behandles som levende governance-dokumentation og ikke som regneark hos databeskyttelsesteamet.

Hos Clarysec ser vi det samme mønster i hurtigt voksende SaaS-, fintech-, cloud-, MSP- og B2B-teknologivirksomheder. De har tilstrækkelig dokumentation til at besvare et spørgeskema, men ikke nok sammenhængende dokumentation til at stå igennem en tilsynsgennemgang, en cyberhændelse, et leverandørsvigt eller en intern revision. Problemet er sjældent mangel på oplysninger. Det er mangel på sammenhæng.

Løsningen er at gøre RoPA og kortlægning af dataflow til det fælles dokumentationslag for databeskyttelse, cyberrobusthed, leverandørstyring, cloudstyring og forretningskontinuitet.

Hvorfor RoPA og kortlægning af dataflow blev et styringsspørgsmål i 2026

RoPA blev tidligere betragtet som et databeskyttelsesartefakt. Dataflowkort blev ofte udarbejdet i forbindelse med en DPIA, cloudmigrering eller gennemgang af sikkerhedsarkitekturen og derefter efterladt til at blive forældede. Den tilgang fungerer ikke længere.

GDPR gælder bredt for behandling af personoplysninger i forbindelse med en etablering i EU og også for mange dataansvarlige eller databehandlere uden for EU, der tilbyder varer eller tjenester til personer i EU eller overvåger deres adfærd. Personoplysninger omfatter oplysninger om en identificeret eller identificerbar person. Behandling omfatter indsamling, opbevaring, brug, videregivelse, begrænsning, sletning og destruktion. En dataansvarlig fastlægger formål og hjælpemidler, mens en databehandler handler på vegne af en dataansvarlig.

En RoPA er derfor ikke blot en liste over databaser. Den er en registrering af forretningsformål, datakategorier, roller, modtagere, opbevaringsperioder, sikkerhedsforanstaltninger og internationale afhængigheder.

NIS2 tilføjer et service- og robusthedsperspektiv. Direktivet bringer mange mellemstore og større organisationer i højkritiske og andre kritiske sektorer inden for anvendelsesområdet, herunder digital infrastruktur, cloud computing-tjenesteudbydere, datacentertjenesteudbydere, content delivery networks, tillidstjenesteudbydere, udbydere af offentlige elektroniske kommunikationstjenester, managed service providers og managed security service providers. Annex I omfatter også banksektoren og infrastrukturer for finansielle markeder. Nogle enheder kan være omfattet uanset størrelse, herunder visse DNS-, TLD-, tillidstjeneste- og offentlige kommunikationsudbydere samt enheder, hvis forstyrrelse kan påvirke offentlig sikkerhed, folkesundhed, systemisk risiko eller kritiske samfundsmæssige og økonomiske aktiviteter væsentligt.

NIS2 Article 21 kræver forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger for net- og informationssystemer, der anvendes til drift eller levering af tjenester. Minimumsområderne omfatter risikoanalyse, sikkerhedspolitikker, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, vurdering af effektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver og autentifikation.

For en NIS2-enhed er en RoPA uden et billede af tjenesteafhængigheder ufuldstændig. En væsentlig hændelse skal forstås i forhold til påvirkning af tjenester, driftsafbrydelse, berørte modtagere, leverandører og grænseoverskridende konsekvenser.

DORA skærper det samme krav for finansielle enheder. Forordningen finder anvendelse fra 17. januar 2025 og fastsætter ensartede krav til styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed, deling af oplysninger om cybertrusler og sårbarheder, IKT-tredjepartsrisiko og kontraktlige arrangementer med IKT-tredjepartsleverandører. DORA definerer IKT-tjenester bredt som digitale tjenester og datatjenester, der leveres løbende via IKT-systemer. En kritisk eller vigtig funktion defineres som en funktion, hvor en forstyrrelse væsentligt ville forringe den finansielle præstation, servicekontinuiteten eller efterlevelsesforpligtelserne.

For finansielle enheder, der også er identificeret under national gennemførelse af NIS2, behandles DORA som den sektorspecifikke EU-retsakt for tilsvarende krav til IKT-risiko, hændelsesrapportering, test, informationsdeling og tredjepartsrisiko. I praksis kan en fintech ikke opbygge ét dokumentationssæt for databeskyttelse, et andet for DORA og et tredje for NIS2. Den har brug for ét afhængighedsbevidst lag til datastyring.

Det lag er RoPA plus kortlægning af dataflow.

ISO/IEC 27001:2022 er rygraden

ISO/IEC 27001:2022 er velegnet til denne type integration. Standarden etablerer et skalerbart ledelsessystem for informationssikkerhed (ISMS), der er udformet til at bevare fortrolighed, integritet og tilgængelighed gennem risikostyring. Standarden er beregnet til at blive integreret i organisationens processer og skaleret efter organisationens behov, størrelse og struktur.

Udgangspunktet er ikke diagramværktøjet. Det er omfanget.

ISO/IEC 27001:2022 punkt 4.1 til 4.4 kræver, at organisationen fastlægger kontekst, interessenter, ISMS-omfang og samspillende processer. Omfanget skal tage højde for retlige, regulatoriske og kontraktlige forpligtelser samt grænseflader og afhængigheder mellem interne aktiviteter og aktiviteter udført af andre organisationer. For RoPA og kortlægning af dataflow betyder det, at jeres ISMS-omfang udtrykkeligt bør omfatte outsourcede cloudplatforme, betalingsbehandlere, identitetsudbydere, supportværktøjer, administrerede sikkerhedsleverandører og forretningskritiske SaaS-integrationer.

Punkt 5.1 til 5.3 gør ledelsen ansvarlig for politik, ressourcer, rolletildeling og rapportering. Det afspejler retningen i NIS2 Article 20, som kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og gennemfører træning. Det er også i overensstemmelse med DORA Article 5, som giver ledelsesorganet det endelige ansvar for IKT-risiko og tilsyn med politikker, robusthedsstrategi, kontinuitetsplaner, revisionsplaner, IKT-tredjepartstjenester og rapporteringskanaler for større hændelser.

Punkt 6.1.1 til 6.1.3 udgør planlægningsmotoren: identificér risici for fortrolighed, integritet og tilgængelighed, tildel risikoejere, analysér konsekvenser og sandsynlighed, vælg behandlingsmuligheder, sammenhold kontroller med Annex A, udarbejd anvendelseserklæringen og indhent risikoejerens godkendelse.

Det er her, RoPA bliver operationel. Hver behandlingsaktivitet og hvert dataflow bør kobles til risici, kontroller, leverandører, aktiver og kritiske tjenester. Hvis det ikke sker, forbliver RoPA en databeskyttelsesfortegnelse, der ikke kan understøtte hændelseshåndtering, robusthedstest eller beslutninger om leverandørrisiko.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap gør dette praktisk i risikostyringsfasen, trin 9, Identifikation af aktiver, trusler og sårbarheder:

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

Samme trin 9 tilføjer den centrale efterlevelsesindsigt: aktiver med personoplysninger bør markeres for GDPR-relevans, og aktiver, der understøtter kritiske tjenester, bør markeres for potentiel NIS2-relevans, hvis organisationen er i en reguleret sektor. Det er broen mellem RoPA, aktivfortegnelse og kortlægning af kritiske tjenesteafhængigheder.

Hvad en revisionsklar RoPA skal indeholde

En stærk RoPA behøver ikke være kompliceret, men den skal være sammenhængende.

GDPR Article 5 kræver, at personoplysninger behandles lovligt, rimeligt og gennemsigtigt, indsamles til specifikke og legitime formål, begrænses til det nødvendige, holdes korrekte, kun opbevares så længe som nødvendigt og sikres gennem passende tekniske og organisatoriske foranstaltninger. Article 5(2) kræver, at den dataansvarlige er ansvarlig for og kan dokumentere efterlevelse.

Article 6 kræver et behandlingsgrundlag, f.eks. samtykke, kontraktmæssig nødvendighed, retlig forpligtelse, vitale interesser, samfundsopgave eller legitime interesser. Hvis behandling sker til et nyt formål, skal forenelighed vurderes ved at tage højde for de oprindelige og nye formål, indsamlingskonteksten, følsomheden, konsekvenserne for de registrerede og sikkerhedsforanstaltninger såsom kryptering eller pseudonymisering. Article 9 tilføjer strengere regler for særlige kategorier af personoplysninger, herunder helbredsoplysninger, biometriske data anvendt til entydig identifikation og andre følsomme kategorier.

Clarysecs politikpakke til SMV’er gør dette til et operationelt krav. Data Protection and Privacy Policy - SME fastsætter:

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

Det stammer fra afsnittet Styringskrav, pkt. 5.2.1. For større organisationer tildeler Clarysecs Data Protection and Privacy Policy ansvaret direkte:

Vedligeholder fortegnelsen over behandlingsaktiviteter (RoPA) i overensstemmelse med GDPR Article 30.

Den formulering kommer fra Roller og ansvar, pkt. 4.2.2. Det praktiske budskab er enkelt: ejerskab for RoPA skal tildeles. Den må ikke være et forældreløst compliance-regneark.

En RoPA, der er klar til 2026, bør indeholde følgende felter.

De sidste rækker er det, der flytter RoPA fra databeskyttelsesdokumentation til dokumentation for cyberrobusthed. Uden systemer, leverandører, placeringer, kritikalitet og kontroller kan en RoPA opfylde en snæver Article 30-tjekliste, men fejle, så snart en hændelse, et nedbrud eller en tilsynsgennemgang kræver konsekvensanalyse.

Kortlægning af dataflow forbinder databeskyttelse, cloud og kritiske tjenester

Hvis RoPA svarer på “hvilken behandling findes og hvorfor”, svarer et dataflowkort på “hvor bevæger data sig hen, hvem berører dem, hvad beskytter dem, og hvad bryder sammen, hvis flowet stopper.”

Clarysecs Data Masking and Pseudonymization Policy - SME gør kravet entydigt:

Der skal oprettes et dataflowkort.

Dette kommer fra Styringskrav, pkt. 5.1.1.1. Enterprise-versionen, Data Masking and Pseudonymization Policy, udvider forventningen i pkt. 5.2.1:

Vedligehold en ajourført fortegnelse over systemer og dataflow, der involverer følsomme data.

Pkt. 5.2.2 tilføjer:

Kortlæg, hvor og hvordan data transformeres, deles eller tilgås på tværs af miljøer.

Revisorer og tilsynsmyndigheder leder ikke efter kunstneriske diagrammer. De vil forstå transformationer, adgangsveje, deling, miljøer og sikkerhedsforanstaltninger.

I Zenith Blueprint, fasen Controls in Action, trin 22, organisatoriske kontroller 5.1 til 5.18, forklarer vejledningen om informationsoverførsel, at organisationer skal definere tilladte overførselsmetoder, afstemme dem med klassificering og sikre, at parterne forstår deres roller og forpligtelser. Den giver eksempler som krypteret e-mail, sikre portaler, SFTP, API’er og fysisk levering med kryptering. Den bemærker også, at personoplysninger, der overføres på tværs af grænser, skal overholde databeskyttelses- og retlige forpligtelser, ikke kun interne præferencer.

Det samme trin forbinder informationsoverførsel med klassificering og mærkning, forebyggelse af datalækage, leverandørrelationer og kryptografi. Det skaber en praktisk model for kortlægning af dataflow:

1. Identificér kildesystemet, f.eks. CRM, betalingsplatform, HRIS eller supportdesk.
2. Identificér datakategorien, herunder personoplysninger, finansielle data, medarbejderdata, særlige kategorier af personoplysninger eller legitimationsoplysninger.
3. Identificér overførselsmetoden, f.eks. API, SFTP, e-mail, sikker portal, manuel eksport eller backupreplikering.
4. Identificér destinationen, herunder internt system, cloudtjeneste, leverandør, underdatabehandler, data warehouse eller arkiv.
5. Identificér beskyttelsen, f.eks. kryptering, pseudonymisering, adgangsstyring, logning, DLP eller kontraktlig begrænsning.
6. Identificér afhængigheden, herunder om flowet understøtter en kritisk forretningsfunktion, kritisk eller vigtig funktion, væsentlig tjeneste eller rapporteringsforpligtelse ved hændelser.

Tre kontroller i ISO/IEC 27001:2022 Annex A er særligt vigtige her. ISO/IEC 27002:2022 giver implementeringsvejledningen til disse kontroller:

Clarysecs Zenith Controls: The Cross-Compliance Guide identificerer 5.9, 5.14 og 5.34 som emnerelaterede kontroller for dette styringslag. Behandl dem som ankerkontroller, og forbind dem derefter med leverandør-, cloud-, hændelses-, kontinuitets-, lognings-, adgangs- og kryptografikontroller gennem jeres anvendelseserklæring.

Hvorfor NIS2 og DORA kræver mere end et databeskyttelsesregister

En almindelig fejl er at opbygge en RoPA, der er teknisk korrekt efter GDPR, men ubrugelig for NIS2 eller DORA. Forskellen er tjenestekritikalitet.

NIS2 Article 23 kræver, at væsentlige og vigtige enheder underretter om væsentlige hændelser uden unødig forsinkelse. Rapporteringsmodellen omfatter en tidlig advarsel inden for 24 timer, en hændelsesunderretning inden for 72 timer og en endelig rapport inden for én måned. Væsentlige hændelser vurderes ud fra alvorlig driftsforstyrrelse, økonomisk tab eller materiel eller immateriel skade på andre fysiske eller juridiske personer. Den vurdering afhænger af viden om, hvilke tjenester, modtagere, lande, systemer og leverandører der er berørt.

DORA Article 17 kræver, at finansielle enheder definerer og implementerer en proces for styring af IKT-relaterede hændelser, der detekterer, håndterer og underretter om hændelser, registrerer hændelser og væsentlige cybertrusler, identificerer rodårsager, fastsætter tidlige advarselsindikatorer, klassificerer hændelser efter alvorlighed og kritikaliteten af berørte tjenester, tildeler roller og etablerer kommunikations- og eskalationsprocedurer. Article 18 kræver klassificering baseret på berørte kunder eller modparter og transaktioner, varighed og nedetid, geografisk udbredelse, datatab, der påvirker tilgængelighed, autenticitet, integritet eller fortrolighed, kritikaliteten af berørte tjenester og økonomisk påvirkning.

Du kan ikke klassificere en hændelse hurtigt, hvis du ikke kender dataflowet og afhængighedskæden.

Clarysecs Business Continuity Policy and Disaster Recovery Policy - SME peger på det dokumentationsfelt, organisationer har brug for:

prioriterede tjenester og systemer (kritiske forretningsfunktioner)

Dette kommer fra Styringskrav, pkt. 5.2.1.2. Enterprise-versionen Business Continuity Policy and Disaster Recovery Policy tilføjer afhængighedsdimensionen i pkt. 5.2.4:

Kritiske afhængigheder (systemer, leverandører, personale)

For DORA-regulerede organisationer skal dette være afstemt med kritiske eller vigtige funktioner, IKT-tjenester, kontraktlige arrangementer og exitstrategier. DORA Article 28 kræver, at IKT-tredjepartsrisiko styres som en del af IKT-risikostyringsrammen. Den foreskriver et register over kontraktlige arrangementer for IKT-tjenester, kræver due diligence før kontraktindgåelse og vurdering af kritikalitet, koncentrationsrisiko, egnethed og interessekonflikter samt exitstrategier for IKT-tjenester, der understøtter kritiske eller vigtige funktioner.

DORA Article 30 angiver minimumsvilkår for IKT-kontrakter, herunder tjenestebeskrivelser, betingelser for underleverandører, placeringer for databehandling og -opbevaring, databeskyttelse, adgang, genopretning og tilbagelevering af data, serviceniveauer, bistand ved hændelser, samarbejde med myndigheder, opsigelsesrettigheder, revisionsrettigheder og overgangs- eller exitarrangementer.

En RoPA, der ikke identificerer leverandører, placeringer, overførselsmetoder, kritikalitet og exitafhængigheder, understøtter ikke DORA-dokumentation.

Kortlægning af leverandører, cloud og underdatabehandlere er der, hvor dokumentationen ofte bryder sammen

I reelle revisioner viser RoPA-svigt sig ofte som leverandørsvigt. Behandlingsaktiviteten siger “kundesupport”. Dataflowkortet siger “supportplatform”. Men ingen kan identificere hostingregionen, AI-transskriptionsmodulet, analyse-underdatabehandleren, opbevaring af ticketvedhæftninger, modellen for administratoradgang eller exitproceduren.

Clarysecs SMV-leverandørpolitik fastlægger det minimale operationelle dokumentationsgrundlag. Third-Party and Supplier Security Policy - SME fastsætter:

Et leverandørregister skal vedligeholdes og opdateres af den administrative kontakt eller indkøbskontakten. Det skal omfatte:

Dette kommer fra Styringskrav, pkt. 5.4. Cloudpolitikken tilføjer et særskilt krav om fortegnelse. Cloud Usage Policy - SME fastsætter:

Et register over cloudtjenester skal vedligeholdes af IT-leverandøren eller GM. Det skal registrere:

Dette kommer fra Styringskrav, pkt. 5.3. For afhængighedsrisiko i enterprise-miljøer er Clarysecs Supplier Dependency Risk Management Policy mere eksplicit:

Register over leverandørafhængigheder: VMO skal vedligeholde et ajourført register over alle kritiske leverandører, herunder oplysninger såsom leverede tjenester/produkter; om leverandøren er eneleverandør; tilgængelige alternative leverandører eller substitutionsmulighed; aktuelle kontraktvilkår; og en vurdering af påvirkningen, hvis leverandøren skulle fejle eller blive kompromitteret. Registeret skal klart identificere leverandører med høj afhængighed (f.eks. dem, hvor der ikke findes et hurtigt alternativ).

Det krav, fra Implementeringskrav pkt. 6.1, er præcis det, der forbinder RoPA med NIS2-sikkerhed i forsyningskæden og DORA IKT-tredjepartsrisiko.

Zenith Blueprint, fasen Controls in Action, trin 23, organisatoriske kontroller 5.19 til 5.37, anbefaler at udarbejde en fuld leverandørliste, klassificere leverandører baseret på adgang til systemer, data eller driftsmæssig kontrol, indarbejde sikkerhedsforventninger i kontrakter, gennemgå underleverandører, etablere udløsende forhold ved leverandørændringer og opbygge en proces til vurdering af cloudtjenester, der dækker dataplacering, adgangsmodel, logning og kryptering.

Det er det, der gør det muligt for en CISO under en hændelse at svare: “Hvilken kritisk tjeneste bruger denne leverandør, hvilke data blev eksponeret, hvilke kunder skal underrettes, hvilken tilsynsmyndighed kan kræve en rapport, og hvilken alternativ leverandør eller exitvej findes der?”

Et praktisk eksempel: kunde-onboarding i en fintech

Overvej en fintech, der leverer onboarding til digitale wallets. Kunder uploader identitetsdokumenter, en leverandør udfører biometriske liveness-kontroller, resultater lagres i en clouddatabase, og kundesupport kan se verifikationsstatus i et helpdesk-sagsstyringssystem.

Onboarding-tjenesten kan være en kritisk eller vigtig funktion under DORA, fordi en forstyrrelse væsentligt påvirker servicekontinuitet og regulatoriske forpligtelser. Hvis virksomheden er i en NIS2-sektor eller leverer relevante IKT-tjenester, kan den også indgå i dokumentation for kritiske tjenester.

Et nyttigt kort starter med én samlet registrering.

Tilføj derefter sporbarhed for ISO/IEC 27001:2022-risikobehandling.

I Zenith Blueprint, risikostyringsfasen, trin 13, planlægning af risikobehandling og anvendelseserklæring, beskriver Clarysec SoA som et brodokument, der forbinder risikovurdering og behandling med faktiske kontroller. Den anbefaler at kortlægge kontroller til risici og krydshenvise til regler som GDPR, NIS2 eller DORA i risikoregisteret eller SoA-noter, hvor det er relevant.

For onboarding-eksemplet kan risikoscenariet være: “Nedbrud eller kompromittering hos identitetsverifikationsudbyderen forstyrrer onboarding og eksponerer biometriske identitetsdata.” Behandlingskontrollerne kan omfatte leverandør-due diligence, kontraktlig hændelsesunderretning, kryptering, adgangsstyring, logning, backup og genopretning, dataminimering, pseudonymisering, overvågning, exitplanlægning og beredskabsprocedurer for hændelseshåndtering.

SoA-noten kan angive, at kontrolsættet understøtter GDPR-ansvarlighed, NIS2 Article 21 vedrørende forsyningskæde og hændelsesberedskab samt DORA IKT-tredjepartsrisiko og robusthed for kritiske funktioner.

Det er det, revisorer vil have: sporbarhed.

Kortlægning på tværs af krav: ét dokumentationslag, flere spørgsmål

RoPA og kortlægning af dataflow er ikke adskilte efterlevelsessiloer. De understøtter et fælles sæt spørgsmål på tværs af GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 og COBIT 2019.

NIST CSF 2.0 er nyttig som organiserende lag. Dens CSF-profiler understøtter analyse af nuværende og ønsket tilstand ved hjælp af input som politikker, risikoprioriteter, registre over forretningskonsekvenser, krav, standarder, praksisser, værktøjer og arbejdsroller. GOVERN-funktionen omfatter retlige, regulatoriske, kontraktlige, databeskyttelses- og borgerrettighedsforpligtelser, risikomål, ledelsesansvarlighed, roller, politik, tilsyn og gennemgang af performance. Dens resultater for forsyningskæden kræver, at leverandører er kendte og prioriterede efter kritikalitet, at kontraktlige cybersikkerhedskrav integreres, at due diligence sker før relationer, at leverandørrisici registreres og overvåges, og at leverandører indgår i hændelseshåndtering og genopretningsplanlægning.

Det passer direkte til en Clarysec-driftsmodel for RoPA. RoPA giver databeskyttelseskontekst. Aktivfortegnelsen giver teknisk kontekst. Leverandør- og cloudregistrene giver tredjepartskontekst. BIA giver kritikalitetskontekst. SoA giver kontrolkontekst.

Én enkelt kontrol i ISO/IEC 27001:2022 Annex A kan også understøtte flere rammeværker. Control 5.14, Information transfer, er et godt eksempel.

Det er værdien af Zenith Controls som kompas på tværs af krav. Det hjælper organisationer med at forklare, hvorfor én kontrolpraksis understøtter flere regulatoriske og revisionsmæssige forventninger.

Hvordan forskellige revisorer tester det samme kort

Et modent RoPA- og dataflowkort kan opfylde flere revisorers behov, men de vil tilgå det forskelligt.

En ISO/IEC 27001:2022-revisor vil starte med omfang, interessenter, risici, dokumenteret information og kontroludvælgelse. Vedkommende vil spørge, om retlige og kontraktlige krav er identificeret, om personoplysninger og kritiske tjenester er inden for ISMS-omfanget, om aktiver har ejere og klassificeringer, om risikovurderingen har vurderet fortrolighed, integritet og tilgængelighed, og om SoA begrunder de anvendelige kontroller.

En GDPR-revisor eller databeskyttelsesmyndighed vil starte med ansvarlighed. De vil teste, om RoPA afspejler den faktiske behandling, om formål og behandlingsgrundlag er dokumenteret, om særlige kategorier af personoplysninger er identificeret, om opbevaringsperioder anvendes, om modtagere og databehandlere er korrekte, og om der findes passende sikkerhedsforanstaltninger for overførsler og sikkerhed.

En NIS2-fokuseret revisor vil se på tjenestepåvirkning. Vedkommende vil spørge, hvordan organisationen fastlægger kritiske eller vigtige tjenester, hvordan ledelsen har godkendt og fører tilsyn med risikoforanstaltningerne, hvordan leverandørsårbarheder og serviceudbyderrisici vurderes, hvordan kontinuitet og hændelseshåndtering er forbundet, og om organisationen kan understøtte 24-timers-, 72-timers- og endelige rapporteringsfrister med pålidelig dokumentation.

En DORA-revisor vil se på styring af IKT-risiko og kritiske eller vigtige funktioner. Vedkommende vil teste, om ledelsesorganet har godkendt IKT-risikostyringsrammen og robusthedsstrategien, om IKT-tredjepartsarrangementer er registreret, om kritikalitet og koncentrationsrisiko er vurderet, om kontrakter indeholder de krævede vilkår, om test dækker systemer, der understøtter kritiske eller vigtige funktioner, og om hændelser klassificeres ud fra berørte kunder, transaktioner, nedetid, geografi, datatab, tjenestekritikalitet og økonomisk påvirkning.

En NIST CSF 2.0-vurderingspart vil ofte bruge profiler. Vedkommende vil sammenligne nuværende og ønskede resultater på tværs af GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER. RoPA og dataflowkort bliver input til styring af retlige forpligtelser, aktivfortegnelser, leverandørrisiko, databeskyttelse, overvågning, hændelseskommunikation og genopretningsplanlægning.

En COBIT 2019- eller ISACA-lignende revisor vil fokusere på styring, ejerskab og proceskapabilitet. Vedkommende vil teste, om informationsflow er ejet, om beslutningsrettigheder er klare, om risikovillighed anvendes, om kontroller overvåges, om undtagelser eskaleres, og om dokumentationen er tilstrækkeligt pålidelig til ledelsens assurance.

Almindelige fejlmønstre

De hyppigste fejl i RoPA og kortlægning af dataflow er forudsigelige.

For det første oplister RoPA behandlingsaktiviteter, men ikke systemer. Det gør det umuligt at forbinde GDPR-ansvarlighed med sårbarhedsstyring, gennemgang af adgangsrettigheder, backup, logning eller hændelseshåndtering.

For det andet stopper dataflowkort ved den første leverandør. De viser ikke underdatabehandlere, cloudregioner, supportadgang, analyseværktøjer, overvågningsplatforme eller backuplokationer.

For det tredje identificerer planer for forretningskontinuitet systemer, men ikke personoplysninger. Under et nedbrud forstår organisationen genopretningsprioriteten, men ikke databeskyttelsespåvirkningen.

For det fjerde registrerer leverandørregistre kontraktejere, men ikke kritikalitet, substitutionsmulighed, datakategorier, forpligtelser til hændelsesunderretning eller exitmuligheder.

For det femte skrives SoA som et certificeringsdokument frem for en kontrolbro. Den siger, at kontroller er anvendelige, men forklarer ikke, hvilket dokumentationsproblem under GDPR, NIS2 eller DORA kontrollen hjælper med at løse.

Endelig er ejerskabet fragmenteret. DPO’en ejer RoPA, IT ejer aktiver, indkøb ejer leverandører, drift ejer BIA, finans ejer DORA-registre, og ingen ejer det integrerede afhængighedskort.

Clarysecs tilgang løser dette ved at tildele dokumentationsobjekter til politikejere og derefter bruge trinnene i Zenith Blueprint til at forbinde aktiver, risici, kontroller og SoA-sporbarhed.

En 30-dages implementeringsplan

I behøver ikke koge havet. Start med de tjenester, der betyder mest.

Uge 1: Vælg tre kritiske behandlingsaktiviteter eller højrisikobehandlingsaktiviteter. Gode kandidater er kunde-onboarding, betalingsbehandling, HR-administration af medarbejdere, supportticketing eller sikkerhedsovervågning. For hver aktivitet valideres RoPA-posten mod faktiske systemer, datakategorier, formål, behandlingsgrundlag og opbevaringsregler.

Uge 2: Opbyg dataflowkort for disse aktiviteter. Identificér kilde, destination, overførselsmetode, miljø, leverandør, underdatabehandler, dataplacering, adgangsvej, transformation og opbevaringspunkt. Brug kravet i Clarysecs Data Masking and Pseudonymization Policy om at vedligeholde fortegnelser over systemer og dataflow, der involverer følsomme data.

Uge 3: Kobl hvert flow til aktiver, leverandører, cloudtjenester og kritiske forretningsfunktioner. Brug Zenith Blueprint trin 9 til ejerskab og klassificering af aktiver. Brug kravene i politikkerne for leverandør- og cloudregistre til at indsamle tredjepartsdokumentation. Brug politikken for forretningskontinuitet til at identificere prioriterede tjenester og kritiske afhængigheder.

Uge 4: Tilføj sporbarhed for risiko og kontroller. For hvert flow oprettes eller opdateres risikoscenarier. Kortlæg kontroller i SoA ved hjælp af Zenith Blueprint trin 13. Tilføj noter for GDPR Article 30-ansvarlighed, NIS2 Article 21-risikoforanstaltninger og DORA-dokumentation for IKT-afhængigheder, hvor det er relevant.

Gennemfør derefter én tabletop-øvelse: “Leverandørnedbrud plus dataeksponering i en kritisk tjeneste.” Test, om jeres dokumentation understøtter hændelsesklassificering, beslutninger om underretning, kundekommunikation, kommunikation med tilsynsmyndigheder og prioritering af genopretning.

Efter 30 dage har I en gentagelig model for resten af organisationen.

Clarysec-metoden: Gør RoPA til levende dokumentation for robusthed

RoPA og kortlægning af dataflow er ikke længere kun databeskyttelsesadministration. De er det bindevæv, der forbinder GDPR-ansvarlighed, NIS2-styring af kritiske tjenester og DORA-dokumentation for IKT-afhængigheder.

De organisationer, der klarer sig bedst i 2026, er ikke dem med flest dokumenter. Det er dem, der kan spore en forretningstjeneste til dens behandlingsaktiviteter, dataflow, systemer, leverandører, cloudregioner, kontrakter, kontroller, risici, hændelsestærskler og genopretningsplaner.

Clarysec hjælper teams med at opbygge denne sporbarhed uden unødigt bureaukrati. Vores politikpakke tildeler ejerskab og dokumentationskrav. Zenith Blueprint giver implementeringskøreplanen, herunder identifikation af aktiver, implementering af leverandør- og cloudkontroller samt SoA-sporbarhed. Zenith Controls giver kompasset på tværs af krav til kortlægning af ISO/IEC 27001:2022 Annex A-kontroller mod forventninger til databeskyttelse, robusthed, leverandører, cloud og revision.

Jeres næste skridt er enkelt: vælg én kritisk tjeneste, én RoPA-post og ét leverandørunderstøttet dataflow. Kortlæg det fra start til slut. Hvis I ikke kan forklare data, afhængighed, kontrol og hændelsespåvirkning på én side, er jeres dokumentationslag ikke klar til 2026.

Clarysec kan hjælpe jer med at gøre det klar. Udforsk Zenith Blueprint, styrk jeres styring med Data Protection and Privacy Policy og Supplier Dependency Risk Management Policy, og brug Zenith Controls til at gøre fragmenteret dokumentation for efterlevelse til én revisionsklar driftsmodel.