Kartläggning av RoPA-dataflöden för GDPR, NIS2 och DORA

Klockan är 09:10 en tisdag och informationssäkerhetschefen (CISO), dataskyddsombudet (DPO), upphandlingsansvarig och operativ chef sitter i samma videomöte, men utgår inte från samma underlag.

Dataskyddsombudet har ett register över behandlingsaktiviteter, RoPA, som omfattar kundonboarding, lönehantering, supportärenden och marknadsföringsanalys. CISO har en tillgångsförteckning för moln. Upphandling har leverantörsavtal. Driften har ett kalkylblad för verksamhetskontinuitet. Ekonomi har DORA:s informationsregister. Ingen kan besvara tillsynsmyndighetens mest grundläggande sammanhållna fråga:

Om denna tjänst för betalningsonboarding fallerar, vilka system, leverantörer, datakategorier, underbiträden, gränsöverskridande överföringar och kritiska verksamhetsfunktioner påverkas?

Den frågan är det verkliga efterlevnadstestet för 2026.

GDPR kräver fortfarande ansvarsskyldighet och register enligt Article 30. NIS2 har gjort cybersäkerhet till en fråga om ansvarsskyldighet för ledningsorgan hos väsentliga och viktiga entiteter. DORA kräver att finansiella entiteter kan styrka IKT-beroenden, kritiska eller viktiga funktioner, IKT-tredjepartsarrangemang, incidentklassificering och resiliensprovning. ISO/IEC 27001:2022 ger ledningssystemets struktur för att hålla ihop detta, men bara om RoPA och kartläggning av dataflöden behandlas som levande styrningsunderlag och inte som kalkylblad hos dataskyddsteamet.

På Clarysec ser vi samma mönster hos snabbväxande SaaS-, fintech-, moln-, MSP- och B2B-teknikbolag. De har tillräckligt med dokumentation för att besvara ett frågeformulär, men inte tillräckligt sammanlänkat underlag för att klara en tillsynsgranskning, en cyberincident, ett leverantörsfel eller en internrevision. Problemet är sällan brist på information. Det är brist på samband.

Lösningen är att göra RoPA och kartläggning av dataflöden till det gemensamma underlagslagret för dataskydd, cyberresiliens, leverantörshantering, molnstyrning och verksamhetskontinuitet.

Varför RoPA och kartläggning av dataflöden blev en styrningsfråga 2026

RoPA betraktades tidigare som en dataskyddsartefakt. Dataflödeskartor togs ofta fram under en DPIA, en molnmigrering eller en säkerhetsarkitekturgranskning och lämnades sedan att åldras. Det arbetssättet fungerar inte längre.

GDPR gäller brett för behandling av personuppgifter inom ramen för ett etableringsställe i EU, och även för många personuppgiftsansvariga eller personuppgiftsbiträden utanför EU som erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende. Personuppgifter omfattar information som avser en identifierad eller identifierbar person. Behandling omfattar insamling, lagring, användning, utlämnande, begränsning, radering och förstöring. En personuppgiftsansvarig bestämmer ändamål och medel, medan ett personuppgiftsbiträde agerar för den personuppgiftsansvariges räkning.

En RoPA är därför inte bara en lista över databaser. Den är en förteckning över verksamhetsändamål, datakategorier, roller, mottagare, bevarandetider, skyddsåtgärder och internationella beroenden.

NIS2 tillför ett tjänsteresiliensperspektiv. Direktivet omfattar många medelstora och större organisationer inom sektorer med hög kritikalitet och andra kritiska sektorer, inklusive digital infrastruktur, leverantörer av molntjänster, leverantörer av datacentertjänster, innehållsleveransnätverk, betrodda tjänsteleverantörer, leverantörer av allmänna elektroniska kommunikationstjänster, hanterade tjänsteleverantörer och leverantörer av hanterade säkerhetstjänster. Bilaga I omfattar även bankverksamhet och finansmarknadsinfrastruktur. Vissa entiteter kan omfattas oavsett storlek, inklusive vissa DNS-, TLD-, betrodda tjänste- och allmänna kommunikationsleverantörer samt entiteter vars störning kan påverka allmän säkerhet, folkhälsa, systemrisk eller kritiska samhälleliga och ekonomiska aktiviteter i betydande grad.

