Dokazila za TOMs po GDPR Article 32 z ISO, NIS2 in DORA

E-poštno sporočilo pristane v nabiralniku direktorja za informacijsko varnost (CISO) z znano težo posla, ki bi lahko spremenil četrtletne rezultate podjetja.

Velik potencialni naročnik zahteva dokazila o »tehničnih in organizacijskih ukrepih po GDPR Article 32, mapiranih na ISO 27001:2022, NIS2 in DORA, kjer je to ustrezno«. Hkrati je pravna služba upravni odbor seznanila z odgovornostjo vodstva po NIS2 in pričakovanji DORA glede operativne odpornosti. Navodilo upravnega odbora zveni preprosto: dokažite skladnost, preprečite podvajanje dela in iz tega ne naredite treh ločenih projektov.

Podjetje kontrole ima. MFA je omogočen. Varnostne kopije se izvajajo. Razvijalci pregledujejo izvorno kodo. Ekipa za zasebnost vzdržuje evidence dejavnosti obdelave. Infrastrukturna ekipa izvaja preglede ranljivosti. Dobavitelji se preverjajo v postopku nabave. Ko pa potencialni naročnik zahteva dokazila, se odgovor razdrobi.

Poročilo ponudnika identitet je na enem mestu. Dnevniki varnostnega kopiranja so drugje. Register tveganj ni bil posodobljen od zadnje izdaje produkta. Dokazila o varnosti dobaviteljev so v nabavnih e-poštnih sporočilih. Zapisi namiznih vaj za odziv na incidente obstajajo, vendar nihče ne more dokazati, da so bile pridobljene izkušnje vključene nazaj v obravnavo tveganj. Upravni odbor je odobril varnostna sredstva, vendar odobritev ni povezana z IKT-tveganjem ali dokumentirano odločitvijo o kontroli.

To je dejanska težava tehničnih in organizacijskih ukrepov po GDPR Article 32, pogosto imenovanih TOMs. Večina organizacij ne pade zato, ker nima kontrol. Pade zato, ker ne more dokazati, da so kontrole zasnovane na tveganjih, odobrene, uvedene, spremljane in izboljševane.

Načelo odgovornosti po GDPR to pričakovanje določa izrecno. GDPR Article 5 zahteva, da so osebni podatki zaščiteni z ustrezno varnostjo pred nepooblaščeno ali nezakonito obdelavo ter nenamerno izgubo, uničenjem ali poškodbo. Article 5(2) določa odgovornost upravljavca za dokazovanje skladnosti. Pomembne so tudi opredelitve po GDPR. Osebni podatki so opredeljeni široko, obdelava zajema skoraj vsako operacijo nad podatki, psevdonimizacija je priznan zaščitni ukrep, kršitev varnosti osebnih podatkov pa vključuje nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje ali dostop.

Dosje dokazil za Article 32 zato ne sme biti mapa naključnih posnetkov zaslona. Biti mora živ sistem kontrol.

Pristop Clarysec je pretvoriti TOMs po GDPR Article 32 v sledljiv mehanizem dokazil, zgrajen na ISO/IEC 27001:2022 ISO/IEC 27001:2022, okrepljen z upravljanjem tveganj po ISO/IEC 27005:2022 in navzkrižno povezan z obveznostmi NIS2 in DORA, kjer se uporabljajo. Cilj ni dokumentacija sama sebi namen. Cilj je, da je organizacija pripravljena na presojo, še preden naročnik, presojevalec, regulator ali član upravnega odbora postavi zahtevno vprašanje.

Zakaj TOMs po GDPR Article 32 v praksi odpovejo

Article 32 se pogosto napačno razume kot seznam varnostnih orodij: šifriranje, varnostne kopije, beleženje, nadzor dostopa in odziv na incidente. Ti ukrepi so pomembni, vendar so zagovorljivi samo, kadar so ustrezni glede na tveganje in povezani z življenjskim ciklom osebnih podatkov.

