GDPR 32 straipsnio TOMs įrodymai su ISO, NIS2 ir DORA

El. laiškas patenka į CISO pašto dėžutę su pažįstamu sandorio svoriu, galinčiu pakeisti įmonės ketvirčio rezultatus.

Stambus potencialus įmonės klientas prašo įrodymų apie „GDPR Article 32 technines ir organizacines priemones, susietas su ISO 27001:2022, NIS2 ir DORA, kai taikoma“. Tuo pat metu teisininkai valdybai pristatė NIS2 vadovybės atsakomybę ir DORA operacinio atsparumo lūkesčius. Valdybos nurodymas skamba paprastai: pagrįsti atitiktį, išvengti dubliuojamo darbo ir nepaversti to trimis atskirais projektais.

Įmonė turi kontrolės priemones. MFA įjungtas. Atsarginės kopijos kuriamos. Kūrėjai atlieka kodo peržiūras. Privatumo komanda prižiūri tvarkymo veiklos įrašus. Infrastruktūros komanda skenuoja pažeidžiamumus. Tiekėjai vertinami pirkimų proceso metu. Tačiau kai potencialus klientas paprašo įrodymų, atsakymas išsiskaido į atskiras dalis.

Tapatybės teikėjo ataskaita yra vienoje vietoje. Atsarginių kopijų žurnalai – kitoje. Rizikų registras neatnaujintas nuo paskutinės produkto laidos. Tiekėjų saugumo įrodymai saugomi pirkimų el. laiškuose. Reagavimo į incidentus stalo pratybų pastabos yra, bet niekas negali įrodyti, kad įgyta patirtis buvo grąžinta į rizikos tvarkymą. Valdyba patvirtino saugumo biudžetą, bet patvirtinimas nesusietas su IRT rizika ar dokumentuotu sprendimu dėl kontrolės priemonės.

Tai ir yra tikroji GDPR Article 32 techninių ir organizacinių priemonių, dažnai vadinamų TOMs, problema. Dauguma organizacijų suklumpa ne todėl, kad neturi kontrolės priemonių. Jos suklumpa todėl, kad negali parodyti, jog kontrolės priemonės yra grindžiamos rizika, patvirtintos, įgyvendintos, stebimos ir tobulinamos.

GDPR atskaitomybės principas šį lūkestį išreiškia aiškiai. GDPR Article 5 reikalauja, kad asmens duomenys būtų saugomi užtikrinant tinkamą saugumą nuo neautorizuoto ar neteisėto tvarkymo ir atsitiktinio praradimo, sunaikinimo ar sugadinimo. Article 5(2) nustato duomenų valdytojo atsakomybę pagrįsti atitiktį. GDPR apibrėžtys taip pat svarbios. Asmens duomenų sąvoka yra plati, tvarkymas apima beveik kiekvieną operaciją su duomenimis, pseudonimizavimas yra pripažinta apsaugos priemonė, o asmens duomenų saugumo pažeidimas apima atsitiktinį ar neteisėtą sunaikinimą, praradimą, pakeitimą, neautorizuotą atskleidimą ar prieigą.

Todėl Article 32 įrodymų failas negali būti atsitiktinių ekrano kopijų aplankas. Tai turi būti gyva kontrolės priemonių sistema.

Clarysec požiūris – paversti GDPR Article 32 TOMs atsekamu įrodymų varikliu, sukurtu pagal ISO/IEC 27001:2022 ISO/IEC 27001:2022, sustiprintu ISO/IEC 27005:2022 rizikos valdymu ir susietu su NIS2 bei DORA įpareigojimais, kai jie taikomi. Tikslas nėra dokumentacija dėl pačios dokumentacijos. Tikslas – užtikrinti, kad organizacija būtų pasirengusi auditui dar prieš klientui, auditoriui, reguliuotojui ar valdybos nariui užduodant sudėtingą klausimą.

Kodėl GDPR Article 32 TOMs praktikoje neveikia

Article 32 dažnai klaidingai suprantamas kaip saugumo priemonių sąrašas: šifravimas, atsarginės kopijos, žurnalavimas, prieigos kontrolė ir reagavimas į incidentus. Šios priemonės svarbios, tačiau jos pagrįstos tik tada, kai yra tinkamos rizikai ir susietos su asmens duomenų gyvavimo ciklu.

