GDPR Article 32 TOMs-dokumentation med ISO, NIS2 og DORA

E-mailen lander i CISO’ens indbakke med den velkendte tyngde af en aftale, der kan ændre virksomhedens kvartal.

En stor potentiel erhvervskunde anmoder om dokumentation for “GDPR Article 32 technical and organisational measures, mapped to ISO 27001:2022, NIS2 and DORA where applicable.” Samtidig har juridisk afdeling orienteret bestyrelsen om ledelsesansvar under NIS2 og forventningerne til digital operationel robusthed under DORA. Bestyrelsens instruktion er enkel: dokumentér efterlevelse, undgå dobbeltarbejde, og gør ikke dette til tre separate projekter.

Virksomheden har kontroller. MFA er aktiveret. Backups kører. Udviklere gennemgår kode. Privatlivsteamet vedligeholder fortegnelser over behandlingsaktiviteter. Infrastrukturteamet scanner for sårbarheder. Leverandører gennemgås som led i indkøbsprocessen. Men når den potentielle kunde beder om dokumentation, bliver svaret fragmenteret.

Rapporten fra identitetsudbyderen ligger ét sted. Backup-logfiler ligger et andet. Risikoregisteret er ikke blevet opdateret siden den seneste produktrelease. Dokumentation for leverandørers sikkerhed ligger i indkøbs-e-mails. Noter fra tabletop-øvelser om hændelseshåndtering findes, men ingen kan dokumentere, at erfaringerne er ført tilbage til risikobehandlingen. Bestyrelsen har godkendt sikkerhedsudgifter, men godkendelsen er ikke knyttet til en IKT-risiko eller en dokumenteret kontrolbeslutning.

Det er det reelle problem med tekniske og organisatoriske foranstaltninger efter GDPR Article 32, ofte kaldet TOMs. De fleste organisationer fejler ikke, fordi de mangler kontroller. De fejler, fordi de ikke kan dokumentere, at kontrollerne er risikobaserede, godkendte, implementerede, overvågede og forbedrede.

GDPR’s ansvarlighedskrav gør denne forventning eksplicit. GDPR Article 5 kræver, at personoplysninger beskyttes med passende sikkerhed mod uautoriseret eller ulovlig behandling og mod hændeligt tab, tilintetgørelse eller beskadigelse. Article 5(2) gør den dataansvarlige ansvarlig for at kunne dokumentere efterlevelse. GDPR-definitionerne har også betydning. Personoplysninger er et bredt begreb, behandling omfatter næsten enhver operation på data, pseudonymisering er en anerkendt sikkerhedsforanstaltning, og et brud på persondatasikkerheden omfatter hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse eller adgang.

En dokumentationspakke for Article 32 kan derfor ikke være en mappe med tilfældige skærmbilleder. Den skal være et levende kontrolsystem.

Clarysecs tilgang er at omsætte GDPR Article 32 TOMs til en sporbar dokumentationsmotor bygget på ISO/IEC 27001:2022 ISO/IEC 27001:2022, styrket af ISO/IEC 27005:2022-risikostyring og krydshenvisninger til NIS2- og DORA-forpligtelser, hvor de gælder. Målet er ikke papirarbejde for papirarbejdets skyld. Målet er at gøre organisationen revisionsklar, før en kunde, revisor, tilsynsmyndighed eller et bestyrelsesmedlem stiller det vanskelige spørgsmål.

Hvorfor GDPR Article 32 TOMs fejler i praksis

Article 32 misforstås ofte som en liste over sikkerhedsværktøjer: kryptering, backups, logning, adgangsstyring og hændelseshåndtering. Disse foranstaltninger er vigtige, men de er kun forsvarlige, når de passer til risikoen og er knyttet til personoplysningernes livscyklus.

For en SaaS-virksomhed, der behandler medarbejderdata for kunder, er “vi bruger kryptering” ikke tilstrækkeligt. En revisor kan spørge, hvilke data krypteringen beskytter, hvor kryptering er påkrævet, hvordan nøgler administreres, om backups er krypterede, om produktionsdata maskeres i test, hvem der kan omgå kontroller, og hvordan undtagelser godkendes.