Za podjetje SaaS, ki obdeluje podatke o zaposlenih pri naročnikih, trditev »uporabljamo šifriranje« ni dovolj. Presojevalec lahko vpraša, katere podatke šifriranje varuje, kje je šifriranje zahtevano, kako se upravljajo ključi, ali so varnostne kopije šifrirane, ali so produkcijski podatki maskirani pri testiranju, kdo lahko obide kontrole in kako se odobrijo izjeme.

Podjetniška Politika varstva podatkov in zasebnosti Clarysec zajema operativno načelo:

»Uvesti tehnične in organizacijske ukrepe (TOMs), ki varujejo zaupnost, celovitost in razpoložljivost osebno določljivih podatkov (PII) skozi njihov življenjski cikel.«

Vir: Politika varstva podatkov in zasebnosti, cilji, klavzula politike 3.3. Politika varstva podatkov in zasebnosti

Besedna zveza »skozi njihov življenjski cikel« je točka, kjer številni programi TOMs oslabijo. Osebni podatki so lahko zaščiteni v produkciji, vendar se kopirajo v analitične sisteme, dnevnike, podporne izvoze, testna okolja, varnostne kopije, platforme dobaviteljev in naprave zaposlenih. Vsaka lokacija ustvarja varnostno tveganje in tveganje za zasebnost.

GDPR Article 6 zahteva pravno podlago za obdelavo, vključno s privolitvijo, pogodbo, zakonsko obveznostjo, življenjskimi interesi, javno nalogo ali zakonitimi interesi. Kadar se podatki ponovno uporabijo za nadaljnji namen, je treba upoštevati združljivost in zaščitne ukrepe, kot sta šifriranje ali psevdonimizacija. Pri podatkih z višjim tveganjem se dokazno breme poveča. GDPR Article 9 strogo omejuje posebne vrste osebnih podatkov, kot so zdravstveni podatki, biometrični podatki, uporabljeni za identifikacijo, in druge občutljive informacije. Article 10 omejuje podatke o kazenskih obsodbah in prekrških.

Za MSP Clarysec obravnavo tveganj izraža praktično:

»Kontrole morajo biti uvedene za zmanjšanje identificiranih tveganj, vključno s šifriranjem, anonimizacijo, varnim odstranjevanjem in omejitvami dostopa«

Vir: Politika varstva podatkov in zasebnosti za MSP, obravnava tveganj in izjeme, klavzula politike 7.2.1. Politika varstva podatkov in zasebnosti - MSP

To je močna izhodiščna osnova za TOMs. Da postane primerna za presojo, mora biti vsaka kontrola povezana tudi s tveganjem, lastnikom, zahtevo politike, dokazilom in pogostostjo pregleda.

ISO 27001:2022 je hrbtenica dokazil za Article 32

ISO 27001:2022 je za GDPR Article 32 primeren zato, ker varnost obravnava kot sistem upravljanja, ne kot nepovezan kontrolni seznam. Zahteva sistem upravljanja informacijske varnosti oziroma ISMS, zasnovan za ohranjanje zaupnosti, celovitosti in razpoložljivosti z upravljanjem tveganj.

Prvi ključni korak je obseg. Klavzule ISO 27001:2022 od 4.1 do 4.4 zahtevajo, da organizacija razume notranje in zunanje dejavnike, identificira zainteresirane strani in zahteve, določi, katere zahteve bo ISMS obravnaval, ter opredeli obseg ISMS, vključno z vmesniki in odvisnostmi od zunanjih organizacij. Za TOMs po Article 32 mora obseg ISMS odražati obdelavo osebnih podatkov, obveznosti do naročnikov, obdelovalce, podobdelovalce, oblačne platforme, delo na daljavo, podporne funkcije in produktna okolja.

