RoPA ir duomenų srautų atvaizdavimas GDPR, NIS2 ir DORA kontekste

Antradienis, 09:10. CISO, duomenų apsaugos pareigūnas (DPO), pirkimų vadovas ir veiklos operacijų direktorius dalyvauja tame pačiame vaizdo skambutyje, tačiau remiasi ne tais pačiais įrodymais.

DPO turi Tvarkymo veiklos įrašus (RoPA), kuriuose nurodyta klientų registracija, darbuotojų darbo užmokestis, pagalbos užklausos ir rinkodaros analizė. CISO turi debesijos turto apskaitą. Pirkimų funkcija turi tiekėjų sutartis. Veiklos padalinys turi veiklos tęstinumo skaičiuoklę. Finansų funkcija turi DORA informacijos registrą. Niekas negali atsakyti į paprastą priežiūros institucijos klausimą, kuriam reikia bendro vaizdo:

Jei sutriktų ši mokėjimų klientų registracijos paslauga, kurios sistemos, tiekėjai, duomenų kategorijos, subtvarkytojai, tarpvalstybiniai duomenų perdavimai ir kritinės verslo funkcijos būtų paveikti?

Šis klausimas yra tikrasis 2026 m. atitikties testas.

GDPR vis dar reikalauja atskaitingų Article 30 įrašų. NIS2 kibernetinį saugumą pavertė valdymo organų atskaitomybės klausimu esminiams ir svarbiems subjektams. DORA reikalauja, kad finansų subjektai pagrįstų IRT priklausomybes, kritines ar svarbias funkcijas, susitarimus su IRT trečiųjų šalių paslaugų teikėjais, incidentų klasifikavimą ir atsparumo testavimą. ISO/IEC 27001:2022 suteikia valdymo sistemos struktūrą, leidžiančią visa tai sujungti, tačiau tik tada, kai RoPA ir duomenų srautų atvaizdavimas laikomi gyvais valdysenos įrodymais, o ne privatumo komandos skaičiuoklėmis.

Clarysec tą patį modelį matome sparčiai augančiose SaaS, finansinių technologijų, debesijos, MSP ir B2B technologijų įmonėse. Jos turi pakankamai dokumentacijos, kad atsakytų į klausimyną, bet nepakankamai susietų įrodymų, kad atlaikytų priežiūros institucijos peržiūrą, kibernetinį incidentą, tiekėjo sutrikimą ar vidaus auditą. Problema retai būna informacijos trūkumas. Dažniausiai trūksta ryšių tarp informacijos.

Sprendimas – RoPA ir duomenų srautų atvaizdavimą paversti bendru įrodymų sluoksniu privatumui, kibernetiniam atsparumui, tiekėjų valdymui, debesijos valdysenai ir veiklos tęstinumui.

Kodėl RoPA ir duomenų srautų atvaizdavimas tapo 2026 m. valdysenos klausimu

RoPA anksčiau dažnai buvo laikoma privatumo artefaktu. Duomenų srautų žemėlapiai dažnai būdavo parengiami atliekant DPIA, debesijos migraciją ar saugumo architektūros peržiūrą, o vėliau paliekami senti. Toks požiūris nebeveikia.

GDPR plačiai taikomas asmens duomenų tvarkymui ES įsisteigusio subjekto veiklos kontekste, taip pat daugeliui ne ES duomenų valdytojų ar duomenų tvarkytojų, siūlančių prekes ar paslaugas asmenims ES arba stebinčių jų elgesį. Asmens duomenys apima informaciją, susijusią su nustatytu arba nustatomu asmeniu. Tvarkymas apima rinkimą, saugojimą, naudojimą, atskleidimą, apribojimą, ištrynimą ir sunaikinimą. Duomenų valdytojas nustato tikslus ir priemones, o duomenų tvarkytojas veikia duomenų valdytojo vardu.

Todėl RoPA nėra tik duomenų bazių sąrašas. Tai verslo tikslų, duomenų kategorijų, vaidmenų, gavėjų, saugojimo terminų, apsaugos priemonių ir tarptautinių priklausomybių įrašas.

NIS2 prideda paslaugų atsparumo perspektyvą. Į jos taikymo sritį patenka daug vidutinio dydžio ir didesnių organizacijų itin kritiniuose ir kituose kritiniuose sektoriuose, įskaitant skaitmeninę infrastruktūrą, debesijos paslaugų teikėjus, duomenų centrų paslaugų teikėjus, turinio pristatymo tinklus, patikimumo užtikrinimo paslaugų teikėjus, viešųjų elektroninių ryšių teikėjus, valdomų paslaugų teikėjus ir valdomo saugumo paslaugų teikėjus. I priedas taip pat apima bankininkystę ir finansų rinkų infrastruktūras. Kai kuriems subjektams reikalavimai gali būti taikomi nepriklausomai nuo dydžio, įskaitant tam tikrus DNS, TLD, patikimumo užtikrinimo paslaugų ir viešųjų ryšių teikėjus, taip pat subjektus, kurių sutrikimas galėtų reikšmingai paveikti visuomenės saugą, visuomenės sveikatą, sisteminę riziką arba kritinę visuomeninę ir ekonominę veiklą.