NIS2 Article 21 kräver proportionella tekniska, operativa och organisatoriska åtgärder för nätverks- och informationssystem som används för verksamhet eller tjänsteleverans. De angivna minimiområdena omfattar riskanalys, säkerhetspolicyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, effektivitetsbedömning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och autentisering.

För en NIS2-entitet är en RoPA utan vy över tjänsteberoenden ofullständig. En betydande incident måste förstås utifrån tjänstepåverkan, operativa störningar, berörda mottagare, leverantörer och gränsöverskridande konsekvenser.

DORA skärper samma krav för finansiella entiteter. Förordningen gäller från den 17 januari 2025 och fastställer enhetliga krav på IKT-riskhantering, rapportering av större IKT-relaterade incidenter, testning av digital operativ resiliens, informationsdelning om cyberhot och sårbarheter, IKT-tredjepartsrisker och avtalsarrangemang med IKT-tredjepartstjänsteleverantörer. DORA definierar IKT-tjänster brett som digitala tjänster och datatjänster som tillhandahålls genom IKT-system på löpande basis. En kritisk eller viktig funktion definieras som en funktion vars störning väsentligt skulle försämra finansiellt resultat, tjänstekontinuitet eller krav på regelefterlevnad.

För finansiella entiteter som också identifieras enligt nationellt införlivande av NIS2 behandlas DORA som den sektorsspecifika unionsrättsakten för motsvarande krav på IKT-risk, incidentrapportering, testning, informationsdelning och tredjepartsrisk. I praktiken kan ett fintechbolag inte bygga ett underlag för dataskydd, ett annat för DORA och ett tredje för NIS2. Det behöver ett enda beroendemedvetet lager för datastyrning.

Det lagret är RoPA plus kartläggning av dataflöden.

ISO/IEC 27001:2022 är ryggraden

ISO/IEC 27001:2022 är utformad för denna typ av integration. Standarden etablerar ett skalbart ledningssystem för informationssäkerhet, ISMS, avsett att bevara konfidentialitet, riktighet och tillgänglighet genom riskhantering. Standarden är avsedd att integreras i organisationens processer och anpassas till organisationens behov, storlek och struktur.

Startpunkten är inte diagramverktyget. Det är omfattningen.

ISO/IEC 27001:2022 klausulerna 4.1 till 4.4 kräver att organisationen definierar kontext, intressenter, ISMS-omfattning och samverkande processer. Omfattningen ska beakta rättsliga, regulatoriska och avtalsmässiga skyldigheter samt gränssnitt och beroenden mellan interna aktiviteter och aktiviteter som utförs av andra organisationer. För RoPA och kartläggning av dataflöden innebär detta att ISMS-omfattningen uttryckligen bör omfatta outsourcade molnplattformar, betalningsförmedlare, identitetsleverantörer, supportverktyg, leverantörer av hanterade säkerhetstjänster och verksamhetskritiska SaaS-integrationer.

Klausulerna 5.1 till 5.3 gör ledningen ansvarig för policy, resurser, rolltilldelning och rapportering. Detta speglar inriktningen i NIS2 Article 20, som kräver att ledningsorgan godkänner riskhanteringsåtgärder för cybersäkerhet, övervakar genomförandet och genomgår utbildning. Det är också i linje med DORA Article 5, som ger ledningsorganet det yttersta ansvaret för IKT-risk och tillsyn över policyer, resiliensstrategi, kontinuitetsplaner, revisionsplaner, IKT-tredjepartstjänster och rapporteringskanaler för större incidenter.

Klausulerna 6.1.1 till 6.1.3 utgör planeringsmotorn: identifiera risker för konfidentialitet, riktighet och tillgänglighet, utse riskägare, analysera konsekvens och sannolikhet, välja behandlingsalternativ, jämföra kontroller med bilaga A, ta fram tillämpbarhetsförklaring och inhämta godkännande från riskägare.