Drugi korak je vodstvo. Klavzule 5.1 do 5.3 zahtevajo zavezanost najvišjega vodstva, politiko informacijske varnosti, vire, vloge in odgovornosti ter poročanje o uspešnosti. To je pomembno, ker GDPR Article 32, NIS2 in DORA temeljijo na upravljanju. Kontrola brez lastništva, financiranja ali pregleda je šibko dokazilo.

Podjetniška Politika informacijske varnosti Clarysec to določa izrecno:

»ISMS mora vključevati opredeljene meje obsega, metodologijo ocenjevanja tveganj, merljive cilje in dokumentirane kontrole, utemeljene v izjavi o uporabnosti (SoA).«

Vir: Politika informacijske varnosti, zahteve za izvajanje politike, klavzula politike 6.1.2. Politika informacijske varnosti

Ista politika določa pričakovanje glede dokazil:

»Vse uvedene kontrole morajo biti preverljive, podprte z dokumentiranimi postopki in ohranjenimi dokazili o delovanju.«

Vir: Politika informacijske varnosti, zahteve za izvajanje politike, klavzula politike 6.6.1.

Klavzule ISO 27001:2022 od 6.1.1 do 6.1.3 nato zahtevajo oceno tveganj, obravnavo tveganj, izjavo o uporabnosti, odobritev preostalega tveganja in odgovornost lastnika tveganja. Klavzula 6.2 zahteva merljive cilje. Klavzule 7.5, 9.1, 9.2, 9.3 in 10.2 zahtevajo dokumentirane informacije, spremljanje, notranjo presojo, vodstveni pregled in korektivni ukrep.

Za GDPR Article 32 to ustvari zagovorljivo strukturo.

ISO/IEC 27005:2022 to strukturo okrepi. Organizacijam svetuje, naj identificirajo zahteve iz Priloge A k ISO 27001:2022, predpisov, pogodb, sektorskih standardov, notranjih pravil in obstoječih kontrol ter jih vključijo v oceno in obravnavo tveganj. Zahteva tudi merila tveganja in merila sprejemanja, ki upoštevajo pravne, regulativne, operativne, dobaviteljske, tehnološke in človeške dejavnike, vključno z zasebnostjo.

Politika upravljanja tveganj Clarysec je s tem neposredno usklajena:

»Formalni proces obvladovanja tveganj se vzdržuje v skladu z ISO/IEC 27005 in ISO 31000 ter zajema identifikacijo, analizo, vrednotenje, obravnavo, spremljanje in komuniciranje tveganj.«

Vir: Politika upravljanja tveganj, zahteve upravljanja, klavzula politike 5.1. Politika upravljanja tveganj

Za MSP ista zahteva postane preprosta in izvedljiva:

»Vsak vnos tveganja mora vključevati: opis, verjetnost, vpliv, oceno, lastnika in načrt obravnave tveganja.«

Vir: Politika upravljanja tveganj za MSP, zahteve upravljanja, klavzula politike 5.1.2. Politika upravljanja tveganj - MSP

Ta stavek je hiter test pripravljenosti na presojo. Če tveganje nima lastnika ali načrta obravnave tveganja, še ni pripravljeno za dokazovanje.

Most Clarysec: tveganje, SoA, kontrole in predpisi

Clarysecov Zenith Blueprint: 30-koračni načrt presojevalca Zenith Blueprint obravnava skladnost kot delo na sledljivosti. V fazi upravljanja tveganj se Step 13 osredotoča na načrtovanje obravnave tveganj in izjavo o uporabnosti. Pojasnjuje, da morajo organizacije mapirati kontrole na tveganja, v vnose obravnave tveganj dodati sklice na kontrole iz Priloge A, navzkrižno povezati zunanje predpise in pridobiti odobritev vodstva.

Zenith Blueprint neposredno opredeli vlogo SoA:

»SoA je dejansko povezovalni dokument: povezuje vašo oceno/obravnavo tveganj z dejanskimi kontrolami, ki jih imate. Z njegovo izpolnitvijo tudi ponovno preverite, ali ste katero od kontrol spregledali.«

