RoPA un datu plūsmu kartēšana GDPR, NIS2 un DORA vajadzībām

Ir otrdienas 09:10, un galvenais informācijas drošības vadītājs, datu aizsardzības speciālists, iepirkumu vadītājs un operatīvās darbības direktors piedalās vienā un tajā pašā videokonferencē, taču neskatās uz vieniem un tiem pašiem pierādījumiem.

Datu aizsardzības speciālistam ir Apstrādes darbību reģistrs (RoPA), kurā uzskaitīta klientu reģistrācija, darbinieku algu aprēķins, atbalsta pieteikumi un mārketinga analītika. Galvenajam informācijas drošības vadītājam ir mākoņaktīvu uzskaite. Iepirkumu komandai ir piegādātāju līgumi. Operatīvās darbības komandai ir darbības nepārtrauktības izklājlapa. Finanšu komandai ir DORA informācijas reģistrs. Neviens nevar atbildēt uz regulatora vienkāršāko savstarpēji sasaistīto jautājumu:

Ja šis maksājumu reģistrācijas pakalpojums pārstāj darboties, kuras sistēmas, piegādātāji, datu kategorijas, apakšapstrādātāji, pārrobežu datu nosūtīšana un kritiskās uzņēmējdarbības funkcijas tiek ietekmētas?

Tas ir īstais 2026. gada atbilstības tests.

GDPR joprojām prasa pārskatatbildīgus Article 30 ierakstus. NIS2 kiberdrošību ir padarījusi par vadības institūcijas pārskatatbildības jautājumu būtiskajiem un svarīgajiem subjektiem. DORA prasa finanšu vienībām pamatot IKT atkarības, kritiskas vai svarīgas funkcijas, IKT trešo pušu vienošanās, incidentu klasifikāciju un noturības testēšanu. ISO/IEC 27001:2022 nodrošina pārvaldības sistēmas struktūru, kas to visu satur kopā, bet tikai tad, ja RoPA un datu plūsmu kartēšana tiek uztverta kā aktuāli pārvaldības pierādījumi, nevis kā privātuma komandas izklājlapas.

Clarysec praksē mēs redzam vienu un to pašu modeli strauji augošos SaaS, finanšu tehnoloģiju, mākoņpakalpojumu, MSP un B2B tehnoloģiju uzņēmumos. Tiem ir pietiekami daudz dokumentācijas, lai atbildētu uz anketu, bet nepietiek savienotu pierādījumu, lai izturētu uzraudzības pārbaudi, kiberincidentu, piegādātāja atteici vai iekšējo auditu. Problēma reti ir informācijas trūkums. Problēma ir sasaistes trūkums.

Risinājums ir padarīt RoPA un datu plūsmu kartēšanu par kopīgu pierādījumu slāni privātumam, kiberdrošības noturībai, piegādātāju pārvaldībai, mākoņpakalpojumu pārvaldībai un darbības nepārtrauktībai.

Kāpēc RoPA un datu plūsmu kartēšana kļuva par 2026. gada pārvaldības jautājumu

RoPA agrāk bieži tika uzskatīta par privātuma artefaktu. Datu plūsmu kartes nereti tika izveidotas DPIA, migrācijas uz mākoņvidi vai drošības arhitektūras izvērtēšanas laikā un pēc tam atstātas novecošanai. Šāda pieeja vairs nedarbojas.

GDPR plaši attiecas uz personas datu apstrādi ES uzņēmuma darbības kontekstā, kā arī uz daudziem ārpus ES esošiem pārziņiem vai apstrādātājiem, kas piedāvā preces vai pakalpojumus fiziskām personām ES vai uzrauga to uzvedību. Personas dati ietver informāciju, kas attiecas uz identificētu vai identificējamu personu. Apstrāde ietver vākšanu, glabāšanu, izmantošanu, izpaušanu, ierobežošanu, dzēšanu un iznīcināšanu. Pārzinis nosaka apstrādes nolūkus un līdzekļus, savukārt apstrādātājs rīkojas pārziņa vārdā.

Tādēļ RoPA nav tikai datubāzu saraksts. Tas ir ieraksts par uzņēmējdarbības nolūkiem, datu kategorijām, lomām, saņēmējiem, glabāšanas termiņiem, drošības pasākumiem un starptautiskajām atkarībām.

NIS2 pievieno pakalpojumu noturības skatījumu. Tās darbības jomā ietilpst daudzas vidēja lieluma un lielākas organizācijas augstas kritiskuma un citās kritiskās nozarēs, tostarp digitālā infrastruktūra, mākoņdatošanas pakalpojumu sniedzēji, datu centru pakalpojumu sniedzēji, satura piegādes tīkli, uzticamības pakalpojumu sniedzēji, publisko elektronisko sakaru nodrošinātāji, pārvaldīto pakalpojumu sniedzēji un pārvaldīto drošības pakalpojumu sniedzēji. Annex I ietver arī banku un finanšu tirgus infrastruktūras. Daži subjekti var tikt aptverti neatkarīgi no lieluma, tostarp noteikti DNS, TLD, uzticamības pakalpojumu un publisko sakaru nodrošinātāji, kā arī subjekti, kuru darbības traucējumi varētu būtiski ietekmēt sabiedrisko drošību, sabiedrības veselību, sistēmisku risku vai kritiskas sabiedriskās un ekonomiskās darbības.