Det är här RoPA blir operativ. Varje behandlingsaktivitet och dataflöde bör kopplas till risker, kontroller, leverantörer, tillgångar och kritiska tjänster. Annars förblir den en dataskyddsförteckning som inte kan stödja incidenthantering, resiliensprovning eller beslut om leverantörsrisker.

Clarysecs Zenith Blueprint: en revisors färdplan i 30 steg gör detta praktiskt i fasen Riskhantering, steg 9, Identifiering av tillgångar, hot och sårbarheter:

För varje tillgång ska centrala uppgifter registreras: namn/beskrivning, ägare, plats och klassificering (känslighet). En tillgång kan exempelvis vara ”Kunddatabas – ägs av IT-avdelningen – driftas på AWS – innehåller personuppgifter och finansiella data (hög känslighet).”

Samma steg 9 tillför den centrala efterlevnadsinsikten: tillgångar med personuppgifter bör markeras för GDPR-relevans, och tillgångar för kritiska tjänster bör noteras för potentiell NIS2-tillämplighet om organisationen finns i en reglerad sektor. Det är bryggan mellan RoPA, tillgångsförteckning och kartläggning av kritiska tjänsteberoenden.

Vad en revisionsredo RoPA måste innehålla

En stark RoPA behöver inte vara komplicerad, men den måste vara sammanlänkad.

GDPR Article 5 kräver att personuppgifter behandlas lagligt, korrekt och transparent, samlas in för specificerade och berättigade ändamål, begränsas till vad som är nödvändigt, hålls korrekta, bevaras endast så länge det behövs och skyddas genom lämpliga tekniska och organisatoriska åtgärder. Article 5(2) kräver att den personuppgiftsansvarige är ansvarig för, och kan visa, efterlevnad.

Article 6 kräver en rättslig grund, såsom samtycke, nödvändighet för avtal, rättslig förpliktelse, skydd av vitala intressen, uppgift av allmänt intresse eller berättigat intresse. Om behandling sker för ett nytt ändamål ska förenlighet bedömas genom att beakta de ursprungliga och nya ändamålen, insamlingskontexten, känslighet, konsekvenser för individer och skyddsåtgärder såsom kryptering eller pseudonymisering. Article 9 lägger till striktare regler för särskilda kategorier av personuppgifter, inklusive hälsodata, biometriska data som används för unik identifiering och andra känsliga kategorier.

Clarysecs policyuppsättning för små och medelstora företag omvandlar detta till ett operativt krav. Policy för dataskydd och integritet - SME anger:

Integritetssamordnaren ska upprätthålla ett register över alla behandlingsaktiviteter för personuppgifter, inklusive datakategorier, ändamål, rättslig grund och bevarandetider

Detta kommer från avsnittet Styrningskrav, klausul 5.2.1. För större organisationer tilldelar Clarysecs Policy för dataskydd och integritet ansvaret direkt:

Upprätthåller registret över behandlingsaktiviteter (RoPA) i enlighet med GDPR Article 30.

Den formuleringen kommer från Roller och ansvar, klausul 4.2.2. Det praktiska budskapet är enkelt: ägarskap för RoPA måste tilldelas. Den får inte vara ett herrelöst kalkylblad för regelefterlevnad.

En RoPA som är redo för 2026 bör innehålla följande fält.

De sista raderna är det som flyttar RoPA från dataskyddsdokumentation till underlag för cyberresiliens. Utan system, leverantörer, platser, kritikalitet och kontroller kan en RoPA uppfylla en snäv Article 30-checklista men fallera så snart en incident, ett avbrott eller en tillsynsgranskning kräver konsekvensanalys.

Kartläggning av dataflöden kopplar samman dataskydd, moln och kritiska tjänster

Om RoPA besvarar ”vilken behandling finns och varför”, besvarar en dataflödeskarta ”vart data rör sig, vem som berör den, vad som skyddar den och vad som brister om den stannar”.

Clarysecs Policy för datamaskering och pseudonymisering - SME gör kravet entydigt:

En dataflödeskarta ska skapas.

Detta kommer från Styrningskrav, klausul 5.1.1.1. Företagsversionen, Policy för datamaskering och pseudonymisering, utökar förväntan i klausul 5.2.1:

Upprätthåll en aktuell förteckning över system och dataflöden som omfattar känsliga data.