Vir: Zenith Blueprint: 30-koračni načrt presojevalca, faza upravljanja tveganj, Step 13: načrtovanje obravnave tveganj in izjava o uporabnosti (SoA). Zenith Blueprint

Step 14 v Zenith Blueprint doda plast navzkrižnih sklicev na predpise. Organizacijam svetuje, naj dokumentirajo, kako so zahteve GDPR, NIS2 in DORA pokrite s politikami in kontrolami. Za GDPR poudarja varstvo osebnih podatkov v ocenah in obravnavah tveganj, vključno s šifriranjem kot tehničnim ukrepom in odzivom na kršitve kot delom kontrolnega okolja. Za NIS2 izpostavlja oceno tveganj, varnost omrežja, nadzor dostopa, obravnavanje incidentov in neprekinjeno poslovanje. Za DORA opozarja na upravljanje IKT-tveganj, odziv na incidente, poročanje in nadzor nad tretjimi ponudniki IKT.

To je jedro metode Clarysec: en ISMS, en register tveganj, ena SoA, ena knjižnica dokazil, več izidov skladnosti.

Zenith Controls: vodnik za navzkrižno skladnost Zenith Controls to podpira tako, da organizacijam pomaga uporabljati kontrolne teme ISO/IEC 27002:2022 ISO/IEC 27002:2022 kot sidra za navzkrižno skladnost. Za GDPR Article 32 so najpomembnejša sidra pogosto zasebnost in varstvo PII, kontrola 5.34; neodvisni pregled informacijske varnosti, kontrola 5.35; ter uporaba kriptografije, kontrola 8.24.

NIS2 spremeni TOMs v vprašanje kibernetske varnosti na ravni upravnega odbora

Številne organizacije TOMs po GDPR obravnavajo kot odgovornost ekipe za zasebnost. NIS2 spremeni razpravo.

NIS2 se uporablja za številne srednje in velike subjekte v navedenih sektorjih, v nekaterih primerih pa ne glede na velikost. Zajeti digitalni in tehnološki sektorji vključujejo ponudnike storitev računalništva v oblaku, ponudnike podatkovnih centrov, omrežja za dostavo vsebin, ponudnike storitev DNS, registre TLD, ponudnike storitev zaupanja, ponudnike javnih elektronskih komunikacij, ponudnike upravljanih storitev, ponudnike upravljanih varnostnih storitev, spletne tržnice, iskalnike in platforme družbenih medijev. Uporabljivost za SaaS in tehnološke MSP je odvisna od sektorja, velikosti, določitve države članice ter sistemskega ali čezmejnega vpliva.

NIS2 Article 20 nalaga odgovornost za kibernetsko varnost organom upravljanja. Ti morajo odobriti ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirati izvajanje in opraviti usposabljanje. Bistveni subjekti se lahko soočijo z upravnimi globami najmanj 10 milijonov EUR ali najmanj 2 odstotka svetovnega letnega prometa. Pomembni subjekti se lahko soočijo z globami najmanj 7 milijonov EUR ali najmanj 1,4 odstotka.

NIS2 Article 21 je neposredno relevanten za TOMs po Article 32, ker zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe. Ti ukrepi morajo upoštevati stanje tehnike, evropske in mednarodne standarde, stroške, izpostavljenost, velikost, verjetnost, resnost ter družbeni ali gospodarski vpliv. Zahtevana področja vključujejo analizo tveganj, varnostne politike, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varno nabavo in razvoj, obravnavo ranljivosti, oceno učinkovitosti, kibernetsko higieno, usposabljanje, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev, MFA ali neprekinjeno avtentikacijo ter varne komunikacije, kjer je ustrezno.