NIS2 Article 21 reikalauja proporcingų techninių, operacinių ir organizacinių priemonių tinklų ir informacinėms sistemoms, naudojamoms operacijoms vykdyti ar paslaugoms teikti. Minimalios sritys apima rizikos analizę, saugumo politikas, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų kūrimą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, personalo saugumą, prieigos kontrolę, turto valdymą ir autentifikavimą.

NIS2 subjektui RoPA be paslaugų priklausomybių vaizdo yra neišsami. Reikšmingas incidentas turi būti suprantamas pagal paslaugos poveikį, veiklos sutrikimą, paveiktus gavėjus, tiekėjus ir tarpvalstybines pasekmes.

DORA tą patį aspektą finansų subjektams dar labiau sukonkretina. Ji taikoma nuo 2025 m. sausio 17 d. ir nustato vienodus reikalavimus IRT rizikos valdymui, pranešimams apie reikšmingus su IRT susijusius incidentus, skaitmeninio operacinio atsparumo testavimui, kibernetinių grėsmių ir pažeidžiamumų informacijos mainams, IRT trečiųjų šalių rizikai ir sutartiniams susitarimams su IRT trečiųjų šalių paslaugų teikėjais. DORA IRT paslaugas apibrėžia plačiai – kaip skaitmenines ir duomenų paslaugas, nuolat teikiamas per IRT sistemas. Kritinė ar svarbi funkcija apibrėžiama kaip tokia, kurios sutrikimas reikšmingai pablogintų finansinius rezultatus, paslaugų tęstinumą ar atitikties įsipareigojimus.

Finansų subjektams, kurie pagal nacionalinį NIS2 perkėlimą taip pat identifikuojami kaip NIS2 subjektai, DORA laikoma sektoriniu Sąjungos teisės aktu, nustatančiu lygiaverčius IRT rizikos, incidentų pranešimo, testavimo, informacijos mainų ir trečiųjų šalių rizikos reikalavimus. Praktikoje finansinių technologijų įmonė negali kurti vieno įrodymų rinkinio privatumui, kito – DORA, o trečio – NIS2. Jai reikia vieno duomenų valdysenos sluoksnio, kuriame matomos priklausomybės.

Tas sluoksnis yra RoPA kartu su duomenų srautų atvaizdavimu.

ISO/IEC 27001:2022 yra pagrindas

ISO/IEC 27001:2022 yra pritaikytas būtent tokiai integracijai. Jis nustato mastelio keitimui tinkamą informacijos saugumo valdymo sistemą (ISVS), skirtą konfidencialumui, vientisumui ir prieinamumui išsaugoti taikant rizikos valdymą. Standartas skirtas integruoti į organizacijos procesus ir pritaikyti pagal organizacijos poreikius, dydį ir struktūrą.

Pradžios taškas nėra diagramų braižymo įrankis. Pradžios taškas yra taikymo sritis.

ISO/IEC 27001:2022 4.1–4.4 punktai reikalauja, kad organizacija apibrėžtų kontekstą, suinteresuotąsias šalis, ISVS taikymo sritį ir sąveikaujančius procesus. Taikymo sritis turi atsižvelgti į teisinius, reguliavimo ir sutartinius įsipareigojimus, taip pat sąsajas ir priklausomybes tarp vidaus veiklų ir kitų organizacijų vykdomų veiklų. RoPA ir duomenų srautų atvaizdavimo kontekste tai reiškia, kad jūsų ISVS taikymo sritis turi aiškiai apimti išorines debesijos platformas, mokėjimų tvarkytojus, tapatybės teikėjus, pagalbos įrankius, valdomo saugumo paslaugų teikėjus ir verslui kritines SaaS integracijas.

5.1–5.3 punktai nustato vadovybės atskaitomybę už politiką, išteklius, vaidmenų priskyrimą ir ataskaitų teikimą. Tai atitinka NIS2 Article 20 kryptį, pagal kurią valdymo organai turi patvirtinti kibernetinio saugumo rizikos valdymo priemones, prižiūrėti jų įgyvendinimą ir dalyvauti mokymuose. Tai taip pat dera su DORA Article 5, kuriame valdymo organui priskiriama galutinė atsakomybė už IRT riziką ir politikų, atsparumo strategijos, tęstinumo planų, audito planų, IRT trečiųjų šalių paslaugų bei reikšmingų incidentų pranešimo kanalų priežiūrą.

6.1.1–6.1.3 punktai suteikia planavimo mechanizmą: identifikuoti konfidencialumo, vientisumo ir prieinamumo rizikas, priskirti rizikos savininkus, išanalizuoti pasekmes ir tikimybę, pasirinkti rizikos tvarkymo parinktis, palyginti kontrolės priemones su A priedu, parengti Taikytinumo pareiškimą (SoA) ir gauti rizikos savininko patvirtinimą.