NIS2 Article 21 prasa samērīgus tehniskus, operatīvus un organizatoriskus pasākumus tīklu un informācijas sistēmām, ko izmanto darbībās vai pakalpojumu sniegšanā. Minimālās jomas ietver risku analīzi, drošības politikas, incidentu pārvaldību, darbības nepārtrauktību, piegādes ķēdes drošību, drošu izstrādi, efektivitātes izvērtēšanu, kiberdrošības higiēnu, kriptogrāfiju, personāla drošību, piekļuves kontroli, aktīvu pārvaldību un autentifikāciju.

NIS2 subjektam RoPA bez pakalpojumu atkarību skatījuma ir nepilnīga. Nozīmīgs incidents ir jāizprot pakalpojuma ietekmes, operacionālo traucējumu, ietekmēto saņēmēju, piegādātāju un pārrobežu seku kontekstā.

DORA to pašu prasību finanšu vienībām padara vēl konkrētāku. Tā ir piemērojama no 2025. gada 17. janvāra un nosaka vienotas prasības IKT risku pārvaldībai, būtisku ar IKT saistītu incidentu ziņošanai, digitālās operacionālās noturības testēšanai, kiberdraudu un ievainojamību informācijas apmaiņai, IKT trešo pušu riskam un līgumiskajām vienošanām ar IKT trešo pušu pakalpojumu sniedzējiem. DORA definē IKT pakalpojumus plaši — kā digitālos un datu pakalpojumus, ko nepārtraukti sniedz, izmantojot IKT sistēmas. Tā definē kritisku vai svarīgu funkciju kā tādu, kuras traucējumi būtiski pasliktinātu finanšu rezultātus, pakalpojumu nepārtrauktību vai atbilstības pienākumu izpildi.

Finanšu vienībām, kas identificētas arī saskaņā ar NIS2 nacionālo transponēšanu, DORA tiek uzskatīta par nozares specifisku Savienības tiesību aktu līdzvērtīgām IKT riska, incidentu ziņošanas, testēšanas, informācijas apmaiņas un trešo pušu riska prasībām. Praksē finanšu tehnoloģiju uzņēmums nevar veidot vienu pierādījumu kopu privātumam, citu DORA un vēl citu NIS2 vajadzībām. Tam ir nepieciešams viens uz atkarībām balstīts datu pārvaldības slānis.

Šis slānis ir RoPA kopā ar datu plūsmu kartēšanu.

ISO/IEC 27001:2022 ir pamats

ISO/IEC 27001:2022 ir piemērots šādai integrācijai. Tas izveido mērogojamu informācijas drošības pārvaldības sistēmu jeb IDPS, kuras mērķis ir saglabāt konfidencialitāti, integritāti un pieejamību, izmantojot risku pārvaldību. Standarts ir paredzēts integrēšanai organizācijas procesos un pielāgošanai organizācijas vajadzībām, lielumam un struktūrai.

Sākumpunkts nav diagrammu veidošanas rīks. Sākumpunkts ir darbības joma.

ISO/IEC 27001:2022 punkti 4.1 līdz 4.4 prasa organizācijai definēt kontekstu, ieinteresētās puses, IDPS darbības jomu un savstarpēji saistītos procesus. Darbības jomai jāņem vērā juridiskie, regulatīvie un līgumiskie pienākumi, kā arī saskarnes un atkarības starp iekšējām darbībām un darbībām, ko veic citas organizācijas. RoPA un datu plūsmu kartēšanai tas nozīmē, ka IDPS darbības jomai skaidri jāaptver ārpakalpojumā nodotas mākoņplatformas, maksājumu apstrādātāji, identitātes nodrošinātāji, atbalsta rīki, pārvaldīto drošības pakalpojumu sniedzēji un darbībai kritiskas SaaS integrācijas.

Punkti 5.1 līdz 5.3 nosaka vadības pārskatatbildību par politiku, resursiem, lomu piešķiršanu un ziņošanu. Tas atbilst NIS2 Article 20 virzienam, kas prasa vadības institūcijām apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt to ieviešanu un piedalīties apmācībās. Tas saskan arī ar DORA Article 5, kas vadības institūcijai piešķir galīgo atbildību par IKT risku un politiku, noturības stratēģijas, nepārtrauktības plānu, audita plānu, IKT trešo pušu pakalpojumu un būtisku incidentu ziņošanas kanālu pārraudzību.

Punkti 6.1.1 līdz 6.1.3 nodrošina plānošanas mehānismu: identificēt riskus konfidencialitātei, integritātei un pieejamībai, piešķirt riska īpašniekus, analizēt sekas un varbūtību, izvēlēties riska apstrādes iespējas, salīdzināt kontroles pasākumus ar Annex A, sagatavot piemērojamības deklarāciju (SoA) un saņemt riska īpašnieka apstiprinājumu.

