Testning av ISO 27701-kontroller för dataskydd enligt GDPR

Fredagens dataskyddsrevision som visade det verkliga problemet

Klockan är 15.40 en fredag när Maria, informationssäkerhetschef (CISO) på ett snabbväxande SaaS-företag, ansluter till ett videosamtal med den ansvariga inköpschefen hos en större potentiell företagskund.

Hennes team har arbetat i månader med sitt ledningssystem för hantering av integritetsinformation. Policyer är godkända. Behandlingsregistret finns. Företaget har en beredskapsplan för ISO 27701. Dataskyddsombudet (DPO) har arbetsflöden för registrerades begäranden. Juridik har uppdaterat personuppgiftsbiträdesavtal. Utvecklingsorganisationen säger att produktionsåtkomsten är begränsad.

Den ansvariga inköpschefen inleder artigt men direkt.

”Tack för dokumentationen, Maria. Certifikatet och policypaketet är en bra utgångspunkt. Vårt leverantörsgranskningsteam kommer att vara på plats nästa månad. De vill se er DSAR-process i praktiken, verifiera kontroller för uppgiftsminimering på våra testkonton, granska åtkomstloggar för produktion och kontrollera underlag som visar att dataskyddskontrollerna är testade, inte bara dokumenterade.”

Inom några minuter får Maria två meddelanden till.

Dataskyddsombudet frågar om den nya analysfunktionen omfattas av behandlingsregistret, bedömningen av rättslig grund, bevarandeschemat och vidareförda skyldigheter för personuppgiftsbiträden.

Regelefterlevnadschefen frågar om beredskapsgranskningen för ISO 27701:2025 kan visa att PIMS-kontrollerna är operativt effektiva.

Det är i detta ögonblick många dataskyddsprogram börjar vackla. Organisationen har dataskyddsdokument, men inte dataskyddsunderlag. Den har arbetsflöden, men inte urvalsbaserat underlag. Den har avtal, men svaga uppföljningsposter. Den har intern trygghet, men inget försvarbart revisionsspår.

Det glappet är skillnaden mellan efterlevnad på papper och påvisbar ansvarsskyldighet.

GDPR gör problemet tydligt. Den personuppgiftsansvarige ansvarar för, och ska kunna visa, efterlevnad av dataskyddsprinciperna. Personuppgifter ska behandlas lagligt, korrekt och öppet, för särskilda ändamål, begränsas till vad som är nödvändigt, vara korrekta, bevaras endast så länge som behövs och skyddas genom lämpliga tekniska och organisatoriska åtgärder.

ISO 27701:2025 ger organisationer strukturen för dataskyddsstyrning. ISO/IEC 27001:2022 ger ISMS-ryggraden för omfattning, riskbehandling, operativ styrning, internrevision, ledningens genomgång och ständig förbättring. GDPR medför kravet på rättslig ansvarsskyldighet. NIS2, DORA, NIST CSF 2.0, COBIT 2019-liknande assurance och kunders säkerhetsgranskningar ökar trycket att visa att kontrollerna fungerar.

Clarysecs syn är enkel: testning av dataskyddskontroller ska inte vara en årlig jakt på skärmdumpar. Den ska vara ett PIMS-underlagssystem som kopplar samman behandlingsaktiviteter, tillämpliga kontroller, risker, urval, tekniska kontroller, iakttagelser, CAPA och ledningens genomgång i en spårbar modell.

Det är där Clarysecs PIMS-policyuppsättning, Zenith Blueprint: An Auditor’s 30-Step Roadmap och Zenith Controls: The Cross-Compliance Guide blir operativa verktyg, inte hyllvärmare.

Testning av dataskyddskontroller är bryggan mellan policy och ansvarsskyldighet

Ett test av en dataskyddskontroll besvarar tre praktiska frågor:

1. Är kontrollen utformad för att uppfylla dataskyddsskyldigheten eller minska integritetsrisken?
2. Är kontrollen införd i relevant process, system, team, leverantör eller produktarbetsflöde?
3. Är kontrollen operativt effektiv över tid, med underlag som skulle klara granskning av en revisor, kund, tillsynsmyndighet eller styrelsekommitté?