Čia RoPA tampa operacinė. Kiekviena tvarkymo veikla ir duomenų srautas turi būti susieti su rizikomis, kontrolės priemonėmis, tiekėjais, turtu ir kritinėmis paslaugomis. Jei taip nėra, RoPA liks privatumo apskaita, kuri negali pagrįsti reagavimo į incidentus, atsparumo testavimo ar tiekėjų rizikos sprendimų.

Clarysec Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas tai paverčia praktika Rizikos valdymo etape, 9 žingsnyje „Turto, grėsmių ir pažeidžiamumų identifikavimas“:

Kiekvienam turtui įrašykite pagrindinę informaciją: pavadinimą / aprašymą, savininką, vietą ir klasifikaciją (jautrumą). Pavyzdžiui, turtas gali būti „Klientų duomenų bazė – priklauso IT skyriui – priglobta AWS – joje yra asmens ir finansinių duomenų (didelis jautrumas)“.

Tas pats 9 žingsnis prideda pagrindinę atitikties įžvalgą: asmens duomenų turtas turi būti pažymėtas kaip aktualus GDPR, o kritinių paslaugų turtas turi būti pažymėtas dėl galimo NIS2 taikymo, jei organizacija veikia reguliuojamame sektoriuje. Tai yra jungtis tarp RoPA, turto apskaitos ir kritinių paslaugų priklausomybių atvaizdavimo.

Kas turi būti auditui tinkamoje RoPA

Stipri RoPA neturi būti sudėtinga, tačiau ji turi būti susieta.

GDPR Article 5 reikalauja, kad asmens duomenys būtų tvarkomi teisėtai, sąžiningai ir skaidriai, renkami nustatytais ir teisėtais tikslais, apsiribotų tuo, kas būtina, būtų tikslūs, saugomi ne ilgiau nei reikia ir apsaugomi tinkamomis techninėmis ir organizacinėmis priemonėmis. Article 5(2) reikalauja, kad duomenų valdytojas būtų atsakingas už atitiktį ir galėtų ją įrodyti.

Article 6 reikalauja teisinio pagrindo, pavyzdžiui, sutikimo, sutarties vykdymo būtinybės, teisinės prievolės, gyvybinių interesų, viešojo intereso užduoties arba teisėtų interesų. Jei tvarkymas vykdomas nauju tikslu, suderinamumas turi būti įvertintas atsižvelgiant į pradinį ir naują tikslą, rinkimo kontekstą, jautrumą, pasekmes asmenims ir apsaugos priemones, tokias kaip šifravimas ar pseudonimizavimas. Article 9 nustato griežtesnes taisykles specialių kategorijų asmens duomenims, įskaitant sveikatos duomenis, biometrinius duomenis, naudojamus unikaliam identifikavimui, ir kitas jautrias kategorijas.

Clarysec MVĮ politikų rinkinys tai paverčia operaciniu reikalavimu. Duomenų apsaugos ir privatumo politika - MVĮ nurodo:

Privatumo koordinatorius privalo tvarkyti visų asmens duomenų tvarkymo veiklų registrą, įskaitant duomenų kategorijas, tikslą, teisinį pagrindą ir saugojimo terminus.

Tai pateikta Valdysenos reikalavimų skyriaus 5.2.1 punkte. Didesnėms organizacijoms Clarysec Duomenų apsaugos ir privatumo politika atsakomybę priskiria tiesiogiai:

Tvarko Tvarkymo veiklos įrašus (RoPA) pagal GDPR Article 30.

Ši formuluotė yra iš Vaidmenų ir atsakomybių 4.2.2 punkto. Praktinė žinutė paprasta: RoPA savininkystė turi būti priskirta. Ji negali būti bešeimininkė atitikties skaičiuoklė.

2026 m. poreikiams parengta RoPA turėtų apimti šiuos laukus.

Paskutinės eilutės perkelia RoPA iš privatumo dokumentacijos į kibernetinio atsparumo įrodymus. Be sistemų, tiekėjų, vietų, kritiškumo ir kontrolės priemonių RoPA gali atitikti siaurą Article 30 kontrolinį sąrašą, bet žlugti vos tik incidentui, paslaugos sutrikimui ar priežiūros institucijos peržiūrai prireikia poveikio analizės.

Duomenų srautų atvaizdavimas susieja privatumą, debesiją ir kritines paslaugas

Jei RoPA atsako į klausimą „koks tvarkymas vyksta ir kodėl“, duomenų srautų žemėlapis atsako į klausimą „kur juda duomenys, kas prie jų prisiliečia, kas juos apsaugo ir kas sutrinka, jei srautas sustoja“.

Clarysec Duomenų maskavimo ir pseudonimizavimo politika - MVĮ reikalavimą suformuluoja nedviprasmiškai:

Turi būti sukurtas duomenų srautų žemėlapis.

Tai pateikta Valdysenos reikalavimų 5.1.1.1 punkte. Įmonėms skirta versija, Duomenų maskavimo ir pseudonimizavimo politika, 5.2.1 punkte išplečia lūkestį:

Tvarkyti aktualią sistemų ir duomenų srautų, susijusių su jautriais duomenimis, apskaitą.

5.2.2 punktas papildo:

Atvaizduoti, kur ir kaip duomenys transformuojami, bendrinami arba pasiekiami skirtingose aplinkose.

Auditoriai ir reguliuotojai neieško meniškų diagramų. Jie nori suprasti transformacijas, prieigos kelius, bendrinimą, aplinkas ir apsaugos priemones.

Zenith Blueprint skyriuje „Kontrolės priemonės praktikoje“, 22 žingsnyje „Organizacinės kontrolės priemonės 5.1–5.18“, informacijos perdavimo gairės paaiškina, kad organizacijos turi apibrėžti leidžiamus perdavimo būdus, suderinti juos su klasifikacija ir užtikrinti, kad šalys suprastų savo vaidmenis ir pareigas. Pateikiami pavyzdžiai: šifruotas el. paštas, saugūs portalai, SFTP, taikomųjų programų sąsajos ir fizinis pristatymas su šifravimu. Taip pat pažymima, kad tarpvalstybinis asmens duomenų perdavimas turi atitikti privatumo ir teisinius įsipareigojimus, o ne vien vidaus pageidavimus.

Tas pats žingsnis informacijos perdavimą susieja su klasifikavimu ir ženklinimu, duomenų nutekėjimo prevencija, tiekėjų santykiais ir kriptografija. Tai sukuria praktinį duomenų srautų atvaizdavimo modelį:

1. Identifikuokite šaltinio sistemą, pavyzdžiui, CRM, mokėjimų platformą, HRIS arba pagalbos tarnybą.
2. Identifikuokite duomenų kategoriją, įskaitant asmens duomenis, finansinius duomenis, darbuotojų duomenis, specialių kategorijų duomenis arba prisijungimo duomenis.
3. Identifikuokite perdavimo būdą, pavyzdžiui, API, SFTP, el. paštą, saugų portalą, rankinį eksportą arba atsarginių kopijų replikaciją.
4. Identifikuokite paskirties vietą, įskaitant vidinę sistemą, debesijos paslaugą, tiekėją, subtvarkytoją, duomenų saugyklą arba archyvą.
5. Identifikuokite apsaugą, pavyzdžiui, šifravimą, pseudonimizavimą, prieigos kontrolę, žurnalavimą, DLP arba sutartinį apribojimą.
6. Identifikuokite priklausomybę, įskaitant tai, ar srautas palaiko kritinę verslo funkciją, kritinę ar svarbią funkciją, esminę paslaugą arba incidentų pranešimo pareigą.

Čia ypač svarbios trys ISO/IEC 27001:2022 A priedo kontrolės priemonės. ISO/IEC 27002:2022 pateikia šių kontrolės priemonių įgyvendinimo gaires:

Clarysec Zenith Controls: kryžminės atitikties vadovas nurodo 5.9, 5.14 ir 5.34 kaip su šiuo valdysenos sluoksniu susijusias kontrolės priemones. Laikykite jas atraminėmis kontrolės priemonėmis, o tada per Taikytinumo pareiškimą susiekite jas su tiekėjų, debesijos, incidentų, tęstinumo, žurnalavimo, prieigos ir kriptografijos kontrolės priemonėmis.

Kodėl NIS2 ir DORA reikia daugiau nei privatumo registro

Dažna klaida – parengti RoPA, kuri techniniu požiūriu yra teisinga pagal GDPR, bet nenaudinga NIS2 ar DORA. Skirtumas yra paslaugos kritiškumas.

NIS2 Article 23 reikalauja, kad esminiai ir svarbūs subjektai apie reikšmingus incidentus praneštų nepagrįstai nedelsdami. Pranešimo modelis apima ankstyvą įspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas ir galutinę ataskaitą per vieną mėnesį. Reikšmingi incidentai vertinami pagal didelį veiklos sutrikimą, finansinius nuostolius arba materialinę ar nematerialinę žalą kitiems fiziniams ar juridiniams asmenims. Toks vertinimas priklauso nuo žinojimo, kurios paslaugos, gavėjai, šalys, sistemos ir tiekėjai yra paveikti.

DORA Article 17 reikalauja, kad finansų subjektai apibrėžtų ir įgyvendintų su IRT susijusių incidentų valdymo procesą, kuris aptinka ir valdo incidentus, apie juos praneša, registruoja incidentus ir reikšmingas kibernetines grėsmes, identifikuoja pagrindines priežastis, nustato ankstyvojo perspėjimo indikatorius, klasifikuoja incidentus pagal paveiktų paslaugų sunkumą ir kritiškumą, priskiria vaidmenis ir sukuria komunikacijos bei eskalavimo procedūras. Article 18 reikalauja klasifikuoti pagal paveiktus klientus ar sandorio šalis ir operacijas, trukmę ir prastovą, geografinį paplitimą, duomenų praradimą, paveikiantį prieinamumą, autentiškumą, vientisumą ar konfidencialumą, paveiktų paslaugų kritiškumą ir ekonominį poveikį.