SaaS įmonei, tvarkančiai klientų darbuotojų duomenis, teiginio „naudojame šifravimą“ nepakanka. Auditorius gali paklausti, kokius duomenis šifravimas apsaugo, kur šifravimas privalomas, kaip valdomi raktai, ar atsarginės kopijos šifruojamos, ar produkciniai duomenys maskuojami testavimo metu, kas gali apeiti kontrolės priemones ir kaip tvirtinamos išimtys.

Clarysec įmonės Duomenų apsaugos ir privatumo politika įtvirtina veikimo principą:

„Įgyvendinti technines ir organizacines priemones (TOMs), kurios apsaugo asmens identifikavimo informacijos (PII) konfidencialumą, vientisumą ir prieinamumą per visą jos gyvavimo ciklą.“

Šaltinis: Duomenų apsaugos ir privatumo politika, Tikslai, politikos punktas 3.3. Duomenų apsaugos ir privatumo politika

Frazė „per visą jos gyvavimo ciklą“ yra vieta, kur daugelis TOMs programų susilpnėja. Asmens duomenys gali būti apsaugoti produkcinėje aplinkoje, bet nukopijuoti į analitikos sistemas, žurnalus, pagalbos eksportus, testavimo aplinkas, atsargines kopijas, tiekėjų platformas ir darbuotojų įrenginius. Kiekviena vieta sukuria saugumo ir privatumo riziką.

GDPR Article 6 reikalauja teisinio pagrindo tvarkymui, įskaitant sutikimą, sutartį, teisinę prievolę, gyvybinius interesus, viešąją užduotį arba teisėtus interesus. Kai duomenys pakartotinai naudojami kitam tikslui, turi būti įvertintas suderinamumas ir apsaugos priemonės, tokios kaip šifravimas ar pseudonimizavimas. Didesnės rizikos duomenims įrodymų našta didėja. GDPR Article 9 nustato griežtus specialiųjų kategorijų asmens duomenų, tokių kaip sveikatos duomenys, identifikavimui naudojami biometriniai duomenys ir kita jautri informacija, apribojimus. Article 10 riboja duomenų apie apkaltinamuosius nuosprendžius ir nusikalstamas veikas tvarkymą.

MVĮ atveju Clarysec rizikos tvarkymą išreiškia praktine kalba:

„Kontrolės priemonės turi būti įgyvendintos nustatytoms rizikoms sumažinti, įskaitant šifravimą, anonimizavimą, saugų sunaikinimą ir prieigos apribojimus.“

Šaltinis: Duomenų apsaugos ir privatumo politika MVĮ, Rizikos tvarkymas ir išimtys, politikos punktas 7.2.1. Duomenų apsaugos ir privatumo politika MVĮ

Tai yra tvirtas TOMs bazinis rinkinys. Kad jis būtų tinkamas auditui, kiekviena kontrolės priemonė taip pat turi būti susieta su rizika, savininku, politikos reikalavimu, įrodymo elementu ir peržiūros periodiškumu.

ISO 27001:2022 yra Article 32 įrodymų pagrindas

ISO 27001:2022 gerai tinka GDPR Article 32, nes saugumą traktuoja kaip valdymo sistemą, o ne kaip atskirą kontrolinį sąrašą. Jis reikalauja informacijos saugumo valdymo sistemos, arba ISVS, skirtos išsaugoti konfidencialumą, vientisumą ir prieinamumą taikant rizikos valdymą.

Pirmas kritinis žingsnis yra taikymo sritis. ISO 27001:2022 4.1–4.4 punktai reikalauja, kad organizacija suprastų vidaus ir išorės klausimus, nustatytų suinteresuotąsias šalis ir reikalavimus, apibrėžtų, kuriuos reikalavimus apims ISVS, ir nustatytų ISVS taikymo sritį, įskaitant sąsajas ir priklausomybes nuo išorės organizacijų. Article 32 TOMs atveju ISVS taikymo sritis turėtų atspindėti asmens duomenų tvarkymą, klientų įpareigojimus, tvarkytojus, subtvarkytojus, debesijos platformas, nuotolinį darbą, pagalbos funkcijas ir produkto aplinkas.

