Underlag för TOMs enligt GDPR Article 32 med ISO, NIS2 och DORA
E-postmeddelandet landar i informationssäkerhetschefens inkorg med den välbekanta tyngden av en affär som kan påverka bolagets kvartal.
En stor potentiell företagskund vill se underlag för ”tekniska och organisatoriska åtgärder enligt GDPR Article 32, mappade mot ISO 27001:2022, NIS2 och DORA där det är tillämpligt”. Samtidigt har juristfunktionen informerat styrelsen om ledningens ansvar enligt NIS2 och förväntningarna på operativ resiliens enligt DORA. Styrelsens instruktion låter enkel: visa efterlevnad, undvik dubbelarbete och gör inte detta till tre separata projekt.
Organisationen har kontroller. MFA är aktiverat. Säkerhetskopiering körs. Utvecklare granskar kod. Dataskyddsteamet underhåller register över behandlingsaktiviteter. Infrastrukturteamet skannar efter sårbarheter. Leverantörer granskas vid upphandling. Men när den potentiella kunden begär underlag splittras svaret.
Rapporten från identitetsleverantören finns på ett ställe. Loggar för säkerhetskopiering finns på ett annat. Riskregistret har inte uppdaterats sedan den senaste produktreleasen. Underlag för leverantörssäkerhet ligger i e-postmeddelanden från inköp. Anteckningar från incidenthanteringens skrivbordsövningar finns, men ingen kan visa att erfarenheterna har förts tillbaka till riskbehandlingen. Styrelsen godkände säkerhetsinvesteringar, men godkännandet är inte kopplat till en IKT-risk eller ett dokumenterat kontrollbeslut.
Det är det verkliga problemet med tekniska och organisatoriska åtgärder enligt GDPR Article 32, ofta kallade TOMs. De flesta organisationer misslyckas inte för att de saknar kontroller. De misslyckas för att de inte kan visa att kontrollerna är riskbaserade, godkända, införda, övervakade och förbättrade.
GDPR:s ansvarsskyldighet gör denna förväntan uttrycklig. GDPR Article 5 kräver att personuppgifter skyddas med lämplig säkerhet mot obehörig eller olaglig behandling och mot oavsiktlig förlust, förstöring eller skada. Article 5(2) gör den personuppgiftsansvarige ansvarig för att visa efterlevnad. GDPR:s definitioner är också viktiga. Personuppgifter är ett brett begrepp, behandling omfattar nästan varje åtgärd som utförs med data, pseudonymisering är en erkänd skyddsåtgärd, och en personuppgiftsincident omfattar oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande eller obehörig åtkomst.
En underlagsfil för Article 32 kan därför inte vara en mapp med slumpmässiga skärmdumpar. Den måste vara ett levande kontrollsystem.
Clarysec:s metod är att omvandla TOMs enligt GDPR Article 32 till en spårbar underlagsmotor byggd på ISO/IEC 27001:2022 ISO/IEC 27001:2022, förstärkt med riskhantering enligt ISO/IEC 27005:2022 och korsrefererad mot NIS2- och DORA-skyldigheter där de är tillämpliga. Målet är inte dokumentation för dokumentationens skull. Målet är att göra organisationen revisionsredo innan en kund, revisor, tillsynsmyndighet eller styrelseledamot ställer den svåra frågan.
Varför TOMs enligt GDPR Article 32 fallerar i praktiken
Article 32 missförstås ofta som en lista över säkerhetsverktyg: kryptering, säkerhetskopiering, loggning, åtkomstkontroll och incidenthantering. Dessa åtgärder är viktiga, men de är bara försvarbara när de är lämpliga i förhållande till risken och kopplade till personuppgifternas livscykel.
För ett SaaS-bolag som behandlar uppgifter om kunders anställda räcker det inte att säga ”vi använder kryptering”. En revisor kan fråga vilka data krypteringen skyddar, var kryptering krävs, hur nycklar hanteras, om säkerhetskopior är krypterade, om produktionsdata maskeras vid testning, vem som kan kringgå kontroller och hur undantag godkänns.
Clarysec:s företagsversion av Policy för dataskydd och integritet fångar den operativa principen:
”Inför tekniska och organisatoriska åtgärder (TOMs) som skyddar konfidentialitet, riktighet och tillgänglighet för personligt identifierbar information (PII) genom hela dess livscykel.”
Källa: Policy för dataskydd och integritet, Mål, policyklausul 3.3. Policy för dataskydd och integritet
Formuleringen ”genom hela dess livscykel” är där många TOM-program blir svaga. Personuppgifter kan vara skyddade i produktion men kopieras till analyssystem, loggar, supportexporter, testmiljöer, säkerhetskopior, leverantörsplattformar och medarbetares enheter. Varje plats skapar säkerhets- och dataskyddsrisk.
GDPR Article 6 kräver en rättslig grund för behandling, inklusive samtycke, avtal, rättslig förpliktelse, skydd av grundläggande intressen, uppgift av allmänt intresse eller berättigat intresse. När data återanvänds för ett ytterligare ändamål måste förenlighet och skyddsåtgärder såsom kryptering eller pseudonymisering beaktas. För data med högre risk ökar kraven på underlag. GDPR Article 9 ställer strikta begränsningar för särskilda kategorier av personuppgifter, såsom hälsodata, biometriska data som används för identifiering och annan känslig information. Article 10 begränsar behandling av uppgifter om fällande domar och lagöverträdelser.
För små och medelstora företag uttrycker Clarysec riskbehandling i praktiska termer:
”Kontroller måste införas för att minska identifierade risker, inklusive kryptering, anonymisering, säker avveckling och åtkomstbegränsningar”
Källa: Policy för dataskydd och integritet-sme, Riskbehandling och undantag, policyklausul 7.2.1. Policy för dataskydd och integritet - SME
Det är en stark baslinje för TOMs. För att bli revisionsklar måste varje kontroll också kopplas till en risk, en ägare, ett policykrav, en bevispost och en granskningsfrekvens.
ISO 27001:2022 är ryggraden för underlag enligt Article 32
ISO 27001:2022 fungerar väl för GDPR Article 32 eftersom standarden behandlar säkerhet som ett ledningssystem, inte som en frikopplad checklista över kontroller. Den kräver ett ledningssystem för informationssäkerhet (ISMS) utformat för att bevara konfidentialitet, riktighet och tillgänglighet genom riskhantering.
Det första kritiska steget är omfattning. ISO 27001:2022 klausulerna 4.1 till 4.4 kräver att organisationen förstår interna och externa förutsättningar, identifierar intressenter och krav, avgör vilka krav som ska hanteras av ISMS och definierar ISMS-omfattningen, inklusive gränssnitt och beroenden med externa organisationer. För TOMs enligt Article 32 bör ISMS-omfattningen återspegla behandling av personuppgifter, kundskyldigheter, personuppgiftsbiträden, underbiträden, molnplattformar, distansarbete, supportfunktioner och produktionsmiljöer.
Det andra steget är ledarskap. Klausulerna 5.1 till 5.3 kräver åtagande från högsta ledningen, en informationssäkerhetspolicy, resurser, roller och ansvar samt resultatrapportering. Detta är viktigt eftersom GDPR Article 32, NIS2 och DORA alla bygger på styrning. En kontroll utan ägarskap, finansiering eller granskning är svagt underlag.
Clarysec:s företagsversion av Informationssäkerhetspolicy gör detta uttryckligt:
”ISMS ska omfatta definierade omfattningsgränser, en riskbedömningsmetodik, mätbara mål och dokumenterade kontroller som motiveras i tillämpbarhetsförklaringen (SoA).”
Källa: Informationssäkerhetspolicy, Krav för genomförande av policyn, policyklausul 6.1.2. Informationssäkerhetspolicy
Samma policy fastställer förväntan på underlag:
”Alla införda kontroller ska vara möjliga att granska, stödjas av dokumenterade rutiner och ha bevarat underlag som visar drift.”
Källa: Informationssäkerhetspolicy, Krav för genomförande av policyn, policyklausul 6.6.1.
ISO 27001:2022 klausulerna 6.1.1 till 6.1.3 kräver därefter riskbedömning, riskbehandling, en tillämpbarhetsförklaring, godkännande av kvarstående risk och ansvarsskyldighet för riskägare. Klausul 6.2 kräver mätbara mål. Klausulerna 7.5, 9.1, 9.2, 9.3 och 10.2 kräver dokumenterad information, övervakning, internrevision, ledningens genomgång och korrigerande åtgärder.
För GDPR Article 32 skapar detta en försvarbar struktur.
| Underlagsfråga för GDPR Article 32 | Underlagssvar enligt ISO 27001:2022 |
|---|---|
| Hur avgjorde ni vilka TOMs som är lämpliga? | Riskbedömningskriterier, riskregister, poängsättning av sannolikhet och konsekvens, riskbehandlingsplan |
| Vilka kontroller gäller och varför? | Tillämpbarhetsförklaring med motiveringar för inkludering och exkludering |
| Vem godkände kvarstående risk? | Godkännande från riskägare och formellt godkännande från ledningen |
| Fungerar kontrollerna i drift? | Loggar, ärenden, granskningsprotokoll, testresultat, övervakningsrapporter |
| Granskas kontrollerna? | Internrevisionsrapporter, protokoll från ledningens genomgång, logg över korrigerande åtgärder |
| Beaktas risker för personuppgifter? | Riskposter för dataskydd, integritetskrav inom omfattningen, DPIA eller likvärdig bedömning där det är tillämpligt |
ISO/IEC 27005:2022 stärker denna struktur. Den rekommenderar att organisationer identifierar krav från ISO 27001:2022 bilaga A, regelverk, avtal, branschstandarder, interna regler och befintliga kontroller och därefter för in dem i riskbedömning och riskbehandling. Den kräver också riskkriterier och acceptanskriterier som beaktar rättsliga, regulatoriska, operativa, leverantörsrelaterade, tekniska och mänskliga faktorer, inklusive dataskydd.
Clarysec:s Riskhanteringspolicy är direkt anpassad till detta:
”En formell riskhanteringsprocess ska upprätthållas i enlighet med ISO/IEC 27005 och ISO 31000 och omfatta riskidentifiering, analys, utvärdering, behandling, övervakning och kommunikation.”
Källa: Riskhanteringspolicy, Styrningskrav, policyklausul 5.1. Riskhanteringspolicy
För små och medelstora företag blir samma krav enkelt och genomförbart:
”Varje riskpost måste innehålla: beskrivning, sannolikhet, konsekvens, poäng, ägare och behandlingsplan.”
Källa: Riskhanteringspolicy-sme, Styrningskrav, policyklausul 5.1.2. Riskhanteringspolicy - SME
Den meningen är ett snabbt test av revisionsberedskap. Om en risk saknar ägare eller behandlingsplan är den ännu inte redo som revisionsunderlag.
Clarysec-bryggan: risk, SoA, kontroller och regelverk
Clarysec:s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandlar efterlevnad som spårbarhetsarbete. I riskhanteringsfasen fokuserar Step 13 på planering av riskbehandling och tillämpbarhetsförklaringen. Den förklarar att organisationer bör mappa kontroller till risker, lägga till kontrollreferenser från bilaga A i riskbehandlingsposter, korsreferera externa regelverk och inhämta ledningens godkännande.
Zenith Blueprint är tydlig om SoA:s roll:
”SoA är i praktiken ett bryggdokument: det kopplar er riskbedömning/riskbehandling till de faktiska kontroller ni har. Genom att färdigställa det dubbelkontrollerar ni också om ni har missat några kontroller.”
Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, riskhanteringsfasen, Step 13: planering av riskbehandling och tillämpbarhetsförklaring (SoA). Zenith Blueprint
Step 14 i Zenith Blueprint lägger till lagret för regulatoriska korsreferenser. Den rekommenderar att organisationer dokumenterar hur krav enligt GDPR, NIS2 och DORA täcks av policyer och kontroller. För GDPR betonas skydd av personuppgifter i riskbedömningar och riskbehandlingar, inklusive kryptering som teknisk åtgärd och hantering av personuppgiftsincidenter som en del av kontrollmiljön. För NIS2 lyfts riskbedömning, nätverkssäkerhet, åtkomstkontroll, incidenthantering och verksamhetskontinuitet. För DORA pekar den på IKT-riskhantering, incidenthantering, rapportering och tillsyn över IKT-tredjepartsleverantörer.
Det är kärnan i Clarysec:s metod: ett ISMS, ett riskregister, en SoA, ett underlagsbibliotek och flera efterlevnadsutfall.
Zenith Controls: The Cross-Compliance Guide Zenith Controls stödjer detta genom att hjälpa organisationer att använda kontrollområden i ISO/IEC 27002:2022 ISO/IEC 27002:2022 som ankare för korsvis efterlevnad. För GDPR Article 32 är de viktigaste ankaren ofta integritet och skydd av PII, kontroll 5.34; oberoende granskning av informationssäkerhet, kontroll 5.35; och användning av kryptografi, kontroll 8.24.
| Kontrollankare i ISO/IEC 27002:2022 enligt Zenith Controls | Varför det är viktigt för TOMs enligt Article 32 | Exempel på underlag |
|---|---|---|
| 5.34 Integritet och skydd av PII | Kopplar informationssäkerhetskontroller till hantering av personuppgifter och dataskyddsskyldigheter | Dataregister, integritetsriskbedömning, bevarandeschema, poster över personuppgiftsbiträdesavtal, åtkomstgranskningar |
| 5.35 Oberoende granskning av informationssäkerhet | Visar objektiv säkerhetsförsäkran, revisionsbarhet och förbättring | Internrevisionsrapport, extern bedömning, logg över korrigerande åtgärder, ledningens genomgång |
| 8.24 Användning av kryptografi | Skyddar konfidentialitet och riktighet för data under överföring, data i vila och säkerhetskopior | Krypteringsstandard, poster för nyckelhantering, underlag för diskkryptering, TLS-konfiguration, kryptering av säkerhetskopior |
NIS2 gör TOMs till en cybersäkerhetsfråga på styrelsenivå
Många organisationer behandlar GDPR TOMs som dataskyddsteamets ansvar. NIS2 förändrar samtalet.
NIS2 gäller för många medelstora och stora entiteter i angivna sektorer och i vissa fall oberoende av storlek. Omfattade digitala och tekniska sektorer inkluderar molntjänstleverantörer, datacenterleverantörer, innehållsleveransnätverk, DNS-tjänsteleverantörer, TLD-register, tillhandahållare av betrodda tjänster, tillhandahållare av allmänna elektroniska kommunikationstjänster, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, onlinemarknadsplatser, sökmotorer och sociala nätverksplattformar. Tillämpligheten för SaaS och tekniska små och medelstora företag beror på sektor, storlek, medlemsstatens utpekande och systemisk eller gränsöverskridande påverkan.
NIS2 Article 20 lägger cybersäkerhetsansvar på ledningsorgan. De måste godkänna riskhanteringsåtgärder för cybersäkerhet, övervaka genomförandet och genomgå utbildning. Väsentliga entiteter kan drabbas av administrativa sanktionsavgifter om minst 10 miljoner EUR eller minst 2 procent av den globala årsomsättningen. Viktiga entiteter kan drabbas av sanktionsavgifter om minst 7 miljoner EUR eller minst 1,4 procent.
NIS2 Article 21 är direkt relevant för TOMs enligt Article 32 eftersom den kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder. Dessa åtgärder ska beakta aktuell tekniknivå, europeiska och internationella standarder, kostnad, exponering, storlek, sannolikhet, allvarlighetsgrad och samhällelig eller ekonomisk påverkan. Kravområdena omfattar riskanalys, säkerhetspolicyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och utveckling, hantering av sårbarheter, bedömning av effektivitet, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering, MFA eller kontinuerlig autentisering samt säker kommunikation där det är lämpligt.
NIS2 Article 23 tillför stegvis incidentrapportering: tidig varning inom 24 timmar, incidentanmälan inom 72 timmar, mellanliggande uppdateringar när de begärs och en slutrapport senast en månad efter 72-timmarsanmälan. Om en personuppgiftsincident också utgör en betydande NIS2-incident måste underlagsfilen stödja både dataskydds- och cybersäkerhetsbeslut om rapportering.
DORA höjer kraven på finansiell resiliens och IKT-leverantörer
DORA gäller från den 17 januari 2025 och skapar ett regelverk för digital operativ resiliens i finanssektorn. Det omfattar IKT-riskhantering, rapportering av större IKT-relaterade incidenter, testning av operativ resiliens, informationsdelning om cyberhot och sårbarheter, IKT-tredjepartsrisk, avtalskrav för IKT-leverantörer, tillsyn över kritiska IKT-tredjepartstjänsteleverantörer och övervakning.
För finansiella entiteter som också har identifierats enligt nationella NIS2-regler fungerar DORA som den sektorsspecifika unionsrättsakten för överlappande skyldigheter inom cybersäkerhetsriskhantering och incidentrapportering. I praktiken bör omfattade finansiella entiteter prioritera DORA för dessa överlappande områden och samtidigt samordna med behöriga NIS2-myndigheter och CSIRT:er där det är relevant.
För underlag enligt GDPR Article 32 är DORA relevant på två sätt. För det första kan fintech-bolag omfattas direkt som finansiella entiteter, inklusive kreditinstitut, betalningsinstitut, leverantörer av kontoinformationstjänster, institut för elektroniska pengar, värdepappersföretag, leverantörer av kryptotillgångstjänster, handelsplatser och leverantörer av gräsrotsfinansieringstjänster. För det andra kan SaaS-, moln-, data-, programvaru- och leverantörer av hanterade tjänster behandlas av finansiella kunder som IKT-tredjepartstjänsteleverantörer eftersom DORA definierar IKT-tjänster brett.
DORA Article 5 kräver styrning och interna kontroller för IKT-riskhantering, där ledningsorganet definierar, godkänner, övervakar och förblir ansvarigt för arrangemang för IKT-risk. Article 6 kräver ett dokumenterat ramverk för IKT-riskhantering, inklusive strategier, policyer, rutiner, IKT-protokoll och verktyg för att skydda information och IKT-tillgångar. Article 17 kräver en process för hantering av IKT-relaterade incidenter som omfattar detektering, hantering, underrättelse, registrering, rotorsak, indikatorer för tidig varning, klassificering, roller, kommunikation, eskalering och respons. Article 19 kräver att större IKT-relaterade incidenter rapporteras till behöriga myndigheter.
DORA Articles 28 och 30 gör IKT-tredjepartsrisk till ett reglerat kontrollområde. Finansiella entiteter förblir ansvariga för efterlevnad när de använder IKT-tjänster. De behöver en strategi för tredjepartsrisk, avtalsregister, kritikalitetsbedömningar, leverantörsgranskning, granskning av koncentrationsrisk, revisions- och inspektionsrättigheter, uppsägningsutlösare, exitstrategier och avtalsbestämmelser som omfattar datalagringsplatser, tillgänglighet, autenticitet, riktighet, konfidentialitet, incidentstöd, återställning, servicenivåer och samarbete med myndigheter.
För Article 32 innebär detta att leverantörer ingår i TOMs-filen. Det går inte att visa säkerhet i behandlingen om kritiska personuppgiftsbiträden, molnplattformar, analysleverantörer, supportverktyg och IKT-leverantörer inte är kontrollerade.
Praktiskt enveckorsbygge av underlag för Article 32
En stark underlagsfil börjar med ett tydligt riskscenario.
Använd detta exempel: ”Obehörig åtkomst till kunders personuppgifter i produktionsapplikationen.”
Skapa eller uppdatera riskposten. Inkludera beskrivning, sannolikhet, konsekvens, poäng, ägare och behandlingsplan. Tilldela ägarskapet till Head of Engineering, säkerhetsansvarig eller motsvarande ansvarig roll. Bedöm sannolikheten utifrån åtkomstmodellen, exponerad angreppsyta, kända sårbarheter och tidigare incidenter. Bedöm konsekvensen utifrån mängden personuppgifter, känslighet, kundavtal, GDPR-konsekvenser och möjlig påverkan på tjänsten enligt NIS2 eller DORA.
Välj behandlingar såsom MFA för privilegierad åtkomst, rollbaserad åtkomstkontroll, kvartalsvisa åtkomstgranskningar, kryptering i vila, TLS, sårbarhetsskanning, loggning, larmning, säker säkerhetskopiering, incidenthanteringsrutiner och datamaskering i icke-produktionsmiljöer.
Mappa därefter risken till SoA. Lägg till ISO/IEC 27002:2022-referenser såsom 5.34 Integritet och skydd av PII, 8.24 Användning av kryptografi, 5.15 Åtkomstkontroll, 5.18 Åtkomsträttigheter, 8.13 Säkerhetskopiering av information, 8.15 Loggning, 8.16 Övervakningsaktiviteter, 8.8 Hantering av tekniska sårbarheter, 8.25 Säker utvecklingslivscykel och 8.10 Radering av information där det är tillämpligt. Lägg till noteringar som visar hur dessa kontroller stödjer GDPR Article 32, NIS2 Article 21 och DORA:s IKT-riskhantering där det är relevant.
Vid regulatorisk mappning ska kontrollnamnen hållas korrekta och falska likställanden undvikas.
| ISO/IEC 27002:2022-kontroll | Kontrollnamn | Varför inkluderad | Regulatorisk mappning |
|---|---|---|---|
| 8.24 | Användning av kryptografi | Skyddar konfidentialitet och riktighet för personuppgifter under överföring, i vila och i säkerhetskopior | GDPR Art. 32; NIS2 Art. 21(2)(h) |
| 5.20 | Hantering av informationssäkerhet i leverantörsavtal | Säkerställer att leverantörers säkerhetsförpliktelser är avtalsmässigt definierade och kan göras gällande | GDPR-kontroller för personuppgiftsbiträden; NIS2 Art. 21(2)(d); DORA Art. 28 och Art. 30 |
| 5.24 | Planering och förberedelse för hantering av informationssäkerhetsincidenter | Etablerar beredskap för detektering, eskalering, bedömning och rapportering | Ansvarsskyldighet vid personuppgiftsincident enligt GDPR; NIS2 Art. 23; DORA Art. 17 och Art. 19 |
| 8.13 | Säkerhetskopiering av information | Stödjer tillgänglighet, återställning och resiliens efter störning eller dataförlust | GDPR Art. 32; NIS2 Art. 21(2)(c); DORA:s förväntningar på IKT-kontinuitet |
| 8.10 | Radering av information | Stödjer säker avveckling, tillämpning av bevarande och uppgiftsminimering | GDPR:s lagringsbegränsning och Art. 32; avtalskrav från kunder |
Bygg därefter underlagsmappen. Clarysec:s SME-version av Policy för revision och regelefterlevnadsövervakning ger en enkel regel:
”Allt underlag måste lagras i en centraliserad revisionsmapp.”
Källa: Policy för revision och regelefterlevnadsövervakning-sme, Krav för genomförande av policyn, policyklausul 6.2.1. Policy för revision och regelefterlevnadsövervakning - SME
För detta enda riskscenario bör mappen innehålla:
| Bevispost | Vad som ska lagras | Varför det är viktigt |
|---|---|---|
| Riskpost | Riskbeskrivning, ägare, poäng, behandlingsplan och beslut om kvarstående risk | Visar riskbaserat urval av TOMs |
| SoA-utdrag | Tillämpliga kontroller och noteringar för GDPR, NIS2 och DORA | Visar spårbarhet från risk till kontroll |
| Åtkomstgranskning | Granskade användare, beslut, borttagningar och undantag | Visar att åtkomstkontrollen fungerar i drift |
| MFA-rapport | Export som visar att privilegierad MFA tillämpas | Stödjer underlag för autentisering |
| Krypteringsunderlag | Konfigurationspost, arkitekturanteckning eller nyckelhanteringspost | Stödjer konfidentialitet och riktighet |
| Sårbarhetspost | Senaste skanning, åtgärdsärenden och accepterade undantag | Stödjer teknisk riskreducering |
| Loggningsunderlag | Exempel på SIEM-händelse, larmregel och inställning för bevarande | Stödjer detektering och utredning |
| Säkerhetskopieringstest | Resultat från återställningstest och post om täckning för säkerhetskopiering | Stödjer tillgänglighet och resiliens |
| Incidentövning | Anteckningar från skrivbordsövning, testincidentlogg eller erfarenhetsåterföring | Stödjer beredskap för respons |
| Ledningsgodkännande | Mötesprotokoll, formellt godkännande eller riskacceptanspost | Stödjer ansvarsskyldighet och proportionalitet |
Åtkomstunderlag bör inte stanna vid skärmdumpar. Access Control Policy-sme tillför ett användbart operativt krav:
”IT-chefen måste dokumentera granskningsresultat och korrigerande åtgärder.”
Källa: Åtkomstkontrollpolicy-sme, Styrningskrav, policyklausul 5.5.3. Åtkomstkontrollpolicy - SME
Underlag för säkerhetskopiering måste visa återställningsförmåga, inte bara lyckade jobb. Backup and Restore Policy-sme anger:
”Återställningstester genomförs minst kvartalsvis och resultaten dokumenteras för att verifiera återställningsförmåga”
Källa: Policy för säkerhetskopiering och återställning-sme, Styrningskrav, policyklausul 5.3.3. Policy för säkerhetskopiering och återställning - SME
Detta ger en komplett underlagsslinga: regelverket skapar kravet, risken förklarar varför det är viktigt, SoA väljer kontrollen, policyn definierar driften och bevarat underlag visar att kontrollen fungerar.
Kontroller i drift: att omvandla policy till operativt underlag
Fasen Controls in Action i Zenith Blueprint, Step 19, fokuserar på teknisk verifiering. Den rekommenderar granskning av efterlevnad för slutpunktssäkerhet, identitets- och åtkomsthantering, autentiseringskonfigurationer, säkerhet i källkodshantering, kapacitet och tillgänglighet, sårbarhets- och patchhantering, säkra baslinjer, skydd mot skadlig kod, radering och uppgiftsminimering, maskering och testdata, DLP, säkerhetskopiering och återställning, redundans, loggning och övervakning samt tidssynkronisering.
För TOMs enligt GDPR Article 32 är Step 19 där abstrakt kontrollspråk blir underlag. En stark underlagsfil bör visa att:
- Slutpunktskryptering är aktiverad och övervakad.
- Privilegierade användare har MFA.
- Processer för nyanställningar, interna förflyttningar och avgångar stäms av mot HR-poster.
- Tjänstekonton är dokumenterade och begränsade.
- Kodarkiv har åtkomstkontroll och skanning efter hemligheter utförs.
- Sårbarhetsskanningar genomförs och följs upp till åtgärdande.
- Produktionsdata kopieras inte rutinmässigt till testmiljöer.
- Policyer för säker radering och bevarande tillämpas.
- DLP-larm granskas.
- Återställningstester av säkerhetskopior visar återställningsförmåga.
- Loggar är centraliserade, bevarade och granskningsbara.
- Tidssynkronisering stödjer tillförlitlig incidentutredning.
Nyckeln är kopplingen. En patchrapport utan risk-, policy- och SoA-referens är en IT-artefakt. En patchrapport kopplad till GDPR Article 32, NIS2 Article 21, DORA:s IKT-riskhantering och en riskbehandlingsplan enligt ISO 27001:2022 är revisionsklart underlag.
En underlagsfil, flera revisionsperspektiv
Samma TOMs-underlag kommer att läsas på olika sätt av olika intressenter. En dataskyddsgranskare kan fokusera på personuppgifter, nödvändighet, proportionalitet och ansvarsskyldighet. En ISO 27001-revisor kan fokusera på omfattning, riskbehandling, SoA och underlag för drift. En NIS2-myndighet kan fokusera på ledningens tillsyn, åtgärder enligt Article 21 och rapporteringsberedskap enligt Article 23. En DORA-tillsynsmyndighet eller finansiell kund kan fokusera på IKT-riskstyrning, resiliensövningar och tredjepartsberoenden.
Clarysec använder Zenith Controls som vägledning för korsvis efterlevnad i denna översättning.
| Målgrupp | Vad de kommer att fråga | Hur underlaget bör svara |
|---|---|---|
| GDPR-dataskyddsgranskare | Är TOMs lämpliga i förhållande till personuppgiftsrisken och kan ansvarsskyldighet visas? | Riskregister, dataregister, dataskyddskontroller, poster om bevarande, åtkomstbegränsningar, krypteringsunderlag och bedömningsposter för personuppgiftsincidenter |
| ISO 27001:2022-revisor | Är ISMS avgränsat, riskbaserat, infört, övervakat och förbättrat? | Omfattning, riskmetodik, SoA, internrevision, ledningens genomgång och korrigerande åtgärder |
| NIS2-granskare | Är cybersäkerhetsåtgärder godkända, proportionerliga och täcker de områdena i Article 21? | Styrelsegodkännande, säkerhetspolicyer, incidenthantering, kontinuitet, leverantörsrisk, utbildning, MFA och hantering av sårbarheter |
| DORA-tillsynsmyndighet eller finansiell kund | Är IKT-risk styrd, testad och resilient, inklusive IKT-tredjepartsrisk? | IKT-riskramverk, resiliensstrategi, incidentprocess, testunderlag, leverantörsregister och exitplaner |
| NIST-orienterad bedömare | Kan organisationen identifiera, skydda, detektera, respondera och återställa med repeterbart underlag? | Tillgångs- och dataregister, skyddskontroller, övervakningsposter, responsloggar och återställningstester |
| COBIT 2019- eller ISACA-revisor | Är styrningen ansvarssatt, mätt och anpassad till organisationens mål? | Roller, ledningsrapportering, riskaptit, prestandamått, säkerhetsförsäkransresultat och förbättringsåtgärder |
Detta förhindrar duplicerat efterlevnadsarbete. I stället för att bygga separata underlagspaket för GDPR, NIS2 och DORA bör ni bygga en kontrollunderlagsfil och tagga varje post med de skyldigheter den stödjer.
Vanliga luckor i Article 32 TOMs-program
Den vanligaste luckan är herrelösa kontroller. En organisation har en kontroll, exempelvis kryptering, men kan inte förklara vilken risk den behandlar, vilken policy som kräver den, vem som äger den eller hur den granskas.
Den andra luckan är svagt leverantörsunderlag. Enligt GDPR är personuppgiftsbiträden och underbiträden viktiga. Enligt NIS2 ingår säkerhet i leveranskedjan i cybersäkerhetsriskhanteringen. Enligt DORA är IKT-tredjepartsrisk ett reglerat område med register, leverantörsgranskning, avtalsmässiga skyddsåtgärder, revisionsrätt och exitplanering. Ett leverantörskalkylblad räcker inte om kritiska beroenden inte riskbedöms och kontrolleras.
Den tredje luckan är incidentunderlag. Organisationer har ofta en incidenthanteringsplan men saknar underlag som visar att klassificering, eskalering, myndighetsrapportering och kundkommunikation har testats. NIS2 och DORA höjer förväntningarna här, och bedömning av personuppgiftsincidenter enligt GDPR måste integreras i samma arbetsflöde.
Den fjärde luckan är underlag för säkerhetskopiering. Ett lyckat säkerhetskopieringsjobb visar inte återställningsförmåga. Ett dokumenterat återställningstest gör det.
Den femte luckan är ledningens genomgång. TOMs enligt Article 32 måste vara proportionerliga i förhållande till risken. Om ledningen aldrig granskar risker, incidenter, leverantörsproblem, budget, revisionsiakttagelser och kvarstående risk blir proportionalitet svår att visa.
Den slutliga revisionsklara verktygslådan
Fasen Audit, Review and Improvement i Zenith Blueprint, Step 30, ger den slutliga checklistan för beredskap. Den omfattar ISMS-omfattning och kontext, signerad informationssäkerhetspolicy, dokument för riskbedömning och riskbehandling, SoA, policyer och rutiner för bilaga A, utbildningsregister, operativa poster, internrevisionsrapport, logg över korrigerande åtgärder, protokoll från ledningens genomgång, underlag för ständig förbättring och register över krav på regelefterlevnad.
Clarysec:s företagsversion av Policy för revision och regelefterlevnadsövervakning anger syftet med denna disciplin:
”Att generera försvarbart underlag och ett revisionsspår till stöd för regulatoriska förfrågningar, rättsprocesser eller förfrågningar om säkerhetsförsäkran från kunder.”
Källa: Policy för revision och regelefterlevnadsövervakning, Mål, policyklausul 3.4. Policy för revision och regelefterlevnadsövervakning
En mogen underlagsfil för TOMs enligt Article 32 bör innehålla:
| Underlagskategori | Minsta revisionsklara innehåll |
|---|---|
| Styrning | ISMS-omfattning, policygodkännande, roller, mål, protokoll från ledningens genomgång |
| Risk | Riskmetodik, riskregister, behandlingsplan, godkännanden av kvarstående risk |
| SoA | Tillämpliga kontroller, exkluderingar, motiveringar och regulatorisk mappning |
| Dataskydd | Dataregister, PII-kontroller, underlag för bevarande, DPIA eller integritetsriskbedömning där det är tillämpligt |
| Tekniska kontroller | MFA, åtkomstgranskningar, kryptering, hantering av sårbarheter, loggning, övervakning och underlag för säker utveckling |
| Resiliens | Täckning för säkerhetskopiering, återställningstester, kontinuitetsplaner, incidentövningar och återställningsmätetal |
| Leverantörssäkerhetsförsäkran | Leverantörsregister, leverantörsgranskning, avtalsklausuler, övervakning, revisionsrätt och exitplanering |
| Förbättring | Internrevisioner, korrigerande åtgärder, erfarenhetsåterföring och granskningar av kontrolleffektivitet |
Nästa steg: bygg underlag för TOMs enligt Article 32 med Clarysec
Om ni behöver visa tekniska och organisatoriska åtgärder enligt GDPR Article 32 ska ni inte börja med att samla slumpmässiga skärmdumpar. Börja med spårbarhet.
- Definiera ISMS-omfattningen och gränserna för behandling av personuppgifter.
- Identifiera krav enligt GDPR, NIS2, DORA, avtal och kundkrav.
- Bygg riskkriterier med ISO/IEC 27005:2022 och en riskaptit som godkänts av ledningen.
- Skapa eller uppdatera riskregistret.
- Mappa varje behandling till ISO 27001:2022-kontroller och SoA.
- Använd Zenith Controls för att korsreferera dataskydds-, kryptografi-, leverantörs-, incident- och oberoende granskningskontroller mot efterlevnadsförväntningar.
- Följ Zenith Blueprint Step 13 och Step 14 för att koppla risker, kontroller och regulatoriska skyldigheter.
- Använd Zenith Blueprint Step 19 för att verifiera tekniska kontroller i drift.
- Använd Zenith Blueprint Step 30 för att sammanställa den slutliga revisionsklara underlagsfilen.
- Lagra allt underlag centralt, märk det efter risk och kontrolltema och håll korrigerande åtgärder synliga.
Clarysec kan hjälpa er att omvandla GDPR Article 32 från en vag efterlevnadsskyldighet till ett försvarbart, riskbaserat underlagssystem anpassat till ISO 27001:2022, NIS2 och DORA.
Börja med Zenith Blueprint, stärk det med Clarysec-policyer och använd Zenith Controls för att göra varje TOM spårbar, testbar och revisionsklar.
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