Ett SaaS-företag kan säga att det hanterar raderingsbegäranden. Ett designtest kontrollerar om raderingspolicyn, processen för verifiering av digital identitet, ägarskapsmodellen, samordningen med personuppgiftsbiträden, undantag från bevarande och hanteringen av säkerhetskopior är definierade. Ett test av kontrollens operativa effektivitet tar urval av genomförda raderingsbegäranden, jämför tidsstämplar, kontrollerar godkännanden, granskar systemloggar, verifierar aviseringar till nedströms personuppgiftsbiträden och bekräftar avslutsunderlag.

Policy för PIMS-övervakning, revision och förbättring gör detta till ett granskningsbart krav:

[Båda] Internrevisor / regelefterlevnadsgranskare SKA testa tillämplig införandestatus för PIMS-kontroller mot REG03 vid varje PIMS-revision.

Från avsnittet ”PIMS-internrevisionsprogram”, policyklausul 4.2.5.

Formuleringen ”mot REG03” är central. Testning är inte en fri intervju. REG03 fungerar som referens för tillämplighet och införande av PIMS-kontroller. Den visar vad som är tillämpligt, varför det är tillämpligt och vilket underlag som bör finnas.

Samma policy lägger till:

[Båda] Internrevisor / regelefterlevnadsgranskare SKA registrera det valda underlagsurvalet för PII-behandling i REG12 vid varje PIMS-revision.

Från avsnittet ”PIMS-internrevisionsprogram”, policyklausul 4.2.6.

Detta är kärnan i testning av dataskyddskontroller enligt ISO 27701:2025. En PIMS-revision utan urval är ett samtal. En PIMS-revision med valt underlag, kontrollmappning, undantag, korrigerande åtgärder och spårbarhet till ledningens genomgång är ansvarsskyldighet.

Börja med omfattning, roll och faktisk behandling

De flesta svaga dataskyddsrevisioner fallerar innan testningen börjar. De väljer generiska kontroller utan att bekräfta vilka personuppgifter som behandlas, var de finns, vilka system och leverantörer som berör dem och om organisationen agerar som personuppgiftsansvarig, personuppgiftsbiträde, gemensamt personuppgiftsansvarig eller underbiträde.

Skyldigheter enligt GDPR beror i hög grad på rollen. En personuppgiftsansvarig som avgör varför och hur personuppgifter behandlas har andra skyldigheter än ett personuppgiftsbiträde som agerar enligt dokumenterade kundinstruktioner. Uppgifternas känslighet spelar också roll. Personuppgifter om anställda, kundkontodata, telemetri, finansiella data, biometrisk verifiering, hälsorelaterade uppgifter, sanktionsscreening och uppgifter om lagöverträdelser innebär inte samma risk.

Ett starkt testprogram för ISO 27701:2025 börjar med tydlig omfattningsstyrning.

ISO/IEC 27001:2022 stödjer denna integrerade ansats genom sina krav på organisationens kontext, krav från intressenter, rättsliga och avtalsmässiga skyldigheter, ledningssystemets omfattning, operativ planering och riskbehandling. För dataskydd innebär det att PII-behandling inte kan ligga i ett frikopplat kalkylblad. Den måste ingå i driftmodellen för ISMS och PIMS.

Policy för ledningssystem för hantering av integritetsinformation kopplar dataskyddstestning direkt till styrning:

[Alla] Högsta ledningen SKA årligen granska PIMS-prestanda, dataskyddsmål, öppna risker, avvikelser, korrigerande åtgärder och förbättringsbeslut i REG12.

Från avsnittet ”PIMS-styrning”, policyklausul 6.1.1.

Om testningen identifierar ett dataskyddsglapp är det inte bara en revisionsnotering. Det är input till ledningssystemet som bör påverka riskbehandling, prioriteringar, resurser och ledningsbeslut.

Kontrollutformningens ändamålsenlighet jämfört med kontrollens operativa effektivitet

När en kund frågar om dataskyddskontroller testas avser de vanligtvis kontrollens operativa effektivitet. Revisorer kommer dock också att granska kontrollutformningens ändamålsenlighet.

