⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

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

Igor Petreski

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:

  1. Vilken är PIMS-omfattningen, inklusive roller som personuppgiftsansvarig, personuppgiftsbiträde, gemensamt personuppgiftsansvarig och underbiträde?
  2. Vilka behandlingsaktiviteter, datakategorier, ändamål, rättsliga grunder, mottagare, överföringar och bevaranderegler omfattas?
  3. Vilka integritetsrisker kräver DPIA, behandling, godkännande och acceptans av kvarstående risk?
  4. Vilka policyer, kontroller, avtal, tekniska skyddsåtgärder och poster bevisar ansvarsskyldighet enligt GDPR?
  5. 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ångspostUnderlag att samla inClarysec-artefakt
PIMS-omfattningAffärsenheter, system, regioner, behandlingsroller, undantag, beroendenREG01 PIMS-omfattning
BehandlingsaktiviteterÄndamål, rättslig grund, datakategorier, registrerade, bevarande, mottagare, överföringarREG02 behandlingsregister
KontrolltillämpbarhetInkluderade kontroller, exkluderade kontroller, genomförandestatus, motiveringREG03 PIMS kontrolltillämpbarhet
DPIA-utlösareHögriskbehandling, nya ändamål, särskilda kategorier av personuppgifter, övervakning, automatiserade beslutREG04 integritetsrisk och DPIA-screening
ÖvergångsplanÄgare, milstolpar, revisionsschema, indata till ledningens genomgång, avhjälpande åtgärderREG12 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-skyldighetPIMS-övergångsunderlagOperativ ägare
Rättslig grund och ändamålsbegränsningREG02 behandlingspost med ändamål, rättslig grund, roll och granskningsdatumIntegritetsansvarig och processägare
Inbyggt dataskydd och dataskydd som standardChecklista för ändringsintag, DPIA-screening, arkitekturgranskning, godkännandepostProduktägare och säkerhetsarkitekt
Styrning av personuppgiftsbiträdenPersonuppgiftsbiträdesavtal, leverantörsriskbedömning, lista över underbiträden, revisionsrätt, klausul om stöd vid personuppgiftsincidentUpphandling och juridik
Registrerades rättigheterBegärandelogg, post för identitetsverifiering, underlag för fullgörande, undantagsbeslutIntegritetsdrift
Hantering av personuppgiftsincidentIncidentpost, bedömning av allvarlighetsgrad, beslut om anmälan, erfarenhetsåterföringIncidentansvarig och DPO
Bevarande och raderingBevarandeschema, underlag för radering, undantagsgodkännandeDataä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ångarIdentifierar lagringsplatser för personuppgifter, system, ägare och dataflöden
5.12 Klassificering av informationMärker personuppgifter och särskilda kategorier av personuppgifter så att starkare kontroller tillämpas
5.14 InformationsöverföringKontrollerar intern och extern överföring av personuppgifter
5.15 ÅtkomstkontrollUpprätthåller Need-to-know-principen för åtkomst till personuppgifter
5.16 IdentitetshanteringSäkerställer att identiteter med åtkomst till personuppgifter styrs och är spårbara
5.19 Informationssäkerhet i leverantörsrelationerStödjer leverantörsintegritet, försäkran för personuppgiftsbiträden och tredjepartsövervakning
5.20 Hantering av informationssäkerhet i leverantörsavtalInförlivar säkerhets- och integritetskrav i avtal
5.21 Hantering av informationssäkerhet i IKT-leveranskedjanStödjer styrning av underbiträden och IKT-beroenden
5.23 Informationssäkerhet vid användning av molntjänsterSäkerställer att molnleverantörer uppfyller förväntningar på integritet, plats, radering och avtal
5.31 Rättsliga, lagstadgade, regulatoriska och avtalsmässiga kravMappar GDPR, DORA, NIS2, kundkrav och avtalsförpliktelser
5.33 Skydd av posterStödjer bevarande, integritet och skydd av underlagsposter
5.34 Integritet och skydd av personuppgifterFörankrar integritetskontroller genom hela livscykeln för personuppgifter
5.35 Oberoende granskning av informationssäkerhetStödjer internrevision och extern säkerhetsförsäkran
5.36 Efterlevnad av policyer, regler och standarder för informationssäkerhetTestar om integritetskontroller följs
5.8 Informationssäkerhet i projektledningInförlivar integritet och säkerhet i projektstyrning
8.10 Radering av informationStödjer lagringsminimering och åtaganden om radering
8.11 DatamaskeringSkyddar personuppgifter i icke-produktionsmiljöer och analysfall
8.15 LoggningGer underlag för åtkomst och aktivitet som rör personuppgifter
8.16 ÖvervakningsaktiviteterDetekterar misstänkt aktivitet och stödjer incidentutredning
8.32 ÄndringshanteringSä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örskategoriNödvändigt integritetsunderlag
Personuppgiftsbiträde som hanterar kunders personuppgifterPersonuppgiftsbiträdesavtal, instruktioner, tekniska och organisatoriska åtgärder, lista över underbiträden, stöd vid anmälan av personuppgiftsincident, revisionsrätt
Underbiträde i SaaS-leveranskedjaVidareförda skyldigheter, plats, överföringsmekanism, åtagande om radering, ändringsavisering
MolndriftleverantörVal 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.