Šeit RoPA kļūst operacionāla. Katra apstrādes darbība un datu plūsma ir jāsasaista ar riskiem, kontroles pasākumiem, piegādātājiem, aktīviem un kritiskiem pakalpojumiem. Ja tas netiek izdarīts, tā paliks privātuma uzskaite, kas nevar atbalstīt incidentu reaģēšanu, noturības testēšanu vai lēmumus par piegādātāju risku.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap padara to praktisku Risku pārvaldības posmā, 9. solī “Aktīvu, draudu un ievainojamību identificēšana”:

Katram aktīvam reģistrējiet galveno informāciju: nosaukums/apraksts, īpašnieks, atrašanās vieta un klasifikācija (sensitivitāte). Piemēram, aktīvs varētu būt “Klientu datubāze — pieder IT nodaļai — izvietota AWS — satur personas un finanšu datus (augsta sensitivitāte).”

Tas pats 9. solis pievieno būtisku atbilstības atziņu: personas datu aktīvi jāatzīmē kā būtiski GDPR kontekstā, un kritisko pakalpojumu aktīvi jānorāda iespējamai NIS2 piemērojamībai, ja organizācija darbojas regulētā nozarē. Tas ir tilts starp RoPA, aktīvu uzskaiti un kritisko pakalpojumu atkarību kartēšanu.

Kas jāietver auditam gatavā RoPA

Spēcīgai RoPA nav jābūt sarežģītai, taču tai jābūt savienotai.

GDPR Article 5 prasa personas datus apstrādāt likumīgi, godprātīgi un pārredzami, vākt noteiktiem un leģitīmiem nolūkiem, ierobežot līdz nepieciešamajam apjomam, uzturēt precīzus, glabāt tikai tik ilgi, cik nepieciešams, un aizsargāt ar atbilstošiem tehniskiem un organizatoriskiem pasākumiem. Article 5(2) prasa, lai pārzinis būtu atbildīgs par atbilstību un spētu to pierādīt.

Article 6 prasa tiesisku pamatu, piemēram, piekrišanu, līguma izpildes nepieciešamību, juridisku pienākumu, vitālas intereses, sabiedrisku uzdevumu vai leģitīmas intereses. Ja apstrāde tiek veikta jaunam nolūkam, ir jāizvērtē saderība, ņemot vērā sākotnējo un jauno nolūku, vākšanas kontekstu, sensitivitāti, sekas fiziskām personām un drošības pasākumus, piemēram, šifrēšanu vai pseidonimizāciju. Article 9 nosaka stingrākus noteikumus īpašām personas datu kategorijām, tostarp veselības datiem, biometriskajiem datiem, ko izmanto unikālai identificēšanai, un citām sensitīvām kategorijām.

Clarysec SME politiku kopa pārvērš to par operacionālu prasību. Data Protection and Privacy Policy - SME nosaka:

Privātuma koordinatoram jāuztur visu personas datu apstrādes darbību reģistrs, tostarp datu kategorijas, nolūks, tiesiskais pamats un glabāšanas termiņi.

Tas izriet no Pārvaldības prasību sadaļas, 5.2.1. punkta. Lielākām organizācijām Clarysec Data Protection and Privacy Policy atbildību piešķir tieši:

Uztur Apstrādes darbību reģistru (RoPA) saskaņā ar GDPR Article 30.

Šis formulējums ir no sadaļas Lomas un pienākumi, 4.2.2. punkta. Praktiskais vēstījums ir vienkāršs: RoPA īpašniekam jābūt skaidri noteiktam. Tā nedrīkst būt bez īpašnieka atstāta atbilstības izklājlapa.

2026. gadam gatavai RoPA jāietver šādi lauki.

Pēdējās rindas ir tās, kas pārvieto RoPA no privātuma dokumentācijas uz kiberdrošības noturības pierādījumiem. Bez sistēmām, piegādātājiem, atrašanās vietām, kritiskuma un kontroles pasākumiem RoPA var izpildīt šauru Article 30 kontrolsarakstu, bet izgāzties brīdī, kad incidents, dīkstāve vai uzraudzības pārbaude prasa ietekmes analīzi.

Datu plūsmu kartēšana savieno privātumu, mākoņvidi un kritiskos pakalpojumus

Ja RoPA atbild uz jautājumu “kāda apstrāde pastāv un kāpēc”, datu plūsmu karte atbild uz jautājumu “kur dati pārvietojas, kas tiem piekļūst, kas tos aizsargā un kas pārstāj darboties, ja plūsma apstājas”.

Clarysec Data Masking and Pseudonymization Policy - SME šo prasību formulē nepārprotami:

Jāizveido datu plūsmu karte.

Tas izriet no Pārvaldības prasībām, 5.1.1.1. punkta. Uzņēmuma versija Data Masking and Pseudonymization Policy paplašina prasību 5.2.1. punktā:

Uzturēt aktuālu sistēmu un datu plūsmu uzskaiti, kas ietver sensitīvus datus.

5.2.2. punkts papildina:

Kartēt, kur un kā dati tiek transformēti, koplietoti vai tiem piekļūst dažādās vidēs.

Auditori un regulatori nemeklē mākslinieciskas diagrammas. Viņi vēlas saprast transformācijas, piekļuves ceļus, koplietošanu, vides un drošības pasākumus.

Zenith Blueprint posmā “Controls in Action”, 22. solī, Organizatoriskie kontroles pasākumi 5.1 līdz 5.18, informācijas pārsūtīšanas vadlīnijas skaidro, ka organizācijām jādefinē atļautās pārsūtīšanas metodes, jāsaskaņo tās ar klasifikāciju un jānodrošina, ka puses izprot savas lomas un pienākumus. Piemēri ietver šifrētu e-pastu, drošus portālus, SFTP, lietojumprogrammu saskarnes un fizisku piegādi ar šifrēšanu. Tajā arī norādīts, ka personas datu pārrobežu nosūtīšanai jāatbilst privātuma un juridiskajiem pienākumiem, nevis tikai iekšējām preferencēm.

Tas pats solis sasaista informācijas pārsūtīšanu ar klasifikāciju un marķēšanu, datu noplūdes novēršanu, piegādātāju attiecībām un kriptogrāfiju. Tas izveido praktisku modeli datu plūsmu kartēšanai:

1. Identificēt avota sistēmu, piemēram, CRM, maksājumu platformu, HRIS vai atbalsta dienestu.
2. Identificēt datu kategoriju, tostarp personas datus, finanšu datus, darbinieku datus, īpašu kategoriju datus vai autentifikācijas datus.
3. Identificēt pārsūtīšanas metodi, piemēram, API, SFTP, e-pastu, drošu portālu, manuālu eksportu vai rezerves kopiju replicēšanu.
4. Identificēt galamērķi, tostarp iekšējo sistēmu, mākoņpakalpojumu, piegādātāju, apakšapstrādātāju, datu noliktavu vai arhīvu.
5. Identificēt aizsardzības pasākumus, piemēram, šifrēšanu, pseidonimizāciju, piekļuves kontroli, notikumu žurnalēšanu, DLP vai līgumisku ierobežojumu.
6. Identificēt atkarību, tostarp to, vai plūsma atbalsta kritisku uzņēmējdarbības funkciju, kritisku vai svarīgu funkciju, būtisku pakalpojumu vai incidentu ziņošanas pienākumu.

Šeit īpaši svarīgi ir trīs ISO/IEC 27001:2022 Annex A kontroles pasākumi. ISO/IEC 27002:2022 sniedz ieviešanas vadlīnijas šiem kontroles pasākumiem:

Clarysec Zenith Controls: The Cross-Compliance Guide identificē 5.9, 5.14 un 5.34 kā ar šo pārvaldības slāni saistītos kontroles pasākumus. Izmantojiet tos kā enkura kontroles pasākumus un pēc tam, izmantojot piemērojamības deklarāciju, sasaistiet tos ar piegādātāju, mākoņvides, incidentu, nepārtrauktības, notikumu žurnalēšanas, piekļuves un kriptogrāfijas kontroles pasākumiem.

Kāpēc NIS2 un DORA vajag vairāk nekā privātuma reģistru

Bieža kļūda ir izveidot RoPA, kas tehniski atbilst GDPR, bet ir nederīga NIS2 vai DORA vajadzībām. Atšķirība ir pakalpojuma kritiskumā.

NIS2 Article 23 prasa būtiskajiem un svarīgajiem subjektiem bez nepamatotas kavēšanās paziņot par nozīmīgiem incidentiem. Ziņošanas modelis ietver agrīno brīdinājumu 24 stundu laikā, incidenta paziņojumu 72 stundu laikā un galīgo ziņojumu viena mēneša laikā. Nozīmīgi incidenti tiek vērtēti pēc smagiem operacionāliem traucējumiem, finanšu zaudējumiem vai materiāla vai nemateriāla kaitējuma citām fiziskām vai juridiskām personām. Šī izvērtēšana ir atkarīga no zināšanām par to, kuri pakalpojumi, saņēmēji, valstis, sistēmas un piegādātāji ir ietekmēti.

DORA Article 17 prasa finanšu vienībām definēt un ieviest ar IKT saistītu incidentu pārvaldības procesu, kas atklāj, pārvalda un paziņo incidentus, reģistrē incidentus un nozīmīgus kiberdraudus, identificē pamatcēloņus, nosaka agrīnās brīdināšanas indikatorus, klasificē incidentus pēc ietekmēto pakalpojumu smaguma un kritiskuma, piešķir lomas un izveido komunikācijas un eskalācijas procedūras. Article 18 prasa klasifikāciju, izmantojot ietekmētos klientus vai darījuma partnerus un darījumus, ilgumu un dīkstāvi, ģeogrāfisko izplatību, datu zudumu, kas ietekmē pieejamību, autentiskumu, integritāti vai konfidencialitāti, ietekmēto pakalpojumu kritiskumu un ekonomisko ietekmi.

Incidentu nevar ātri klasificēt, ja nav zināma datu plūsma un atkarību ķēde.