Clarysecs enterprise Databeskyttelses- og privatlivspolitik indfanger driftsprincippet:

“Implementér tekniske og organisatoriske foranstaltninger (TOMs), der beskytter fortrolighed, integritet og tilgængelighed af personhenførbare oplysninger (PII) gennem hele deres livscyklus.”

Kilde: Databeskyttelses- og privatlivspolitik, Mål, politikklausul 3.3. Databeskyttelses- og privatlivspolitik

Udtrykket “gennem hele deres livscyklus” er dér, mange TOM-programmer bliver svage. Personoplysninger kan være beskyttet i produktion, men kopieres til analysesystemer, logfiler, supporteksporter, testmiljøer, backups, leverandørplatforme og medarbejderenheder. Hver placering skaber sikkerheds- og privatlivsrisiko.

GDPR Article 6 kræver et behandlingsgrundlag for behandling, herunder samtykke, kontrakt, retlig forpligtelse, vitale interesser, offentlig opgave eller legitime interesser. Når data genbruges til et yderligere formål, skal forenelighed og sikkerhedsforanstaltninger som kryptering eller pseudonymisering vurderes. For data med højere risiko øges dokumentationsbyrden. GDPR Article 9 fastsætter strenge begrænsninger for særlige kategorier af personoplysninger, f.eks. helbredsoplysninger, biometriske data anvendt til identifikation og andre følsomme oplysninger. Article 10 begrænser oplysninger om straffedomme og lovovertrædelser.

For SMV’er udtrykker Clarysec risikobehandling i praktisk sprog:

“Kontroller skal implementeres for at reducere identificerede risici, herunder kryptering, anonymisering, sikker bortskaffelse og adgangsbegrænsninger”

Kilde: Databeskyttelses- og privatlivspolitik-sme, Risikobehandling og undtagelser, politikklausul 7.2.1. Databeskyttelses- og privatlivspolitik - SME

Det er en stærk TOMs-baseline. For at blive revisionsklar skal hver kontrol også knyttes til en risiko, en ejer, et politikkrav, et dokumentationselement og en gennemgangsfrekvens.

ISO 27001:2022 er rygraden i dokumentation for Article 32

ISO 27001:2022 fungerer godt for GDPR Article 32, fordi standarden behandler sikkerhed som et ledelsessystem og ikke som en løsrevet kontroltjekliste. Den kræver et ledelsessystem for informationssikkerhed, eller ISMS, der er designet til at bevare fortrolighed, integritet og tilgængelighed gennem risikostyring.

Det første kritiske skridt er afgrænsning. ISO 27001:2022 klausul 4.1 til 4.4 kræver, at organisationen forstår interne og eksterne forhold, identificerer interessenter og krav, bestemmer hvilke krav der skal håndteres af ISMS, og definerer ISMS-omfanget, herunder grænseflader og afhængigheder til eksterne organisationer. For Article 32 TOMs bør ISMS-omfanget afspejle behandling af personoplysninger, kundeforpligtelser, databehandlere, underdatabehandlere, cloudplatforme, fjernarbejde, supportfunktioner og produktionsmiljøer.

Det andet skridt er ledelse. Klausul 5.1 til 5.3 kræver topledelsens engagement, en informationssikkerhedspolitik, ressourcer, roller og ansvar samt rapportering af performance. Det er vigtigt, fordi GDPR Article 32, NIS2 og DORA alle bygger på governance. En kontrol uden ejerskab, finansiering eller gennemgang er svag dokumentation.

Clarysecs enterprise Informationssikkerhedspolitik gør dette eksplicit:

“ISMS skal omfatte defineret omfangsafgrænsning, en risikovurderingsmetodik, målbare målsætninger og dokumenterede kontroller, der er begrundet i anvendelighedserklæringen (SoA).”

Kilde: Informationssikkerhedspolitik, Krav til implementering af politikken, politikklausul 6.1.2. Informationssikkerhedspolitik

Den samme politik fastsætter forventningen til dokumentation:

“Alle implementerede kontroller skal kunne revideres, understøttes af dokumenterede procedurer og have opbevaret bevismateriale for drift.”