NIS2 Article 23 dodaja fazno poročanje o incidentih: zgodnje opozorilo v 24 urah, obvestilo o incidentu v 72 urah, vmesne posodobitve na zahtevo in končno poročilo najpozneje en mesec po 72-urnem obvestilu. Če kršitev varnosti osebnih podatkov hkrati izpolnjuje pogoje za pomemben incident po NIS2, mora vaš dosje dokazil podpirati odločitve o poročanju tako na področju zasebnosti kot kibernetske varnosti.

DORA dviguje standard za finančno odpornost in ponudnike IKT

DORA se uporablja od 17. januarja 2025 in vzpostavlja pravilnik za digitalno operativno odpornost finančnega sektorja. Zajema upravljanje IKT-tveganj, poročanje o večjih incidentih, povezanih z IKT, testiranje operativne odpornosti, izmenjavo informacij o kibernetskih grožnjah in ranljivostih, tveganje tretjih ponudnikov IKT, pogodbene zahteve za ponudnike IKT, nadzor nad kritičnimi tretjimi ponudniki storitev IKT in nadzor.

Za finančne subjekte, ki so opredeljeni tudi po nacionalnih pravilih NIS2, DORA deluje kot sektorsko specifičen pravni akt Unije za prekrivajoče se obveznosti upravljanja tveganj kibernetske varnosti in poročanja o incidentih. V praksi morajo zajeti finančni subjekti za ta prekrivajoča se področja prednostno uporabljati DORA, hkrati pa ohranjati koordinacijo s pristojnimi organi NIS2 in CSIRT, kjer je to ustrezno.

Za dokazila po GDPR Article 32 je DORA pomembna na dva načina. Prvič, fintech podjetja so lahko neposredno zajeta kot finančni subjekti, vključno s kreditnimi institucijami, plačilnimi institucijami, ponudniki storitev informacij o računih, institucijami za izdajo elektronskega denarja, investicijskimi podjetji, ponudniki storitev v zvezi s kriptosredstvi, mesti trgovanja in ponudniki storitev množičnega financiranja. Drugič, finančni naročniki lahko ponudnike SaaS, oblaka, podatkov, programske opreme in upravljanih storitev obravnavajo kot tretje ponudnike storitev IKT, ker DORA široko opredeljuje storitve IKT.

DORA Article 5 zahteva upravljanje in notranje kontrole za upravljanje IKT-tveganj, pri čemer organ upravljanja opredeli, odobri, nadzira in ostaja odgovoren za ureditve IKT-tveganj. Article 6 zahteva dokumentiran okvir upravljanja IKT-tveganj, vključno s strategijami, politikami, postopki, IKT-protokoli in orodji za varovanje informacij in sredstev IKT. Article 17 zahteva proces upravljanja incidentov, povezanih z IKT, ki zajema odkrivanje, upravljanje, obveščanje, evidentiranje, temeljni vzrok, kazalnike zgodnjega opozarjanja, razvrščanje, vloge, komunikacije, eskalacijo in odziv. Article 19 zahteva poročanje o večjih incidentih, povezanih z IKT, pristojnim organom.

DORA Articles 28 and 30 tveganje tretjih ponudnikov IKT postavita v regulirano področje kontrol. Finančni subjekti ostanejo odgovorni za skladnost pri uporabi storitev IKT. Potrebujejo strategijo tveganj tretjih oseb, pogodbene registre, ocene kritičnosti, skrbni pregled, pregled tveganja koncentracije, pravice do revizije in pregledov, sprožilce za odpoved, izstopne strategije in pogodbene določbe, ki zajemajo lokacije podatkov, razpoložljivost, avtentičnost, celovitost, zaupnost, pomoč pri incidentih, obnovitev, ravni storitev in sodelovanje z organi.

Za Article 32 to pomeni, da so dobavitelji del dosjeja TOMs. Varnosti obdelave ne morete dokazati, če kritični obdelovalci, oblačne platforme, analitični ponudniki, podporna orodja in ponudniki IKT niso nadzorovani.