Clarysec Business Continuity Policy and Disaster Recovery Policy - SME norāda uz nepieciešamo pierādījumu lauku:

prioritizēti pakalpojumi un sistēmas (kritiskās uzņēmējdarbības funkcijas)

Tas izriet no Pārvaldības prasībām, 5.2.1.2. punkta. Uzņēmuma Business Continuity Policy and Disaster Recovery Policy 5.2.4. punktā pievieno atkarību dimensiju:

Kritiskās atkarības (sistēmas, piegādātāji, personāls)

DORA regulētām organizācijām tam jābūt saskaņotam ar kritiskām vai svarīgām funkcijām, IKT pakalpojumiem, līgumiskajām vienošanām un izstāšanās stratēģijām. DORA Article 28 prasa IKT trešo pušu risku pārvaldīt kā daļu no IKT riska ietvara. Tas nosaka pienākumu uzturēt IKT pakalpojumu līgumisko vienošanos reģistru, prasa pirmslīguma pienācīgu pārbaudi un kritiskuma, koncentrācijas riska, piemērotības un interešu konfliktu izvērtēšanu, kā arī prasa izstāšanās stratēģijas IKT pakalpojumiem, kas atbalsta kritiskas vai svarīgas funkcijas.

DORA Article 30 nosaka minimālos IKT līgumu noteikumus, tostarp pakalpojumu aprakstus, apakšuzņēmēju piesaistes nosacījumus, datu apstrādes un glabāšanas vietas, datu aizsardzību, piekļuvi, datu atjaunošanu un atdošanu, pakalpojumu līmeņus, palīdzību incidentu gadījumā, sadarbību ar iestādēm, izbeigšanas tiesības, audita tiesības un pārejas vai izstāšanās kārtību.

RoPA, kas neidentificē piegādātājus, atrašanās vietas, pārsūtīšanas metodes, kritiskumu un izstāšanās atkarības, neatbalstīs DORA pierādījumus.

Piegādātāju, mākoņvides un apakšapstrādātāju kartēšana ir vieta, kur pierādījumi bieži sabrūk

Reālos auditos RoPA nepilnības bieži izpaužas kā piegādātāju nepilnības. Apstrādes darbība norāda “klientu atbalsts”. Datu plūsmu karte norāda “atbalsta platforma”. Taču neviens nevar identificēt mitināšanas reģionu, AI transkripcijas papildinājumu, analītikas apakšapstrādātāju, pieteikumu pielikumu glabāšanu, administratora piekļuves modeli vai izstāšanās procedūru.

Clarysec SME piegādātāju politika izveido minimālos operacionālos pierādījumus. Third-Party and Supplier Security Policy - SME nosaka:

Piegādātāju reģistrs jāuztur un jāatjaunina administratīvajai vai iepirkumu kontaktpersonai. Tajā jāiekļauj:

Tas izriet no Pārvaldības prasībām, 5.4. punkta. Mākoņvides politika pievieno atsevišķu uzskaites prasību. Cloud Usage Policy - SME nosaka:

Mākoņpakalpojumu reģistrs jāuztur IT pakalpojumu sniedzējam vai ģenerāldirektoram. Tajā jāreģistrē:

Tas izriet no Pārvaldības prasībām, 5.3. punkta. Uzņēmuma atkarību riskam Clarysec Supplier Dependency Risk Management Policy ir vēl konkrētāka:

Piegādātāju atkarību reģistrs: piegādātāju pārvaldības birojam (VMO) jāuztur aktuāls visu kritisko piegādātāju reģistrs, ietverot tādu informāciju kā sniegtie pakalpojumi/produkti; vai piegādātājs ir vienīgais piegādes avots; pieejamie alternatīvie piegādātāji vai aizstājamība; spēkā esošie līguma noteikumi; un ietekmes izvērtējums, ja piegādātājs pārstātu darboties vai tiktu kompromitēts. Reģistram skaidri jāidentificē augstas atkarības piegādātāji (piemēram, tādi, kuriem nav ātras alternatīvas).

Šī prasība no ieviešanas prasību 6.1. punkta ir tieši tas, kas savieno RoPA ar NIS2 piegādes ķēdes drošību un DORA IKT trešo pušu risku.

Zenith Blueprint posmā “Controls in Action”, 23. solī, Organizatoriskie kontroles pasākumi 5.19 līdz 5.37, iesaka apkopot pilnu piegādātāju sarakstu, klasificēt piegādātājus pēc piekļuves sistēmām, datiem vai operacionālās kontroles, iekļaut drošības prasības līgumos, pārskatīt apakšuzņēmējus, noteikt piegādātāju izmaiņu ierosinātājus un izveidot mākoņpakalpojumu izvērtēšanas procesu, kas aptver datu atrašanās vietu, piekļuves modeli, notikumu žurnalēšanu un šifrēšanu.

Tas ļauj galvenajam informācijas drošības vadītājam incidenta laikā atbildēt: “Kurš kritiskais pakalpojums izmanto šo piegādātāju, kuri dati tika atklāti, kuri klienti jāinformē, kuram regulatoram, iespējams, jāziņo un kāds alternatīvais piegādātājs vai izstāšanās ceļš pastāv?”