Kilde: Informationssikkerhedspolitik, Krav til implementering af politikken, politikklausul 6.6.1.

ISO 27001:2022 klausul 6.1.1 til 6.1.3 kræver derefter risikovurdering, risikobehandling, en anvendelighedserklæring, godkendelse af restrisiko og ansvarlighed hos risikoejeren. Klausul 6.2 kræver målbare målsætninger. Klausul 7.5, 9.1, 9.2, 9.3 og 10.2 kræver dokumenteret information, overvågning, intern revision, ledelsens evaluering og korrigerende handling.

For GDPR Article 32 skaber dette en forsvarlig struktur.

ISO/IEC 27005:2022 styrker denne struktur. Den anbefaler organisationer at identificere krav fra ISO 27001:2022 Annex A, reguleringer, kontrakter, sektorstandarder, interne regler og eksisterende kontroller og derefter føre dem ind i risikovurdering og risikobehandling. Den kræver også risikokriterier og acceptkriterier, der tager højde for juridiske, regulatoriske, driftsmæssige, leverandørmæssige, teknologiske og menneskelige faktorer, herunder privatliv.

Clarysecs Politik for risikostyring er direkte tilpasset:

“En formel risikostyringsproces skal vedligeholdes i overensstemmelse med ISO/IEC 27005 og ISO 31000 og omfatte risikoidentifikation, analyse, evaluering, behandling, overvågning og kommunikation.”

Kilde: Politik for risikostyring, Styringskrav, politikklausul 5.1. Politik for risikostyring

For SMV’er bliver det samme krav enkelt og handlingsorienteret:

“Hver risikopost skal indeholde: beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan.”

Kilde: Politik for risikostyring-sme, Styringskrav, politikklausul 5.1.2. Politik for risikostyring - SME

Den sætning er en hurtig test af revisionsberedskab. Hvis en risiko ikke har en ejer eller behandlingsplan, er den endnu ikke klar som revisionsdokumentation.

Clarysec-broen: risiko, SoA, kontroller og reguleringer

Clarysecs Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint behandler efterlevelse som sporbarhedsarbejde. I risikostyringsfasen fokuserer Step 13 på planlægning af risikobehandling og anvendelighedserklæringen. Den forklarer, at organisationer bør kortlægge kontroller til risici, tilføje Annex A-kontrolreferencer til risikobehandlingsposter, krydshenvise eksterne reguleringer og indhente ledelsens godkendelse.

Zenith Blueprint er direkte om SoA’ens rolle:

“SoA’en er reelt et brobyggende dokument: den forbinder jeres risikovurdering/-behandling med de faktiske kontroller, I har. Ved at udfylde den dobbelttjekker I også, om I har overset kontroller.”

Kilde: Zenith Blueprint: En revisors 30-trins køreplan, risikostyringsfasen, Step 13: Planlægning af risikobehandling og anvendelighedserklæring (SoA). Zenith Blueprint

Step 14 i Zenith Blueprint tilføjer laget med regulatoriske krydshenvisninger. Den anbefaler organisationer at dokumentere, hvordan GDPR-, NIS2- og DORA-krav dækkes af politikker og kontroller. For GDPR fremhæver den beskyttelse af personoplysninger i risikovurderinger og behandlinger, herunder kryptering som teknisk foranstaltning og håndtering af brud som en del af kontrolmiljøet. For NIS2 fremhæver den risikovurdering, netværkssikkerhed, adgangsstyring, hændelseshåndtering og forretningskontinuitet. For DORA peger den på styring af IKT-risiko, hændelseshåndtering, rapportering og tilsyn med IKT-tredjeparter.

Det er kernen i Clarysec-metoden: ét ISMS, ét risikoregister, én SoA, ét dokumentationsbibliotek, flere efterlevelsesresultater.

Zenith Controls: Vejledningen til tværgående efterlevelse Zenith Controls understøtter dette ved at hjælpe organisationer med at bruge kontroltemaer fra ISO/IEC 27002:2022 ISO/IEC 27002:2022 som tværgående efterlevelsesankre. For GDPR Article 32 omfatter de vigtigste ankre ofte Privacy and Protection of PII, kontrol 5.34; Independent Review of Information Security, kontrol 5.35; og Use of Cryptography, kontrol 8.24.

