Styrning av personuppgifter för ISO 27701:2025 och GDPR

Begäran landade i CISO:ns inkorg med bedräglig enkelhet: ”Project Wellness.” Ett snabbväxande fintechbolag ville analysera befintliga kundtransaktionsdata för att erbjuda personliga spartips, produktrekommendationer och insikter om risk för kundbortfall. Marknadsföring såg kundengagemang. Produkt såg innovation. Ledningen såg en konkurrensfördel.
CISO:n såg en styrningsmässig landmina.
Transaktionsdata hade samlats in för betalningshantering enligt ett definierat ändamål och en rättslig grund. Nu ville verksamheten återanvända dem för analys av ekonomiskt välmående, kampanjpersonalisering och prediktiv poängsättning. För att påskynda leveransen ville teamet även skicka ett pseudonymiserat dataset till en tredjepartsleverantör av AI-analys.
Ingen angripare fanns i nätverket. Ingen databas hade läckt. Inget incidentärende blinkade rött.
Ändå är det precis här många brister i ansvarsskyldighet enligt GDPR börjar.
Frågan är inte om organisationen har ett integritetsmeddelande, ett dataskyddsombud, ett register över rättslig grund eller ett lagringsschema. Den djupare frågan är operativ: vem godkänner ny insamling av personuppgifter, vem bekräftar nödvändigheten, vem definierar tillåten intern användning, vem avgör om sekundär användning är förenlig, vem godkänner utlämnande till en leverantör och vem kan styrka beslutet i efterhand?
Det är den kontrolluckan som införanden av ISO/IEC 27701:2025 ledningssystem för hantering av integritetsinformation, eller PIMS, måste stänga. GDPR Article 5 kräver att personuppgifter behandlas lagligt, korrekt och öppet, samlas in för särskilda, uttryckliga och berättigade ändamål, begränsas till vad som är nödvändigt, är korrekta, bevaras endast så länge det behövs, skyddas på lämpligt sätt och hanteras under den personuppgiftsansvariges ansvarsskyldighet. GDPR Article 6 tillför logik för rättslig grund och förenlighet vid vidarebehandling. Men dessa principer blir försvarbara först när de översätts till arbetsflöden, register, godkännanden, åtkomstregler, leverantörskontroller, övervakning och underlag.
Clarysecs ansats är enkel: behandla styrning av insamling, användning och utlämnande av personuppgifter som en kontrollerad operativ modell, inte som ett juridiskt PM. Modellen vilar på ryggraden i ett ISO/IEC 27001:2022 ISMS, utvidgas med roller i ISO/IEC 27701:2025 PIMS och styrks genom Clarysecs policyer, register, Zenith Blueprint: en 30-stegs färdplan för revisorer och Zenith Controls: vägledning för mappning mellan efterlevnadskrav.
Varför styrning av personuppgifter brister även när integritetsdokument finns
De flesta integritetsprogram misslyckas inte för att ingen känner till GDPR. De misslyckas för att integritetsbeslut fattas i produktärenden, e-post om leverantörsonboarding, kalkylbladsexporter, experiment i kontrollpaneler och AI-piloter utan en upprepbar kontrollgrind.
Ett typiskt mönster känns igen:
- Ett team lägger till ett nytt fält i ett registreringsformulär eftersom det förbättrar segmenteringen.
- Ingen dokumenterar varför just det fältet är nödvändigt.
- Ett annat team återanvänder senare uppgifterna för ett annat ändamål.
- En leverantör får en export enligt ett brett tjänsteavtal.
- Behandlingsförteckningen uppdateras efter lansering, om den uppdateras alls.
- Vid revision kan organisationen visa ett integritetsmeddelande men inte beslutsunderlaget.
GDPR Articles 4 och 5 definierar behandling brett. Insamling, registrering, lagring, användning, utlämnande, radering och förstöring räknas alla som behandling. Article 5 gör också ansvarsskyldigheten uttrycklig. Personuppgiftsansvariga måste kunna visa efterlevnad av principerna.
Det innebär att revisionsfrågan inte bara är: ”Har ni en policy?” Den är: ”Visa hur detta specifika dataelement godkändes, varför det behövdes, hur det användes, vem som tog emot det och vilka kontroller som förhindrade missbruk.”
Clarysec P17 Policy för dataskydd och integritet anger tydligt förväntan på livscykelstyrning:
Den formaliserar organisationens ansvar enligt internationella standarder och regulatoriska ramverk och säkerställer att personuppgifter (PII) samlas in, behandlas, bevaras, delas och raderas lagligt, säkert och öppet.
För små och medelstora företag gör Clarysec Policy för dataskydd och integritet – SME samma princip till en pragmatisk operativ regel:
Personuppgifter får endast samlas in när det är nödvändigt för ett berättigat, lagligt eller avtalsenligt ändamål
Och för uppgiftsminimering:
Endast den minsta mängd personuppgifter som är nödvändig ska samlas in och bevaras
Dessa uttalanden är kraftfulla endast när de tillämpas innan behandlingen börjar. Annars förblir de integritetsspråk utan operativt underlag.
Kontrollmålet: stoppa okontrollerad behandling vid tre grindar
Ett starkt PIMS bör styra beslut om personuppgifter vid tre tidpunkter: före insamling, före användning och före utlämnande.
Före insamling måste organisationen veta vad den vill samla in, från vem, genom vilken kanal, för vilket ändamål, enligt vilken rättslig grund och varför varje fält är nödvändigt.
Före användning måste organisationen definiera regler för tillåten intern användning. Support, kundteam, marknadsföring, bedrägeriförebyggande, ekonomi och utveckling behöver sällan samma insyn eller samma rätt att agera på personuppgifter.
Före utlämnande måste organisationen veta vem mottagaren är, vilken roll mottagaren har, varför utlämnandet är nödvändigt, var behandlingen sker, vilka kategorier av personuppgifter som delas, hur ofta delning sker och vilken behörighetsgrund som tillåter delningen.
Clarysec PII09 Policy för insamling, användning, utlämnande och delning av personuppgifter är utformad för detta styrningslager. Den använder rolltaggning i PIMS, särskilt rollen som personuppgiftsansvarig, eftersom beslut om insamling, användning och utlämnande normalt ligger hos den organisation som fastställer ändamål och medel.
För begränsning av insamling kräver PII09 Policy för insamling, användning, utlämnande och delning av personuppgifter:
[Personuppgiftsansvarig] Processägaren / verksamhetsägaren SKA registrera insamlingsändamål, källa eller kanal, kategorier av personuppgifter, kategorier av registrerade och minsta dataelement i REG02 innan någon ny insamlingsaktivitet eller väsentlig ändring av insamling påbörjas.
Därefter gör den uppgiftsminimering testbar:
[Personuppgiftsansvarig] Processägaren / verksamhetsägaren SKA registrera en nödvändighetsmotivering i REG02 för varje dataelement med personuppgifter innan elementet samlas in.
Kravet på ”varje dataelement med personuppgifter” är skillnaden mellan en generisk behandlingsförteckning och underlag för ansvarsskyldighet på fältnivå.
För intern användning kräver samma policy:
[Personuppgiftsansvarig] Processägaren / verksamhetsägaren SKA registrera godkända regler för intern användning för varje behandlingsaktivitet i REG02 innan användningen påbörjas.
För sekundär användning:
[Personuppgiftsansvarig] Processägaren / verksamhetsägaren SKA registrera en förenlighetsbedömning för sekundär användning i REG02 innan personuppgifter används för ett ändamål som inte redan har godkänts för behandlingsaktiviteten.
Och för externt utlämnande:
[Personuppgiftsansvarig] Leverantörsansvarig / upphandlingsansvarig SKA registrera mottagarens identitet, mottagarens roll, utlämnandets ändamål, kategorier av personuppgifter, delningsfrekvens, behandlingsplats och behörighetsgrund i REG08 innan återkommande extern delning påbörjas.
Dessa klausuler ger ett tydligt svar när ledningen frågar om verksamheten kan innovera snabbt: ja, om beslutet passerar ett dokumenterat styrningsarbetsflöde och kontrollerna motsvarar godkännandet.
REG02 och REG08: Clarysecs kedja från policy till kontroll
I Clarysec-införanden är REG02 inte en passiv behandlingsförteckning. Det är beslutsunderlaget för insamlingsändamål, rättslig grund, kategorier av personuppgifter, nödvändighet, regler för intern användning, koppling till lagring och förenlighet vid sekundär användning.
REG08 är kontrollregistret för utlämnande och delning. Det är särskilt viktigt för leverantörer, partner, koncernbolag, myndigheter, underbiträden, integrationer och återkommande exporter.
Tillsammans skapar de en kedja från policy till kontroll som kan testas av dataskydds-, säkerhets-, upphandlings- och revisionsteam.
| Styrningsfråga | Underlagsartefakt | Policyutlösare i Clarysec | Praktiskt kontrollresultat |
|---|---|---|---|
| Vilka personuppgifter samlar vi in? | REG02 behandlingspost | PII09 klausul 4.1.1 | Insamlingen definieras före lansering |
| Varför behövs varje fält? | REG02 nödvändighetsmotivering per dataelement | PII09 klausul 4.1.3 | Uppgiftsminimering styrks |
| Hur får team använda personuppgifterna? | REG02 regler för intern användning | PII09 klausul 4.2.1 | Åtkomst och användning är ändamålsbundna |
| Kan vi återanvända personuppgifter för ett nytt ändamål? | REG02 förenlighetsbedömning | PII09 klausul 4.3.1 | Sekundär användning godkänns, villkoras eller blockeras |
| Vem tar emot personuppgifter externt? | REG08 utlämnandepost | PII09 klausul 4.4.2 | Utlämnandet är spårbart och godkänt |
| Begränsas leverantörer enligt principen om behovsstyrd åtkomst? | Leverantörens åtkomstgranskning | Tredjepartspolicy klausul 6.2.1 | Leverantörsåtkomst minimeras |
Denna modell ligger naturligt i linje med ISO/IEC 27001:2022. Klausulerna 4 till 10 kräver att organisationen förstår kontext, krav från intressenter, omfattning, ledningens ansvar, riskbedömning, riskbehandling, operativ styrning, utvärdering av prestation och förbättring. Dataskyddsskyldigheter enligt GDPR och ISO/IEC 27701:2025 blir en del av ledningssystemet i stället för en separat integritetsö.
ISO/IEC 27002:2022 stödjer också den operativa modellen. Kontroll 5.31, rättsliga, regulatoriska och avtalsmässiga krav, förankrar GDPR och sektorskrav. Kontroll 5.34, integritet och skydd av personuppgifter, hanterar integritetsspecifikt skydd. Kontroll 5.9, förteckning över information och andra associerade tillgångar, stödjer datamedvetenhet. Kontrollerna 5.12 och 5.13 stödjer klassificering och märkning. Kontroll 5.14 styr informationsöverföring. Kontrollerna 5.19 till 5.23 omfattar leverantörsrelationer, leverantörsavtal, IKT-leveranskedja, övervakning av leverantörstjänster och molntjänster. Kontroll 8.11 stödjer datamaskering, 8.12 stödjer förebyggande av dataläckage, 8.15 loggning, 8.16 övervakningsaktiviteter och 8.24 användning av kryptografi.
Zenith Blueprint placerar dessa kontroller i en genomförandeväg. I fasen Controls in Action omfattar steg 23 organisatoriska kontroller 5.19 till 5.37, inklusive kontroll 5.34 för integritet och skydd av personuppgifter. Blueprint förklarar:
I dagens datadrivna värld är personligt identifierbar information inte bara en annan datatyp, utan en djupt känslig representation av förtroende. Namn, adresser, ID-handlingar, hälsouppgifter och finansiella uppgifter berättar en historia om verkliga människor.
Därefter anger den den operativa baslinjen:
Grunden för denna kontroll är datamedvetenhet. Organisationen måste veta vilka personuppgifter den samlar in, var de finns, varför de behandlas och vem som kan få åtkomst till dem.
Det är vad REG02 och REG08 ger när de behandlas som levande styrningsposter.
Praktiskt exempel: godkänna Project Wellness utan att tappa kontroll
Återgå till fintechscenariot. Verksamheten vill analysera kundtransaktionsdata för personliga rekommendationer om ekonomiskt välmående. Marknadsföring vill använda resultaten för kampanjer. Produkt vill bygga poäng för kundbortfall och engagemang. En tredjepartsplattform för AI-analys ska behandla en del av datasetet.
Så här skulle Clarysec styra begäran.
Steg 1: Skapa eller uppdatera behandlingsaktiviteten i REG02
Processägaren öppnar REG02 och registrerar behandlingsaktiviteten innan arbetet påbörjas.
| REG02-fält | Exempel för Project Wellness |
|---|---|
| Behandlingsaktivitet | Analys av ekonomiskt välmående och rekommendationsfunktion |
| Primärt ändamål | Ge kunder anpassade sparinsikter och produktvägledning |
| Kategorier av registrerade | Privatkunder, kontoinnehavare, behöriga användare |
| Kategorier av personuppgifter | Transaktionskategori, transaktionsbelopp, transaktionsdatum, kontostatus, produktinnehav |
| Källa eller kanal | Betalningsplattform, kundkontoposter, system för produktanvändning |
| Rättslig grund | Fastställs av integritetsjurist eller dataskyddsansvarig utifrån personuppgiftsansvarigs kontext |
| Lagring | Kopplas till godkänt lagringsschema |
| Regler för intern användning | Produkt får använda aggregerade insikter; marknadsföring kräver godkännande av sekundär användning; utveckling ska använda maskerade dataset |
Den viktiga punkten är tidpunkten. REG02 uppdateras innan ny behandling börjar, inte efter att funktionen redan är i produktion.
Steg 2: Registrera nödvändighetsmotiveringar på fältnivå
Marknadsföring begär inledningsvis fem års fullständig transaktionshistorik, inklusive handlarnamn, exakta tidsstämplar, kortmetadata och kundprofilattribut. Styrningsteamet ifrågasätter varje fält.
| PII-element | Nödvändighetsmotivering | Beslut |
|---|---|---|
| Transaktionskategori | Behövs för att identifiera utgiftsmönster för spartips | Godkänt |
| Transaktionsbelopp | Behövs för att beräkna trendintervall och rekommendationers relevans | Godkänt med aggregeringströsklar |
| Transaktionsdatum | Behövs för trendanalys | Godkänt på månadsnivå där det är möjligt |
| Handlarnamn | Krävs inte för första releasen och ökar återidentifieringsrisken | Avslås |
| Exakt tidsstämpel | Inte nödvändigt för rekommendationer om ekonomiskt välmående | Avslås |
| Kundens e-postadress | Behövs endast för koppling till konto, inte för modellträning | Begränsas |
| Produktinnehav | Behövs för att undvika irrelevanta rekommendationer | Godkänt med åtkomstbegränsningar |
Detta är uppgiftsminimering som underlag, inte som ambition. Verksamheten får fortfarande användbar analys, men datasetet begränsas till vad som är nödvändigt för det godkända ändamålet.
Steg 3: Klassificera och märk datasetet
Datasetet klassificeras enligt Clarysec policy för dataklassificering och märkning. SME-versionen kräver:
Extern delning ska uttryckligen godkännas och loggas.
Organisationens policy för dataklassificering och märkning lägger till en skyddsåtgärd för känslig information:
Får endast delas externt enligt ett NDA eller likvärdiga avtalsmässiga skyddsåtgärder
I praktiken kan Project Wellness-datasetet inte exporteras slentrianmässigt till en AI-plattform. Det behöver en godkänd utlämnandepost, avtalsmässiga skyddsåtgärder, tekniska kontroller för överföring och loggar.
Zenith Blueprint, i steg 22 för kontroll 5.12 klassificering av information, förklarar varför detta är viktigt:
Varje informationssäkerhetskontroll som någonsin skrivits – åtkomstbegränsning, kryptering, säkerhetskopiering, övervakning eller radering – förutsätter en sak: att organisationen vet vad den skyddar.
Utan klassificering blir åtkomstbegränsningar, kryptering, DLP och lagringsregler gissningar.
Steg 4: Definiera regler för intern användning före produktionssättning
Processägaren registrerar godkända regler för intern användning i REG02. Det är här ändamålsglidning ofta stoppas.
En försvarbar regeluppsättning kan ange:
- Produkt får använda aggregerade mätetal för rekommendationsprestanda.
- Kundsupport får se om en rekommendation visades för en kund vid hantering av ett supportärende.
- Marknadsföring får inte använda poäng för ekonomiskt välmående på individnivå för kampanjsegmentering om inte en förenlighetsbedömning för sekundär användning har slutförts.
- Ekonomi får inte åtkomst till detaljerad analys av ekonomiskt välmående om det inte finns ett separat godkänt ändamål.
- Utvecklare får inte använda personuppgifter från produktion i testmiljöer.
- Utvärdering av AI-modeller ska använda maskerade, pseudonymiserade eller aggregerade dataset där det är möjligt.
De två sista reglerna kopplar till ISO/IEC 27002:2022 kontroll 8.11, datamaskering. Zenith Blueprint, steg 19, beskriver datamaskering som en praktisk metod för att förhindra onödig exponering i testmiljöer, utbildningsdataset, analysplattformar, tredjepartsintegrationer och CI/CD-testpipelines.
Steg 5: Genomför förenlighetsbedömningen för sekundär användning
Marknadsföring begär senare att få använda wellness-poäng för riktade kampanjer. Det är ett nytt ändamål. Enligt PII09 Policy för insamling, användning, utlämnande och delning av personuppgifter klausul 4.3.1 ska verksamhetsägaren registrera en förenlighetsbedömning i REG02 innan den nya användningen påbörjas.
Bedömningen bör omfatta:
- Om marknadsföring kopplad till ekonomiskt välmående är förenlig med det ursprungliga behandlingsändamålet.
- Vad kunderna informerades om vid insamlingen och i integritetsmeddelandet.
- Om slutsatser härledda från transaktioner kan vara känsliga eller oväntade.
- Om den nya användningen kan skapa press, exkludering eller otillbörlig profilering.
- Om skyddsåtgärder som aggregering, opt-out, pseudonymisering eller segmentering på kontonivå minskar risken.
- Om den rättsliga grunden fortfarande är giltig.
- Om transparensuppdateringar eller samtyckesmekanismer krävs.
Utfallet kan vara godkännande, godkännande med skyddsåtgärder eller avslag. Värdet ligger i att beslutet dokumenteras innan användningen börjar.
Steg 6: Godkänn externt utlämnande genom REG08
Om leverantören av AI-analys ska ta emot data registrerar leverantörsansvarig eller upphandlingsansvarig följande i REG08:
| REG08-fält | Nödvändigt beslutsunderlag |
|---|---|
| Mottagarens identitet | Juridiskt namn, tjänsteägare och leverantörskontakt |
| Mottagarens roll | Personuppgiftsbiträde, underbiträde, självständig personuppgiftsansvarig eller gemensamt personuppgiftsansvarig |
| Utlämnandets ändamål | Definierat analysändamål kopplat till Project Wellness |
| Kategorier av personuppgifter | Endast godkända fält, med undantag för avslagna dataelement |
| Delningsfrekvens | Engångsöverföring, batchfrekvens eller API-flöde |
| Behandlingsplats | Länder och driftregioner |
| Behörighetsgrund | Avtal, personuppgiftsbiträdesavtal, dokumenterad instruktion eller annan godkänd grund |
| Säkerhetskrav | Kryptering, åtkomstbegränsning, loggning, radering och incidentanmälan |
| Exit-krav | Återlämnande, radering, stöd vid övergång och revisionsunderlag |
Clarysec policy för leverantörssäkerhet och tredjepartssäkerhet – SME förstärker minimerad leverantörsåtkomst:
Leverantörer ska endast beviljas åtkomst till de minsta system och data som krävs för att utföra sin funktion.
Detta är integritetsrelaterad minimering tillämpad på leverantörsåtkomst och utlämnande.
Steg 7: Lägg till teknisk efterlevnadskontroll
Styrningsposter måste stödjas av tekniska kontroller. För Project Wellness skulle Clarysec normalt rekommendera DLP-regler för exporter, rollbaserade åtkomstbegränsningar, loggning av åtkomst- och överföringshändelser, maskerade dataset för utveckling, kryptering för överföring och lagring, leverantörsåtkomstgranskningar, granskning av leverantörers molnsäkerhet och periodiska stickprov där REG02 och REG08 jämförs med faktiskt systembeteende.
Det är så ansvarsskyldighet enligt ISO/IEC 27701:2025 och GDPR blir operativt underlag.
Kontrollmappning: från integritetsbeslut till säkerhetstillämpning
Styrning av personuppgifter är inte en isolerad kontroll. Den är en relation mellan integritetskrav, säkerhetskontroller, leverantörsstyrning och revisionsunderlag.
Zenith Controls behandlar ISO/IEC 27002:2022 kontroll 5.34, integritet och skydd av personuppgifter, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, med cybersäkerhetsbegreppen Identify och Protect samt operativa förmågor inom informationsskydd, juridik och regelefterlevnad.
För 5.34 kartlägger Zenith Controls det omgivande kontrollekosystemet, inklusive förteckning, klassificering, överföring, åtkomst, identitet, moln, leverantörssäkerhet, maskering, förebyggande av dataläckage, loggning, övervakning och kryptografi.
| ISO/IEC 27002:2022-kontroll | Kontrollnamn | Varför den är viktig för styrning av personuppgifter |
|---|---|---|
| 5.9 | Förteckning över information och andra associerade tillgångar | Innehav av personuppgifter måste vara kända innan de kan skyddas |
| 5.12 | Klassificering av information | Personuppgifter måste klassificeras efter känslighet och hanteringskrav |
| 5.13 | Märkning av information | Etiketter bidrar till att tillämpa regler för hantering, delning och lagring |
| 5.14 | Informationsöverföring | Förflyttning av personuppgifter måste vara godkänd, skyddad och spårbar |
| 5.15 | Åtkomstkontroll | Åtkomst till personuppgifter måste begränsas till godkända roller och ändamål |
| 5.16 | Identitetshantering | Användare och tjänsteidentiteter som får åtkomst till personuppgifter måste styras |
| 5.19 | Informationssäkerhet i leverantörsrelationer | Leverantörsrisker kopplade till personuppgifter måste identifieras och kontrolleras |
| 5.20 | Informationssäkerhet i leverantörsavtal | Avtal måste innehålla säkerhets- och integritetskrav |
| 5.21 | Hantering av informationssäkerhet i IKT-leveranskedjan | Nedströms IKT-risker och underbiträdesrisker måste hanteras |
| 5.22 | Övervakning, granskning och ändringshantering av leverantörstjänster | Leverantörstjänster måste granskas och ändringar bedömas |
| 5.23 | Informationssäkerhet vid användning av molntjänster | SaaS och behandling av personuppgifter i molntjänster måste styras |
| 5.31 | Rättsliga, regulatoriska och avtalsmässiga krav | GDPR, DORA, NIS2 och kundkrav måste identifieras |
| 5.34 | Integritet och skydd av personuppgifter | Skydd av personuppgifter måste genomföras enligt integritetskrav |
| 8.11 | Datamaskering | Verkliga personuppgifter bör döljas när fullständiga data inte behövs |
| 8.12 | Förebyggande av dataläckage | Otillåten förflyttning av personuppgifter bör upptäckas och förhindras |
| 8.15 | Loggning | Åtkomst, ändringar och överföringar bör kunna styrkas |
| 8.16 | Övervakningsaktiviteter | Misstänkt eller otillåten aktivitet bör upptäckas |
| 8.24 | Användning av kryptografi | Personuppgifter bör skyddas vid lagring och överföring där det krävs |
För maskering anger Zenith Controls:
Datamaskering (8.11) är en teknik som ofta används för att skydda personuppgifter i icke-produktionsmiljöer eller vid delning av data. Den stödjer 5.34 direkt genom att minska exponeringen av verkliga personuppgifter och därmed sänka integritetsrisken.
För förebyggande av dataläckage förklarar vägledningen den praktiska gränsen:
DLP spelar en direkt roll i att skydda personuppgifter. Kontroll 8.12 tillämpar gränser för hur personuppgifter får åtkomst, delas eller flyttas och säkerställer att personuppgifter inte kan läcka via otillåtna kanaler.
En revisor som testar styrning av utlämnanden kan därför begära inte bara REG08, utan även DLP-policyer, loggar över blockerade överföringar, kontroller för utgående e-post, begränsningar för molndelning, krypteringskrav, registerposter över leverantörsåtkomst och underlag för godkända undantag.
Värde för mappning mellan efterlevnadskrav: GDPR, ISO 27701, NIS2, DORA, NIST och COBIT
Styrning av insamling, användning och utlämnande av personuppgifter leds av dataskyddskraven, men dess underlag stödjer bredare skyldigheter inom cybersäkerhet, resiliens och styrning.
GDPR Articles 2 och 3 definierar ett brett materiellt och territoriellt tillämpningsområde, vilket kan omfatta SaaS, fintech och digitala tjänsteleverantörer utanför EU när de betjänar eller övervakar personer i EU. Article 5 kräver ändamålsbegränsning, uppgiftsminimering, riktighet, lagringsminimering, integritet, konfidentialitet och ansvarsskyldighet. Article 6 kräver rättslig grund och förenlighetsbedömning för vidarebehandling. Article 9 lägger till strängare villkor för särskilda kategorier av personuppgifter, vilket är relevant när profilering, hälsorelaterade data, biometrisk onboarding eller känsliga attribut förekommer.
NIS2 Article 21 kräver att väsentliga och viktiga entiteter genomför proportionerliga tekniska, operativa och organisatoriska riskhanteringsåtgärder. Minimiområdena omfattar riskanalys, policyer för informationssystemsäkerhet, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, kontrolleffektivitet, utbildning, kryptografi, personalsäkerhet, åtkomstkontroll, tillgångshantering och autentisering.
DORA kräver att finansiella entiteter upprätthåller ett ramverk för IKT-riskhantering, ansvarsskyldighet för ledningsorganet, identifiering av IKT-tillgångar och beroenden, skydds- och förebyggandekontroller, detektering, respons, återhämtning, säkerhetskopiering, lärande, incidenthantering, testning och riskhantering för IKT-tredjepart. Den kräver också informationsregister för IKT-tjänsteavtal, leverantörsgranskning, revisionsrätt, säkerhetskrav och exitstrategier.
NIST Cybersecurity Framework 2.0 ger ett integrerande styrningsspråk. Funktionen GOVERN förutsätter att rättsliga, regulatoriska och avtalsmässiga krav, inklusive integritetskrav, förstås och hanteras. Den omfattar även riskstrategi, roller, policyer, tillsyn och leverantörsriskhantering.
COBIT 2019-revisorer söker styrningsmål, beslutanderätt, ansvarsskyldighet, processägarskap, prestandaindikatorer och försäkransunderlag. För styrning av personuppgifter innebär det att integritetskrav måste bäddas in i företagsstyrningen, inte hanteras som en sidoprocess.
| Ramverk eller regelverk | Vad det förväntar sig | Clarysec-underlag som hjälper |
|---|---|---|
| ISO/IEC 27701:2025 PIMS | Rollbaserad integritetsstyrning för skyldigheter som personuppgiftsansvarig och personuppgiftsbiträde | PII09-klausuler, REG02, REG08, integritetsroller, förenlighetsbedömningar |
| GDPR | Ändamålsbegränsning, uppgiftsminimering, rättslig grund, ansvarsskyldighet och säker behandling | Nödvändighetsmotiveringar, regler för intern användning, godkännanden av utlämnande, DLP, åtkomstloggar |
| ISO/IEC 27001:2022 och ISO/IEC 27002:2022 | Riskbaserade ISMS-kontroller för personuppgifter, leverantörer, överföringar, åtkomst, maskering och övervakning | Tillämplighetsförklaring (Statement of Applicability), riskbehandlingsplan, 5.34, 5.12, 5.14, 8.11, 8.12 |
| NIS2 | Operativa och organisatoriska cybersäkerhetsåtgärder, leverantörssäkerhet och ledningens ansvarsskyldighet | Tillgångsförteckning, leverantörskontroller, incident- och övervakningskontroller, styrelserapportering |
| DORA | IKT-riskhantering, dataskydd, tredjepartsrisk, resiliensövning och revisionsrätt | Leverantörsregister, avtalsklausuler, åtkomstkontroller, testunderlag, utlämnandeloggar |
| NIST CSF 2.0 | Styrning, rättsliga krav, riskhantering och dataskyddsresultat | Current Profile, Target Profile, policymappning, riskregister, kontrollåtgärdsplan |
| COBIT 2019 | Ansvarsskyldighet i styrning, processägarskap, försäkran och prestationsövervakning | RACI, kontroll-KPI:er, revisionsurval, protokoll från ledningens genomgång, undantagsuppföljning |
Hur revisorer testar samma styrningslager
Ett starkt PIMS-införande bör klara olika revisionsstilar.
En revisor för ISO/IEC 27001:2022 och ISO/IEC 27701:2025 börjar med omfattning, intressenter, rättsliga och avtalsmässiga krav, riskbedömning, tillämplighetsförklaring (Statement of Applicability), operativ planering och dokumenterat underlag. Revisorn kan ta stickprov på behandlingsaktiviteter från REG02 och testa om kontroller som 5.34, 5.12, 5.14, 5.19 till 5.23, 8.11, 8.12, 8.15, 8.16 och 8.24 är genomförda och övervakade.
En GDPR-inriktad revisor eller tillsynsmyndighet testar ansvarsskyldighet. De kan börja med ett integritetsmeddelande, ett klagomål, en begäran från registrerad eller ett leverantörsutlämnande och sedan spåra bakåt. Varför samlades dessa uppgifter in? Vilken rättslig grund tillämpades? Var ändamålet specificerat? Var den senare användningen förenlig? Var mottagaren godkänd? Informerades de registrerade? Uppdaterades posterna innan behandlingen började?
En tillsynsmyndighet enligt DORA, där det är tillämpligt, fokuserar på IKT-stödda verksamhetsfunktioner, IKT-tredjepartsleverantörer, avtalsklausuler, revisionsrätt, dataskydd, incidentkommunikation, resiliensövning och exitplanering. Om kundpersonuppgifter delas med en kritisk analys- eller molnleverantör blir REG08, leverantörsgranskning och avtalskontroller centrala underlag.
En NIST CSF-bedömare ramar in frågan genom styrningsresultat. Hanteras rättsliga och regulatoriska krav? Är roller och ansvar tydliga? Underhålls och tillämpas policyer? Styrs leverantörsrisker? Fungerar dataskydd, övervakning och respons?
En COBIT- eller ISACA-liknande revisor frågar om beslutanderätt är definierad, om verksamhetsägare accepterar integritetsrisk, om kontrollprestanda mäts, om undantag följs upp och om ledningen får meningsfull rapportering.
| Revisorsprofil | Centrala fokusområden | Underlag de kommer att kräva |
|---|---|---|
| ISO 27001- och ISO 27701-revisor | Integrering av ISMS och PIMS, kontrolleffektivitet, dokumenterat underlag | REG02, REG08, tillämplighetsförklaring (Statement of Applicability), riskbehandling, underlag för 5.34, maskeringsposter |
| GDPR-tillsynsmyndighet | Rättslig grund, ändamålsbegränsning, uppgiftsminimering, transparens, ansvarsskyldighet | Förenlighetsbedömningar, nödvändighetsmotiveringar, integritetsmeddelanden, godkännanden av utlämnande |
| DORA-tillsynsmyndighet | IKT-risk, tredjepartsresiliens, styrelsetillsyn, avtalskontroller | Leverantörsgranskning, IKT-avtalsregister, revisionsrätt, exitplan, incidentrutiner |
| NIS2-bedömare | Cybersäkerhetsriskåtgärder, leveranskedja, incidentberedskap, ledningens ansvarsskyldighet | Leverantörsgranskningar, övervakningsunderlag, åtkomstkontroller, tillgångsförteckning, incidentåtgärdsplaner |
| COBIT- eller ISACA-revisor | Styrningsmognad, roller, processägarskap, mätetal, försäkran | RACI, styrningsprotokoll, KPI:er, undantagsuppföljning, poster från ledningens genomgång |
Vanliga fallgropar som Clarysec ser i införanden
Den första fallgropen är att behandla behandlingsförteckningen som en dokumentationsövning i stället för en godkännandegrind. Om REG02 uppdateras efter lansering kan den inte styrka föregående styrning.
Den andra är vaga ändamålsformuleringar. ”Analys”, ”tjänsteförbättring” eller ”kundinsikt” är sällan tillräckligt specifikt för att styra intern användning eller sekundär användning.
Den tredje är avsaknad av nödvändighet på fältnivå. Uppgiftsminimering kan inte bevisas genom att säga att varje fält är användbart. Verksamheten måste förklara varför varje fält är nödvändigt för det godkända ändamålet.
Den fjärde är okontrollerad sekundär användning. Data som samlats in för kontoadministration blir i tysthet säljinformation, sedan marknadssegmentering och därefter AI-träning. Varje ändring av ändamål kräver förenlighetsanalys och i vissa fall en ny rättslig grund eller uppdaterad transparens.
Den femte är svag styrning av utlämnanden. Leverantörslistor är inte detsamma som utlämnandeposter. REG08 binder samman mottagare, roll, ändamål, kategorier av personuppgifter, plats, frekvens och behörighetsgrund i ett samlat godkännandespår.
Den sjätte är avsaknad av teknisk efterlevnadskontroll. Policyer kan säga att personuppgifter inte ska lämna godkända kanaler, men e-post, exporter, delade enheter och analysverktyg tillåter ofta detta. Det är här ISO/IEC 27002:2022-kontrollerna 5.14, 8.12, 8.15, 8.16 och 8.24 blir avgörande.
En praktisk startplan på 30 dagar
Organisationer behöver inte koka havet. Börja med en högriskbehandlingsaktivitet, helst en som omfattar kundprofilering, AI-analys, känsliga attribut, gränsöverskridande överföring eller en tredjepartsplattform.
Under den första veckan identifieras behandlingsaktiviteten, ägaren, kategorier av personuppgifter, system, leverantörer och aktuellt ändamål. Bekräfta om aktiviteten redan finns i REG02 och om utlämnande finns i REG08.
Under den andra veckan slutförs nödvändighetsmotiveringar på fältnivå. Ifrågasätt överflödiga dataelement. Bekräfta klassificering och märkning. Identifiera om maskering, aggregering eller pseudonymisering kan minska risken.
Under den tredje veckan definieras regler för intern användning och eventuella förenlighetsbedömningar för sekundär användning genomförs. Avgör om integritetsmeddelanden, bedömningar av rättslig grund eller kontroller för registrerade behöver uppdateras.
Under den fjärde veckan valideras poster för externt utlämnande, leverantörsåtkomst, avtalsmässiga skyddsåtgärder, villkor i personuppgiftsbiträdesavtal, överföringskontroller, loggning, DLP och raderingsskyldigheter. Ta därefter stickprov på faktiskt systembeteende mot godkännandena.
Efter 30 dagar bör ledningen ha ett konkret underlagspaket: REG02, REG08, klassificeringsposter, åtkomstmatriser, DLP- och loggningsunderlag, leverantörsgranskning, avtalsmässiga skyddsåtgärder, förenlighetsbedömningar och öppna avhjälpande åtgärder.
Från policy till bevis
Styrning av insamling, användning och utlämnande av personuppgifter är där dataskydd blir verkligt. Det är skillnaden mellan att säga ”vi följer GDPR” och att bevisa att varje beslut om insamling, användning, återanvändning och utlämnande var kontrollerat innan behandlingen skedde.
Clarysecs verktygssats ger dataskydds-, säkerhets- och regelefterlevnadsteam en praktisk väg:
- Använd PII09 Policy för insamling, användning, utlämnande och delning av personuppgifter för att definiera obligatoriska godkännandegrindar.
- Använd P17 Policy för dataskydd och integritet eller Policy för dataskydd och integritet – SME för att förankra laglig, korrekt, öppen och minimerad behandling.
- Använd policy för dataklassificering och märkning och policy för leverantörssäkerhet och tredjepartssäkerhet – SME för att styra klassificering, delning och leverantörsåtkomst.
- Följ Zenith Blueprint: en 30-stegs färdplan för revisorer för att införa kontrollmiljön i rätt ordning.
- Använd Zenith Controls: vägledning för mappning mellan efterlevnadskrav för att förstå hur ISO/IEC 27002:2022-kontroller som 5.34, 5.12, 5.14, 8.11 och 8.12 stödjer GDPR, NIS2, DORA, NIST och revisionsförväntningar.
Om nästa revision, kundgranskning eller styrelsegenomgång frågar hur ni styr vilka personuppgifter som samlas in, hur de används och när de lämnas ut, förlita er inte enbart på policyuttalanden.
Börja med en högriskaktivitet. Bygg REG02-posten. Motivera varje dataelement. Definiera regler för intern användning. Genomför förenlighetsbedömningen för sekundär användning. Skapa REG08-utlämnandeposten. Testa därefter om åtkomst, DLP, maskering, loggning, kryptering och leverantörskontroller motsvarar beslutet.
Det är så ansvarsskyldighet enligt ISO/IEC 27701:2025 och GDPR blir underlag.
Utforska Clarysec PIMS-verktygssatsen, börja med PII09 Policy för insamling, användning, utlämnande och delning av personuppgifter och använd Zenith Blueprint för att omvandla integritetsstyrning från policyavsikt till revisionsklart underlag.
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