En ändamålsenligt utformad kontroll kan uppfylla kravet om den utförs som avsett. En operativt effektiv kontroll utförs faktiskt konsekvent och stöds av underlag.

Policy för revision och regelefterlevnadsövervakning anger syftet direkt:

Validera effektiviteten hos säkerhets- och dataskyddskontroller

Från avsnittet ”Syfte”, policyklausul 1.1.1.

SME-versionen behåller samma princip för kontrollförsäkran i operativt språk. Policy för revision och regelefterlevnadsövervakning - SME anger:

Denna policy fastställer organisationens arbetssätt för att genomföra internrevisioner, granskningar av säkerhetskontroller och övervakning av efterlevnad. Den säkerställer att alla kontroller, policyer, system och tjänsteleverantörer omfattas av regelbunden och strukturerad granskning.

Från avsnittet ”Syfte”, policyklausul 1.1.

Beredskap för ISO 27701 handlar inte om företagets storlek. Ett SaaS-personuppgiftsbiträde med 30 personer behöver kanske inte samma revisionsverktyg som en global bank, men det måste ändå kunna visa att åtkomst, radering, incidenteskalering, styrning av underbiträden och bevarande av underlag är kontrollerade.

Clarysecs underlagskedja: REG03, REG12, CAPA och granskning

Clarysec strukturerar testning av dataskyddskontroller kring en enkel underlagskedja.

REG03 definierar tillämpliga PIMS-kontroller och införandestatus. REG12 registrerar urval, underlag, iakttagelser, spårbarhetsbrister, verifiering av korrigerande åtgärder och input till ledningens genomgång. CAPA-poster omvandlar iakttagelser till förbättringar baserade på rotorsak. Högsta ledningen granskar PIMS-prestanda, risker, avvikelser, korrigerande åtgärder och förbättringsbeslut.

Policy för dokumenterad information och underlagshantering i PIMS kräver att brister i underlagskvalitet registreras:

[Alla] Internrevisor / regelefterlevnadsgranskare SKA registrera brister i underlagets fullständighet, korrekthet eller spårbarhet i REG12 vid varje planerad revision eller efterlevnadsgranskning.

Från avsnittet ”Skapande, namngivning och kvalitet för underlag”, policyklausul 4.3.4.

Detta är viktigt eftersom inte varje iakttagelse är ett totalt kontrollmisslyckande. Ibland fungerade kontrollen, men underlaget är ofullständigt. Ibland är ett raderingsärende stängt, men ingen systemlogg visar raderingen. Ibland anger behandlingsregistret CRM-systemet, men missar exporten till datalagret. Ibland finns ett leverantörsavtal, men löpande uppföljning saknas.

Policy för revision och regelefterlevnadsövervakning kräver också strukturerade internrevisioner:

Internrevisioner ska följa ett dokumenterat förfarande som omfattar:

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

Och när iakttagelser uppstår:

Alla iakttagelser ska resultera i en dokumenterad CAPA som omfattar:

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

Riskhanteringspolicy - SME förstärker disciplinen för avslut:

Genomförande och effektivitet för riskbehandlingsåtgärder måste verifieras.

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3.2.

Policy för PIMS-övervakning, revision och förbättring stänger loopen:

[Alla] Internrevisor / regelefterlevnadsgranskare SKA verifiera effektiviteten hos korrigerande åtgärder i REG12 inom 30 dagar från rapporterat avslut av korrigerande åtgärd.

Från avsnittet ”Avvikelse och korrigerande åtgärd”, policyklausul 4.4.7.

Detta är skillnaden mellan att lösa ett ärende och att förbättra ett ledningssystem.

Praktiskt test 1: raderingsbegäranden och ansvarsskyldighet enligt GDPR

Raderingsbegäranden är ett av de tydligaste sätten att testa om ansvarsskyldighet för dataskydd fungerar i praktiken.

Anta att ett medelstort SaaS-företag agerar både som personuppgiftsansvarig och personuppgiftsbiträde. Det ansvarar för personuppgifter om anställda, marknadsföringsdata och faktureringsdata. Det behandlar kunders slutanvändardata för företagskunders räkning. Organisationen vill testa om raderingskontrollerna är redo för ISO 27701:2025-revision och kundförsäkran enligt GDPR.