NIS2 gør TOMs til et cybersikkerhedsanliggende på bestyrelsesniveau

Mange organisationer behandler GDPR TOMs som privatlivsteamets ansvar. NIS2 ændrer samtalen.

NIS2 gælder for mange mellemstore og store enheder i oplistede sektorer og i visse tilfælde uanset størrelse. Omfattede digitale og teknologiske sektorer inkluderer udbydere af cloud computing-tjenester, datacenterudbydere, content delivery networks, DNS-tjenesteudbydere, TLD-registre, tillidstjenesteudbydere, udbydere af offentlige elektroniske kommunikationstjenester, managed service providers, managed security service providers, online markedspladser, søgemaskiner og sociale netværksplatforme. Anvendelighed for SaaS- og teknologi-SMV’er afhænger af sektor, størrelse, udpegning i medlemsstaten og systemisk eller grænseoverskridende påvirkning.

NIS2 Article 20 placerer cybersikkerhedsansvaret hos ledelsesorganerne. De skal godkende foranstaltninger til cybersikkerhedsrisikostyring, føre tilsyn med implementeringen og gennemføre uddannelse. Væsentlige enheder kan mødes med administrative bøder på mindst EUR 10 mio. eller mindst 2 procent af den globale årlige omsætning. Vigtige enheder kan mødes med bøder på mindst EUR 7 mio. eller mindst 1,4 procent.

NIS2 Article 21 er direkte relevant for Article 32 TOMs, fordi den kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger. Disse foranstaltninger skal tage højde for det aktuelle tekniske niveau, europæiske og internationale standarder, omkostninger, eksponering, størrelse, sandsynlighed, alvorlighed og samfundsmæssig eller økonomisk påvirkning. Påkrævede områder omfatter risikoanalyse, sikkerhedspolitikker, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, håndtering af sårbarheder, vurdering af effektivitet, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring, MFA eller løbende autentifikation samt sikker kommunikation, hvor relevant.

NIS2 Article 23 tilføjer trinvis hændelsesrapportering: tidlig advarsel inden for 24 timer, hændelsesunderretning inden for 72 timer, mellemliggende opdateringer efter anmodning og en endelig rapport senest én måned efter 72-timers-underretningen. Hvis et brud på persondatasikkerheden også kvalificerer som en væsentlig NIS2-hændelse, skal jeres dokumentationspakke understøtte både privatlivs- og cybersikkerhedsrelaterede rapporteringsbeslutninger.

DORA hæver barren for finansiel robusthed og IKT-udbydere

DORA finder anvendelse fra 17. januar 2025 og skaber et regelsæt for digital operationel robusthed i finanssektoren. Den dækker styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af operationel robusthed, deling af information om cybertrusler og sårbarheder, IKT-tredjepartsrisiko, kontraktlige krav til IKT-udbydere, tilsyn med kritiske IKT-tredjepartsudbydere og tilsyn.

For finansielle enheder, der også er identificeret under nationale NIS2-regler, fungerer DORA som den sektorspecifikke EU-retsakt for overlappende forpligtelser vedrørende cybersikkerhedsrisikostyring og hændelsesrapportering. I praksis bør omfattede finansielle enheder prioritere DORA for disse overlappende områder, samtidig med at de koordinerer med NIS2-kompetente myndigheder og CSIRT’er, hvor relevant.

For dokumentation efter GDPR Article 32 har DORA betydning på to måder. For det første kan fintech-virksomheder være direkte omfattet som finansielle enheder, herunder kreditinstitutter, betalingsinstitutter, kontooplysningstjenesteudbydere, e-pengeinstitutter, investeringsselskaber, udbydere af kryptoaktivtjenester, handelspladser og crowdfunding-tjenesteudbydere. For det andet kan SaaS-, cloud-, data-, software- og managed service providers blive behandlet af finansielle kunder som IKT-tredjepartsudbydere, fordi DORA definerer IKT-tjenester bredt.