Praktisks piemērs: klientu reģistrācija finanšu tehnoloģiju uzņēmumā

Apsveriet finanšu tehnoloģiju uzņēmumu, kas nodrošina klientu reģistrāciju digitālajā makā. Klienti augšupielādē identitātes dokumentus, piegādātājs veic biometriskās dzīvīguma pārbaudes, rezultāti tiek glabāti mākoņa datubāzē, un klientu atbalsts pieteikumu sistēmā var skatīt verifikācijas statusu.

Reģistrācijas pakalpojums DORA izpratnē var būt kritiska vai svarīga funkcija, jo tā darbības traucējumi būtiski ietekmē pakalpojumu nepārtrauktību un regulatīvos pienākumus. Ja uzņēmums darbojas NIS2 nozarē vai sniedz attiecīgus IKT pakalpojumus, tas var būt arī daļa no kritiskā pakalpojuma pierādījumiem.

Noderīga karte sākas ar vienu apvienotu ierakstu.

Tagad pievienojiet ISO/IEC 27001:2022 riska apstrādes izsekojamību.

Zenith Blueprint Risku pārvaldības posmā, 13. solī “Riska apstrādes plānošana un piemērojamības deklarācija”, Clarysec apraksta SoA kā sasaistes dokumentu, kas savieno risku izvērtēšanu un apstrādi ar faktiskajiem kontroles pasākumiem. Tas iesaka kartēt kontroles pasākumus pret riskiem un, kur attiecināms, riska reģistrā vai SoA piezīmēs veikt krusteniskas atsauces uz regulējumiem, piemēram, GDPR, NIS2 vai DORA.

Reģistrācijas piemērā riska scenārijs varētu būt: “Identitātes verifikācijas pakalpojumu sniedzēja dīkstāve vai kompromitēšana traucē reģistrāciju un atklāj biometriskos identitātes datus.” Apstrādes kontroles pasākumi varētu ietvert piegādātāju pienācīgu pārbaudi, līgumisku incidentu paziņošanu, šifrēšanu, piekļuves kontroli, notikumu žurnalēšanu, rezerves kopiju veidošanu un atjaunošanu, datu minimizēšanu, pseidonimizāciju, uzraudzību, izstāšanās plānošanu un incidentu reaģēšanas rokasgrāmatas.

SoA piezīmē var norādīt, ka kontroles pasākumu kopa atbalsta GDPR pārskatatbildību, NIS2 Article 21 piegādes ķēdi un gatavību incidentiem, kā arī DORA IKT trešo pušu risku un kritisko funkciju noturību.

Tas ir tas, ko vēlas auditori: izsekojamība.

Savstarpējās atbilstības kartēšana: viens pierādījumu slānis, vairāki jautājumi

RoPA un datu plūsmu kartēšana nav atsevišķi atbilstības silosi. Tie atbalsta kopīgu jautājumu kopu GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 un COBIT 2019 kontekstā.

NIST CSF 2.0 ir noderīgs kā organizējošs slānis. Tā CSF profili atbalsta pašreizējā un mērķa stāvokļa analīzi, izmantojot ievaddatus, piemēram, politikas, risku prioritātes, biznesa ietekmes reģistrus, prasības, standartus, prakses, rīkus un darba lomas. Tā GOVERN funkcija ietver juridiskos, regulatīvos, līgumiskos, privātuma un pilsonisko brīvību pienākumus, riska mērķus, vadības pārskatatbildību, lomas, politiku, pārraudzību un veiktspējas pārskatīšanu. Tās piegādes ķēdes rezultāti prasa, lai piegādātāji būtu zināmi un prioritizēti pēc kritiskuma, līgumiskās kiberdrošības prasības būtu integrētas, pienācīga pārbaude notiktu pirms attiecību uzsākšanas, piegādātāju riski tiktu reģistrēti un uzraudzīti, un piegādātāji tiktu iekļauti incidentu reaģēšanas un atjaunošanas plānošanā.

Tas labi atbilst Clarysec RoPA darbības modelim. RoPA nodrošina privātuma kontekstu. Aktīvu uzskaite nodrošina tehnisko kontekstu. Piegādātāju un mākoņpakalpojumu reģistri nodrošina trešo pušu kontekstu. BIA nodrošina kritiskuma kontekstu. SoA nodrošina kontroles kontekstu.

Viens ISO/IEC 27001:2022 Annex A kontroles pasākums var atbalstīt arī vairākus ietvarus. Control 5.14, Information transfer, ir labs piemērs.

Tā ir Zenith Controls vērtība kā savstarpējās atbilstības kompasam. Tas palīdz organizācijām izskaidrot, kāpēc viena kontroles prakse atbalsta vairākas regulatīvās un audita gaidas.

Kā dažādi auditori pārbaudīs vienu un to pašu karti

Nobriedusi RoPA un datu plūsmu karte var apmierināt vairākus auditorus, taču katrs tai pieies atšķirīgi.