Klausul 5.2.2 lägger till:

Kartlägg var och hur data transformeras, delas eller nås mellan miljöer.

Revisorer och tillsynsmyndigheter söker inte konstnärliga diagram. De vill förstå transformeringar, åtkomstvägar, delning, miljöer och skyddsåtgärder.

I Zenith Blueprint, fasen Kontroller i praktiken, steg 22, organisatoriska kontroller 5.1 till 5.18, förklarar vägledningen om informationsöverföring att organisationer måste definiera tillåtna överföringsmetoder, anpassa dem till klassificering och säkerställa att parterna förstår sina roller och skyldigheter. Den ger exempel som krypterad e-post, säkra portaler, SFTP, API:er och fysisk leverans med kryptering. Den noterar också att personuppgifter som överförs över gränser måste följa dataskydds- och rättsliga skyldigheter, inte bara interna preferenser.

Samma steg kopplar informationsöverföring till klassificering och märkning, dataförlustprevention, leverantörsrelationer och kryptografi. Det skapar en praktisk modell för kartläggning av dataflöden:

1. Identifiera källsystemet, exempelvis CRM, betalningsplattform, HRIS eller supportdesk.
2. Identifiera datakategorin, inklusive personuppgifter, finansiella data, anställdas uppgifter, särskilda kategorier av personuppgifter eller autentiseringsuppgifter.
3. Identifiera överföringsmetoden, exempelvis API, SFTP, e-post, säker portal, manuell export eller replikering av säkerhetskopior.
4. Identifiera destinationen, inklusive internt system, molntjänst, leverantör, underbiträde, datalager eller arkiv.
5. Identifiera skyddet, exempelvis kryptering, pseudonymisering, åtkomstkontroll, loggning, DLP eller avtalsmässig begränsning.
6. Identifiera beroendet, inklusive om flödet stöder en kritisk verksamhetsfunktion, kritisk eller viktig funktion, väsentlig tjänst eller rapporteringsskyldighet för incidenter.

Tre kontroller i ISO/IEC 27001:2022 bilaga A är särskilt viktiga här. ISO/IEC 27002:2022 ger vägledning för genomförande av dessa kontroller:

Clarysecs Zenith Controls: vägledningen för korsvis efterlevnad identifierar 5.9, 5.14 och 5.34 som temarelaterade kontroller för detta styrningslager. Behandla dem som ankarkontroller och koppla dem sedan till kontroller för leverantörer, moln, incidenter, kontinuitet, loggning, åtkomst och kryptografi genom er tillämpbarhetsförklaring.

Varför NIS2 och DORA behöver mer än ett dataskyddsregister

Ett vanligt misstag är att bygga en RoPA som är tekniskt korrekt enligt GDPR men oanvändbar för NIS2 eller DORA. Skillnaden är tjänstekritikalitet.

NIS2 Article 23 kräver att väsentliga och viktiga entiteter anmäler betydande incidenter utan onödigt dröjsmål. Rapporteringsmodellen omfattar en tidig varning inom 24 timmar, en incidentanmälan inom 72 timmar och en slutrapport inom en månad. Betydande incidenter bedöms utifrån allvarlig operativ störning, finansiell förlust eller materiell eller immateriell skada för andra fysiska eller juridiska personer. Den bedömningen beror på kunskap om vilka tjänster, mottagare, länder, system och leverantörer som påverkas.

DORA Article 17 kräver att finansiella entiteter definierar och inför en process för hantering av IKT-relaterade incidenter som detekterar, hanterar och anmäler incidenter, registrerar incidenter och betydande cyberhot, identifierar rotorsaker, fastställer indikatorer för tidig varning, klassificerar incidenter efter allvarlighetsgrad och kritikalitet hos berörda tjänster, tilldelar roller och skapar kommunikations- och eskaleringsrutiner. Article 18 kräver klassificering med hjälp av berörda kunder eller motparter och transaktioner, varaktighet och avbrottstid, geografisk spridning, dataförlust som påverkar tillgänglighet, autenticitet, riktighet eller konfidentialitet, kritikalitet hos berörda tjänster och ekonomisk påverkan.

