Övergångsplan till ISO/IEC 27701:2025 för GDPR-anpassat PIMS

Styrelsefrågan som synliggör ett gap i integritetsunderlaget
Anya, informationssäkerhetschef på ett snabbväxande FinTech-bolag, granskade dagordningen inför styrelsemötet. Mellan intäktsprognoser och marknadsexpansion låg den punkt som hade tagit hela hennes vecka i anspråk: GDPR-efterlevnad och beredskap för ISO/IEC 27701:2025.
Bolaget hade ett GDPR-program. Det fanns ett dataskyddsombud (DPO), integritetsmeddelanden, personuppgiftsbiträdesavtal, en DPIA-mall och en process för begäranden från registrerade. Säljteamet hade redan informerat företagskunder om att bolaget var på väg mot ett ledningssystem för hantering av integritetsinformation enligt ISO/IEC 27701:2025, eller PIMS. Produktteamet förberedde en AI-stödd analysfunktion som skulle behandla kunders användarbeteende, supportärenden, faktureringsmetadata och kontoaktivitet. En större EU-kund hade begärt underlag som visade att skyldigheter för personuppgiftsansvarig och personuppgiftsbiträde hanterades separat.
Den obekväma sanningen var inte att integritetsdokumentation saknades. Problemet var underlaget.
Registret över behandlingsaktiviteter visade inte konsekvent rättslig grund, bevarande, beroenden till underbiträden, internationella överföringar eller om bolaget agerade som personuppgiftsansvarig eller personuppgiftsbiträde för varje behandlingsändamål. Leverantörsgranskningar fokuserade på säkerhet, men inte tillräckligt på integritetsinstruktioner, radering, stöd vid personuppgiftsincidenter, revisionsrätt och vidareförda skyldigheter till underbiträden. Utvecklingsteamen hade säkerhetsgranskningar, men inbyggt dataskydd och dataskydd som standard utlöstes inte alltid när en funktion ändrade ändamålet med behandlingen. Internrevision testade GDPR på övergripande nivå, men kunde inte alltid spåra en skyldighet till en ägare, kontroll, registerpost, test och beslut från ledningens genomgång.
Det är den verkliga övergångsutmaningen med ISO/IEC 27701:2025. Det är inte bara ett certifieringsprojekt. Det är ett mognadstest: kan organisationen driva dataskydd som ett styrt system, inte som en mapp med juridiska dokument?
För GDPR-drivna organisationer är svaret att utvidga ledningssystemet för informationssäkerhet enligt ISO/IEC 27001:2022 till ett ledningssystem för integritetsinformation som integrerar PIMS-omfattning, register över behandlingsaktiviteter, bedömning av integritetsrisker, DPIA:er, leverantörsstyrning, hantering av personuppgiftsincidenter, kontrollmappning, internrevision och ständig förbättring.
Varför fragmenterad GDPR-efterlevnad brister under revisionstryck
Många organisationer behandlar integritetsefterlevnad som ett separat arbetsflöde från informationssäkerhet. Juridik hanterar avtal. IT hanterar kryptering. Upphandling hanterar leverantörer. Dataskyddsombudet besvarar begäranden om registerutdrag. Produktteam lanserar funktioner. Säkerhetsteamet hanterar incidenter. Varje funktion kan göra värdefullt arbete, men utan en gemensam verksamhetsmodell blir integritetsunderlaget fragmenterat.
Det skapar fyra återkommande problem.
För det första dubbelarbetar teamen. Säkerhets- och integritetsriskbedömningar kan använda olika metoder, olika poängsättning och olika ägare.
För det andra uppstår luckor i tredjepartstjänster, molnkonfigurationer, analyspipelines, supportverktyg och nya utvecklingsprojekt eftersom ingen har en fullständig bild av flöden av personuppgifter.
För det tredje blir säkerhetsförsäkran till styrelse och kunder svår. En samling fristående policyer bevisar inte att integritetsskyldigheter är införda, övervakade och förbättrade.
För det fjärde konvergerar moderna regulatoriska förväntningar. GDPR förväntar sig ansvarsskyldighet och underlag. NIS2 förväntar sig styrning, riskhantering, incidenthantering, åtkomstkontroll, policy för tillgångshantering och säkerhet i leveranskedjan. DORA förväntar sig att finansiella entiteter hanterar IKT-risker, incidenter, resiliensprovning, tredjepartsavtal och exitstrategier. Ett isolerat integritetsprogram kan inte effektivt stödja allt detta.
Det starkare angreppssättet är att bygga övergången till ISO/IEC 27701:2025 på ISO/IEC 27001:2022 ISMS. ISO/IEC 27001:2022 ger ledningssystemstrukturen för kontext, intressenter, omfattning, riskbedömning, riskbehandling, mål, operativ planering, internrevision, ledningens genomgång, korrigerande åtgärder och ständig förbättring. ISO/IEC 27002:2022 ger kontrollgrunden för rättsliga skyldigheter, tillgångsförteckning, leverantörsrelationer, molntjänster, åtkomstkontroll, loggning, övervakning, radering, maskering samt integritet och skydd av personuppgifter.
Övergången bör besvara fem frågor:
- Vilken är PIMS-omfattningen, inklusive roller som personuppgiftsansvarig, personuppgiftsbiträde, gemensamt personuppgiftsansvarig och underbiträde?
- Vilka behandlingsaktiviteter, datakategorier, ändamål, rättsliga grunder, mottagare, överföringar och bevaranderegler omfattas?
- Vilka integritetsrisker kräver DPIA, behandling, godkännande och acceptans av kvarstående risk?
- Vilka policyer, kontroller, avtal, tekniska skyddsåtgärder och poster bevisar ansvarsskyldighet enligt GDPR?
- Hur ska internrevision och ledningens genomgång bekräfta att PIMS fungerar och förbättras?
Fas 1: godkänn PIMS-omfattningen innan policyer skrivs om
En stark övergångsplan till ISO/IEC 27701:2025 börjar inte med att skriva om varje integritetspolicy. Den börjar med styrning och omfattning.
Befintlig ISMS-omfattning är utgångspunkten, men PIMS-omfattningen måste uttryckligen identifiera behandling av personuppgifter, affärsenheter, tjänster, system, regioner, molnmiljöer, leverantörer och integritetsroller. Styrelsen eller högsta ledningen måste förstå varför övergången är viktig, särskilt där kunder, tillsynsmyndigheter eller sektorskrav såsom DORA är beroende av påvisbart integritets- och resiliensunderlag.
Clarysecs Policy för ledningssystem för hantering av integritetsinformation [PIMS-policy] gör godkännande av omfattning obligatoriskt:
[Båda] Högsta ledningen SKA godkänna PIMS-omfattningen i REG01 före det första PIMS-införandet och inom 30 dagar efter varje väsentlig ändring.
För övergångsprogram som använder klausulnumreringen från Clarysecs policybibliotek är detta kärnförväntningen i klausul 4.1.1. Det är viktigt eftersom underförstådd integritetsomfattning är en av de vanligaste revisionssvagheterna. Om en produktlinje, jurisdiktion, behandlingsroll, leverantör, molnregion eller verksamhetsprocess ändras väsentligt får PIMS-omfattningen inte lämnas åt tolkning.
Samma policy gör också övergången till ett styrt program:
[Båda] Integritetsansvarig / PIMS-ansvarig SKA dokumentera PIMS-genomförandeplanen i REG12 före PIMS-utrullning eller större PIMS-ändring.
REG12 är inte administrativt overhead. Det är övergångens kontrollforum. Det bör visa vad som ändras, varför det är viktigt, vem som äger det, vilket underlag som krävs, vilka risker som är öppna och när beredskapen ska testas.
Fas 2: bygg en registerstyrd övergångsinventering
För GDPR-baserade ledningssystem för integritetsinformation bör den första praktiska leveransen vara en underlagsinventering, inte en omskriven policy. Clarysec använder en registerstyrd metod eftersom register omsätter integritetsambition till granskningsbart underlag.
PIMS-omfattningen i REG01 kopplas till behandlingsaktiviteter i REG02, kontrollernas tillämplighet i REG03, integritetsrisk och DPIA-screening i REG04 samt genomförandeplanering i REG12.
Policy för dataskydd och integritet – SME [SME-integritetspolicy] anger baslinjen:
Integritetssamordnaren ska upprätthålla ett register över alla behandlingsaktiviteter för personuppgifter, inklusive datakategorier, ändamål, rättslig grund och bevarandetider
För större miljöer höjer Policy för dataskydd och integritet [P17 Policy för dataskydd och integritet] styrningskravet:
Organisationen ska upprätthålla ett formellt ramverk för integritetsstyrning som är integrerat i ledningssystemet för informationssäkerhet (ISMS) för att tillämpa denna policy.
Den integrationen är övergångsprincipen. Ett register över behandlingsaktiviteter utan riskbehandling är ett kalkylblad. En DPIA utan kontrollägarskap är ett juridiskt PM. Ett personuppgiftsbiträdesavtal utan övervakning är en avtalspärm. Övergångsarbetet för ISO/IEC 27701:2025 bör föra in dessa artefakter i ett gemensamt styrt PIMS.
| Övergångspost | Underlag att samla in | Clarysec-artefakt |
|---|---|---|
| PIMS-omfattning | Affärsenheter, system, regioner, behandlingsroller, undantag, beroenden | REG01 PIMS-omfattning |
| Behandlingsaktiviteter | Ändamål, rättslig grund, datakategorier, registrerade, bevarande, mottagare, överföringar | REG02 behandlingsregister |
| Kontrolltillämpbarhet | Inkluderade kontroller, exkluderade kontroller, genomförandestatus, motivering | REG03 PIMS kontrolltillämpbarhet |
| DPIA-utlösare | Högriskbehandling, nya ändamål, särskilda kategorier av personuppgifter, övervakning, automatiserade beslut | REG04 integritetsrisk och DPIA-screening |
| Övergångsplan | Ägare, milstolpar, revisionsschema, indata till ledningens genomgång, avhjälpande åtgärder | REG12 PIMS-genomförandeplan |
Denna inventering stödjer också en NIST Cybersecurity Framework 2.0-liknande aktuell profil och målprofil. Den aktuella profilen dokumenterar befintliga integritetsprocesser, kontroller och underlag. Målprofilen definierar önskat PIMS i linje med ISO/IEC 27701:2025. Gapet mellan dem blir övergångsbackloggen.
Fas 3: mappa ansvarsskyldighet enligt GDPR till PIMS
Ansvarsskyldighet enligt GDPR är ryggraden i integritetsunderlag. GDPR gäller behandling inom ramen för ett etableringsställe i EU och kan även gälla personuppgiftsansvariga eller personuppgiftsbiträden utanför EU som erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende. Förordningen definierar personuppgifter brett, inklusive direkta och indirekta identifierare. Den skiljer mellan personuppgiftsansvariga och personuppgiftsbiträden och definierar en personuppgiftsincident som en säkerhetsöverträdelse som leder till oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller obehörig åtkomst till personuppgifter.
För övergångsplaneringen är den viktiga poängen att GDPR inte uppfylls genom att säga ”vi har säkerhetskontroller”. Article 5 kräver laglig, korrekt och transparent behandling, ändamålsbegränsning, uppgiftsminimering, korrekthet, lagringsminimering, integritet och konfidentialitet samt påvisbar ansvarsskyldighet. Article 6 kräver en rättslig grund. Article 9 tillför strängare villkor för särskilda kategorier av personuppgifter. Article 25 kräver inbyggt dataskydd och dataskydd som standard. Article 28 kräver styrning av personuppgiftsbiträden. Article 32 kräver säkerhet i behandlingen.
Clarysecs Policy för rättslig och regulatorisk efterlevnad – SME [SME Policy för rättslig och regulatorisk efterlevnad] ger mindre organisationer en enkel startpunkt:
Verkställande chefen ska upprätthålla ett enkelt, strukturerat register över krav på regelefterlevnad som listar:
Den företagsövergripande Policy för rättslig och regulatorisk efterlevnad [P37 Policy för rättslig och regulatorisk efterlevnad] är mer uttrycklig:
Alla rättsliga och regulatoriska skyldigheter ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet (ISMS).
Den meningen är skillnaden mellan informell GDPR-efterlevnad och revisionsredo integritetshantering. Varje väsentlig GDPR-skyldighet bör mappas till en policy, kontroll, ägare, registerfält och underlagskälla.
| Område för GDPR-skyldighet | PIMS-övergångsunderlag | Operativ ägare |
|---|---|---|
| Rättslig grund och ändamålsbegränsning | REG02 behandlingspost med ändamål, rättslig grund, roll och granskningsdatum | Integritetsansvarig och processägare |
| Inbyggt dataskydd och dataskydd som standard | Checklista för ändringsintag, DPIA-screening, arkitekturgranskning, godkännandepost | Produktägare och säkerhetsarkitekt |
| Styrning av personuppgiftsbiträden | Personuppgiftsbiträdesavtal, leverantörsriskbedömning, lista över underbiträden, revisionsrätt, klausul om stöd vid personuppgiftsincident | Upphandling och juridik |
| Registrerades rättigheter | Begärandelogg, post för identitetsverifiering, underlag för fullgörande, undantagsbeslut | Integritetsdrift |
| Hantering av personuppgiftsincident | Incidentpost, bedömning av allvarlighetsgrad, beslut om anmälan, erfarenhetsåterföring | Incidentansvarig och DPO |
| Bevarande och radering | Bevarandeschema, underlag för radering, undantagsgodkännande | Dataägare och IT-drift |
Underlag för personuppgiftsansvarig och personuppgiftsbiträde måste separeras. En personuppgiftsansvarig måste kunna bevisa rättslig grund, transparens, hantering av rättigheter, ändamålsbeslut och bevarande. Ett personuppgiftsbiträde måste kunna bevisa behandling enligt dokumenterade instruktioner, styrning av underbiträden, stöd till den personuppgiftsansvarige, säkerhetsåtgärder, stöd för anmälan av personuppgiftsincidenter samt återlämning eller radering vid tjänstens upphörande. Om organisationen agerar i båda rollerna räcker inte en generisk underlagsmodell.
Fas 4: använd SoA som brygga för integritetskontroller
Ett vanligt övergångsmisstag är att skapa ett fristående kalkylblad för PIMS-kontroller samtidigt som ISMS Statement of Applicability lämnas orörd. Det skapar två konkurrerande kontrolluniversum.
ISO/IEC 27001:2022 kräver att riskbehandlingsbeslut återspeglas i Statement of Applicability. Clarysecs Riskhanteringspolicy [Riskhanteringspolicy] anger:
Ett Statement of Applicability (SoA) ska återspegla alla behandlingsbeslut och ska uppdateras när kontrolltäckningen ändras.
Vid övergång till ISO/IEC 27701:2025 blir SoA bryggan mellan ISMS och PIMS. Om en DPIA eller riskbehandling av integritetsrisker lägger till kryptering, datamaskering, raderingskontroller, samtyckesmekanismer, leverantörsgranskning av personuppgiftsbiträden, åtkomstbegränsningar eller övervakning av arbetsflöden för registrerades rättigheter måste SoA och REG03 återspegla beslutet.
Zenith Blueprint: en revisors 30-stegs färdplan [Zenith Blueprint] förstärker detta i steg 6:
✓ Ytterligare kontroller: Finns det kontroller utanför Annex A som ni kan inkludera? ISO 27001
tillåter att andra kontroller läggs till i SoA. Ni kanske till exempel vill inkludera
efterlevnad av NIST CSF eller särskilda integritetskontroller från ISO 27701.
Tvinga inte in integritetsskyldigheter i kontroller som inte passar. Lägg till integritetsspecifika kontroller där det behövs, men styr dem genom samma modell för riskbehandling, ägarskap, genomförandestatus, underlag och revision.
ISO/IEC 27002:2022-kontrollerna som förankrar övergången
I Zenith Controls: vägledningen för mappning över flera regelverk [Zenith Controls] är två ISO/IEC 27002:2022-kontroller centrala för övergången till ISO/IEC 27701:2025: 5.31 Rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav samt 5.34 Integritet och skydd av personuppgifter.
Kontroll 5.31 är navet för regelefterlevnad. Den stödjer identifiering, dokumentation, ägarskap och granskning av rättsliga, regulatoriska, lagstadgade och avtalsmässiga krav. Den kopplas naturligt till ansvarsskyldighet enligt GDPR, NIS2-styrning, DORA IKT-riskkrav, kunders integritetsklausuler och åtaganden för behandling i molntjänster.
Kontroll 5.34 är den operativa förankringen för integritet. Zenith Controls förklarar beroendet tydligt:
En förteckning över informationstillgångar (5.9) bör inkludera datamängder med personuppgifter (kunddatabaser, HR-filer). Detta stödjer 5.34 genom att säkerställa att organisationen vet vilka personuppgifter den har och var de finns, vilket är det första steget för att skydda dem.
Kontrollmappningen bör användas som en praktisk designchecklista.
| ISO/IEC 27002:2022-kontroll | Övergångsrelevans för GDPR-PIMS |
|---|---|
| 5.9 Förteckning över information och andra tillhörande tillgångar | Identifierar lagringsplatser för personuppgifter, system, ägare och dataflöden |
| 5.12 Klassificering av information | Märker personuppgifter och särskilda kategorier av personuppgifter så att starkare kontroller tillämpas |
| 5.14 Informationsöverföring | Kontrollerar intern och extern överföring av personuppgifter |
| 5.15 Åtkomstkontroll | Upprätthåller Need-to-know-principen för åtkomst till personuppgifter |
| 5.16 Identitetshantering | Säkerställer att identiteter med åtkomst till personuppgifter styrs och är spårbara |
| 5.19 Informationssäkerhet i leverantörsrelationer | Stödjer leverantörsintegritet, försäkran för personuppgiftsbiträden och tredjepartsövervakning |
| 5.20 Hantering av informationssäkerhet i leverantörsavtal | Införlivar säkerhets- och integritetskrav i avtal |
| 5.21 Hantering av informationssäkerhet i IKT-leveranskedjan | Stödjer styrning av underbiträden och IKT-beroenden |
| 5.23 Informationssäkerhet vid användning av molntjänster | Säkerställer att molnleverantörer uppfyller förväntningar på integritet, plats, radering och avtal |
| 5.31 Rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav | Mappar GDPR, DORA, NIS2, kundkrav och avtalsförpliktelser |
| 5.33 Skydd av poster | Stödjer bevarande, integritet och skydd av underlagsposter |
| 5.34 Integritet och skydd av personuppgifter | Förankrar integritetskontroller genom hela livscykeln för personuppgifter |
| 5.35 Oberoende granskning av informationssäkerhet | Stödjer internrevision och extern säkerhetsförsäkran |
| 5.36 Efterlevnad av policyer, regler och standarder för informationssäkerhet | Testar om integritetskontroller följs |
| 5.8 Informationssäkerhet i projektledning | Införlivar integritet och säkerhet i projektstyrning |
| 8.10 Radering av information | Stödjer lagringsminimering och åtaganden om radering |
| 8.11 Datamaskering | Skyddar personuppgifter i icke-produktionsmiljöer och analysfall |
| 8.15 Loggning | Ger underlag för åtkomst och aktivitet som rör personuppgifter |
| 8.16 Övervakningsaktiviteter | Detekterar misstänkt aktivitet och stödjer incidentutredning |
| 8.32 Ändringshantering | Säkerställer att integritetspåverkan granskas före produktionsändringar |
Det är här integritet blir operativ. För varje högriskbehandling, fråga: vilka tillgångar innehåller personuppgifterna, hur klassificeras de, vem kan komma åt dem, vart överförs de, vilka molntjänster behandlar dem, vilken bevaranderegel gäller, vilken övervakning detekterar missbruk och vilket underlag visar att kontrollerna fungerar?
Exempel på arbetsflöde: introduktion av en AI-stödd analysfunktion
Återgå till Anyas FinTech-bolag. Produktteamet vill lansera en AI-stödd analysfunktion som behandlar användaridentifierare, kontoaktivitet, supportmetadata, faktureringsmetadata och beteendesignaler. Vissa företagskunder kan använda resultaten för övervakning av anställda, vilket ökar integritetsrisken.
Ett PIMS-övergångsarbetsflöde bör hantera lanseringen som en kontrollerad integritetshändelse.
Steg 1: uppdatera REG02 för behandlingsroller och ändamål
Processägaren skapar eller uppdaterar behandlingsposten. Obligatoriska fält omfattar ändamål, datakategorier, kategorier av registrerade, rättslig grund eller instruktion från personuppgiftsansvarig, bevarandetid, system, leverantörer, mottagare, överföringar och rollkontext.
Om bolaget är personuppgiftsbiträde för kundanalys måste REG02 visa behandling enligt kundinstruktioner. Om bolaget också använder aggregerade data för att förbättra sin egen produkt kan det separata ändamålet göra bolaget till personuppgiftsansvarig för sekundär behandling. Posten får inte blanda samman rollerna.
Steg 2: slutför REG04-screening
Clarysecs Policy för bedömning av integritetsrisker och DPIA [Policy för bedömning av integritetsrisker och DPIA] kräver:
[Båda] Processägaren / verksamhetsägaren SKA slutföra baslinje-REG04-screening för alla aktiva REG02-behandlingsaktiviteter inom omfattningen inom 30 arbetsdagar från godkännande av PIMS-omfattningen eller utökning av omfattningen.
Screeningen bör identifiera övervakning, profilering, särskilda kategorier, sårbara personer, ny teknik, storskalig behandling, gränsöverskridande överföringar eller ändrat ändamål. Om tröskelvärden uppfylls utlöses en DPIA.
Steg 3: genomför DPIA och definiera behandling
P17 Policy för dataskydd och integritet kräver:
Alla väsentliga ändringar i system eller processer som involverar personuppgifter (PII) ska kräva en dokumenterad konsekvensbedömning avseende dataskydd (DPIA), granskad av dataskyddsombudet (DPO).
I Clarysec-biblioteket är detta kopplat till klausul 5.6. DPIA:n bör bedöma risker såsom överdriven insamling, oklart ändamål, återidentifiering, obehörig åtkomst för kundadministratörer, oklart bevarande och exponering via underbiträden. Behandlingar kan omfatta minimering på fältnivå, pseudonymisering, kundkonfigurationskontroller, standardinställningar för bevarande, starkare revisionsloggning, uppdateringar av personuppgiftsbiträdesavtal, produktmeddelanden och begränsningar för modellträning.
Steg 4: uppdatera REG03 och SoA
PIMS-policy kräver:
[Båda] Integritetsansvarig / PIMS-ansvarig SKA upprätthålla REG03 med inkluderade kontroller, exkluderade kontroller, genomförandestatus och motivering årligen och inom 30 dagar efter varje ändring av riskbehandling av integritetsrisker.
Om DPIA:n lägger till maskering för icke-produktionsanalys, loggning av administratörsåtkomst, raderingskontroller, leverantörsklausuler eller skyddsåtgärder för kundkonfiguration måste REG03 och SoA uppdateras.
Steg 5: visa inbyggt dataskydd och dataskydd som standard
SME-integritetspolicy fångar principen tydligt:
Integritetsskydd genom design och som standard ska tillämpas i alla nya system och tjänster
Underlag bör omfatta DPIA, arkitekturgranskning, beslut om uppgiftsminimering, åtkomstmodell, loggningskonfiguration, inställning för bevarande, testresultat, releasegodkännande och granskning efter lansering. Det gör funktionslanseringen till återanvändbart PIMS-underlag.
Styrning av leverantörsintegritet i en DORA- och NIS2-värld
Styrning av leverantörsintegritet är där många övergångar misslyckas. GDPR Article 28 kräver att personuppgiftsansvariga använder personuppgiftsbiträden som lämnar tillräckliga garantier och att skyldigheter för personuppgiftsbiträden förs in i skriftliga avtal. DORA Articles 28 to 30 kräver att finansiella entiteter hanterar IKT-tredjepartsrisker, upprätthåller register över avtalsarrangemang, genomför leverantörsgranskning, inkluderar revisionsrätt och exitvillkor, hanterar underleverantörer och adresserar kritiska eller viktiga funktioner. NIS2 Article 21 kräver säkerhetsåtgärder i leveranskedjan, inklusive beaktande av leverantörers sårbarheter, cybersäkerhetspraxis och rutiner för säker utveckling.
ISO/IEC 27002:2022 kontroll 5.19, Informationssäkerhet i leverantörsrelationer, är den operativa förankringen. Zenith Controls mappar detta område till leverantörsavtal, säkerhet i IKT-leveranskedjan, informationsöverföring, övervakning av regelefterlevnad, godtagbar användning, GDPR-skyldigheter för personuppgiftsbiträden, cybersäkerhet i leveranskedjan enligt NIS2, IKT-tredjepartsrisk enligt DORA, leverantörsstyrning enligt NIST och leverantörshantering enligt COBIT.
| Leverantörskategori | Nödvändigt integritetsunderlag |
|---|---|
| Personuppgiftsbiträde som hanterar kunders personuppgifter | Personuppgiftsbiträdesavtal, instruktioner, tekniska och organisatoriska åtgärder, lista över underbiträden, stöd vid anmälan av personuppgiftsincident, revisionsrätt |
| Underbiträde i SaaS-leveranskedja | Vidareförda skyldigheter, plats, överföringsmekanism, åtagande om radering, ändringsavisering |
| Molndriftleverantör | Val av region, kryptering, åtkomstkontroller, incidentstöd, villkor för radering och återlämning |
| Leverantör av supportverktyg | Åtkomstbegränsning, maskering av ärenden, bevarande, loggning, sekretess för supportpersonal |
| Analys- eller AI-leverantör | Ändamålsbegränsning, begränsning av modellträning, pseudonymisering, möjlighet till opt-out eller konfigurationskontroller |
För finansiella entiteter som omfattas av DORA måste detta underlag kopplas till IKT-tredjepartsregister och bedömningar av kritiska eller viktiga funktioner. För NIS2-entiteter stödjer samma leverantörsposter riskhantering i leveranskedjan. För NIST CSF 2.0 ligger leverantörsstyrning i linje med GOVERN Function, särskilt resultat för riskhantering i leveranskedjan. För COBIT 2019 ligger leverantörsstyrning i linje med mål såsom APO10 Managed Vendors och DSS-relaterade operativa leverantörskontroller.
Incident- och personuppgiftsincidentberedskap måste integreras
Övergångsplaner för integritet fokuserar ofta för mycket på dokumentation och för lite på hantering av personuppgiftsincidenter. Det är riskfyllt eftersom GDPR, NIS2 och DORA alla förväntar sig disciplinerade incidentprocesser, även om tröskelvärden och rapporteringstider skiljer sig.
GDPR kräver bedömning av om en säkerhetshändelse har orsakat en personuppgiftsincident och om anmälan till tillsynsmyndigheten eller berörda personer krävs. NIS2 inför stegvis rapportering för betydande incidenter, inklusive tidig varning inom 24 timmar, anmälan inom 72 timmar och slutrapport inom en månad. DORA kräver att finansiella entiteter detekterar, hanterar, klassificerar, registrerar, anmäler, svarar på och lär av IKT-relaterade incidenter, med stegvis rapportering för större incidenter.
| Incidentunderlag | Syfte enligt GDPR | Syfte enligt NIS2 eller DORA |
|---|---|---|
| Post för incidentklassificering | Avgör om en personuppgiftsincident har inträffat | Avgör klassificering som betydande eller större IKT-incident |
| Konsekvensbedömning av data | Identifierar berörda registrerade och risk för rättigheter och friheter | Stödjer rapportering av allvarlighetsgrad och påverkan |
| Tidslinjelogg | Visar tidpunkt för kännedom, eskalering, beslut och tidpunkt för anmälan | Stödjer stegvis rapportering och myndighetskommunikation |
| Rotorsaksanalys | Stödjer åtgärdande och ansvarsskyldighet | Stödjer slutrapportering och förbättrad resiliens |
| Erfarenhetsåterföring | Uppdaterar DPIA:er, kontroller, utbildning och leverantörstillsyn | Matar in i testning, revision och ledningens genomgång |
NIST CSF 2.0 stödjer denna cykel genom resultaten Detect, Respond, Recover och Govern. Övergångsteamet bör säkerställa att beslut om personuppgiftsincidenter är inbäddade i arbetsflödet för säkerhetsincidenter och inte hanteras som en fristående juridisk efterhandsåtgärd.
En färdplan, många efterlevnadsresultat
Övergången till ISO/IEC 27701:2025 blir mer värdefull när den minskar dubbelarbete inom efterlevnad. Zenith Blueprint, steg 14, rekommenderar korsreferenser mellan GDPR, NIS2 och DORA så att organisationer kan visa att riskbehandling och kontroller uppfyller flera skyldigheter:
För varje regelverk, om tillämpligt, kan ni skapa en enkel mappningstabell (eventuellt som en
bilaga i en rapport) som listar regelverkets centrala säkerhetskrav och de
motsvarande kontrollerna/policyerna i ert ISMS.
För övergångsplanering inom integritet bör mappningen vara praktisk och underlagsstyrd.
| Ramverk | Vad revisorer eller bedömare förväntar sig | PIMS-övergångssvar |
|---|---|---|
| GDPR | Ansvarsskyldighet, rättslig grund, DPIA:er, styrning av personuppgiftsbiträden, hantering av personuppgiftsincidenter, stöd för rättigheter | REG02, REG04, DPIA-poster, register över personuppgiftsbiträdesavtal, beslutsloggar för personuppgiftsincidenter, underlag för registrerades rättigheter |
| NIS2 | Riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, åtkomstkontroll, tillgångshantering | ISMS-riskregister, leverantörsnivåer, incidentarbetsflöde, åtkomstgranskning, tillgångsförteckning |
| DORA | IKT-riskramverk, incidentrapportering, resiliensprovning, IKT-tredjepartsrisk, avtalsklausuler | IKT-beroenderegister, mappning av kritiska leverantörer, incidentrapporter, testunderlag, exitplaner |
| NIST CSF 2.0 | Styrning, rättsliga krav och integritetsförpliktelser, riskprofiler, leverantörsrisk, resultat för incidenthantering och återhämtning | Aktuell profil och målprofil, efterlevnadsmappning, leverantörsövervakning, underlag för respons och återhämtning |
| COBIT 2019 | Styrning av integritetsprogram, övervakning av regelefterlevnad, leverantörsavtal, operativa integritetskontroller | Styrelserapportering, register över regelefterlevnadskrav, APO- och DSS-anpassat underlag, internrevisionsiakttagelser |
I Zenith Controls stödjer ISO/IEC 27002:2022 kontroll 5.31 rättslig och regulatorisk spårbarhet över ansvarsskyldighet enligt GDPR, DORA-krav på regelefterlevnad, styrningsförväntningar enligt NIS2, NIST CSF 2.0 GV.OC-03 och COBIT-övervakning av extern efterlevnad. Kontroll 5.34 stödjer GDPR Articles 25 och 32, skydd av personuppgifter genom hela livscykeln, förväntningar på behandling av personuppgifter i molnmiljö och integritetsmedvetna säkerhetskontroller.
Resultatet är inte en förenklad modell där ”en kontroll är lika med en lag”. Det är en försvarbar underlagsmodell där en väl utformad kontrolluppsättning stödjer flera behov av säkerhetsförsäkran.
Hur revisorer kommer att testa övergången
En stark övergångsplan förutser revisionstekniker.
En revisor av ISO-ledningssystem börjar med omfattning, intressenter, rättsliga krav, risker, mål, operativa kontroller, internrevisioner, ledningens genomgångar, avvikelser och förbättringar. Revisorn kontrollerar om PIMS-omfattningen är godkänd, om integritetsskyldigheter ingår i registret över krav på regelefterlevnad, om kontroller är motiverade i SoA och om genomförandeunderlaget motsvarar den angivna omfattningen.
En integritetsrevisor tar stickprov på behandlingsposter, DPIA:er, begäranden från registrerade, beslut om personuppgiftsincidenter, biträdesavtal, bevarandekontroller och projektintroduktion. Policyavsikter godtas inte när operativt underlag saknas.
En NIST-anpassad bedömare söker efter styrning, rättsliga och avtalsmässiga skyldigheter, målprofiler, leverantörsrisk, övervakning, respons och återställningsunderlag.
En COBIT 2019-revisor fokuserar på styrelsetillsyn, rapportering av regelefterlevnad, leverantörsstyrning, roller och ansvar samt om integritetsrisk hanteras genom hela informationslivscykeln.
Clarysecs Policy för PIMS-övervakning, revision och förbättring [Policy för PIMS-övervakning, revision och förbättring] gör revisionsprogrammet obligatoriskt:
[Alla] Internrevision / granskare av regelefterlevnad SKA ta fram ett riskbaserat internt PIMS-revisionsprogram i REG12 årligen före den första planerade PIMS-revisionscykeln.
Policy för revision och regelefterlevnadsövervakning [Policy för revision och regelefterlevnadsövervakning] tillämpar samma disciplin på ISMS-nivå:
En riskbaserad revisionsplan ska utvecklas och godkännas årligen, med beaktande av:
För mindre organisationer håller Policy för revision och regelefterlevnadsövervakning – SME [SME Policy för revision och regelefterlevnadsövervakning] revisionsplaneringen fokuserad:
Planen ska identifiera viktiga system och policyer som ska granskas, med fokus på:
Under övergången bör den första internrevisionen inte testa allt. Den bör testa de största övergångsriskerna: ofullständiga behandlingsposter, saknade DPIA-utlösare, svaga integritetsklausuler för leverantörer, otestade beslut om personuppgiftsincidenter, oklara roller som personuppgiftsansvarig och personuppgiftsbiträde samt avvikelse mot SoA.
En praktisk 90-dagars färdplan för övergång till ISO/IEC 27701:2025
En realistisk färdplan bör vara tillräckligt kort för att genomföra och tillräckligt strukturerad för att skapa underlag.
| Tidslinje | Övergångsmål | Centrala leveranser |
|---|---|---|
| Dag 1 till 15 | Fastställ omfattning och styrning | REG01-godkännande, sponsor, rollmatris, uppdatering av register över krav på regelefterlevnad, REG12-övergångsplan |
| Dag 16 till 35 | Bygg baslinjen för integritetsunderlag | Rensning av REG02, datakategorier, ändamål, rättsliga grunder, bevarande, system, leverantörer, överföringar |
| Dag 36 till 55 | Genomför integritetsrisk- och DPIA-screening | REG04-screening, DPIA-utlösare, riskbehandlingsbeslut, godkännanden av kvarstående risk |
| Dag 56 till 70 | Uppdatera kontroller, avtal och skyddsåtgärder | REG03-uppdatering, SoA-uppdatering, åtgärdande av brister i personuppgiftsbiträdesavtal, åtkomst, radering, maskering, loggning, molnkontroller |
| Dag 71 till 85 | Testa underlag genom internrevision | Stickprovsrevision av en process där organisationen är personuppgiftsansvarig, en tjänst där organisationen är personuppgiftsbiträde, en leverantör, en DPIA, en begäran från registrerad och ett scenario för personuppgiftsincident |
| Dag 86 till 90 | Genomför ledningens genomgång och besluta om beredskap | Granskningsåtgärder, leverantörsfrågor, incidenter, revisionsiakttagelser, integritetsmål, beslut om extern bedömning |
90-dagarsmålet innebär inte att varje åtgärdspunkt kommer att vara stängd. Det innebär att ledningen bör ha en godkänd omfattning, en trovärdig underlagsbaslinje, prioriterad riskbehandling, fokuserade revisionsresultat och ett ledningsbeslut om beredskap.
Gör övergången underlagsdriven
Organisationer som lyckas med övergången till ISO/IEC 27701:2025 är inte de som har den längsta integritetspolicyn. De är de som kan visa hur integritetsskyldigheter rör sig från lag till omfattning, från omfattning till behandlingsposter, från behandlingsposter till riskbedömning, från riskbedömning till kontroller, från kontroller till underlag och från underlag till förbättring.
Clarysec hjälper team att göra övergången praktisk. Våra PIMS-policyer, GDPR-mappningar, underlagsregister för personuppgiftsansvariga och personuppgiftsbiträden, DPIA-arbetsflöden, mallar för styrning av leverantörsintegritet, material för hantering av personuppgiftsincidenter, agendor för ledningens genomgång, Zenith Blueprint och Zenith Controls ger informationssäkerhetschefer, dataskyddsombud, chefer för regelefterlevnad, revisorer och verksamhetsägare en strukturerad väg från integritetsambition till revisionsredo drift.
Om organisationen förbereder sig för ISO/IEC 27701:2025, börja denna vecka med tre åtgärder: godkänn PIMS-övergångens omfattning i REG01, fyll i REG02 för er tjänst med högst risk och genomför den första REG04-screeningen. Använd sedan Clarysec för att omvandla den underlagsuppsättningen till en komplett GDPR-anpassad PIMS-övergångsfärdplan, redo för kunder, revisorer, tillsynsmyndigheter och styrelsen.
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