Incidento greitai nesuklasifikuosite, jei nežinote duomenų srauto ir priklausomybių grandinės.

Clarysec Veiklos tęstinumo ir atkūrimo po katastrofos politika - MVĮ nurodo įrodymų lauką, kurio organizacijoms reikia:

prioritetinės paslaugos ir sistemos (kritinės verslo funkcijos)

Tai pateikta Valdysenos reikalavimų 5.2.1.2 punkte. Įmonėms skirta Veiklos tęstinumo ir atkūrimo po katastrofos politika 5.2.4 punkte prideda priklausomybių dimensiją:

Kritinės priklausomybės (sistemos, tiekėjai, personalas)

DORA reguliuojamoms organizacijoms tai turi būti suderinta su kritinėmis ar svarbiomis funkcijomis, IRT paslaugomis, sutartiniais susitarimais ir išėjimo strategijomis. DORA Article 28 reikalauja, kad IRT trečiųjų šalių rizika būtų valdoma kaip IRT rizikos valdymo sistemos dalis. Jis įpareigoja tvarkyti IRT paslaugų sutartinių susitarimų registrą, reikalauja ikisutartinio deramo patikrinimo ir kritiškumo, koncentracijos rizikos, tinkamumo bei interesų konfliktų vertinimo, taip pat reikalauja išėjimo strategijų IRT paslaugoms, palaikančioms kritines ar svarbias funkcijas.

DORA Article 30 nustato minimalius IRT sutarčių terminus, įskaitant paslaugų aprašymus, subtiekimo sąlygas, duomenų tvarkymo ir saugojimo vietas, duomenų apsaugą, prieigą, duomenų atkūrimą ir grąžinimą, paslaugų lygius, pagalbą incidentų atveju, bendradarbiavimą su institucijomis, nutraukimo teises, audito teises ir perėjimo ar išėjimo susitarimus.

RoPA, kuri neidentifikuoja tiekėjų, vietų, perdavimo būdų, kritiškumo ir išėjimo priklausomybių, nepagrįs DORA įrodymų.

Tiekėjų, debesijos ir subtvarkytojų atvaizdavimas yra vieta, kur įrodymai dažnai subyra

Realiose auditų situacijose RoPA trūkumai dažnai pasireiškia kaip tiekėjų trūkumai. Tvarkymo veikla nurodo „klientų pagalbą“. Duomenų srautų žemėlapis nurodo „pagalbos platformą“. Tačiau niekas negali identifikuoti prieglobos regiono, DI transkripcijos papildinio, analitikos subtvarkytojo, užklausų priedų saugojimo vietos, administratoriaus lygmens prieigos modelio ar išėjimo procedūros.

Clarysec MVĮ tiekėjų politika sukuria minimalius operacinius įrodymus. Trečiųjų šalių ir tiekėjų saugumo politika - MVĮ nurodo:

Tiekėjų registras turi būti tvarkomas ir atnaujinamas administracinio arba pirkimų kontaktinio asmens. Jame turi būti:

Tai pateikta Valdysenos reikalavimų 5.4 punkte. Debesijos politika prideda atskirą apskaitos reikalavimą. Debesijos paslaugų naudojimo politika - MVĮ nurodo:

Debesijos paslaugų registrą turi tvarkyti IT paslaugų teikėjas arba generalinis direktorius. Jame turi būti registruojama:

Tai pateikta Valdysenos reikalavimų 5.3 punkte. Įmonių priklausomybių rizikai Clarysec Tiekėjų priklausomybės rizikos valdymo politika yra konkretesnė:

Tiekėjų priklausomybės registras: VMO turi tvarkyti aktualų visų kritinių tiekėjų registrą, įskaitant tokią informaciją kaip teikiamos paslaugos / produktai; ar tiekėjas yra vienintelis šaltinis; galimi alternatyvūs tiekėjai arba pakeičiamumas; galiojančios sutarties sąlygos; ir poveikio vertinimas, jei tiekėjas sutriktų arba būtų kompromituotas. Registre turi būti aiškiai identifikuoti didelės priklausomybės tiekėjai (pvz., tie, kuriems nėra greitos alternatyvos).

Šis reikalavimas iš Įgyvendinimo reikalavimų 6.1 punkto tiksliai susieja RoPA su NIS2 tiekimo grandinės saugumu ir DORA IRT trečiųjų šalių rizika.

Zenith Blueprint skyriuje „Kontrolės priemonės praktikoje“, 23 žingsnyje „Organizacinės kontrolės priemonės 5.19–5.37“, rekomenduojama sudaryti išsamų tiekėjų sąrašą, klasifikuoti tiekėjus pagal prieigą prie sistemų, duomenų ar operacinės kontrolės, įtraukti saugumo lūkesčius į sutartis, peržiūrėti subtiekėjus, nustatyti tiekėjų pakeitimų paleidiklius ir sukurti debesijos paslaugų vertinimo procesą, apimantį duomenų vietą, prieigos modelį, žurnalavimą ir šifravimą.