Steg 1: Välj behandlingsaktiviteten från REG03

Välj en behandlingsaktivitet med verklig integritetsrisk, exempelvis ”kunders slutanvändarprofildata som behandlas i SaaS-plattformen”. Bekräfta om organisationen agerar som personuppgiftsansvarig, personuppgiftsbiträde eller båda. Identifiera kopplade kontroller för hantering av rättigheter, validering av instruktioner till personuppgiftsbiträde, bevarande, radering, åtkomstkontroll, loggning, hantering av säkerhetskopior och leverantörssamordning.

Steg 2: Definiera ett precist testmål

Ett användbart testmål är specifikt och underlagsdrivet:

”Verifiera att raderingsbegäranden för kunders slutanvändarprofildata tas emot, autentiseras eller valideras mot instruktion, hanteras inom det definierade arbetsflödet, loggas, genomförs tekniskt i produktionssystem, vidarebefordras till relevanta underbiträden där så krävs och avslutas med underlag.”

Steg 3: Ta fram ett representativt urval

Välj fem raderingsbegäranden från det senaste kvartalet. Inkludera en rutinbegäran, en begäran som involverar en kundadministratör, en begäran baserad på instruktion till personuppgiftsbiträde, en begäran med undantag från bevarande och en begäran som berör hantering av säkerhetskopior.

Zenith Blueprint, i fasen Audit, Review & Improvement, Step 26: Audit Execution, betonar urval och insamling av underlag:

✓ Intervjua relevant personal: Be personer som ansvarar för processer förklara hur de uppfyller kraven. Fråga exempelvis riskägaren om den senaste riskbedömningen eller fråga HR hur nyanställda utbildas i säkerhet (för att täcka kontroll 6.3 om medvetenhet).
✓ Granska dokumentation: Kontrollera att dokument och poster finns och är aktuella.
✓ Observera praxis: Gör om möjligt en direkt observation.
✓ Ta urval och gör stickprovskontroller: Du kan inte kontrollera allt, så använd urval.

Från fasen Audit, Review & Improvement, Step 26: Audit Execution (Conducting an Internal Audit).

Steg 4: Granska underlag för varje urval

För varje vald begäran ska mottagningsärende, rollklassificering, identitetsverifiering eller kundauktorisering, systemlogg för radering, beslut om undantag från bevarande, förklaring av hantering av säkerhetskopior, underrättelse till underbiträde, avslutskommunikation, tidsstämplar och granskarens godkännande samlas in.

Steg 5: Registrera resultat i REG12

Registrera urvalet, underlagskällan, kontrollresultatet, undantaget och spårbarhetsbristen i REG12. Om raderingen har skett men ingen produktionslogg finns kan kontrollen ha fungerat, men underlaget är svagt. Om begäran försenades eftersom leverantörsansvaret var otydligt kan iakttagelsen avse tredjepartsstyrning och vidareförda avtalsmässiga skyldigheter.

Steg 6: Skapa CAPA och verifiera effektivitet

Om rotorsaken är otydligt ägarskap mellan support, juridik och utvecklingsorganisationen kan CAPA omfatta ett reviderat arbetsflöde, uppdaterad RACI, obligatoriska underlagsfält och månatliga urvalskontroller av raderingar.

Zenith Blueprint, i fasen Audit, Review & Improvement, Step 29, förklarar förväntan på avslut:

Planera hur du ska verifiera effektiviteten för varje korrigerande åtgärd. Det kan innebära att schemalägga en uppföljande revision eller kontroll. Om din korrigerande åtgärd exempelvis var att utbilda IT-personal i åtkomstkontroll kan du planera att granska nya konton efter en månad för att se om alla har korrekta godkännanden (verifiering).

Från fasen Audit, Review & Improvement, Step 29: Continual Improvement (Corrective Actions & Lessons Learned).

För radering kan verifiering innebära urval av de fem nästkommande raderingsbegärandena efter att det reviderade arbetsflödet tagits i produktion. Först därefter bör CAPA avslutas.

Praktiskt test 2: ändamålsbegränsning och uppgiftsminimering