Det går inte att klassificera en incident snabbt om dataflödet och beroendekedjan inte är kända.

Clarysecs Policy för verksamhetskontinuitet och katastrofåterställning - SME pekar på det underlagsfält organisationer behöver:

prioriterade tjänster och system (kritiska verksamhetsfunktioner)

Detta kommer från Styrningskrav, klausul 5.2.1.2. Företagsversionen Policy för verksamhetskontinuitet och katastrofåterställning lägger till beroendedimensionen i klausul 5.2.4:

Kritiska beroenden (system, leverantörer, personal)

För DORA-reglerade organisationer måste detta anpassas till kritiska eller viktiga funktioner, IKT-tjänster, avtalsarrangemang och exitstrategier. DORA Article 28 kräver att IKT-tredjepartsrisk hanteras som en del av IKT-riskramverket. Den kräver ett register över avtalsarrangemang för IKT-tjänster, förhandsgranskning före avtal och bedömning av kritikalitet, koncentrationsrisk, lämplighet och intressekonflikter samt exitstrategier för IKT-tjänster som stödjer kritiska eller viktiga funktioner.

DORA Article 30 anger minsta avtalsvillkor för IKT, inklusive tjänstebeskrivningar, villkor för underleverantörer, platser för behandling och lagring av data, dataskydd, åtkomst, återställning och återlämnande av data, servicenivåer, incidentstöd, samarbete med myndigheter, uppsägningsrätt, revisionsrätt och övergångs- eller exitarrangemang.

En RoPA som inte identifierar leverantörer, platser, överföringsmetoder, kritikalitet och exitberoenden kommer inte att stödja underlag för DORA.

Kartläggning av leverantörer, moln och underbiträden är där underlag ofta brister

I verkliga revisioner visar sig RoPA-brister ofta som leverantörsbrister. Behandlingsaktiviteten säger ”kundsupport”. Dataflödeskartan säger ”supportplattform”. Men ingen kan identifiera driftregionen, AI-transkriberingsmodulen, analysunderbiträdet, bevarandet av ärendebilagor, modellen för administratörsåtkomst eller exitrutinen.

Clarysecs leverantörspolicy för små och medelstora företag skapar minsta operativa underlag. Policy för leverantörssäkerhet och tredjepartssäkerhet - SME anger:

Ett leverantörsregister ska upprätthållas och uppdateras av administrativ kontakt eller upphandlingskontakt. Det ska omfatta:

Detta kommer från Styrningskrav, klausul 5.4. Molnpolicyn tillför ett separat förteckningskrav. Policy för användning av molntjänster - SME anger:

Ett register över molntjänster ska upprätthållas av IT-leverantören eller GM. Det ska registrera:

Detta kommer från Styrningskrav, klausul 5.3. För beroenderisk i större organisationer är Clarysecs Policy för hantering av risker kopplade till leverantörsberoenden mer explicit:

Register över leverantörsberoenden: VMO ska upprätthålla ett aktuellt register över alla kritiska leverantörer, inklusive uppgifter såsom tillhandahållna tjänster/produkter, om leverantören är enda källa, tillgängliga alternativa leverantörer eller utbytbarhet, aktuella avtalsvillkor samt en bedömning av påverkan om leverantören skulle fallera eller komprometteras. Registret ska tydligt identifiera leverantörer med högt beroende (t.ex. sådana där inget snabbt alternativ finns).

Det kravet, från Genomförandekrav klausul 6.1, är exakt det som kopplar RoPA till NIS2:s säkerhet i leveranskedjan och DORA:s IKT-tredjepartsrisk.

Zenith Blueprint, fasen Kontroller i praktiken, steg 23, organisatoriska kontroller 5.19 till 5.37, rekommenderar att en komplett leverantörslista sammanställs, att leverantörer klassificeras utifrån åtkomst till system, data eller operativ kontroll, att säkerhetsförväntningar införs i avtal, att underleverantörer granskas, att utlösare för leverantörsändringar etableras och att en process för utvärdering av molntjänster byggs upp med täckning av dataplats, åtkomstmodell, loggning och kryptering.