Būtent tai leidžia CISO incidento metu atsakyti: „Kuri kritinė paslauga naudoja šį tiekėją, kokie duomenys buvo atskleisti, kuriuos klientus reikia informuoti, kuriam reguliuotojui gali reikėti pateikti pranešimą ir koks alternatyvus tiekėjas ar išėjimo kelias egzistuoja?“

Praktinis pavyzdys: klientų registracija finansinių technologijų įmonėje

Apsvarstykime finansinių technologijų įmonę, teikiančią skaitmeninės piniginės klientų registracijos paslaugą. Klientai įkelia tapatybės dokumentus, tiekėjas atlieka biometrinius gyvumo patikrinimus, rezultatai saugomi debesijos duomenų bazėje, o klientų pagalba užklausų valdymo įrankyje gali matyti patikrinimo būseną.

Klientų registracijos paslauga pagal DORA gali būti kritinė ar svarbi funkcija, nes sutrikimas reikšmingai paveiktų paslaugų tęstinumą ir reguliavimo įsipareigojimus. Jei įmonė veikia NIS2 sektoriuje arba teikia atitinkamas IRT paslaugas, ši paslauga taip pat gali būti kritinių paslaugų įrodymų dalis.

Naudingas žemėlapis pradedamas nuo vieno susieto įrašo.

Dabar pridėkite ISO/IEC 27001:2022 rizikos tvarkymo atsekamumą.

Zenith Blueprint Rizikos valdymo etape, 13 žingsnyje „Rizikos tvarkymo planavimas ir Taikytinumo pareiškimas“, Clarysec apibūdina SoA kaip jungiamąjį dokumentą, susiejantį rizikos vertinimą ir tvarkymą su faktinėmis kontrolės priemonėmis. Rekomenduojama susieti kontrolės priemones su rizikomis ir, kai aktualu, rizikų registre arba SoA pastabose pateikti kryžmines nuorodas į tokius reglamentus kaip GDPR, NIS2 ar DORA.

Klientų registracijos pavyzdyje rizikos scenarijus galėtų būti: „Tapatybės patikrinimo teikėjo paslaugos sutrikimas arba kompromitavimas sutrikdo klientų registraciją ir atskleidžia biometrinius tapatybės duomenis.“ Rizikos tvarkymo kontrolės priemonės galėtų apimti tiekėjų deramą patikrinimą, sutartinį pranešimą apie incidentus, šifravimą, prieigos kontrolę, žurnalavimą, atsarginių kopijų kūrimą ir atkūrimą, duomenų minimizavimą, pseudonimizavimą, stebėseną, išėjimo planavimą ir reagavimo į incidentus veiksmų planus.

SoA pastaboje galima nurodyti, kad kontrolės priemonių rinkinys palaiko GDPR atskaitomybę, NIS2 Article 21 tiekimo grandinės ir pasirengimo incidentams priemones bei DORA IRT trečiųjų šalių riziką ir kritinių funkcijų atsparumą.

Būtent to auditoriai ir ieško: atsekamumo.

Kryžminės atitikties atvaizdavimas: vienas įrodymų sluoksnis, keli klausimai

RoPA ir duomenų srautų atvaizdavimas nėra atskiri atitikties silosai. Jie palaiko bendrą klausimų rinkinį pagal GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 ir COBIT 2019.

NIST CSF 2.0 naudinga kaip struktūravimo sistema. Jos CSF profiliai palaiko esamos ir tikslinės būsenos analizę, naudojant tokius įvesties duomenis kaip politikos, rizikos prioritetai, verslo poveikio registrai, reikalavimai, standartai, praktikos, priemonės ir darbo vaidmenys. GOVERN funkcija apima teisinius, reguliavimo, sutartinius, privatumo ir pilietinių laisvių įsipareigojimus, rizikos tikslus, vadovybės atskaitomybę, vaidmenis, politiką, priežiūrą ir veiklos rezultatų peržiūrą. Tiekimo grandinės rezultatai reikalauja, kad tiekėjai būtų žinomi ir prioritetizuojami pagal kritiškumą, sutartiniai kibernetinio saugumo reikalavimai būtų integruoti, deramas patikrinimas būtų atliekamas prieš santykių pradžią, tiekėjų rizikos būtų registruojamos ir stebimos, o tiekėjai būtų įtraukti į reagavimo į incidentus ir atkūrimo planavimą.

Tai tiksliai atitinka Clarysec RoPA veiklos modelį. RoPA suteikia privatumo kontekstą. Turto apskaita suteikia techninį kontekstą. Tiekėjų ir debesijos registrai suteikia trečiųjų šalių kontekstą. BIA suteikia kritiškumo kontekstą. SoA suteikia kontrolės priemonių kontekstą.

Viena ISO/IEC 27001:2022 A priedo kontrolės priemonė taip pat gali palaikyti kelias sistemas. Kontrolės priemonė 5.14 „Informacijos perdavimas“ yra geras pavyzdys.

Tai yra Zenith Controls vertė kaip kryžminės atitikties kompaso. Jis padeda organizacijoms paaiškinti, kodėl viena kontrolės praktika palaiko kelis reguliavimo ir audito lūkesčius.