DORA Article 5 kræver governance og interne kontroller for styring af IKT-risiko, hvor ledelsesorganet definerer, godkender, fører tilsyn med og fortsat er ansvarligt for IKT-risikoarrangementer. Article 6 kræver en dokumenteret ramme for styring af IKT-risiko, herunder strategier, politikker, procedurer, IKT-protokoller og værktøjer til at beskytte information og IKT-aktiver. Article 17 kræver en proces for styring af IKT-relaterede hændelser, der dækker detektion, styring, underretning, registrering, rodårsag, indikatorer for tidlig varsling, klassificering, roller, kommunikation, eskalering og respons. Article 19 kræver, at større IKT-relaterede hændelser rapporteres til kompetente myndigheder.

DORA Articles 28 og 30 gør IKT-tredjepartsrisiko til et reguleret kontroldomæne. Finansielle enheder forbliver ansvarlige for efterlevelse, når de bruger IKT-tjenester. De har brug for en tredjepartsrisikostrategi, kontraktregistre, kritikalitetsvurderinger, due diligence, gennemgang af koncentrationsrisiko, revisions- og inspektionsrettigheder, udløsere for ophør, exitstrategier og kontraktlige bestemmelser, der dækker datalokationer, tilgængelighed, autenticitet, integritet, fortrolighed, bistand ved hændelser, genopretning, serviceniveauer og samarbejde med myndigheder.

For Article 32 betyder det, at leverandører er en del af TOMs-dokumentationen. I kan ikke dokumentere behandlingssikkerhed, hvis kritiske databehandlere, cloudplatforme, analyseudbydere, supportværktøjer og IKT-udbydere ikke er kontrolleret.

En praktisk opbygning af Article 32-dokumentation på én uge

En stærk dokumentationspakke starter med ét klart risikoscenarie.

Brug dette eksempel: “Uautoriseret adgang til kunders personoplysninger i produktionsapplikationen.”

Opret eller opdater risikoposten. Medtag beskrivelse, sandsynlighed, konsekvens, score, ejer og behandlingsplan. Tildel ejerskabet til Head of Engineering, Security Manager eller en tilsvarende ansvarlig rolle. Vurdér sandsynligheden ud fra adgangsmodellen, eksponeret angrebsflade, kendte sårbarheder og tidligere hændelser. Vurdér konsekvensen ud fra mængden af personoplysninger, følsomhed, kundekontrakter, GDPR-konsekvenser og mulig NIS2- eller DORA-påvirkning af tjenesten.

Vælg behandlinger såsom MFA for privilegeret adgang, rollebaseret adgangskontrol, kvartalsvise gennemgange af adgangsrettigheder, kryptering i hvile, TLS, sårbarhedsscanning, logning, alarmering, sikker backup, procedurer for hændelseshåndtering og datamaskering i ikke-produktionsmiljøer.

Kortlæg derefter risikoen til SoA. Tilføj ISO/IEC 27002:2022-referencer såsom 5.34 Privacy and Protection of PII, 8.24 Use of Cryptography, 5.15 Access Control, 5.18 Access Rights, 8.13 Information Backup, 8.15 Logging, 8.16 Monitoring Activities, 8.8 Management of Technical Vulnerabilities, 8.25 Secure Development Life Cycle og 8.10 Information Deletion, hvor det er relevant. Tilføj noter, der viser, hvordan disse kontroller understøtter GDPR Article 32, NIS2 Article 21 og DORA-styring af IKT-risiko, hvor relevant.

Ved regulatorisk kortlægning skal kontrolnavnene være præcise, og falsk ækvivalens må ikke tvinges igennem.

Opbyg nu dokumentationsmappen. Clarysecs SME-politik for revision og overvågning af efterlevelse giver en enkel regel:

“Alt bevismateriale skal opbevares i en central revisionsmappe.”

Kilde: Politik for revision og overvågning af efterlevelse-sme, Krav til implementering af politikken, politikklausul 6.2.1. Politik for revision og overvågning af efterlevelse - SME

For dette ene risikoscenarie bør mappen indeholde:

Dokumentation for adgang bør ikke stoppe ved skærmbilleder. Politik for adgangskontrol-sme tilføjer et nyttigt driftskrav:

“IT-ansvarlig skal dokumentere gennemgangsresultater og korrigerende handlinger.”