Det är det som gör att en CISO under en incident kan svara: ”Vilken kritisk tjänst använder denna leverantör, vilka data exponerades, vilka kunder måste underrättas, vilken tillsynsmyndighet kan behöva en rapport och vilken alternativ leverantör eller exitväg finns?”

Ett praktiskt exempel: kundonboarding i fintech

Tänk på ett fintechbolag som tillhandahåller onboarding för digitala plånböcker. Kunder laddar upp identitetshandlingar, biometriska liveness-kontroller utförs av en leverantör, resultaten lagras i en molndatabas och kundsupport kan se verifieringsstatus i ett ärendehanteringsverktyg.

Onboardingtjänsten kan vara en kritisk eller viktig funktion enligt DORA eftersom en störning väsentligt påverkar tjänstekontinuitet och regulatoriska skyldigheter. Om företaget finns i en NIS2-sektor eller tillhandahåller relevanta IKT-tjänster kan den också ingå i underlaget för kritiska tjänster.

En användbar karta börjar med en sammanhållen post.

Lägg sedan till spårbarhet för riskbehandling enligt ISO/IEC 27001:2022.

I Zenith Blueprint, fasen Riskhantering, steg 13, Riskbehandlingsplanering och tillämpbarhetsförklaring, beskriver Clarysec SoA som ett bryggdokument som kopplar riskbedömning och riskbehandling till faktiska kontroller. Den rekommenderar att kontroller mappas till risker och att regelverk som GDPR, NIS2 eller DORA korsrefereras i riskregistret eller i SoA-anteckningar där det är relevant.

För onboardingexemplet kan riskscenariot vara: ”Avbrott eller kompromettering hos leverantören av identitetsverifiering stör onboarding och exponerar biometriska identitetsdata.” Behandlingskontrollerna kan omfatta leverantörsgranskning, avtalsmässig incidentanmälan, kryptering, åtkomstkontroll, loggning, säkerhetskopiering och återställning, dataminimering, pseudonymisering, övervakning, exitplanering och åtgärdsplaner för incidenthantering.

SoA-anteckningen kan ange att kontrolluppsättningen stödjer ansvarsskyldighet enligt GDPR, beredskap för leveranskedje- och incidenthantering enligt NIS2 Article 21 samt DORA:s IKT-tredjepartsrisk och resiliens för kritiska funktioner.

Det är detta revisorer vill se: spårbarhet.

Korsvis efterlevnadskartläggning: ett underlagslager, flera frågor

RoPA och kartläggning av dataflöden är inte separata efterlevnadssilor. De stödjer en gemensam uppsättning frågor över GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 och COBIT 2019.

NIST CSF 2.0 är användbart som organiserande lager. CSF-profilerna stödjer analys av nuläge och målläge med hjälp av indata såsom policyer, riskprioriteringar, register över affärskonsekvenser, krav, standarder, praxis, verktyg och arbetsroller. Funktionen GOVERN omfattar rättsliga, regulatoriska, avtalsmässiga, dataskyddsrelaterade och medborgerliga fri- och rättighetsrelaterade skyldigheter, riskmål, ledningens ansvarsskyldighet, roller, policy, tillsyn och granskning av prestation. Resultaten för leveranskedjan kräver att leverantörer är kända och prioriterade efter kritikalitet, att avtalsmässiga cybersäkerhetskrav integreras, att leverantörsgranskning sker före relationer, att leverantörsrisker registreras och övervakas samt att leverantörer inkluderas i planering för incidenthantering och återställning.

Det mappas tydligt till en Clarysec-operativ modell för RoPA. RoPA ger dataskyddskontext. Tillgångsförteckningen ger teknisk kontext. Leverantörs- och molnregistren ger tredjepartskontext. BIA ger kritikalitetskontext. SoA ger kontrollkontext.

En enda kontroll i ISO/IEC 27001:2022 bilaga A kan också stödja flera ramverk. Kontroll 5.14, Informationsöverföring, är ett bra exempel.

Detta är värdet av Zenith Controls som kompass för korsvis efterlevnad. Det hjälper organisationer att förklara varför en kontrollpraxis stödjer flera regulatoriska krav och revisionsförväntningar.

Hur olika revisorer kommer att testa samma karta