ISO/IEC 27001:2022 auditors sāks ar darbības jomu, ieinteresētajām pusēm, riskiem, dokumentēto informāciju un kontroles pasākumu atlasi. Viņš jautās, vai juridiskās un līgumiskās prasības ir identificētas, vai personas dati un kritiskie pakalpojumi ietilpst IDPS darbības jomā, vai aktīviem ir īpašnieki un klasifikācijas, vai risku izvērtēšanā ņemta vērā konfidencialitāte, integritāte un pieejamība, un vai SoA pamato piemērojamos kontroles pasākumus.

GDPR auditors vai privātuma regulators sāks ar pārskatatbildību. Viņš pārbaudīs, vai RoPA atspoguļo faktisko apstrādi, vai nolūki un tiesiskie pamati ir dokumentēti, vai īpašu kategoriju dati ir identificēti, vai glabāšanas termiņi tiek piemēroti, vai saņēmēji un apstrādātāji ir precīzi un vai nosūtīšanai un drošībai pastāv atbilstoši aizsardzības pasākumi.

NIS2 fokusēts auditors skatīsies uz pakalpojuma ietekmi. Viņš jautās, kā organizācija nosaka kritiskus vai svarīgus pakalpojumus, kā vadība apstiprinājusi un pārrauga riska pasākumus, kā tiek ņemtas vērā piegādātāju ievainojamības un pakalpojumu sniedzēju riski, kā ir savienota nepārtrauktība un incidentu pārvaldība un vai organizācija spēj atbalstīt 24 stundu, 72 stundu un galīgās ziņošanas termiņus ar uzticamiem pierādījumiem.

DORA auditors skatīsies uz IKT risku pārvaldību un kritiskām vai svarīgām funkcijām. Viņš pārbaudīs, vai vadības institūcija ir apstiprinājusi IKT riska ietvaru un noturības stratēģiju, vai IKT trešo pušu vienošanās ir reģistrētas, vai kritiskums un koncentrācijas risks ir izvērtēti, vai līgumi ietver obligātos noteikumus, vai testēšana aptver sistēmas, kas atbalsta kritiskas vai svarīgas funkcijas, un vai incidenti tiek klasificēti, izmantojot ietekmētos klientus, darījumus, dīkstāvi, ģeogrāfiju, datu zudumu, pakalpojuma kritiskumu un ekonomisko ietekmi.

NIST CSF 2.0 izvērtētājs bieži izmanto profilus. Viņš salīdzina pašreizējos un mērķa rezultātus funkcijās GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER. RoPA un datu plūsmu kartes kļūst par ievaddatiem juridisko pienākumu pārvaldībai, aktīvu uzskaitei, piegādātāju riskam, datu aizsardzībai, uzraudzībai, incidentu komunikācijai un atjaunošanas plānošanai.

COBIT 2019 vai ISACA stila auditors koncentrēsies uz pārvaldību, īpašumtiesībām un procesa spēju. Viņš pārbaudīs, vai informācijas plūsmām ir īpašnieki, vai lēmumu pieņemšanas tiesības ir skaidras, vai tiek piemērota riska apetīte, vai kontroles pasākumi tiek uzraudzīti, vai izņēmumi tiek eskalēti un vai pierādījumi ir pietiekami uzticami vadības apliecinājumam.

Biežākie neveiksmju modeļi

Biežākās RoPA un datu plūsmu kartēšanas nepilnības ir paredzamas.

Pirmkārt, RoPA uzskaita apstrādes darbības, bet ne sistēmas. Tas padara neiespējamu GDPR pārskatatbildības sasaisti ar ievainojamību pārvaldību, piekļuves tiesību pārskatīšanu, rezerves kopijām, notikumu žurnalēšanu vai incidentu reaģēšanu.

Otrkārt, datu plūsmu kartes apstājas pie pirmā piegādātāja. Tās neparāda apakšapstrādātājus, mākoņreģionus, atbalsta piekļuvi, analītikas rīkus, uzraudzības platformas vai rezerves kopiju atrašanās vietas.

Treškārt, darbības nepārtrauktības plāni identificē sistēmas, bet ne personas datus. Dīkstāves laikā organizācija izprot atjaunošanas prioritāti, bet ne privātuma ietekmi.

Ceturtkārt, piegādātāju reģistri fiksē līgumu īpašniekus, bet ne kritiskumu, aizstājamību, datu kategorijas, incidentu paziņošanas pienākumus vai izstāšanās iespējas.

Piektkārt, SoA ir uzrakstīta kā sertifikācijas dokuments, nevis kontroles sasaistes dokuments. Tā norāda, ka kontroles pasākumi ir piemērojami, bet nepaskaidro, kuru GDPR, NIS2 vai DORA pierādījumu problēmu kontroles pasākums palīdz atrisināt.

Visbeidzot, īpašumtiesības ir sadrumstalotas. Datu aizsardzības speciālists pārvalda RoPA, IT pārvalda aktīvus, iepirkumi pārvalda piegādātājus, operatīvās darbības komanda pārvalda BIA, finanšu komanda pārvalda DORA reģistrus, un neviens nepārvalda integrēto atkarību karti.