Praktična enotedenska priprava dokazil za Article 32

Močan dosje dokazil se začne z enim jasnim scenarijem tveganja.

Uporabite ta primer: »Nepooblaščen dostop do osebnih podatkov naročnikov v produkcijski aplikaciji.«

Ustvarite ali osvežite vnos tveganja. Vključite opis, verjetnost, vpliv, oceno, lastnika in načrt obravnave tveganja. Lastništvo dodelite vodji inženiringa, vodji varnosti ali enakovredni odgovorni vlogi. Verjetnost ocenite na podlagi modela dostopa, izpostavljene napadalne površine, znanih ranljivosti in preteklih incidentov. Vpliv ocenite na podlagi obsega osebnih podatkov, občutljivosti, pogodb z naročniki, posledic po GDPR in morebitnega vpliva na storitev po NIS2 ali DORA.

Izberite obravnave, kot so MFA za privilegirani dostop, nadzor dostopa na podlagi vlog, četrtletni pregledi pravic dostopa, šifriranje podatkov v mirovanju, TLS, pregledovanje ranljivosti, beleženje, opozarjanje, varne varnostne kopije, postopki odzivanja na incidente in maskiranje podatkov v neprodukcijskih okoljih.

Nato tveganje mapirajte na SoA. Dodajte sklice ISO/IEC 27002:2022, kot so 5.34 zasebnost in varstvo PII, 8.24 uporaba kriptografije, 5.15 nadzor dostopa, 5.18 pravice dostopa, 8.13 varnostno kopiranje informacij, 8.15 beleženje, 8.16 dejavnosti spremljanja, 8.8 upravljanje tehničnih ranljivosti, 8.25 varen življenjski cikel razvoja programske opreme in 8.10 brisanje informacij, kjer je ustrezno. Dodajte opombe, ki kažejo, kako te kontrole podpirajo GDPR Article 32, NIS2 Article 21 in upravljanje IKT-tveganj po DORA, kjer je relevantno.

Pri regulativnem mapiranju ohranite imena kontrol točna in se izogibajte vsiljevanju lažne enakovrednosti.

Zdaj pripravite mapo z dokazili. Politika spremljanja presoje in skladnosti za MSP Clarysec daje preprosto pravilo:

»Vsa dokazila morajo biti shranjena v centralizirani revizijski mapi.«

Vir: Politika spremljanja presoje in skladnosti za MSP, zahteve za izvajanje politike, klavzula politike 6.2.1. Politika spremljanja presoje in skladnosti - MSP

Za ta en scenarij tveganja mora mapa vsebovati:

Dokazila o dostopu se ne smejo končati pri posnetkih zaslona. Politika nadzora dostopa za MSP dodaja koristno operativno zahtevo:

»Vodja IT mora dokumentirati rezultate pregledov in korektivne ukrepe.«

Vir: Politika nadzora dostopa za MSP, zahteve upravljanja, klavzula politike 5.5.3. Politika nadzora dostopa - MSP

Dokazila o varnostnem kopiranju morajo dokazati zmožnost obnovitve, ne le uspešnih opravil. Politika varnostnega kopiranja in obnove za MSP določa:

»Testi obnovitve se izvajajo najmanj četrtletno, rezultati pa se dokumentirajo za preverjanje zmožnosti obnovitve«

Vir: Politika varnostnega kopiranja in obnove za MSP, zahteve upravljanja, klavzula politike 5.3.3. Politika varnostnega kopiranja in obnove - MSP

S tem dobite popolno dokazno zanko: predpis ustvari zahtevo, tveganje pojasni, zakaj je pomembna, SoA izbere kontrolo, politika opredeli delovanje, ohranjena dokazila pa dokazujejo, da kontrola deluje.

Kontrole v praksi: pretvorba politike v operativno dokazilo