Kilde: Politik for adgangskontrol-sme, Styringskrav, politikklausul 5.5.3. Politik for adgangskontrol - SME

Dokumentation for backup skal dokumentere mulighed for gendannelse, ikke blot vellykkede job. Politik for backup og gendannelse-sme fastsætter:

“Gendannelsestest gennemføres mindst kvartalsvist, og resultaterne dokumenteres for at verificere mulighed for gendannelse”

Kilde: Politik for backup og gendannelse-sme, Styringskrav, politikklausul 5.3.3. Politik for backup og gendannelse - SME

Dette giver en komplet dokumentationskæde: Reguleringen skaber kravet, risikoen forklarer hvorfor det er vigtigt, SoA’en vælger kontrollen, politikken definerer driften, og opbevaret dokumentation viser, at kontrollen fungerer.

Kontroller i praksis: fra politik til driftsdokumentation

Fasen Controls in Action i Zenith Blueprint, Step 19, fokuserer på teknisk verifikation. Den anbefaler gennemgang af efterlevelse for endepunktssikkerhed, identitets- og adgangsstyring, autentifikationskonfigurationer, sikkerhed i kildekodestyring, kapacitet og tilgængelighed, sårbarheds- og patchstyring, sikre baselines, malwarebeskyttelse, sletning og dataminimering, maskering og testdata, DLP, backup og gendannelse, redundans, logning og overvågning samt tidssynkronisering.

For GDPR Article 32 TOMs er Step 19 dér, abstrakt kontrolsprog bliver til dokumentation. En stærk dokumentationspakke bør vise, at:

• Endepunktskryptering er aktiveret og overvåget.
• Privilegerede brugere har MFA.
• Processer for tiltrædelser, omplaceringer og fratrædelser afstemmes mod HR-registreringer.
• Servicekonti er dokumenterede og begrænsede.
• Koderepositorier er underlagt adgangsstyring, og scanning for hemmeligheder udføres.
• Sårbarhedsscanninger gennemføres og spores til afhjælpning.
• Produktionsdata ikke rutinemæssigt kopieres til testmiljøer.
• Politikker for sikker sletning og opbevaring håndhæves.
• DLP-alarmer gennemgås.
• Gendannelsestest af backups dokumenterer mulighed for gendannelse.
• Logfiler er centraliserede, opbevarede og mulige at gennemgå.
• Tidssynkronisering understøtter pålidelig undersøgelse af hændelser.

Nøglen er sammenhæng. En patchrapport uden reference til risiko, politik og SoA er en IT-artefakt. En patchrapport knyttet til GDPR Article 32, NIS2 Article 21, DORA-styring af IKT-risiko og en ISO 27001:2022-risikobehandlingsplan er revisionsklar dokumentation.

Én dokumentationspakke, flere revisionsperspektiver

Den samme TOMs-dokumentation vil blive læst forskelligt af forskellige interessenter. En privatlivsgennemgang kan fokusere på personoplysninger, nødvendighed, proportionalitet og ansvarlighed. En ISO 27001-revisor kan fokusere på omfang, risikobehandling, SoA og driftsdokumentation. En NIS2-myndighed kan fokusere på ledelsestilsyn, Article 21-foranstaltninger og beredskab til Article 23-rapportering. En DORA-tilsynsmyndighed eller finansiel kunde kan fokusere på styring af IKT-risiko, robusthedstest og tredjepartsafhængigheder.

Clarysec bruger Zenith Controls som vejledningen til tværgående efterlevelse for denne oversættelse mellem perspektiver.

Dette forebygger dobbeltarbejde med efterlevelse. I stedet for at opbygge separate dokumentationspakker til GDPR, NIS2 og DORA opbygges én kontrolbaseret dokumentationspakke, og hvert element mærkes med de forpligtelser, det understøtter.

Almindelige huller i Article 32 TOMs-programmer

Det mest almindelige hul er forældreløse kontroller. En virksomhed har en kontrol, f.eks. kryptering, men kan ikke forklare, hvilken risiko den behandler, hvilken politik der kræver den, hvem der ejer den, eller hvordan den gennemgås.