Antras žingsnis yra vadovavimas. 5.1–5.3 punktai reikalauja aukščiausiosios vadovybės įsipareigojimo, informacijos saugumo politikos, išteklių, vaidmenų ir atsakomybių bei veiklos rezultatų ataskaitų teikimo. Tai svarbu, nes GDPR Article 32, NIS2 ir DORA remiasi valdysena. Kontrolės priemonė be savininkystės, finansavimo ar peržiūros yra silpnas įrodymas.

Clarysec įmonės Informacijos saugumo politika tai aiškiai nustato:

„ISVS turi apimti apibrėžtas taikymo srities ribas, rizikos vertinimo metodiką, išmatuojamus tikslus ir dokumentuotas kontrolės priemones, pagrįstas Taikomumo pareiškime (SoA).“

Šaltinis: Informacijos saugumo politika, Politikos įgyvendinimo reikalavimai, politikos punktas 6.1.2. Informacijos saugumo politika

Ta pati politika nustato įrodymų lūkestį:

„Visos įgyvendintos kontrolės priemonės turi būti audituojamos, pagrįstos dokumentuotomis procedūromis ir saugomais veikimo įrodymais.“

Šaltinis: Informacijos saugumo politika, Politikos įgyvendinimo reikalavimai, politikos punktas 6.6.1.

ISO 27001:2022 6.1.1–6.1.3 punktai toliau reikalauja rizikos vertinimo, rizikos tvarkymo, Taikomumo pareiškimo, liekamosios rizikos patvirtinimo ir rizikos savininko atskaitomybės. 6.2 punktas reikalauja išmatuojamų tikslų. 7.5, 9.1, 9.2, 9.3 ir 10.2 punktai reikalauja dokumentuotos informacijos, stebėsenos, vidaus audito, vadovybės peržiūros ir korekcinių veiksmų.

GDPR Article 32 kontekste tai sukuria pagrįstą struktūrą.

ISO/IEC 27005:2022 sustiprina šią struktūrą. Jis rekomenduoja organizacijoms nustatyti reikalavimus iš ISO 27001:2022 Annex A, reglamentų, sutarčių, sektoriaus standartų, vidaus taisyklių ir esamų kontrolės priemonių, o tada įtraukti juos į rizikos vertinimą ir tvarkymą. Jis taip pat reikalauja rizikos kriterijų ir priėmimo kriterijų, kurie įvertintų teisinius, reglamentavimo, veiklos, tiekėjų, technologijų ir žmogiškuosius veiksnius, įskaitant privatumą.

Clarysec Rizikos valdymo politika tiesiogiai suderinta:

„Formalus rizikos valdymo procesas turi būti palaikomas pagal ISO/IEC 27005 ir ISO 31000, apimant rizikų identifikavimą, analizę, įvertinimą, tvarkymą, stebėseną ir komunikaciją.“

Šaltinis: Rizikos valdymo politika, Valdysenos reikalavimai, politikos punktas 5.1. Rizikos valdymo politika

MVĮ atveju tas pats reikalavimas tampa paprastas ir įgyvendinamas:

„Kiekviename rizikos įraše turi būti: aprašymas, tikimybė, poveikis, balas, savininkas ir tvarkymo planas.“

Šaltinis: Rizikos valdymo politika MVĮ, Valdysenos reikalavimai, politikos punktas 5.1.2. Rizikos valdymo politika MVĮ

Šis sakinys yra greitas pasirengimo auditui testas. Jei rizika neturi savininko ar tvarkymo plano, ji dar nėra įrodymams parengta rizika.

Clarysec tiltas: rizika, SoA, kontrolės priemonės ir reglamentai

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint atitiktį traktuoja kaip atsekamumo darbą. Rizikos valdymo etape Step 13 sutelktas į rizikos tvarkymo planavimą ir Taikomumo pareiškimą. Jame paaiškinama, kad organizacijos turėtų susieti kontrolės priemones su rizikomis, pridėti Annex A kontrolės priemonių nuorodas prie rizikos tvarkymo įrašų, susieti išorinius reglamentus ir gauti vadovybės patvirtinimą.

Zenith Blueprint tiesiogiai apibrėžia SoA vaidmenį:

„SoA faktiškai yra jungiamasis dokumentas: jis susieja jūsų rizikos vertinimą / tvarkymą su faktinėmis turimomis kontrolės priemonėmis. Jį pildydami taip pat dar kartą patikrinate, ar nepraleidote jokių kontrolės priemonių.“

Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Rizikos valdymo etapas, Step 13: Rizikos tvarkymo planavimas ir Taikomumo pareiškimas (SoA). Zenith Blueprint

Step 14 iš Zenith Blueprint prideda reglamentavimo kryžminio susiejimo sluoksnį. Jame organizacijoms rekomenduojama dokumentuoti, kaip GDPR, NIS2 ir DORA reikalavimai padengiami politikomis ir kontrolės priemonėmis. GDPR atveju pabrėžiama asmens duomenų apsauga rizikos vertinimuose ir tvarkymo planuose, įskaitant šifravimą kaip techninę priemonę ir reagavimą į pažeidimus kaip kontrolės aplinkos dalį. NIS2 atveju akcentuojami rizikos vertinimas, tinklo saugumo politika, prieigos kontrolė, incidentų tvarkymas ir veiklos tęstinumas. DORA atveju nurodomas IRT rizikos valdymas, reagavimas į incidentus, ataskaitų teikimas ir IRT trečiųjų šalių priežiūra.

Tai yra Clarysec metodo esmė: viena ISVS, vienas rizikų registras, vienas SoA, viena įrodymų biblioteka, keli atitikties rezultatai.

Zenith Controls: The Cross-Compliance Guide Zenith Controls padeda organizacijoms naudoti ISO/IEC 27002:2022 ISO/IEC 27002:2022 kontrolės temas kaip kryžminės atitikties atramas. GDPR Article 32 atveju svarbiausios atramos dažnai apima Privacy and Protection of PII, kontrolę 5.34; Independent Review of Information Security, kontrolę 5.35; ir Use of Cryptography, kontrolę 8.24.

NIS2 paverčia TOMs valdybos lygmens kibernetinio saugumo klausimu

Daugelis organizacijų GDPR TOMs laiko privatumo komandos atsakomybe. NIS2 pakeičia šį pokalbį.

NIS2 taikoma daugeliui vidutinių ir didelių subjektų nurodytuose sektoriuose, o kai kuriais atvejais – nepriklausomai nuo dydžio. Apimami skaitmeniniai ir technologijų sektoriai apima debesijos paslaugų teikėjus, duomenų centrų teikėjus, turinio pristatymo tinklus, DNS paslaugų teikėjus, TLD registrus, patikimumo užtikrinimo paslaugų teikėjus, viešųjų elektroninių ryšių teikėjus, valdomų paslaugų teikėjus, valdomų saugumo paslaugų teikėjus, internetines prekyvietes, paieškos sistemas ir socialinių tinklų platformas. Taikymas SaaS ir technologijų MVĮ priklauso nuo sektoriaus, dydžio, valstybės narės priskyrimo ir sisteminio ar tarpvalstybinio poveikio.

NIS2 Article 20 nustato kibernetinio saugumo atsakomybę valdymo organams. Jie turi patvirtinti kibernetinio saugumo rizikos valdymo priemones, prižiūrėti jų įgyvendinimą ir dalyvauti mokymuose. Esminiams subjektams gali būti skiriamos administracinės baudos, siekiančios bent 10 mln. EUR arba bent 2 procentus pasaulinės metinės apyvartos. Svarbiems subjektams gali būti skiriamos baudos, siekiančios bent 7 mln. EUR arba bent 1,4 procento.

NIS2 Article 21 yra tiesiogiai svarbus Article 32 TOMs, nes reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių. Šios priemonės turi atsižvelgti į technikos pažangą, Europos ir tarptautinius standartus, sąnaudas, ekspoziciją, dydį, tikimybę, sunkumą ir socialinį ar ekonominį poveikį. Reikalaujamos sritys apima rizikos analizę, saugumo politikas, incidentų tvarkymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir kūrimą, pažeidžiamumų tvarkymą, veiksmingumo vertinimą, kibernetinę higieną, mokymus, kriptografiją, žmogiškųjų išteklių saugumą, prieigos kontrolę, turto valdymą, MFA arba tęstinį autentifikavimą ir saugią komunikaciją, kai tinkama.