En mogen RoPA och dataflödeskarta kan tillgodose flera revisorer, men var och en kommer att närma sig den på olika sätt.

En ISO/IEC 27001:2022-revisor börjar med omfattning, intressenter, risker, dokumenterad information och kontrollurval. Revisorn kommer att fråga om rättsliga och avtalsmässiga krav har identifierats, om personuppgifter och kritiska tjänster ingår i ISMS-omfattningen, om tillgångar har ägare och klassificeringar, om riskbedömningen beaktade konfidentialitet, riktighet och tillgänglighet samt om SoA motiverar tillämpliga kontroller.

En GDPR-revisor eller dataskyddstillsynsmyndighet börjar med ansvarsskyldighet. Den kommer att testa om RoPA återspeglar faktisk behandling, om ändamål och rättsliga grunder är dokumenterade, om särskilda kategorier av personuppgifter är identifierade, om bevarandetider tillämpas, om mottagare och personuppgiftsbiträden är korrekta och om lämpliga skyddsåtgärder finns för överföringar och säkerhet.

En NIS2-inriktad revisor fokuserar på tjänstepåverkan. Den kommer att fråga hur organisationen fastställer kritiska eller viktiga tjänster, hur ledningen har godkänt och övervakar riskåtgärderna, hur leverantörssårbarheter och risker hos tjänsteleverantörer beaktas, hur kontinuitet och incidenthantering är kopplade samt om organisationen kan stödja tidslinjerna 24 timmar, 72 timmar och slutrapport med tillförlitligt underlag.

En DORA-revisor fokuserar på IKT-riskstyrning och kritiska eller viktiga funktioner. Den kommer att testa om ledningsorganet har godkänt IKT-riskramverket och resiliensstrategin, om IKT-tredjepartsarrangemang är registrerade, om kritikalitet och koncentrationsrisk bedöms, om avtal innehåller föreskrivna villkor, om testning omfattar system som stödjer kritiska eller viktiga funktioner och om incidenter klassificeras utifrån berörda kunder, transaktioner, avbrottstid, geografi, dataförlust, tjänstekritikalitet och ekonomisk påverkan.

En bedömare enligt NIST CSF 2.0 använder ofta profiler. Bedömaren jämför aktuella och önskade resultat inom GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER. RoPA och dataflödeskartor blir indata till hantering av rättsliga skyldigheter, tillgångsförteckningar, leverantörsrisk, dataskydd, övervakning, incidentkommunikation och återställningsplanering.

En COBIT 2019- eller ISACA-inriktad revisor fokuserar på styrning, ägarskap och processförmåga. Revisorn kommer att testa om informationsflöden har ägare, om beslutsrättigheter är tydliga, om riskaptit tillämpas, om kontroller övervakas, om undantag eskaleras och om underlaget är tillräckligt tillförlitligt för ledningens säkerställande.

Vanliga felmönster

De vanligaste bristerna i RoPA och kartläggning av dataflöden är förutsägbara.

För det första listar RoPA behandlingsaktiviteter men inte system. Det gör det omöjligt att koppla ansvarsskyldighet enligt GDPR till sårbarhetshantering, åtkomstgranskning, säkerhetskopiering, loggning eller incidenthantering.

För det andra stannar dataflödeskartor vid den första leverantören. De visar inte underbiträden, molnregioner, supportåtkomst, analysverktyg, övervakningsplattformar eller platser för säkerhetskopior.

För det tredje identifierar verksamhetskontinuitetsplaner system men inte personuppgifter. Under ett avbrott förstår organisationen återställningsprioriteten men inte dataskyddspåverkan.

För det fjärde fångar leverantörsregister avtalsägare men inte kritikalitet, utbytbarhet, datakategorier, skyldigheter för incidentanmälan eller exitalternativ.

För det femte skrivs SoA som ett certifieringsdokument snarare än som en kontrollbrygga. Den anger att kontroller är tillämpliga, men förklarar inte vilket underlagsproblem enligt GDPR, NIS2 eller DORA kontrollen hjälper till att lösa.

Slutligen är ägarskapet fragmenterat. DPO äger RoPA, IT äger tillgångar, upphandling äger leverantörer, drift äger BIA, ekonomi äger DORA-register och ingen äger den integrerade beroendekartan.