Kaip skirtingi auditoriai tikrins tą patį žemėlapį

Brandus RoPA ir duomenų srautų žemėlapis gali patenkinti kelių auditorių poreikius, tačiau kiekvienas prie jo prieis skirtingai.

ISO/IEC 27001:2022 auditorius pradės nuo taikymo srities, suinteresuotųjų šalių, rizikų, dokumentuotos informacijos ir kontrolės priemonių parinkimo. Jis klaus, ar identifikuoti teisiniai ir sutartiniai reikalavimai, ar asmens duomenys ir kritinės paslaugos patenka į ISVS taikymo sritį, ar turtas turi savininkus ir klasifikacijas, ar rizikos vertinimas įvertino konfidencialumą, vientisumą ir prieinamumą, ir ar SoA pagrindžia taikomas kontrolės priemones.

GDPR auditorius arba privatumo priežiūros institucija pradės nuo atskaitomybės. Jis tikrins, ar RoPA atspindi realų tvarkymą, ar tikslai ir teisiniai pagrindai dokumentuoti, ar specialių kategorijų duomenys identifikuoti, ar taikomi saugojimo terminai, ar gavėjai ir duomenų tvarkytojai nurodyti tiksliai, ir ar perdavimams bei saugumui taikomos tinkamos apsaugos priemonės.

NIS2 krypties auditorius vertins paslaugų poveikį. Jis klaus, kaip organizacija nustato kritines ar svarbias paslaugas, kaip vadovybė patvirtino ir prižiūri rizikos priemones, kaip vertinami tiekėjų pažeidžiamumai ir paslaugų teikėjų rizikos, kaip susieti tęstinumas ir incidentų valdymas, ir ar organizacija patikimais įrodymais gali pagrįsti 24 valandų, 72 valandų ir galutinio pranešimo terminus.

DORA auditorius vertins IRT rizikos valdyseną ir kritines ar svarbias funkcijas. Jis tikrins, ar valdymo organas patvirtino IRT rizikos sistemą ir atsparumo strategiją, ar IRT trečiųjų šalių susitarimai registruoti, ar vertinamas kritiškumas ir koncentracijos rizika, ar sutartyse įtraukti privalomi terminai, ar testavimas apima sistemas, palaikančias kritines ar svarbias funkcijas, ir ar incidentai klasifikuojami pagal paveiktus klientus, operacijas, prastovą, geografiją, duomenų praradimą, paslaugos kritiškumą ir ekonominį poveikį.

NIST CSF 2.0 vertintojas dažnai naudos profilius. Jis lygins esamus ir tikslinius rezultatus pagal GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER. RoPA ir duomenų srautų žemėlapiai tampa įvestimi teisinių įsipareigojimų valdymui, turto apskaitoms, tiekėjų rizikai, duomenų apsaugai, stebėsenai, incidentų komunikacijai ir atkūrimo planavimui.

COBIT 2019 arba ISACA tipo auditorius daugiausia dėmesio skirs valdysenai, savininkystei ir proceso pajėgumui. Jis tikrins, ar informacijos srautai turi savininkus, ar sprendimų teisės aiškios, ar taikomas rizikos apetitas, ar kontrolės priemonės stebimos, ar išimtys eskaluojamos, ir ar įrodymai pakankamai patikimi vadovybės patikinimui.

Dažniausi nesėkmių modeliai

Dažniausi RoPA ir duomenų srautų atvaizdavimo trūkumai yra nuspėjami.

Pirma, RoPA išvardija tvarkymo veiklas, bet ne sistemas. Dėl to neįmanoma susieti GDPR atskaitomybės su pažeidžiamumų valdymu, prieigos peržiūra, atsarginėmis kopijomis, žurnalavimu ar reagavimu į incidentus.

Antra, duomenų srautų žemėlapiai sustoja ties pirmuoju tiekėju. Jie nerodo subtvarkytojų, debesijos regionų, pagalbos prieigos, analitikos įrankių, stebėsenos platformų ar atsarginių kopijų vietų.

Trečia, veiklos tęstinumo planai identifikuoja sistemas, bet ne asmens duomenis. Paslaugos sutrikimo metu organizacija supranta atkūrimo prioritetą, bet ne privatumo poveikį.

Ketvirta, tiekėjų registrai fiksuoja sutarčių savininkus, bet ne kritiškumą, pakeičiamumą, duomenų kategorijas, pranešimo apie incidentus įsipareigojimus ar išėjimo galimybes.

Penkta, SoA parašytas kaip sertifikavimo dokumentas, o ne kaip kontrolės priemonių jungtis. Jame nurodyta, kad kontrolės priemonės taikomos, bet nepaaiškinta, kurią GDPR, NIS2 ar DORA įrodymų problemą kontrolės priemonė padeda spręsti.

Galiausiai, savininkystė suskaidyta. DPO valdo RoPA, IT valdo turtą, pirkimai valdo tiekėjus, veiklos padalinys valdo BIA, finansai valdo DORA registrus, o integruoto priklausomybių žemėlapio nevaldo niekas.