NIS2 Article 23 prideda etapais vykdomą pranešimą apie incidentus: ankstyvąjį perspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas, tarpinius atnaujinimus, kai jų prašoma, ir galutinę ataskaitą ne vėliau kaip per vieną mėnesį po 72 valandų pranešimo. Jei asmens duomenų saugumo pažeidimas taip pat kvalifikuojamas kaip reikšmingas NIS2 incidentas, jūsų įrodymų failas turi pagrįsti tiek privatumo, tiek kibernetinio saugumo pranešimų sprendimus.

DORA pakelia finansinio atsparumo ir IRT teikėjų kartelę

DORA taikoma nuo 2025 m. sausio 17 d. ir sukuria finansų sektoriaus taisyklių rinkinį skaitmeniniam operaciniam atsparumui. Ji apima IRT rizikos valdymą, pranešimą apie reikšmingus su IRT susijusius incidentus, operacinio atsparumo testavimą, keitimąsi informacija apie kibernetines grėsmes ir pažeidžiamumus, IRT trečiųjų šalių riziką, sutartinius reikalavimus IRT teikėjams, kritinių IRT trečiųjų šalių paslaugų teikėjų priežiūrą ir priežiūrinę kontrolę.

Finansiniams subjektams, taip pat nustatytiems pagal nacionalines NIS2 taisykles, DORA veikia kaip sektoriui skirtas Sąjungos teisės aktas persidengiantiems kibernetinio saugumo rizikos valdymo ir incidentų pranešimo įpareigojimams. Praktikoje į taikymo sritį patenkantys finansiniai subjektai turėtų teikti pirmenybę DORA toms persidengiančioms sritims, kartu palaikydami koordinavimą su NIS2 kompetentingomis institucijomis ir CSIRT, kai aktualu.

GDPR Article 32 įrodymams DORA svarbi dviem aspektais. Pirma, finansinių technologijų įmonės gali tiesiogiai patekti į taikymo sritį kaip finansiniai subjektai, įskaitant kredito įstaigas, mokėjimo įstaigas, sąskaitos informacijos paslaugų teikėjus, elektroninių pinigų įstaigas, investicines įmones, kriptoturto paslaugų teikėjus, prekybos vietas ir sutelktinio finansavimo paslaugų teikėjus. Antra, SaaS, debesijos, duomenų, programinės įrangos ir valdomų paslaugų teikėjus finansiniai klientai gali laikyti IRT trečiųjų šalių paslaugų teikėjais, nes DORA plačiai apibrėžia IRT paslaugas.

DORA Article 5 reikalauja IRT rizikos valdymo valdysenos ir vidaus kontrolės priemonių, kai valdymo organas apibrėžia, tvirtina, prižiūri ir išlieka atsakingas už IRT rizikos tvarką. Article 6 reikalauja dokumentuotos IRT rizikos valdymo sistemos, įskaitant strategijas, politikas, procedūras, IRT protokolus ir priemones informacijai bei IRT turtui apsaugoti. Article 17 reikalauja su IRT susijusių incidentų valdymo proceso, apimančio aptikimą, valdymą, pranešimą, registravimą, pagrindinę priežastį, ankstyvojo perspėjimo indikatorius, klasifikavimą, vaidmenis, komunikaciją, eskalavimą ir reagavimą. Article 19 reikalauja, kad apie reikšmingus su IRT susijusius incidentus būtų pranešama kompetentingoms institucijoms.

DORA Articles 28 and 30 IRT trečiųjų šalių riziką paverčia reglamentuojama kontrolės sritimi. Finansiniai subjektai lieka atsakingi už atitiktį naudodami IRT paslaugas. Jiems reikia trečiųjų šalių rizikos strategijos, sutarčių registrų, kritiškumo vertinimų, deramo rūpestingumo, koncentracijos rizikos peržiūros, audito ir patikrinimo teisių, sutarties nutraukimo sąlygų, pasitraukimo strategijų ir sutartinių nuostatų, apimančių duomenų vietas, prieinamumą, autentiškumą, vientisumą, konfidencialumą, pagalbą incidentų metu, atkūrimą, paslaugų lygius ir bendradarbiavimą su institucijomis.