IncidentunderlagSyfte enligt GDPRSyfte enligt NIS2 eller DORA
Post för incidentklassificeringAvgör om en personuppgiftsincident har inträffatAvgör klassificering som betydande eller större IKT-incident
Konsekvensbedömning av dataIdentifierar berörda registrerade och risk för rättigheter och friheterStödjer rapportering av allvarlighetsgrad och påverkan
TidslinjeloggVisar tidpunkt för kännedom, eskalering, beslut och tidpunkt för anmälanStödjer stegvis rapportering och myndighetskommunikation
RotorsaksanalysStödjer åtgärdande och ansvarsskyldighetStödjer slutrapportering och förbättrad resiliens
ErfarenhetsåterföringUppdaterar DPIA:er, kontroller, utbildning och leverantörstillsynMatar 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.

RamverkVad revisorer eller bedömare förväntar sigPIMS-övergångssvar
GDPRAnsvarsskyldighet, rättslig grund, DPIA:er, styrning av personuppgiftsbiträden, hantering av personuppgiftsincidenter, stöd för rättigheterREG02, REG04, DPIA-poster, register över personuppgiftsbiträdesavtal, beslutsloggar för personuppgiftsincidenter, underlag för registrerades rättigheter
NIS2Riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, åtkomstkontroll, tillgångshanteringISMS-riskregister, leverantörsnivåer, incidentarbetsflöde, åtkomstgranskning, tillgångsförteckning
DORAIKT-riskramverk, incidentrapportering, resiliensprovning, IKT-tredjepartsrisk, avtalsklausulerIKT-beroenderegister, mappning av kritiska leverantörer, incidentrapporter, testunderlag, exitplaner
NIST CSF 2.0Styrning, rättsliga krav och integritetsförpliktelser, riskprofiler, leverantörsrisk, resultat för incidenthantering och återhämtningAktuell profil och målprofil, efterlevnadsmappning, leverantörsövervakning, underlag för respons och återhämtning
COBIT 2019Styrning av integritetsprogram, övervakning av regelefterlevnad, leverantörsavtal, operativa integritetskontrollerStyrelserapportering, 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ålCentrala leveranser
Dag 1 till 15Fastställ omfattning och styrningREG01-godkännande, sponsor, rollmatris, uppdatering av register över krav på regelefterlevnad, REG12-övergångsplan
Dag 16 till 35Bygg baslinjen för integritetsunderlagRensning av REG02, datakategorier, ändamål, rättsliga grunder, bevarande, system, leverantörer, överföringar
Dag 36 till 55Genomför integritetsrisk- och DPIA-screeningREG04-screening, DPIA-utlösare, riskbehandlingsbeslut, godkännanden av kvarstående risk
Dag 56 till 70Uppdatera kontroller, avtal och skyddsåtgärderREG03-uppdatering, SoA-uppdatering, åtgärdande av brister i personuppgiftsbiträdesavtal, åtkomst, radering, maskering, loggning, molnkontroller
Dag 71 till 85Testa underlag genom internrevisionStickprovsrevision 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 90Genomför ledningens genomgång och besluta om beredskapGranskningså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

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

Share this article