Ett andra högt prioriterat test är ändamålsbegränsning. Detta är särskilt användbart inför kunders leverantörsgranskning, lansering av analysfunktioner, AI-berikning, utökning av datalager eller ändringar i marknadsföringsautomatisering.

Marias SaaS-plattform samlar in kunders användardata för tjänsteleverans. Kontrollmålet är att säkerställa att PII endast används för angivna och berättigade ändamål och inte återanvänds för marknadsföringsanalys om användaren inte har lämnat uttryckligt, separat samtycke där detta krävs.

Ett starkt operativt test stannar inte vid policyn. Det tar urval av användare som har samtyckt till marknadsföring och användare som inte har gjort det. Det spårar om samtyckesstatus återspeglas korrekt i centrala applikationsdatabaser, datalagertabeller, kampanjverktyg, kontrollpaneler och exporter. Om användare utan samtycke förekommer i en marknadsföringsmålgrupp har organisationen en konkret avvikelse.

SME-versionen av Policy för revision och regelefterlevnadsövervakning ger rätt synsätt genom ett exempel på teknisk testning:

Verifiering av tekniska kontroller (t.ex. status för säkerhetskopiering, konfiguration av åtkomstkontroll, patchposter)

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.2.

För dataskydd omfattar verifiering av tekniska kontroller kontroller av samtyckessynkronisering, exporter av åtkomstkontroller, raderingsloggar, krypteringsinställningar, tester av datamaskering, DLP-larm, begränsningar för säkerhetskopiering, övervakningshändelser och leverantörsunderlag.

Mappning av dataskyddstestning till ISO/IEC 27001:2022 och Clarysecs efterlevnadsmappning

Dataskyddskontroller fungerar inte isolerat. Skydd av PII beror på tillgångsförteckning, klassificering, åtkomstkontroll, molnstyrning, datamaskering, informationsöverföring, loggning, övervakning, radering, skydd av poster, leverantörstillsyn och oberoende granskning.

I Zenith Controls: The Cross-Compliance Guide mappas ISO/IEC 27001:2022 bilaga A-kontroll 5.34, Privacy and protection of PII, som en förebyggande kontroll kopplad till konfidentialitet, riktighet och tillgänglighet, med cybersäkerhetsbegreppen Identify och Protect samt operativa förmågor inom Information Protection och Legal and Compliance.

Relationen till förteckningen är direkt:

En förteckning över informationstillgångar (5.9) bör omfatta PII-datainnehav (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.

Från Zenith Controls, Privacy and Protection of PII, kontroll 5.34.

För revisionstestning innebär detta att dataskyddsrevisorn inte bör börja med enbart integritetsmeddelandet. Revisorn bör börja med PII-förteckningen, behandlingsregistret, dataflöden, tillgångsförteckningen och leverantörsförteckningen. Om förteckningen är ofullständig kan efterföljande dataskyddskontroller inte vara fullt tillförlitliga.

Guiden mappar också ISO/IEC 27001:2022 bilaga A-kontroll 5.34 till relaterade kontroller såsom 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.14 Information transfer, 5.15 Access control, 5.16 Identity management, 5.23 Information security for use of cloud services, 5.33 Protection of records, 8.11 Data masking, 8.12 Data leakage prevention och 8.10 Information deletion.

Två ytterligare ISO/IEC 27001:2022 bilaga A-kontroller är särskilt relevanta:

Policy för dataskydd och integritet kräver:

En intern revision av dataskyddsefterlevnad ska genomföras årligen eller vid större organisatoriska eller regulatoriska ändringar. Revisionens omfattning ska omfatta:

Från avsnittet ”Styrningskrav”, policyklausul 5.4.

Den omfattar vidare:

Effektivitet hos tekniska och organisatoriska åtgärder

Från avsnittet ”Styrningskrav”, policyklausul 5.4.1.

Policy för dataskydd och integritet - SME behåller samma förväntan i praktisk form:

Regelbundna dataskyddsrevisioner eller kontrollgranskningar måste utföras och loggas

Från avsnittet ”Styrningskrav”, policyklausul 5.3.3.

Varför ansvarsskyldighet enligt GDPR nu är en fråga om cybersäkerhetsstyrning

Dataskyddsunderlag efterfrågas inte längre enbart av dataskyddsrevisorer. Samma underlag kan begäras av en ISO 27701:2025-revisor, en ISO/IEC 27001:2022-revisor, en GDPR-granskare, en behörig myndighet enligt NIS2, en DORA-reglerad kund, en NIST CSF-bedömare eller styrelsens riskkommitté.

NIS2 Article 21 kräver att väsentliga och viktiga entiteter inför lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för cybersäkerhetsriskhantering. Article 21(2)(f) omfattar uttryckligen policyer och förfaranden för att bedöma effektiviteten hos åtgärder för cybersäkerhetsriskhantering. NIS2 gör också ledningsorgan ansvariga för att godkänna och utöva tillsyn över åtgärder för cybersäkerhetsriskhantering.

DORA gäller från den 17 januari 2025 för finansiella entiteter och fastställer ett detaljerat regelverk för digital operativ resiliens. Den kräver IKT-riskhantering, tillsyn från ledningsorgan, internrevision, åtgärdande av kritiska iakttagelser, incidentklassificering och rapportering, resiliensprovning, hantering av IKT-tredjepartsrisker, avtalskontroller, register över IKT-tjänstearrangemang och exitstrategier. IKT-leverantörer som betjänar finansiella entiteter bör förvänta sig DORA-drivna underlagsförfrågningar genom kundförsäkran.

NIST CSF 2.0 ger ett användbart översättningslager. Funktionen GOVERN förväntar sig att organisationer förstår intressenters förväntningar, beroenden och rättsliga, regulatoriska, avtalsmässiga, integritetsrelaterade och civilrättsliga skyldigheter. Dess Profiles-ansats hjälper till att jämföra aktuella resultat med målresultat, identifiera gap och prioritera handlingsplaner.

Zenith Blueprint förstärker spårbarhet i Step 24:

Din SoA bör vara konsekvent med ditt Risk Register och din Risk Treatment Plan. Dubbelkontrollera att varje kontroll som du valt som riskbehandling är markerad som ”Applicable” i SoA. Omvänt gäller att om en kontroll är markerad som ”Applicable” i SoA bör du ha en motivering för den – vanligtvis en mappad risk, ett rättsligt/regulatoriskt krav eller ett verksamhetsbehov.

Från fasen Audit, Review & Improvement, Step 24: Audit, Review & Improvement.

För testning av dataskyddskontroller gäller samma princip för PIMS-tillämplighet. Varje tillämplig dataskyddskontroll bör kunna spåras till en behandlingsrisk, rättslig skyldighet, kundkrav eller ett verksamhetsbehov. Varje test bör kunna spåras tillbaka till den kontrollen.

Hur olika revisorer bedömer samma kontroll

Ett starkt testprogram för dataskydd förutser revisorns perspektiv. Samma raderingskontroll, åtkomstkontroll eller kontroll för introduktion av personuppgiftsbiträde tolkas olika beroende på granskningskontext.

Det är därför REG12 är så värdefullt. Den omvandlar dataskyddsefterlevnad till granskningsbart styrningsunderlag.

Vanliga iakttagelser vid testning av PIMS-kontroller

Clarysec ser återkommande samma dataskyddsrelaterade revisionsiakttagelser hos organisationer som förbereder sig för ISO 27701:2025-certifiering, kundförsäkran enligt GDPR eller leverantörsgranskning i större företag.

Behandlingsregistret motsvarar inte systemverkligheten

Behandlingsregistret listar CRM- och supportplattformar, men utvecklare har lagt till analys­exporter, observability-loggar, AI-verktyg och datalagertabeller.

Testrespons: ta urval av system från tillgångsförteckningen och molnförteckningen och stäm sedan av dem mot behandlingsregistret. Använd relationen mellan ISO/IEC 27001:2022 bilaga A-kontrollerna 5.9 och 5.34 som revisionsmotivering.

PII-åtkomst är godkänd men granskas inte periodiskt

Inledande godkännanden finns, men granskningar av privilegierad åtkomst omfattar inte verktyg för supportimpersonering, produktionsdatabaser, BI-kontrollpaneler eller nödkonton.

Testrespons: ta urval av aktiva användare med PII-åtkomst och jämför roll, verksamhetsbehov, godkännande, MFA-status, senaste inloggning och granskningsunderlag.

Avtal med personuppgiftsbiträden finns, men uppföljningen är svag

Personuppgiftsbiträdesavtalet är undertecknat, men leverantörens frågeformulär är gammalt. Ingen har granskat ändringar av underbiträden, datalagringsplatser, säkerhetsläge eller skyldigheter för incidentavisering.

Testrespons: ta urval av kritiska personuppgiftsbiträden och granska leverantörsbedömning, avtalsklausuler, ändringar av underbiträden, skyddsåtgärder vid överföring och uppföljningsposter. Detta stödjer GDPR, NIS2:s förväntningar på leveranskedjan och DORA:s förväntningar på tredjepartsrisker.

Incidenthantering finns, men dataskyddsklassificeringen är inkonsekvent

Säkerhetsincidenter loggas, men integritetspåverkan bedöms inte alltid. Kriterier för personuppgiftsincidenter enligt GDPR dokumenteras inte konsekvent. Kundaviseringar hanteras informellt.

Testrespons: ta urval av incidenter som involverar dataexponering och granska klassificering, dataskyddseskalering, juridisk granskning, aviseringsbeslut, bevarande av underlag, rotorsak och erfarenhetsåterföring.

CAPA avslutas utan verifiering av effektivitet

En rutin uppdateras och iakttagelsen stängs. Ingen testar om nästa urval förbättrades.

Testrespons: verifiera effektiviteten hos korrigerande åtgärder i REG12 inom 30 dagar från rapporterat avslut, enligt krav i Policy för PIMS-övervakning, revision och förbättring.

En 90-dagars sprint för testning av dataskyddskontroller

För organisationer som rör sig mot beredskap för ISO 27701:2025, kunders leverantörsgranskning eller granskning av ansvarsskyldighet enligt GDPR rekommenderar Clarysec en fokuserad 90-dagars sprint.

Vid sprintens slut bör organisationen kunna besvara de frågor som revisorer faktiskt ställer:

• Vilka personuppgifter behandlar ni?
• I vilken roll?
• Vilka kontroller är tillämpliga?
• Varför är de tillämpliga?
• Vilket underlag visar att de är införda?
• Vilket urval visar att de fungerar?
• Vilka brister identifierades?
• Vilka korrigerande åtgärder vidtogs?
• Vem verifierade effektiviteten?
• Vad granskade och beslutade högsta ledningen?

Från dataskydd på papper till påvisbar ansvarsskyldighet

Ett ISO 27701-certifikat är värdefullt, men det är inte slutmålet. Kunder, tillsynsmyndigheter, styrelser och revisorer förväntar sig i allt högre grad bevis för att dataskyddskontroller är utformade, införda, övervakade, korrigerade och styrda.

Dataskyddsefterlevnad misslyckas när den behandlas som ett dokumentationsprojekt. Den klarar granskning när den blir ett testat underlagssystem.

Clarysec hjälper organisationer att gå från påstådd efterlevnad till påvisbar ansvarsskyldighet genom att koppla samman PIMS-policyer, REG03-tillämplighet, REG12-underlagsurval, CAPA-verifiering, ledningens genomgång och mappning mellan ramverk via Zenith Blueprint: An Auditor’s 30-Step Roadmap och Zenith Controls: The Cross-Compliance Guide.

Om din organisation förbereder sig för ISO 27701:2025-certifiering, granskning av ansvarsskyldighet enligt GDPR, kundförsäkran inom dataskydd, styrningsunderlag enligt NIS2 eller DORA-driven leverantörsgranskning bör ni börja med en fokuserad workshop för testning av dataskyddskontroller.

Clarysec kan hjälpa er att mappa REG03-tillämplighet, bygga REG12-revisionsurval, testa prioriterade PIMS-kontroller, koppla iakttagelser till CAPA och förbereda resultat för ledningens genomgång som tål granskning.

Er nästa dataskyddsrevision ska inte vara en jakt på skärmdumpar. Den ska vara en trygg demonstration av att dataskyddet fungerar, är underbyggt med underlag, granskas och förbättras kontinuerligt.