Clarysec požiūris tai ištaiso, priskirdamas įrodymų objektus politikų savininkams, o tada naudodamas Zenith Blueprint žingsnius turtui, rizikoms, kontrolės priemonėms ir SoA atsekamumui susieti.

30 dienų įgyvendinimo planas

Nereikia aprėpti visko iš karto. Pradėkite nuo svarbiausių paslaugų.

1 savaitė: pasirinkite tris kritines arba didelės rizikos tvarkymo veiklas. Tinkami kandidatai yra klientų registracija, mokėjimų tvarkymas, darbuotojų personalo administravimas, pagalbos užklausų valdymas arba saugumo stebėsena. Kiekvienai veiklai patikrinkite RoPA įrašą pagal faktines sistemas, duomenų kategorijas, tikslus, teisinius pagrindus ir saugojimo taisykles.

2 savaitė: sukurkite šių veiklų duomenų srautų žemėlapius. Identifikuokite šaltinį, paskirties vietą, perdavimo būdą, aplinką, tiekėją, subtvarkytoją, duomenų vietą, prieigos kelią, transformaciją ir saugojimo tašką. Naudokite Clarysec Duomenų maskavimo ir pseudonimizavimo politikos reikalavimą tvarkyti sistemų ir duomenų srautų, susijusių su jautriais duomenimis, apskaitas.

3 savaitė: susiekite kiekvieną srautą su turtu, tiekėjais, debesijos paslaugomis ir kritinėmis verslo funkcijomis. Naudokite Zenith Blueprint 9 žingsnį turto savininkystei ir klasifikacijai. Naudokite tiekėjų ir debesijos registrų politikos reikalavimus trečiųjų šalių įrodymams užfiksuoti. Naudokite veiklos tęstinumo politiką prioritetinėms paslaugoms ir kritinėms priklausomybėms identifikuoti.

4 savaitė: pridėkite rizikos ir kontrolės priemonių atsekamumą. Kiekvienam srautui sukurkite arba atnaujinkite rizikos scenarijus. Susiekite kontrolės priemones SoA naudodami Zenith Blueprint 13 žingsnį. Kai taikoma, pridėkite pastabas dėl GDPR Article 30 atskaitomybės, NIS2 Article 21 rizikos priemonių ir DORA IRT priklausomybių įrodymų.

Tada atlikite vienas stalo pratybas: „Tiekėjo paslaugos sutrikimas ir duomenų atskleidimas kritinėje paslaugoje.“ Patikrinkite, ar jūsų įrodymai palaiko incidentų klasifikavimą, pranešimų sprendimus, komunikaciją su klientais, komunikaciją su reguliuotoju ir atkūrimo prioritetų nustatymą.

Po 30 dienų turėsite pakartojamą modelį likusiai organizacijos daliai.

Clarysec požiūris: paverskite RoPA gyvais atsparumo įrodymais

RoPA ir duomenų srautų atvaizdavimas nebėra vien privatumo administravimas. Tai jungiamasis audinys tarp GDPR atskaitomybės, NIS2 kritinių paslaugų valdysenos ir DORA IRT priklausomybių įrodymų.

2026 m. geriausiai veiks ne tos organizacijos, kurios turės daugiausia dokumentų. Geriausiai veiks tos, kurios gebės atsekti verslo paslaugą iki jos tvarkymo veiklų, duomenų srautų, sistemų, tiekėjų, debesijos regionų, sutarčių, kontrolės priemonių, rizikų, incidentų slenksčių ir atkūrimo planų.

Clarysec padeda komandoms sukurti tokį atsekamumą be perteklinės biurokratijos. Mūsų politikų rinkinys priskiria savininkystę ir įrodymų reikalavimus. Zenith Blueprint pateikia įgyvendinimo veiksmų planą, įskaitant turto identifikavimą, tiekėjų ir debesijos kontrolės priemonių įgyvendinimą bei SoA atsekamumą. Zenith Controls suteikia kryžminės atitikties kompasą, skirtą ISO/IEC 27001:2022 A priedo kontrolės priemonėms susieti su privatumo, atsparumo, tiekėjų, debesijos ir audito lūkesčiais.

Kitas jūsų žingsnis paprastas: pasirinkite vieną kritinę paslaugą, vieną RoPA įrašą ir vieną tiekėjo palaikomą duomenų srautą. Atvaizduokite jį nuo pradžios iki pabaigos. Jei viename puslapyje negalite paaiškinti duomenų, priklausomybės, kontrolės priemonės ir incidento poveikio, jūsų įrodymų sluoksnis dar nepasirengęs 2026 metams.

Clarysec gali padėti jį parengti. Susipažinkite su Zenith Blueprint, sustiprinkite valdyseną naudodami Duomenų apsaugos ir privatumo politiką ir Tiekėjų priklausomybės rizikos valdymo politiką, ir naudokite Zenith Controls, kad fragmentuotus atitikties įrodymus paverstumėte vienu auditui tinkamu veiklos modeliu.