Clarysecs arbetssätt åtgärdar detta genom att tilldela underlagsobjekt till policyägare och sedan använda stegen i Zenith Blueprint för att koppla tillgångar, risker, kontroller och SoA-spårbarhet.

En genomförandeplan på 30 dagar

Ni behöver inte försöka göra allt på en gång. Börja med de tjänster som betyder mest.

Vecka 1: Välj tre kritiska behandlingsaktiviteter eller högriskbehandlingsaktiviteter. Bra kandidater är kundonboarding, betalningshantering, HR-administration, supportärenden eller säkerhetsövervakning. Validera RoPA-posten för varje aktivitet mot faktiska system, datakategorier, ändamål, rättsliga grunder och bevaranderegler.

Vecka 2: Bygg dataflödeskartor för dessa aktiviteter. Identifiera källa, destination, överföringsmetod, miljö, leverantör, underbiträde, dataplats, åtkomstväg, transformering och bevarandepunkt. Använd kravet i Clarysecs Policy för datamaskering och pseudonymisering på att upprätthålla förteckningar över system och dataflöden som omfattar känsliga data.

Vecka 3: Koppla varje flöde till tillgångar, leverantörer, molntjänster och kritiska verksamhetsfunktioner. Använd Zenith Blueprint steg 9 för tillgångsägarskap och klassificering. Använd policykraven för leverantörsregister och molnregister för att fånga tredjepartsunderlag. Använd policyn för verksamhetskontinuitet för att identifiera prioriterade tjänster och kritiska beroenden.

Vecka 4: Lägg till spårbarhet för risk och kontroller. Skapa eller uppdatera riskscenarier för varje flöde. Mappa kontroller i SoA med hjälp av Zenith Blueprint steg 13. Lägg till anteckningar för ansvarsskyldighet enligt GDPR Article 30, riskåtgärder enligt NIS2 Article 21 och underlag för DORA:s IKT-beroenden där det är tillämpligt.

Genomför sedan en skrivbordsövning: ”Leverantörsavbrott plus dataexponering i en kritisk tjänst.” Testa om ert underlag stödjer incidentklassificering, beslut om avisering, kundkommunikation, kommunikation med tillsynsmyndighet och prioritering av återställning.

Efter 30 dagar har ni en repeterbar modell för resten av organisationen.

Clarysec-metoden: gör RoPA till levande resiliensunderlag

RoPA och kartläggning av dataflöden är inte längre bara dataskyddsadministration. De är bindväven mellan ansvarsskyldighet enligt GDPR, styrning av kritiska tjänster enligt NIS2 och underlag för IKT-beroenden enligt DORA.

De organisationer som kommer att prestera bäst 2026 är inte de som har flest dokument. Det är de som kan spåra en verksamhetstjänst till dess behandlingsaktiviteter, dataflöden, system, leverantörer, molnregioner, avtal, kontroller, risker, incidenttrösklar och återställningsplaner.

Clarysec hjälper team att bygga den spårbarheten utan onödig byråkrati. Vår policysvit tilldelar ägarskap och krav på underlag. Zenith Blueprint ger färdplanen för genomförande, inklusive tillgångsidentifiering, införande av leverantörs- och molnkontroller samt SoA-spårbarhet. Zenith Controls ger kompassen för korsvis efterlevnad vid mappning av kontroller i ISO/IEC 27001:2022 bilaga A till förväntningar inom dataskydd, resiliens, leverantörer, moln och revision.

Nästa steg är enkelt: välj en kritisk tjänst, en RoPA-post och ett leverantörsstött dataflöde. Kartlägg det från början till slut. Om ni inte kan förklara data, beroende, kontroll och incidentpåverkan på en sida är ert underlagslager inte redo för 2026.

Clarysec kan hjälpa er att få det redo. Utforska Zenith Blueprint, stärk er styrning med Policy för dataskydd och integritet och Policy för hantering av risker kopplade till leverantörsberoenden, och använd Zenith Controls för att omvandla fragmenterat efterlevnadsunderlag till en samlad operativ modell med revisionsberedskap.