Clarysec pieeja to risina, piešķirot pierādījumu objektus politiku īpašniekiem un pēc tam izmantojot Zenith Blueprint soļus, lai savienotu aktīvus, riskus, kontroles pasākumus un SoA izsekojamību.

30 dienu ieviešanas plāns

Nav jācenšas aptvert visu uzreiz. Sāciet ar pakalpojumiem, kuriem ir vislielākā nozīme.

1. nedēļa: izvēlieties trīs kritiskas vai augsta riska apstrādes darbības. Labi kandidāti ir klientu reģistrācija, maksājumu apstrāde, darbinieku HR administrēšana, atbalsta pieteikumu apstrāde vai drošības uzraudzība. Katrai darbībai validējiet RoPA ierakstu pret faktiskajām sistēmām, datu kategorijām, nolūkiem, tiesiskajiem pamatiem un glabāšanas noteikumiem.

2. nedēļa: izveidojiet šo darbību datu plūsmu kartes. Identificējiet avotu, galamērķi, pārsūtīšanas metodi, vidi, piegādātāju, apakšapstrādātāju, datu atrašanās vietu, piekļuves ceļu, transformāciju un glabāšanas punktu. Izmantojiet Clarysec Data Masking and Pseudonymization Policy prasību uzturēt sistēmu un datu plūsmu uzskaiti, kas ietver sensitīvus datus.

3. nedēļa: sasaistiet katru plūsmu ar aktīviem, piegādātājiem, mākoņpakalpojumiem un kritiskām uzņēmējdarbības funkcijām. Izmantojiet Zenith Blueprint 9. soli aktīvu īpašumtiesībām un klasifikācijai. Izmantojiet piegādātāju un mākoņa reģistra politiku prasības, lai fiksētu trešo pušu pierādījumus. Izmantojiet darbības nepārtrauktības politiku, lai identificētu prioritizētos pakalpojumus un kritiskās atkarības.

4. nedēļa: pievienojiet risku un kontroles pasākumu izsekojamību. Katrai plūsmai izveidojiet vai atjauniniet riska scenārijus. Kartējiet kontroles pasākumus SoA, izmantojot Zenith Blueprint 13. soli. Kur attiecināms, pievienojiet piezīmes par GDPR Article 30 pārskatatbildību, NIS2 Article 21 riska pasākumiem un DORA IKT atkarību pierādījumiem.

Pēc tam veiciet vienu galda vingrinājumu: “Piegādātāja dīkstāve plus datu ekspozīcija kritiskā pakalpojumā.” Pārbaudiet, vai jūsu pierādījumi atbalsta incidentu klasifikāciju, paziņošanas lēmumus, komunikāciju ar klientiem, komunikāciju ar regulatoru un atjaunošanas prioritizāciju.

30 dienu beigās jums būs atkārtojams modelis pārējai organizācijai.

Clarysec pieeja: pārvērtiet RoPA par aktuāliem noturības pierādījumiem

RoPA un datu plūsmu kartēšana vairs nav tikai privātuma administrēšana. Tās ir saistaudi starp GDPR pārskatatbildību, NIS2 kritisko pakalpojumu pārvaldību un DORA IKT atkarību pierādījumiem.

Organizācijas, kas 2026. gadā būs sekmīgākās, nebūs tās, kurām ir visvairāk dokumentu. Tās būs organizācijas, kas spēs izsekot uzņēmējdarbības pakalpojumu līdz tā apstrādes darbībām, datu plūsmām, sistēmām, piegādātājiem, mākoņreģioniem, līgumiem, kontroles pasākumiem, riskiem, incidentu sliekšņiem un atjaunošanas plāniem.

Clarysec palīdz komandām izveidot šo izsekojamību bez liekas birokrātijas. Mūsu politiku komplekts piešķir īpašumtiesības un pierādījumu prasības. Zenith Blueprint nodrošina ieviešanas ceļvedi, tostarp aktīvu identificēšanu, piegādātāju un mākoņa kontroles pasākumu ieviešanu un SoA izsekojamību. Zenith Controls nodrošina savstarpējās atbilstības kompasu ISO/IEC 27001:2022 Annex A kontroles pasākumu kartēšanai pret privātuma, noturības, piegādātāju, mākoņvides un audita gaidām.

Nākamais solis ir vienkāršs: izvēlieties vienu kritisku pakalpojumu, vienu RoPA ierakstu un vienu piegādātāja atbalstītu datu plūsmu. Kartējiet to no gala līdz galam. Ja vienā lapā nevarat izskaidrot datus, atkarību, kontroles pasākumu un incidenta ietekmi, jūsu pierādījumu slānis nav gatavs 2026. gadam.

Clarysec var palīdzēt to sagatavot. Izpētiet Zenith Blueprint, stipriniet savu pārvaldību ar Data Protection and Privacy Policy un Supplier Dependency Risk Management Policy un izmantojiet Zenith Controls, lai sadrumstalotus atbilstības pierādījumus pārvērstu vienā auditam gatavā darbības modelī.