Article 32 kontekste tai reiškia, kad tiekėjai yra TOMs failo dalis. Negalite įrodyti tvarkymo saugumo, jei kritiniai tvarkytojai, debesijos platformos, analitikos teikėjai, pagalbos įrankiai ir IRT teikėjai nėra kontroliuojami.

Praktinis vienos savaitės Article 32 įrodymų sukūrimas

Stiprus įrodymų failas prasideda nuo vieno aiškaus rizikos scenarijaus.

Naudokite šį pavyzdį: „Neautorizuota prieiga prie klientų asmens duomenų produkcinėje taikomojoje programoje.“

Sukurkite arba atnaujinkite rizikos įrašą. Įtraukite aprašymą, tikimybę, poveikį, balą, savininką ir tvarkymo planą. Savininku paskirkite inžinerijos vadovą, saugumo vadovą arba lygiavertį atskaitingą vaidmenį. Tikimybę įvertinkite pagal prieigos modelį, išorinį atakos paviršių, žinomus pažeidžiamumus ir ankstesnius incidentus. Poveikį įvertinkite pagal asmens duomenų apimtį, jautrumą, klientų sutartis, GDPR pasekmes ir galimą NIS2 arba DORA paslaugų poveikį.

Pasirinkite tvarkymo priemones, tokias kaip MFA privilegijuotai prieigai, vaidmenimis grindžiama prieigos kontrolė, ketvirtinės prieigos peržiūros, saugomų duomenų šifravimas, TLS, pažeidžiamumų skenavimas, žurnalavimas, perspėjimai, saugios atsarginės kopijos, reagavimo į incidentus procedūros ir duomenų maskavimas neprodukcinėse aplinkose.

Tada susiekite riziką su SoA. Pridėkite ISO/IEC 27002:2022 nuorodas, tokias kaip 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 ir 8.10 Information Deletion, kai taikoma. Pridėkite pastabas, parodančias, kaip šios kontrolės priemonės palaiko GDPR Article 32, NIS2 Article 21 ir DORA IRT rizikos valdymą, kai aktualu.

Reglamentavimo susiejimui išlaikykite tikslius kontrolės priemonių pavadinimus ir nekurkite dirbtinio lygiavertiškumo.

Dabar sukurkite įrodymų aplanką. Clarysec MVĮ Audito ir atitikties stebėsenos politika pateikia paprastą taisyklę:

„Visi įrodymai turi būti saugomi centralizuotame audito aplanke.“

Šaltinis: Audito ir atitikties stebėsenos politika MVĮ, Politikos įgyvendinimo reikalavimai, politikos punktas 6.2.1. Audito ir atitikties stebėsenos politika MVĮ

Šiam vienam rizikos scenarijui aplanke turėtų būti:

Prieigos įrodymai neturėtų apsiriboti ekrano kopijomis. Prieigos kontrolės politika MVĮ prideda naudingą operacinį reikalavimą:

„IT vadovas turi dokumentuoti peržiūros rezultatus ir korekcinius veiksmus.“

Šaltinis: Prieigos kontrolės politika MVĮ, Valdysenos reikalavimai, politikos punktas 5.5.3. Prieigos kontrolės politika MVĮ

Atsarginių kopijų įrodymai turi pagrįsti atkuriamumą, o ne tik sėkmingai įvykdytas užduotis. Atsarginių kopijų ir atkūrimo politika MVĮ nustato:

„Atkūrimo testai atliekami bent kartą per ketvirtį, o rezultatai dokumentuojami atkuriamumui patikrinti.“

Šaltinis: Atsarginių kopijų ir atkūrimo politika MVĮ, Valdysenos reikalavimai, politikos punktas 5.3.3. Atsarginių kopijų ir atkūrimo politika MVĮ

Tai sukuria pilną įrodymų ciklą: reglamentas sukuria reikalavimą, rizika paaiškina, kodėl jis svarbus, SoA parenka kontrolės priemonę, politika apibrėžia veikimą, o saugomi įrodymai patvirtina, kad kontrolės priemonė veikia.

Kontrolės priemonės praktikoje: kaip politiką paversti veikimo įrodymais

