Revisionsklart skydd av PII för GDPR, NIS2 och DORA
Larmet landade i Sarahs inkorg klockan 22.00 en tisdag.
Som CISO på ett växande fintech-SaaS-bolag var sena larm inget ovanligt. Det här var annorlunda. En junior utvecklare hade exponerat en staging-databas mot en publik endpoint under test av en ny analysfunktion. Databasen skulle innehålla testdata, men en nylig synkronisering från produktion till staging hade fyllt den med verkliga kunders personuppgifter.
Incidenten begränsades snabbt. Sedan kom nästa upptäckt. Ett migreringskalkylblad med namnet customer_users_final_v7.xlsx hade kopierats från samma dataset. Det innehöll namn, e-postadresser, rollbehörigheter, användningsloggar, landsfält, supportanteckningar och fritextkommentarer som aldrig borde ha hamnat i ett testarbetsflöde. Det hade kopierats till en delad enhet, laddats ned av en utvecklare, bifogats ett ärende och sedan glömts bort.
Vid midnatt hanterade Sarah inte längre en teknisk felkonfiguration. Hon hanterade ett revisionsproblem.
Bolaget var redan certifierat enligt ISO/IEC 27001:2022. Styrelsen efterfrågade säkerhetsassurans för GDPR inför en lansering på EU-marknaden. Kunder inom finansiella tjänster skickade DORA-frågeformulär för leverantörsgranskning. Molnrelationer och hanterade tjänster väckte NIS2-frågor om leveranskedjan. Juridik kunde förklara skyldigheterna. Utvecklingsorganisationen kunde hänvisa till kryptering. Produktorganisationen hade ambitioner om inbyggt dataskydd. Tillämpbarhetsförklaringen nämnde integritet och skydd av PII.
Men ingen kunde visa, i en sammanhängande och spårbar kedja, vilken PII som fanns, varför den behandlades, vem som hade åtkomst, var den maskeras, vilka leverantörer som berörde den, hur länge den bevarades och hur en incident skulle klassificeras enligt GDPR, NIS2 eller DORA.
Det är exakt därför ISO/IEC 27701:2025 och ISO/IEC 29151:2022 är viktiga. De är inte bara integritetsetiketter. De hjälper organisationer att omsätta integritetslöften till revisionsklara kontroller för skydd av PII. ISO/IEC 27701:2025 utökar ett ledningssystem för informationssäkerhet enligt ISO/IEC 27001:2022 till hantering av integritetsinformation. ISO/IEC 29151:2022 tillför praktisk vägledning för skydd av personligt identifierbar information under hela dess livscykel.
Clarysecs ansats är att bygga en evidensdriven operativ modell för integritet och säkerhet, inte separata efterlevnadssilor. Modellen kombinerar Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls och Clarysec-policyer i ett enda spårbart system för GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, säkerhetsassurans enligt NIST-modell och styrningsförväntningar enligt COBIT 2019.
Varför skydd av PII nu är en revisionsfråga på styrelsenivå
Skydd av PII brukade behandlas som ett ansvar för integritetsteamet. I dag är det en fråga om förtroende, resiliens och regulatoriska krav på styrelsenivå.
GDPR är fortsatt baslinjen för skydd av personuppgifter i Europa och globalt. GDPR definierar personuppgifter, behandling, personuppgiftsansvarig, personuppgiftsbiträde, mottagare, tredje part, samtycke och personuppgiftsincident på sätt som påverkar SaaS-avtal, supportverksamhet, analys, produkttelemetri, leverantörsstyrning och incidenthantering. Principerna kräver laglighet, korrekthet, transparens, ändamålsbegränsning, uppgiftsminimering, riktighet, lagringsminimering, integritet, konfidentialitet och ansvarsskyldighet. I revisionssammanhang frågar GDPR inte bara om data är krypterad. GDPR kräver att organisationen kan visa varför data finns och hur efterlevnad uppnås.
NIS2 höjer kraven på cybersäkerhetsstyrning för väsentliga och viktiga entiteter. Article 21 kräver åtgärder för cybersäkerhetsriskhantering, inklusive riskanalys, policyer för informationssystems säkerhet, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, hantering av sårbarheter, bedömning av kontrolleffektivitet, cyberhygien, kryptografi, personalsäkerhet, åtkomstkontroll, tillgångshantering, autentisering och säker kommunikation. Article 23 lägger till stegvis incidentrapportering, inklusive en tidig varning inom 24 timmar, underrättelse inom 72 timmar och en slutrapport inom en månad efter underrättelsen.
DORA förändrar diskussionen för finansiella entiteter och deras IKT-leverantörer. Förordningen gäller från den 17 januari 2025 och skapar ett harmoniserat regelverk för digital operativ resiliens som omfattar IKT-riskhantering, rapportering av större IKT-relaterade incidenter, resiliensprovning, IKT-tredjepartsrisk, avtalskrav och tillsyn över kritiska IKT-tredjepartsleverantörer. För många finansiella entiteter fungerar DORA som den sektorsspecifika unionsrättsakt där NIS2-likvärdiga skyldigheter överlappar. För SaaS- och IKT-leverantörer som betjänar finansiella institutioner kommer DORA-trycket ofta via avtalsklausuler, kundrevisioner, krav på exit-planering, skyldigheter att stödja incidenthantering och resiliensprovning.
ISO/IEC 27001:2022 ger ledningssystemets ryggrad. Standarden kräver kontext, intressenter, omfattning, ledningens ansvarsskyldighet, policyer, roller, riskbedömning, riskbehandling, tillämpbarhetsförklaring, internrevision, ledningens genomgång och ständig förbättring. Bilaga A omfattar kontroller som är direkt relevanta för skydd av PII, inklusive 5.34 Integritet och skydd av PII, 5.18 Åtkomsträttigheter, 8.11 Datamaskering, 5.23 Informationssäkerhet vid användning av molntjänster, 8.15 Loggning, 8.33 Testinformation, 8.24 Användning av kryptografi och 8.10 Radering av information.
Utmaningen är inte att organisationer saknar kontroller. Utmaningen är att kontrollerna är fragmenterade. Integritetsrelaterade poster finns hos juridik. Åtkomstgranskningar finns hos IT. Maskeringsskript finns hos utvecklingsorganisationen. Leverantörsavtal finns hos inköp. Underlag finns i ärenden, skärmdumpar, kalkylblad och e-post.
ISO/IEC 27701:2025 och ISO/IEC 29151:2022 hjälper till att samla detta underlag kring hantering av integritetsinformation och praxis för skydd av PII. Clarysec omsätter den strukturen till en operativ modell.
Från ISMS till PIMS: den integrerade kontrollkedjan för integritet
Ett ISMS enligt ISO/IEC 27001:2022 besvarar en kärnfråga: är informationssäkerheten styrd, riskbaserad, införd, övervakad och förbättrad?
Ett Privacy Information Management System, eller PIMS, utökar den frågan för personuppgifter: hanteras integritetsansvar, PII-behandlingsaktiviteter, integritetsrisker, skyldigheter för personuppgiftsansvarig och personuppgiftsbiträde, registrerades rättigheter och underlag för integritetskontroller inom samma system?
ISO/IEC 27701:2025 utökar ISMS till integritetsstyrning. ISO/IEC 29151:2022 kompletterar detta med praktisk vägledning för skydd av PII, inklusive begränsning av insamling, hantering av utlämnande, tillämpning av maskering eller pseudonymisering, skydd av överföringar, begränsning av åtkomst och anpassning av kontroller till integritetsrisk.
| Lager | Huvudfråga | Typiskt revisionsbevis |
|---|---|---|
| ISO/IEC 27001:2022 | Finns ett styrt och riskbaserat ISMS med valda och fungerande kontroller? | Omfattning, intressenter, riskbedömning, riskbehandlingsplan, SoA, policyer, internrevision, ledningens genomgång |
| ISO/IEC 27701:2025 | Styrs integritetsansvar, integritetsrisker och PII-behandlingsaktiviteter inom ledningssystemet? | Integritetsroller, behandlingsregister, rutiner för personuppgiftsansvarig och personuppgiftsbiträde, integritetsriskbedömningar, DPIA:er, process för registrerades begäranden |
| ISO/IEC 29151:2022 | Har praktiska åtgärder för skydd av PII införts över datans livscykel? | PII-klassificering, åtkomstbegränsningar, maskering, pseudonymisering, kontroller för bevarande, skyddsåtgärder vid överföring, incidentunderlag |
| GDPR | Kan organisationen visa laglig, korrekt, transparent, minimerad, säker och ansvarsskyldig behandling? | Poster om rättslig grund, integritetsmeddelanden, DPIA:er, incidentprocess, personuppgiftsbiträdesavtal, hantering av rättigheter |
| NIS2 och DORA | Kan organisationen styra cybersäkerhets- och resiliensrisker, inklusive incidenter och leverantörer? | Ledningens tillsyn, IKT-riskramverk, incidentklassificering, rapporteringsplaner, leverantörsregister, revisionsrätt, kontinuitetstester |
Den här lagerindelade modellen förhindrar det vanligaste misstaget inom integritetsefterlevnad: att behandla PII som bara ännu en typ av känsliga data. PII medför rättsliga, etiska, operativa, avtalsmässiga och anseenderelaterade skyldigheter. Den behöver en kontrollkedja som börjar med medvetenhet och slutar med underlag.
Börja med datamedvetenhet, inte krypteringsdiagram
Det vanligaste integritetsfelet Clarysec ser är bristande kontext. Ett företag kan inte skydda PII om det inte vet vilken PII det har, var den finns, vilket ändamål den fyller, hur länge den bevaras eller vem som kan nå den.
Zenith Blueprint påbörjar detta arbete tidigt i fasen Riskhantering. I steg 9, Identifiering av tillgångar, hot och sårbarheter, instrueras organisationer att inventera informationstillgångar och uttryckligen markera personuppgifter:
”För varje tillgång ska viktiga uppgifter registreras: namn/beskrivning, ägare, plats och klassificering (känslighet). En tillgång kan till exempel vara ’kunddatabas – ägs av IT-avdelningen – hostas på AWS – innehåller personuppgifter och finansiella data (hög känslighet).’”
Den lägger också till: ”Säkerställ att personuppgiftstillgångar markeras (för GDPR-relevans) och att kritiska tjänstetillgångar noteras (för eventuell NIS2-tillämplighet om ni verkar i en reglerad sektor).”
Detta är grunden för införande av ISO/IEC 27701:2025 och ISO/IEC 29151:2022. Den praktiska ordningen är enkel:
- Identifiera system, dataset, lagringsplatser, loggar, rapporter, säkerhetskopior, supportverktyg, utvecklingsmiljöer och leverantörer som behandlar PII.
- Tilldela en ägare till varje PII-tillgång.
- Klassificera PII efter känslighet, verksamhetsändamål, rättslig grund, behandlingsroll och krav på bevarande.
- Koppla varje PII-tillgång till hot, sårbarheter, riskscenarier och regulatoriska skyldigheter.
- Välj kontroller, tilldela underlag och övervaka funktionen över tid.
Clarysec-policyer gör detta genomförbart. SME Policy för dataskydd och integritet Policy för dataskydd och integritet - SME anger:
”Integritetssamordnaren ska upprätthålla ett register över alla behandlingsaktiviteter för personuppgifter, inklusive datakategorier, ändamål, rättslig grund och bevarandeperioder”
Från avsnittet ’Styrningskrav’, policyklausul 5.2.1.
För större organisationer fastställer Policy för dataskydd och integritet Policy för dataskydd och integritet en strikt minimeringsregel:
”Endast data som är nödvändiga för ett specifikt och legitimt verksamhetsändamål får samlas in och behandlas.”
Från avsnittet ’Krav för genomförande av policyn’, policyklausul 6.2.1.
Dessa klausuler omsätter GDPR:s ansvarsskyldighet i daglig verksamhet. De stödjer också hantering av integritetsinformation och skydd av PII eftersom de tvingar organisationen att definiera vilka data som finns, varför de finns och om de är nödvändiga.
De tre kontroller som gör skydd av PII verkligt
Tre kontroller i ISO/IEC 27001:2022 bilaga A avgör ofta om skydd av PII är försvarbart vid revision: 5.34 Integritet och skydd av PII, 8.11 Datamaskering och 5.18 Åtkomsträttigheter.
5.34 Integritet och skydd av PII
Kontroll 5.34 är styrningsnavet. I Zenith Controls behandlas 5.34 som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, med cybersäkerhetsbegreppen Identifiera och Skydda samt operativa förmågor inom informationsskydd och efterlevnad av rättsliga krav.
Zenith Controls gör beroendet tydligt:
”En förteckning över informationstillgångar (5.9) bör omfatta PII-datalager (kunddatabaser, HR-filer). Detta stödjer 5.34 genom att säkerställa att organisationen vet vilken PII den har och var den finns, vilket är det första steget för att skydda den.”
Kontroll 5.34 är beroende av 5.9 Förteckning över information och andra tillhörande tillgångar eftersom PII inte kan skyddas om den inte kan hittas. Den kopplar också till 5.23 Informationssäkerhet vid användning av molntjänster eftersom merparten av PII i dag finns i molnplattformar, SaaS-verktyg, analysmiljöer och hanterade tjänster.
För högriskbehandling kräver organisationens Policy för dataskydd och integritet:
”Hotmodellering och konsekvensbedömningar avseende dataskydd (DPIA) är obligatoriska för högriskbehandlingssystem.”
Från avsnittet ’Krav för genomförande av policyn’, policyklausul 6.3.4.
Den klausulen är kritisk. Den gör integritet till en design- och riskhanteringsaktivitet, inte en juridisk slutgranskning.
8.11 Datamaskering
Kontroll 8.11 är det direkta svaret på Sarahs exponering av staging-databasen. Zenith Controls beskriver 8.11 som en förebyggande konfidentialitetskontroll inom informationsskydd. Den kopplar 8.11 till 5.12 Klassificering av information eftersom maskeringsbeslut beror på känslighet, till 5.34 eftersom maskering stödjer integritetsskydd och till 8.33 Testinformation eftersom testmiljöer inte ska exponera verklig PII.
Policy för datamaskering och pseudonymisering Policy för datamaskering och pseudonymisering gör regeln explicit:
”Verkliga personuppgifter får inte användas i utvecklings-, test- eller stagingmiljöer. Maskerade eller pseudonymiserade data ska användas i stället och ska genereras från förhandsgodkända transformationsmallar.”
Från avsnittet ’Krav för genomförande av policyn’, policyklausul 6.3.
För SME:er lägger Policy för datamaskering och pseudonymisering Policy för datamaskering och pseudonymisering - SME till ett centralt säkerhets- och beviskrav:
”Åtkomst till nycklar ska vara krypterad, åtkomststyrd och loggad.”
Från avsnittet ’Krav för genomförande av policyn’, policyklausul 6.2.1.3.
Detta är viktigt eftersom pseudonymisering bara minskar risk när transformationslogik, nycklar och vägar för återidentifiering kontrolleras.
5.18 Åtkomsträttigheter
Kontroll 5.18 är den operativa kärnan i principen om minsta privilegium. Zenith Controls behandlar den som förebyggande, kopplad till konfidentialitet, riktighet och tillgänglighet, och placerad inom identitets- och åtkomsthantering. Den knyter 5.18 till 5.15 Åtkomstkontroll, 5.16 Identitetshantering och 8.2 Privilegierade åtkomsträttigheter.
SME Policy för dataklassificering och märkning Policy för dataklassificering och märkning - SME anger:
”Åtkomst ska begränsas till särskilt behöriga användare med ett behov enligt Need-to-know-principen.”
Från avsnittet ’Styrningskrav’, policyklausul 5.2.1.
Organisationens Policy för dataklassificering och märkning Policy för dataklassificering och märkning lägger till klassificeringsbaslinjen:
”Alla informationstillgångar ska ha en tydligt tilldelad klassificering vid skapande eller introduktion. Om uttrycklig klassificering saknas ska tillgångar som standard klassificeras som ’Konfidentiell’ tills de har granskats formellt.”
Från avsnittet ’Styrningskrav’, policyklausul 5.4.
Tillsammans bildar dessa kontroller den praktiska kedjan för skydd av PII: känna till PII, klassificera den, begränsa åtkomst, maskera den när full identitet inte behövs, skydda nycklar, logga åtkomst och bevara underlag.
Bygg spårbarhet genom tillämpbarhetsförklaringen
Ett integritetsledningssystem blir revisionsklart när det kan visa spårbarhet. Zenith Blueprint, fasen Riskhantering, steg 13, Planering av riskbehandling och tillämpbarhetsförklaring, beskriver tillämpbarhetsförklaringen som ett bryggdokument:
”SoA är i praktiken ett bryggdokument: den kopplar er riskbedömning/riskbehandling till de faktiska kontroller ni har. Genom att fylla i den dubbelkontrollerar ni också om ni har missat några kontroller.”
Detta koncept är centralt för beredskap enligt ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 och DORA. Varje PII-kontroll bör vara spårbar från krav till risk, från risk till kontroll, från kontroll till ägare, från ägare till underlag och från underlag till granskning.
| Spårbarhetspost | Exempel för PII i kundsupport | Förväntat underlag |
|---|---|---|
| PII-tillgång | Supportärendesystem med kundnamn, e-postadresser, loggar och bilagor | Post i tillgångsregister, ägare, molnplats, klassificering |
| Behandlingsändamål | Kundsupport och tjänstediagnostik | Behandlingsregister, rättslig grund, bevarandeperiod |
| Riskscenario | Supportagent eller utvecklare får åtkomst till för mycket kunddata | Post i riskregister, sannolikhet, konsekvens, ägare |
| Kontrollval | 5.34 PII-skydd, 5.18 åtkomsträttigheter, 8.11 maskering, 8.15 loggning, 5.23 molnstyrning | SoA, åtkomstpolicy, maskeringsstandard, loggningskonfiguration |
| Operativt underlag | Rollbaserad åtkomst, maskerade exporter, kvartalsvis åtkomstgranskning, larm vid massnedladdningar | Åtkomstgranskningsposter, DLP-larm, loggar, ärendeunderlag |
| Regulatorisk mappning | GDPR-ansvarsskyldighet och säkerhet, NIS2-riskhantering, DORA:s krav på IKT-risk och leverantörer | Efterlevnadsmatris, incidenthanteringsplan, register över leverantörsavtal |
| Granskningsunderlag | Internrevisionsiakttagelse stängd, åtgärd från ledningens genomgång accepterad | Revisionsrapport, korrigerande åtgärder, mötesprotokoll från ledningens genomgång |
ISO/IEC 27005:2022 stödjer detta riskbaserade angreppssätt genom att betona intressentkrav, gemensamma riskkriterier, ansvariga riskägare, upprepbar riskbedömning, riskbehandling, kontrollval, anpassning till tillämpbarhetsförklaringen, godkännande av kvarstående risk, övervakning och ständig förbättring. Skydd av PII ska vara en levande riskcykel, inte en engångsövning i GDPR-dokumentation.
Åtgärda det riskfyllda kalkylbladet och staging-databasen
Sarahs incident kan omvandlas till ett upprepbart kontrollpaket om åtgärdandet hanteras systematiskt.
| Steg | Åtgärd | Resultat i Clarysec-underlag |
|---|---|---|
| 1 | Registrera staging-databasen och kalkylbladet som PII-tillgångar | Poster i tillgångsregister med ägare, plats, klassificering, PII-kategorier, ändamål och bevarande |
| 2 | Uppdatera behandlingsaktiviteten | Registerpost som visar datakategorier, rättslig grund, ändamål och bevarandeperiod |
| 3 | Klassificera filer och dataset | Konfidentiell eller högre klassificering tillämpas som standard tills formell granskning har gjorts |
| 4 | Ta bort verklig PII från icke-produktionsmiljöer | Maskerat eller pseudonymiserat dataset genererat från godkända transformationsmallar |
| 5 | Begränsa och granska åtkomst | Behörigheter enligt Need-to-know-principen, indragen överdriven åtkomst, post från åtkomstgranskning |
| 6 | Skydda transformationslogik och nycklar | Krypterad, åtkomststyrd och loggad nyckelåtkomst |
| 7 | Samla underlag centralt | Tillgångspost, riskpost, åtkomstgranskning, raderingsbevis, maskeringsgodkännande och ärendestängning |
| 8 | Uppdatera SoA och riskbehandlingsplanen | Riskscenario kopplat till 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 och leverantörskontroller |
| 9 | Besluta om en DPIA krävs | DPIA eller dokumenterad motivering för beslut om högriskbehandling |
| 10 | Dokumentera erfarenhetsåterföring | Uppdaterad utbildning, regler för säker utveckling, exportkontroller, DLP-övervakning och vägledning för testdata |
Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning - SME anger:
”Allt underlag ska lagras i en centraliserad revisionsmapp.”
Från avsnittet ’Krav för genomförande av policyn’, policyklausul 6.2.1.
Informationssäkerhetspolicy Informationssäkerhetspolicy gör det bredare revisionskravet explicit:
”Alla införda kontroller ska vara möjliga att granska, stödjas av dokumenterade rutiner och ha bevarat underlag för kontrollernas funktion.”
Från avsnittet ’Krav för genomförande av policyn’, policyklausul 6.6.1.
Dessa två klausuler är skillnaden mellan att ha en kontroll och att kunna bevisa den.
Mappning över flera regelverk för en gemensam uppsättning PII-kontroller
Skydd av PII blir lättare att försvara när det mappas över ramverk innan revisorn frågar.
| Tema för skydd av PII | Relevans för GDPR | Relevans för ISO/IEC 27001:2022, ISO/IEC 27701:2025 och ISO/IEC 29151:2022 | Relevans för NIS2 | Relevans för DORA | Revisionsperspektiv enligt NIST och COBIT 2019 |
|---|---|---|---|---|---|
| PII-förteckning och behandlingsregister | Ansvarsskyldighet, rättslig grund, ändamålsbegränsning, lagringsminimering | ISMS-kontext, 5.9 tillgångsregister, hantering av integritetsinformation, skydd av PII | Tillgångshantering och riskanalys | Medvetenhet om IKT-tillgångar och tjänsteberoenden | Underlag för identifieringsfunktionen och styrning av informationstillgångar |
| Åtkomsträttigheter och principen om minsta privilegium | Riktighet och konfidentialitet, rollbegränsad åtkomst | 5.15 åtkomstkontroll, 5.16 identitetshantering, 5.18 åtkomsträttigheter, 8.2 privilegierade åtkomsträttigheter | Åtkomstkontroll, personalsäkerhet, autentisering | IKT-riskkontroller och tillsyn över privilegierad åtkomst | Tillämpning av åtkomst, ägarskap, ansvar och övervakning |
| Maskering och pseudonymisering | Uppgiftsminimering, inbyggt dataskydd, säkerhet i behandlingen | 5.12 klassificering, 5.34 PII-skydd, 8.11 datamaskering, 8.33 testinformation | Cyberhygien och säker utveckling | Säker testning, minskad dataförlust, operativ resiliens | Testning av tekniska skyddsåtgärder och tillförlitlig kontrolldrift |
| Incidentklassificering och rapportering | Bedömning och anmälan av personuppgiftsincident | Incidentplanering, händelsebedömning, respons, bevisinsamling | Tidig varning inom 24 timmar, underrättelse inom 72 timmar, slutrapport | Klassificering och rapportering av större IKT-relaterad incident | Eskaleringskriterier, beslutsloggar, rotorsak, åtgärdande |
| Leverantörs- och molnbehandling | Personuppgiftsbiträdesskyldigheter, överföringar, avtal | 5.21 IKT-leveranskedja, 5.23 molntjänster, 5.31 rättsliga och avtalsmässiga krav | Säkerhet i leveranskedjan | IKT-tredjepartsrisk, revisionsrätt, exit och övergång | Tredjepartsstyrning, säkerhetsassurans och ledningens ansvarsskyldighet |
Här är Zenith Controls särskilt användbar. För 5.34 mappar den PII-skydd till tillgångsregister, datamaskering och molnstyrning. För 8.11 mappar den maskering till klassificering, integritetsskydd och testinformation. För 5.18 mappar den åtkomsträttigheter till åtkomstkontroll, identitetshantering och privilegierad åtkomst. Dessa relationer gör det möjligt för ett team att förklara inte bara att en kontroll finns, utan varför den finns och vilka angränsande kontroller som måste fungera tillsammans med den.
Hur olika revisorer testar samma PII-kontroll
En enskild kontroll, till exempel 8.11 Datamaskering, granskas olika beroende på revisionsperspektiv.
| Revisortyp | Huvudfokus | Underlag som förväntas |
|---|---|---|
| ISO/IEC 27001:2022- och ISO/IEC 27701:2025-revisor | Integrering av ISMS och PIMS, riskbehandling, korrekt SoA | Riskbedömning, SoA-post, maskeringspolicy, ändringsposter, internrevisionsresultat |
| GDPR- eller dataskyddsmyndighetsgranskare | Inbyggt dataskydd, minimering, ansvarsskyldighet | Behandlingsregister, rättslig grund, DPIA, underlag för pseudonymisering, bevarandelogik |
| NIS2-bedömare | Säker utveckling, incidentförebyggande, styrning | Rutin för säker utveckling, utvecklarutbildning, underlag för incidentåtgärdande, granskning av kontrolleffektivitet |
| DORA-kund eller revisor | Operativ IKT-resiliens och tredjepartsrisk | Testunderlag för kritiska applikationer, leverantörsavtalsklausuler, skyldigheter att stödja incidenthantering, återställnings- och exit-planering |
| Granskare enligt NIST-modell eller COBIT 2019 | Kontrolldesign, drift, ägarskap, övervakning | Kontrollägare, mätetal, underlagsarkiv, ledningsrapportering, korrigerande åtgärder |
En ISO/IEC 27001:2022-revisor börjar med ledningssystemlogiken. Ingår PII i omfattningen? Har intressentkrav identifierats? Bedöms integritetsrisker med definierade kriterier? Väljs kontroller genom riskbehandling? Är SoA korrekt? Täcker internrevisioner och ledningens genomgång PII-relaterade kontroller?
En integritetsgranskare börjar med ansvarsskyldighet. Vilka personuppgifter behandlas? Vilken är den rättsliga grunden? Informeras de registrerade? Är behandlingen begränsad till ett specifikt ändamål? Bedöms högriskaktiviteter? Styrs personuppgiftsbiträden?
En NIS2-fokuserad bedömare börjar med styrning och cybersäkerhetsriskhantering. Godkänner och utövar ledningen tillsyn över åtgärderna? Är incidenthantering, kontinuitet, leverantörssäkerhet, åtkomstkontroll, tillgångshantering, säker utveckling och bedömning av kontrolleffektivitet integrerade?
En DORA-kund eller revisor frågar om IKT-riskhantering är dokumenterad, styrelsestyrd, proportionerlig och avtalsmässigt understödd. Om PII behandlas i tjänster som stödjer finansiella entiteter, förvänta frågor om incidentstöd, platser för databehandling, återställning, revisionsrätt, servicenivåer, uppsägning och exit.
En granskare enligt COBIT 2019 eller ISACA-modell testar styrningsanpassning. Vem äger PII-risken? Vilket styrningsorgan får rapportering? Är ansvar tilldelade? Övervakas leverantörer? Spåras avvikelser? Används mätetal för beslutsfattande? Är kvarstående risk formellt accepterad?
En evidensmodell kan tillgodose alla dessa perspektiv, men endast om kontrollsystemet från början är utformat för spårbarhet.
Vanliga revisionsiakttagelser i program för skydd av PII
Organisationer som arbetar med beredskap för ISO/IEC 27701:2025 eller ISO/IEC 29151:2022 utan en integrerad verktygslåda ser ofta samma iakttagelser.
| Iakttagelse | Varför det är viktigt | Åtgärdande med Clarysec |
|---|---|---|
| PII-förteckningen utesluter loggar, säkerhetskopior, analysutdrag eller supportbilagor | Dold PII kan inte skyddas eller raderas tillförlitligt | Utöka tillgångsregistret och behandlingsregistret i steg 9 så att alla PII-platser ingår |
| Testmiljöer använder produktionsdata | Verklig PII exponeras där den inte behövs | Tillämpa maskeringspolicy och godkända transformationsmallar |
| Åtkomstgranskningar är generiska och fokuserar inte på PII-lagringsplatser | Överdriven åtkomst förblir oupptäckt | Mappa 5.18 åtkomsträttigheter till PII-tillgångsägare och underlag från periodiska granskningar |
| Rättslig grund är dokumenterad men inte kopplad till system eller bevarande | GDPR:s ansvarsskyldighet kan inte visas | Lägg till fält för rättslig grund och bevarande i behandlingsregistret och tillgångsregistret |
| Leverantörsavtal saknar dataplatser, incidentstöd, revisionsrätt eller exit-bestämmelser | Brister kvarstår i leverantörsassurans för DORA, NIS2 och GDPR | Anpassa leverantörsgranskning och avtal till IKT-tredjepartsstyrning och molnstyrning |
| Incidenthanteringsplaner skiljer inte säkerhetsincidenter från personuppgiftsincidenter | Rapporteringsfrister kan missas | Bygg klassificeringsträd för rapporteringsutlösare enligt GDPR, NIS2 och DORA |
| Underlag är spritt över ärenden, enheter, skärmdumpar och e-post | Beredskap för revision misslyckas även när kontroller fungerar | Använd centraliserade revisionsmappar och namngivningsstandarder för underlag |
Dessa iakttagelser är inte pappersproblem. De är problem i den operativa modellen. ISO/IEC 27701:2025 och ISO/IEC 29151:2022 åtgärdar dem inte om inte integritetsstyrning, säkerhetskontroller och hantering av underlag bäddas in i normala arbetsflöden.
Vad ledningen bör fråga inför nästa revision
Innan organisationen påbörjar beredskap för ISO/IEC 27701:2025, införande av ISO/IEC 29151:2022 eller en kundgranskning för GDPR, NIS2 eller DORA bör ledningen ställa tio direkta frågor:
- Har vi ett komplett register över PII-behandlingsaktiviteter, inklusive datakategorier, ändamål, rättslig grund och bevarande?
- Är PII-tillgångar markerade i tillgångsregistret, inklusive loggar, säkerhetskopior, exporter, analysverktyg och supportbilagor?
- Tilldelas dataklassificeringar vid skapande eller introduktion, med oklassificerade tillgångar som standard klassificerade som Konfidentiell?
- Kan vi bevisa att åtkomst till PII är begränsad till behöriga användare med behov enligt Need-to-know-principen?
- Använder utvecklings-, test- och stagingmiljöer maskerade eller pseudonymiserade data i stället för verkliga personuppgifter?
- Är maskeringsmallar godkända och är nycklar skyddade, åtkomststyrda och loggade?
- Kopplar SoA PII-risker till kontroller och regulatoriska skyldigheter?
- Granskas moln- och leverantörsavtal avseende dataplatser, säkerhet, incidentstöd, revisionsrätt, återställning och exit?
- Kan vår incidentprocess klassificera GDPR-personuppgiftsincidenter, NIS2-betydande incidenter och DORA-större IKT-relaterade incidenter?
- Lagras underlag centralt och bevaras på ett sätt som en revisor kan följa?
Om svaret på någon av dessa frågor är oklart är organisationen ännu inte revisionsklar.
Gör skydd av PII verifierbart
Sarahs sena incident hade kunnat bli en fragmenterad efterlevnadskris. I stället kan den bli startpunkten för en starkare operativ modell: ett ISMS enligt ISO/IEC 27001:2022 utökat till integritet genom ISO/IEC 27701:2025, förstärkt av praxis enligt ISO/IEC 29151:2022 och mappat mot GDPR, NIS2, DORA, säkerhetsassurans enligt NIST-modell och styrningsförväntningar enligt COBIT 2019.
Det är det verkliga värdet av revisionsklart skydd av PII. Det bygger inte på att hitta rätt kalkylblad innan revisorn anländer. Det bygger på ett system som redan vet var PII finns, varför den finns, hur den skyddas, vem som är ansvarig, vilka leverantörer som är involverade och var underlaget finns.
Börja med Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för att strukturera ert genomförande. Använd Zenith Controls: The Cross-Compliance Guide Zenith Controls för att mappa skydd av PII över ISO/IEC 27001:2022, GDPR, NIS2, DORA, säkerhetsassurans enligt NIST-modell och styrningsförväntningar enligt COBIT 2019. Operationalisera arbetet med Clarysec-policyer, inklusive Policy för dataskydd och integritet Policy för dataskydd och integritet, Policy för datamaskering och pseudonymisering Policy för datamaskering och pseudonymisering, Policy för dataklassificering och märkning Policy för dataklassificering och märkning, Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning - SME och Informationssäkerhetspolicy Informationssäkerhetspolicy.
Om nästa kundrevision, GDPR-granskning, NIS2-beredskapsprojekt eller DORA-leverantörsbedömning närmar sig, vänta inte på att en incident ska avslöja luckorna. Ladda ned Clarysec-verktygslådorna, begär en demo eller boka en bedömning av skyddet av PII och bygg ett integritetsprogram som inte bara uppfyller kraven, utan också är försvarbart.
Frequently Asked Questions
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