Faza Zenith Blueprint Kontrole v praksi, Step 19, se osredotoča na tehnično preverjanje. Priporoča pregled skladnosti varnosti končnih točk, upravljanja identitet in dostopa, avtentikacijskih konfiguracij, varnosti nadzora izvorne kode, zmogljivosti in razpoložljivosti, upravljanja ranljivosti in popravkov, varnih osnovnih nastavitev, zaščite pred zlonamerno programsko opremo, brisanja in minimizacije podatkov, maskiranja in testnih podatkov, DLP, varnostnega kopiranja in obnove, redundance, beleženja in spremljanja ter sinhronizacije časa.

Za TOMs po GDPR Article 32 je Step 19 točka, kjer abstrakten jezik kontrol postane dokazilo. Močan dosje dokazil mora pokazati, da:

• je šifriranje končnih točk omogočeno in spremljano;
• imajo privilegirani uporabniki MFA;
• so procesi za novozaposlene, premeščene in odhajajoče zaposlene usklajeni s kadrovskimi zapisi;
• so storitveni računi dokumentirani in omejeni;
• so repozitoriji kode zaščiteni z nadzorom dostopa in se izvaja odkrivanje skrivnosti;
• se pregledovanje ranljivosti izvaja in spremlja do odprave;
• se produkcijski podatki ne kopirajo nekontrolirano v testna okolja;
• se politike varnega brisanja in hrambe uveljavljajo;
• se opozorila DLP pregledujejo;
• testi obnovitve varnostnih kopij dokazujejo zmožnost obnovitve;
• so dnevniki centralizirani, hranjeni in pregledljivi;
• sinhronizacija časa podpira zanesljivo preiskavo incidentov.

Ključna je povezanost. Poročilo o popravkih brez sklica na tveganje, politiko in SoA je IT-artefakt. Poročilo o popravkih, povezano z GDPR Article 32, NIS2 Article 21, upravljanjem IKT-tveganj po DORA in načrtom obravnave tveganja po ISO 27001:2022, je dokazilo, primerno za presojo.

En dosje dokazil, več revizijskih pogledov

Ista dokazila TOMs bodo različne zainteresirane strani brale različno. Pregledovalec zasebnosti se lahko osredotoči na osebne podatke, nujnost, sorazmernost in odgovornost. Presojevalec ISO 27001 se lahko osredotoči na obseg, obravnavo tveganj, SoA in dokazila o delovanju. Organ NIS2 se lahko osredotoči na nadzor vodstva, ukrepe iz Article 21 in pripravljenost na poročanje po Article 23. Nadzornik DORA ali finančni naročnik se lahko osredotoči na upravljanje IKT-tveganj, testiranje odpornosti in odvisnosti od tretjih oseb.

Clarysec uporablja Zenith Controls kot vodnik za navzkrižno skladnost pri tem prevodu med pogledi.

To preprečuje podvajanje dela na področju skladnosti. Namesto da pripravljate ločene pakete dokazil za GDPR, NIS2 in DORA, pripravite en dosje dokazil o kontrolah in vsako dokazilo označite z obveznostmi, ki jih podpira.

Pogoste vrzeli v programih TOMs po Article 32

Najpogostejša vrzel je osirotelost kontrol. Podjetje ima kontrolo, na primer šifriranje, vendar ne more pojasniti, katero tveganje obravnava, katera politika jo zahteva, kdo jo ima v lasti ali kako se pregleduje.

Druga vrzel so šibka dokazila dobaviteljev. Po GDPR so obdelovalci in podobdelovalci pomembni. Po NIS2 je varnost dobavne verige del upravljanja tveganj kibernetske varnosti. Po DORA je tveganje tretjih ponudnikov IKT regulirano področje z registri, skrbnim pregledom, pogodbenimi zaščitnimi ukrepi, pravicami do revizije in izstopnim načrtovanjem. Preglednica dobaviteljev ni dovolj, če kritične odvisnosti niso ocenjene glede tveganj in nadzorovane.