Zenith Blueprint Controls in Action etape Step 19 sutelktas į techninį patikrinimą. Jame rekomenduojama peržiūrėti galinių įrenginių saugumo atitiktį, tapatybės ir prieigos valdymą, autentifikavimo konfigūracijas, pirminio kodo valdymo saugumą, pajėgumus ir prieinamumą, pažeidžiamumų ir pataisų valdymą, saugius bazinius nustatymus, apsaugą nuo kenkėjiškos programinės įrangos, ištrynimą ir duomenų minimizavimą, maskavimą ir testavimo duomenis, DLP, atsarginių kopijų kūrimą ir atkūrimą, perteklinimą, žurnalų tvarkymą ir stebėseną bei laiko sinchronizavimą.

GDPR Article 32 TOMs atveju Step 19 yra vieta, kur abstrakti kontrolės priemonių kalba tampa įrodymais. Stiprus įrodymų failas turėtų parodyti, kad:

• Galinių įrenginių šifravimas įjungtas ir stebimas.
• Privilegijuoti naudotojai naudoja MFA.
• Priimamų, perkeliamų ir išeinančių darbuotojų procesai suderinti su žmogiškųjų išteklių įrašais.
• Paslaugų paskyros dokumentuotos ir apribotos.
• Kodo saugykloms taikoma prieigos kontrolė ir atliekamas paslapčių skenavimas.
• Pažeidžiamumų skenavimas atliekamas, o taisomieji veiksmai sekami iki užbaigimo.
• Produkciniai duomenys nėra neformaliai kopijuojami į testavimo aplinkas.
• Saugus ištrynimas ir saugojimo politika taikomi praktikoje.
• DLP perspėjimai peržiūrimi.
• Atsarginių kopijų atkūrimo testai įrodo atkuriamumą.
• Žurnalai centralizuoti, saugomi ir peržiūrimi.
• Laiko sinchronizavimas palaiko patikimą incidentų tyrimą.

Svarbiausia – susiejimas. Pataisų ataskaita be rizikos, politikos ir SoA nuorodos yra IT artefaktas. Pataisų ataskaita, susieta su GDPR Article 32, NIS2 Article 21, DORA IRT rizikos valdymu ir ISO 27001:2022 rizikos tvarkymo planu, yra auditui tinkamas įrodymas.

Vienas įrodymų failas, keli audito požiūriai

Tie patys TOMs įrodymai skirtingų suinteresuotųjų šalių bus skaitomi skirtingai. Privatumo peržiūrą atliekantis asmuo gali sutelkti dėmesį į asmens duomenis, būtinumą, proporcingumą ir atskaitomybę. ISO 27001 auditorius gali sutelkti dėmesį į taikymo sritį, rizikos tvarkymą, SoA ir veikimo įrodymus. NIS2 institucija gali sutelkti dėmesį į vadovybės priežiūrą, Article 21 priemones ir pasirengimą Article 23 pranešimams. DORA priežiūros institucija arba finansų klientas gali sutelkti dėmesį į IRT rizikos valdyseną, atsparumo testavimą ir priklausomybes nuo trečiųjų šalių.

Clarysec šiam pervedimui naudoja Zenith Controls kaip kryžminės atitikties vadovą.

Tai apsaugo nuo dubliuojamo atitikties darbo. Užuot rengę atskirus įrodymų rinkinius GDPR, NIS2 ir DORA, sukurkite vieną kontrolės įrodymų failą ir pažymėkite kiekvieną elementą pagal įpareigojimus, kuriuos jis palaiko.

Dažnos Article 32 TOMs programų spragos

Dažniausia spraga yra kontrolės priemonių našlaičiavimas. Įmonė turi kontrolės priemonę, pavyzdžiui, šifravimą, bet negali paaiškinti, kurią riziką ji tvarko, kuri politika jos reikalauja, kas ją valdo arba kaip ji peržiūrima.

Antroji spraga – silpni tiekėjų įrodymai. Pagal GDPR svarbūs tvarkytojai ir subtvarkytojai. Pagal NIS2 tiekimo grandinės saugumas yra kibernetinio saugumo rizikos valdymo dalis. Pagal DORA IRT trečiųjų šalių rizika yra reglamentuojama sritis su registrais, deramu rūpestingumu, sutartinėmis apsaugos priemonėmis, audito teisėmis ir pasitraukimo planavimu. Tiekėjų skaičiuoklės nepakanka, jei kritinės priklausomybės nėra įvertintos pagal riziką ir kontroliuojamos.