Det andet hul er svag leverandørdokumentation. Under GDPR er databehandlere og underdatabehandlere vigtige. Under NIS2 er sikkerhed i forsyningskæden en del af cybersikkerhedsrisikostyring. Under DORA er IKT-tredjepartsrisiko et reguleret domæne med registre, due diligence, kontraktlige sikkerhedsforanstaltninger, revisionsrettigheder og exitplanlægning. Et leverandørregneark er ikke nok, hvis kritiske afhængigheder ikke er risikovurderet og kontrolleret.

Det tredje hul er hændelsesdokumentation. Organisationer har ofte en hændelseshåndteringsplan, men intet bevis for, at klassificering, eskalering, rapportering til myndigheder og kundekommunikation er testet. NIS2 og DORA hæver forventningerne her, og vurdering af brud på persondatasikkerheden efter GDPR skal integreres i samme workflow.

Det fjerde hul er dokumentation for backup. Et vellykket backupjob dokumenterer ikke mulighed for gendannelse. En dokumenteret gendannelsestest gør.

Det femte hul er ledelsens evaluering. Article 32 TOMs skal være proportionale med risikoen. Hvis ledelsen aldrig gennemgår risici, hændelser, leverandørforhold, budget, revisionskonstateringer og restrisiko, bliver proportionalitet vanskelig at dokumentere.

Det endelige revisionsklare værktøjssæt

Fasen Audit, Review and Improvement i Zenith Blueprint, Step 30, giver den endelige tjekliste for revisionsberedskab. Den omfatter ISMS-omfang og kontekst, underskrevet informationssikkerhedspolitik, dokumenter om risikovurdering og risikobehandling, SoA, Annex A-politikker og procedurer, træningsregistreringer, driftsregistreringer, intern revisionsrapport, log over korrigerende handlinger, referater fra ledelsens evaluering, dokumentation for løbende forbedring og registreringer over efterlevelsesforpligtelser.

Clarysecs enterprise Politik for revision og overvågning af efterlevelse fastsætter formålet med denne disciplin:

“At generere forsvarligt bevismateriale og et revisionsspor til støtte for regulatoriske forespørgsler, retssager eller anmodninger fra kunder om dokumentation.”

Kilde: Politik for revision og overvågning af efterlevelse, Mål, politikklausul 3.4. Politik for revision og overvågning af efterlevelse

En moden dokumentationspakke for Article 32 TOMs bør omfatte:

Næste skridt: opbyg Article 32 TOMs-dokumentation med Clarysec

Hvis I skal dokumentere tekniske og organisatoriske foranstaltninger efter GDPR Article 32, skal I ikke begynde med at indsamle tilfældige skærmbilleder. Begynd med sporbarhed.

1. Definér ISMS-omfanget og grænserne for behandling af personoplysninger.
2. Identificér GDPR-, NIS2-, DORA-, kontrakt- og kundekrav.
3. Opbyg risikokriterier med ISO/IEC 27005:2022 og ledelsesgodkendt risikovillighed.
4. Opret eller opdater risikoregisteret.
5. Kortlæg hver behandling til ISO 27001:2022-kontroller og SoA.
6. Brug Zenith Controls til at krydshenvise privatlivs-, kryptografi-, leverandør-, hændelses- og uafhængige gennemgangskontroller på tværs af efterlevelsesforventninger.
7. Følg Zenith Blueprint Step 13 og Step 14 for at forbinde risici, kontroller og regulatoriske forpligtelser.
8. Brug Zenith Blueprint Step 19 til at verificere tekniske kontroller i drift.
9. Brug Zenith Blueprint Step 30 til at samle den endelige revisionsklare dokumentationspakke.
10. Opbevar al dokumentation centralt, mærk den efter risiko og kontroltema, og hold korrigerende handlinger synlige.

Clarysec kan hjælpe jer med at omsætte GDPR Article 32 fra en uklar efterlevelsesforpligtelse til et forsvarligt, risikobaseret dokumentationssystem tilpasset ISO 27001:2022, NIS2 og DORA.

Start med Zenith Blueprint, styrk den med Clarysec-politikker, og brug Zenith Controls til at gøre hver TOM sporbar, testbar og revisionsklar.