Tretja vrzel so dokazila o incidentih. Organizacije imajo pogosto načrt odzivanja na incidente, nimajo pa dokazov, da so bile preizkušene razvrstitev, eskalacija, poročanje organom in komunikacija z naročniki. NIS2 in DORA tu dvigujeta pričakovanja, ocena kršitve varnosti osebnih podatkov po GDPR pa mora biti vključena v isti delovni tok.

Četrta vrzel so dokazila o varnostnem kopiranju. Uspešno opravilo varnostnega kopiranja ne dokazuje zmožnosti obnovitve. Dokumentiran test obnovitve jo dokazuje.

Peta vrzel je vodstveni pregled. TOMs po Article 32 morajo biti sorazmerni s tveganjem. Če vodstvo nikoli ne pregleduje tveganj, incidentov, težav z dobavitelji, proračuna, ugotovitev presoje in preostalega tveganja, postane sorazmernost težko dokazljiva.

Končni nabor orodij za pripravljenost na presojo

Faza Zenith Blueprint Presoja, pregled in izboljševanje, Step 30, zagotavlja končni kontrolni seznam pripravljenosti. Vključuje obseg in kontekst ISMS, podpisano politiko informacijske varnosti, dokumente ocene in obravnave tveganj, SoA, politike in postopke Priloge A, zapise o usposabljanju, operativne zapise, poročilo notranje presoje, evidenco korektivnih ukrepov, zapisnike vodstvenih pregledov, dokazila nenehnega izboljševanja in evidence obveznosti skladnosti.

Podjetniška Politika spremljanja presoje in skladnosti Clarysec določa namen te discipline:

»Ustvariti zagovorljiva dokazila in revizijsko sled v podporo regulatornim poizvedbam, pravnim postopkom ali zahtevam naročnikov po zagotovilu.«

Vir: Politika spremljanja presoje in skladnosti, cilji, klavzula politike 3.4. Politika spremljanja presoje in skladnosti

Zrel dosje dokazil za TOMs po Article 32 mora vključevati:

Naslednji koraki: zgradite dokazila za TOMs po Article 32 s Clarysec

Če morate dokazati tehnične in organizacijske ukrepe po GDPR Article 32, ne začnite z zbiranjem naključnih posnetkov zaslona. Začnite s sledljivostjo.

1. Opredelite obseg ISMS in meje obdelave osebnih podatkov.
2. Identificirajte zahteve GDPR, NIS2, DORA, pogodbene zahteve in zahteve naročnikov.
3. Zgradite merila tveganja z uporabo ISO/IEC 27005:2022 in apetita po tveganju, ki ga odobri vodstvo.
4. Ustvarite ali osvežite register tveganj.
5. Vsako obravnavo mapirajte na kontrole ISO 27001:2022 in SoA.
6. Uporabite Zenith Controls za navzkrižno sklicevanje kontrol zasebnosti, kriptografije, dobaviteljev, incidentov in neodvisnega pregleda glede na pričakovanja skladnosti.
7. Sledite Zenith Blueprint Step 13 in Step 14 za povezavo tveganj, kontrol in regulativnih obveznosti.
8. Uporabite Zenith Blueprint Step 19 za preverjanje tehničnih kontrol med delovanjem.
9. Uporabite Zenith Blueprint Step 30 za sestavo končnega dosjeja dokazil, primernega za presojo.
10. Vsa dokazila shranjujte centralno, označite jih po tveganju in kontrolni temi ter naj bodo korektivni ukrepi vidni.

Clarysec vam lahko pomaga pretvoriti GDPR Article 32 iz nejasne obveznosti skladnosti v zagovorljiv, na tveganjih temelječ sistem dokazil, usklajen z ISO 27001:2022, NIS2 in DORA.

Začnite z Zenith Blueprint, okrepite ga s politikami Clarysec in uporabite Zenith Controls, da bo vsak TOM sledljiv, preverljiv in pripravljen za presojo.