Trečioji spraga – incidentų įrodymai. Organizacijos dažnai turi reagavimo į incidentus planą, bet neturi įrodymų, kad klasifikavimas, eskalavimas, pranešimas institucijoms ir komunikacija su klientais buvo testuoti. NIS2 ir DORA čia padidina lūkesčius, o GDPR asmens duomenų saugumo pažeidimo vertinimas turi būti integruotas į tą pačią darbo eigą.

Ketvirtoji spraga – atsarginių kopijų įrodymai. Sėkmingas atsarginės kopijos darbas neįrodo atkuriamumo. Dokumentuotas atkūrimo testas įrodo.

Penktoji spraga – vadovybės peržiūra. Article 32 TOMs turi būti proporcingos rizikai. Jei vadovybė niekada neperžiūri rizikų, incidentų, tiekėjų klausimų, biudžeto, audito išvadų ir liekamosios rizikos, proporcingumą tampa sunku įrodyti.

Galutinis auditui parengtas priemonių rinkinys

Zenith Blueprint Audit, Review and Improvement etapo Step 30 pateikia galutinį pasirengimo kontrolinį sąrašą. Jis apima ISVS taikymo sritį ir kontekstą, pasirašytą informacijos saugumo politiką, rizikos vertinimo ir tvarkymo dokumentus, SoA, Annex A politikas ir procedūras, mokymų įrašus, operacinius įrašus, vidaus audito ataskaitą, korekcinių veiksmų žurnalą, vadovybės peržiūros protokolus, nuolatinio tobulinimo įrodymus ir atitikties įpareigojimų įrašus.

Clarysec įmonės Audito ir atitikties stebėsenos politika nurodo šios disciplinos tikslą:

„Generuoti dokumentuotus įrodymus ir audito pėdsaką, pagrindžiant reglamentavimo institucijų paklausimus, teisinius procesus ar klientų patikinimo prašymus.“

Šaltinis: Audito ir atitikties stebėsenos politika, Tikslai, politikos punktas 3.4. Audito ir atitikties stebėsenos politika

Brandus Article 32 TOMs įrodymų failas turėtų apimti:

Tolesni veiksmai: kurkite Article 32 TOMs įrodymus su Clarysec

Jei turite pagrįsti GDPR Article 32 technines ir organizacines priemones, nepradėkite nuo atsitiktinių ekrano kopijų rinkimo. Pradėkite nuo atsekamumo.

1. Apibrėžkite ISVS taikymo sritį ir asmens duomenų tvarkymo ribas.
2. Nustatykite GDPR, NIS2, DORA, sutartinius ir klientų reikalavimus.
3. Sukurkite rizikos kriterijus naudodami ISO/IEC 27005:2022 ir vadovybės patvirtintą rizikos apetitą.
4. Sukurkite arba atnaujinkite rizikų registrą.
5. Susiekite kiekvieną tvarkymo priemonę su ISO 27001:2022 kontrolės priemonėmis ir SoA.
6. Naudokite Zenith Controls, kad kryžmiškai susietumėte privatumo, kriptografijos, tiekėjų, incidentų ir nepriklausomos peržiūros kontrolės priemones pagal atitikties lūkesčius.
7. Vadovaukitės Zenith Blueprint Step 13 ir Step 14, kad susietumėte rizikas, kontrolės priemones ir reglamentavimo įpareigojimus.
8. Naudokite Zenith Blueprint Step 19 techninėms kontrolės priemonėms veikimo metu patikrinti.
9. Naudokite Zenith Blueprint Step 30 galutiniam auditui tinkamam įrodymų failui surinkti.
10. Visus įrodymus saugokite centralizuotai, žymėkite juos pagal riziką ir kontrolės temą, o korekcinius veiksmus laikykite matomus.

Clarysec gali padėti jums paversti GDPR Article 32 iš neapibrėžto atitikties įpareigojimo į pagrįstą, rizika grindžiamą įrodymų sistemą, suderintą su ISO 27001:2022, NIS2 ir DORA.

Pradėkite nuo Zenith Blueprint, sustiprinkite jį Clarysec politikomis ir naudokite Zenith Controls, kad kiekviena TOM būtų atsekama, testuojama ir tinkama auditui.