NIS2 pierādījumu kartēšana ar ISO 27001:2022 2026. gadam

2026. gada NIS2 problēma nav informētība, bet pierādījumi

Ir pirmdienas rīts, 08:35. Marija, nesen ieceltā CISO strauji augošā B2B mākoņpakalpojumu un pārvaldīto pakalpojumu sniedzējā, pievienojas ceturkšņa valdes riska sanāksmei ar apjomīgu NIS2 trūkumu izvērtējumu, kas atvērts viņas klēpjdatorā. Pirmais slaids izskatās nomierinošs. Politikas pastāv. Risku izvērtēšana ir veikta. Reaģēšana uz incidentiem ir dokumentēta. Piegādātāji ir uzskaitīti. Ievainojamību skenēšana tiek veikta katru mēnesi.

Tad valdes priekšsēdētājs uzdod jautājumu, kas maina sanāksmes gaitu:

“Vai mēs varam pierādīt, ka šie pasākumi darbojās pagājušajā ceturksnī, un vai varam parādīt, kuri ISO 27001:2022 kontroles pasākumi, īpašnieki un ieraksti atbalsta katru NIS2 pienākumu?”

Telpā iestājas klusums.

Juridiskā funkcija zina, ka uzņēmums ietilpst NIS2 tvērumā, jo tas sniedz pārvaldītus IKT un mākoņpakalpojumus ES klientiem. Atbilstības funkcija zina, ka Article 21 prasa tehniskus, operacionālus un organizatoriskus kiberdrošības risku pārvaldības pasākumus. Operāciju komanda zina, ka sistēmām tiek uzstādīti ielāpi, piegādātāji tiek pārskatīti un žurnāli tiek uzraudzīti. Taču pierādījumi ir izkaisīti pa pieteikumu sistēmām, SIEM eksportiem, politiku mapēm, izklājlapām, mākoņvides konsolēm, piegādātāju portāliem un sanāksmju piezīmēm.

Neviens nevar ātri parādīt aizstāvamu ķēdi no NIS2 Article 21 līdz ISO 27001:2022 darbības jomai, riskam, kontroles pasākumam, politikai, īpašniekam, procedūrai, darbības ierakstam un audita konstatējumam.

Tas ir īstais 2026. gada izaicinājums.

Daudzas organizācijas vairs nejautā: “Vai mēs esam NIS2 tvērumā?” Tās uzdod sarežģītāku jautājumu: “Vai mēs varam pierādīt, ka mūsu NIS2 tehniskie pasākumi faktiski darbojas?” Atbilde nevar būt vienreizēja kartēšanas izklājlapa. Tai jābūt dzīvam darbības modelim informācijas drošības pārvaldības sistēmā, kur juridiskie pienākumi tiek pārvērsti riskos, politikās, kontroles pasākumos, īpašniekos, pierādījumos un nepārtrauktā uzlabošanā.

Clarysec modelī ISO/IEC 27001:2022 tiek izmantots kā pārvaldības sistēmas pamats, NIS2 Article 21 — kā regulatīvo pienākumu kopums, politiku punkti — kā operacionālais noteikumu kopums, Zenith Blueprint: auditora 30 soļu ceļvedis — kā ieviešanas ceļš, un Zenith Controls: savstarpējās atbilstības ceļvedis — kā savstarpējās atbilstības karte ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF un COBIT tipa apliecinājumam.

Sāciet ar darbības jomu, jo NIS2 pierādījumi sākas pirms kontroles pasākumiem

Bieža NIS2 kļūda ir uzreiz ķerties pie MFA, žurnālfiksēšanas, reaģēšanas uz incidentiem un ievainojamību pārvaldības, pirms ir apstiprināts subjekta tvērums, pakalpojumu tvērums un jurisdikciju tvērums.

NIS2 attiecas uz aptvertajiem publiskajiem un privātajiem subjektiem regulētajās nozarēs, kas atbilst lieluma un darbības kritērijiem, turklāt noteikti subjektu veidi ir aptverti neatkarīgi no lieluma. Attiecīgās digitālās un IKT kategorijas ietver mākoņskaitļošanas pakalpojumu sniedzējus, datu centru pakalpojumu sniedzējus, satura piegādes tīklu pakalpojumu sniedzējus, uzticamības pakalpojumu sniedzējus, publisko elektronisko sakaru pakalpojumu sniedzējus, pārvaldīto pakalpojumu sniedzējus, pārvaldīto drošības pakalpojumu sniedzējus, tiešsaistes tirdzniecības vietas, tiešsaistes meklētājprogrammas un sociālo tīklu platformas.

Mākoņpakalpojumu sniedzējiem, SaaS platformām, MSP, MSSP un digitālās infrastruktūras nodrošinātājiem šis tvēruma noteikšanas darbs nav teorētisks. Article 3 prasa dalībvalstīm nošķirt būtiskos un svarīgos subjektus. Article 27 prasa ENISA uzturēt reģistru vairākiem digitālo un IKT pakalpojumu sniedzējiem, tostarp DNS pakalpojumu sniedzējiem, TLD nosaukumu reģistriem, domēna nosaukumu reģistrācijas pakalpojumu sniedzējiem, mākoņskaitļošanas pakalpojumu sniedzējiem, datu centru pakalpojumu sniedzējiem, satura piegādes tīklu pakalpojumu sniedzējiem, pārvaldīto pakalpojumu sniedzējiem, pārvaldīto drošības pakalpojumu sniedzējiem, tiešsaistes tirdzniecības vietām, tiešsaistes meklētājprogrammām un sociālo tīklu platformām.

ISO 27001:2022 nodrošina atbilstošu struktūru. Punkti 4.1 līdz 4.4 prasa organizācijai izprast ārējos un iekšējos jautājumus, ieinteresētās puses, prasības, saskarnes un atkarības, un pēc tam definēt ISMS darbības jomu. NIS2 šeit ir jāfiksē, nevis jāatstāj juridiskā piezīmē.

Praktiskam NIS2 tvēruma ierakstam jāietver:

• Juridiskās personas un ES uzņēmējdarbības vietas analīze
• NIS2 nozare un pakalpojumu kategorija
• Būtiska vai svarīga subjekta statuss, ja tas apstiprināts ar nacionālo tiesību aktu vai iestādes norīkojumu
• ENISA reģistra attiecināmība, ja piemērojams
• Klientiem sniegtie kritiskie pakalpojumi
• Tīkli un informācijas sistēmas, kas atbalsta šos pakalpojumus
• Atkarības no mākoņpakalpojumiem, datu centriem, telekomunikāciju, drošības uzraudzības, identitātes un programmatūras pakalpojumu sniedzējiem
• Saites uz DORA, GDPR, klientu līgumiem un nozarei specifiskajiem pienākumiem
• Pierādījumu repozitoriji, sistēmu īpašnieki un pārskatīšanas regularitāte

Šeit ir pareizi jānodala arī DORA. NIS2 atzīst, ka gadījumos, kad nozarei specifisks ES tiesību akts nosaka līdzvērtīgus kiberdrošības risku pārvaldības vai incidentu paziņošanas pienākumus, attiecīgais nozares režīms piemērojams atbilstošo NIS2 normu vietā. Aptvertajām finanšu iestādēm DORA parasti ir piemērojamais kiberdrošības un IKT incidentu ziņošanas režīms. DORA piemēro no 2025. gada 17. janvāra, un tā aptver IKT risku pārvaldību, incidentu ziņošanu, digitālās darbības noturības testēšanu, IKT trešo pušu risku un kritisku IKT trešo pušu pakalpojumu sniedzēju pārraudzību.

Tāpēc finanšu tehnoloģiju grupai vienā korporatīvajā struktūrā var būt atšķirīgas atbilstības pieejas. Maksājumu subjekts galvenokārt var būt DORA tvērumā. MSP meitasuzņēmums var būt tieši NIS2 tvērumā. Koplietota mākoņplatforma var atbalstīt abus. Nobriedusi atbilde nav kontroles pasākumu dublēšana. Tas ir viens ISMS pierādījumu modelis, kas var kalpot vairākiem regulatīvajiem skatījumiem.

ISO 27001:2022 kā NIS2 atbilstības darbības sistēma

NIS2 Article 21 prasa atbilstošus un samērīgus tehniskus, operacionālus un organizatoriskus pasākumus, lai pārvaldītu riskus tīkliem un informācijas sistēmām un novērstu vai mazinātu incidentu ietekmi uz pakalpojumu saņēmējiem un citiem pakalpojumiem.

ISO 27001:2022 ir labi piemērots šīs prasības īstenošanai, jo tas prasa trīs disciplīnas.

Pirmkārt, pārvaldība. Punkti 5.1 līdz 5.3 prasa augstākās vadības apņemšanos, saskaņošanu ar stratēģisko virzienu, resursu nodrošināšanu, komunikāciju, atbildību piešķiršanu un dokumentētu informācijas drošības politiku. Tas tieši atbilst NIS2 Article 20, kas prasa vadības institūcijām apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt ieviešanu un saņemt apmācību.

Otrkārt, risku apstrāde. Punkti 6.1.1 līdz 6.1.3 prasa atkārtojamu riska novērtēšanas procesu, risku īpašniekus, risku izvērtēšanu, apstrādes iespējas, kontroles pasākumu atlasi, piemērojamības deklarāciju (SoA), risku apstrādes plānu un atlikušā riska apstiprināšanu.

Treškārt, darbības kontroles pasākumi. Punkts 8.1 prasa organizācijai plānot, ieviest un kontrolēt ISMS procesus, uzturēt dokumentētu informāciju, kontrolēt izmaiņas un pārvaldīt ārēji nodrošinātus procesus, produktus un pakalpojumus, kas ir būtiski ISMS.

Tas pārvērš NIS2 no juridiska kontrolsaraksta par kontroles pasākumu darbības modeli.

Katrai rindai ir nepieciešams īpašnieks, ieraksta avots un izlases metode. Ja to nav, organizācijai ir kontroles nodoms, nevis kontroles pasākums.

Politika ir vieta, kur NIS2 kļūst par operacionālu rīcību

Politikas bieži tiek uztvertas kā veidnes. NIS2 kontekstā tas ir bīstami. Regulatoru vai auditoru nepārliecinās politiku mape, ja politikas nepiešķir atbildību, nedefinē ierakstus, nesaista prasības ar riskiem un nerada pierādījumus.

Uzņēmuma Tiesiskās un regulatīvās atbilstības politika nosaka pamatu 6.2.1. punktā:

Visi juridiskie un regulatīvie pienākumi jākartē uz konkrētām politikām, kontroles pasākumiem un īpašniekiem informācijas drošības pārvaldības sistēmā (ISMS).

Šis punkts ir tilts starp NIS2 un ISO 27001:2022. NIS2 Article 21 netiek vienkārši uzskaitīts kā ārēja prasība. Tas tiek sadalīts politikas pienākumos, kartēts uz kontroles pasākumiem, piešķirts īpašniekiem un testēts ar pierādījumiem.

Mazākām organizācijām SME Tiesiskās un regulatīvās atbilstības politika saglabā to pašu pieeju vienkāršākā formā. Punkts 5.1.1 prasa:

Ģenerāldirektoram jāuztur vienkāršs, strukturēts Atbilstības reģistrs, kurā norādīts:

Teikums ir apzināti praktisks. SME nav nepieciešama sarežģīta GRC ieviešana, lai sāktu. Tiem ir vajadzīgs atbilstības reģistrs, kas fiksē pienākumu, piemērojamību, īpašnieku, politiku, pierādījumus un pārskatīšanas regularitāti.

Pēc tam risku apstrāde pārvērš pienākumu darbībā. Uzņēmuma Risku pārvaldības politika, 6.4.2. punkts nosaka:

Risku pārvaldniekam jānodrošina, ka apstrādes pasākumi ir reālistiski, laika ziņā ierobežoti un kartēti uz ISO/IEC 27001 Annex A kontroles pasākumiem.

SME vajadzībām Risku pārvaldības politika - SME, 5.1.2. punkts nosaka minimāli nepieciešamo riska ierakstu:

Katrā riska ierakstā jāiekļauj: apraksts, iespējamība, ietekme, vērtējums, īpašnieks un apstrādes plāns.

Šie punkti ir būtiski, jo NIS2 ir skaidri balstīta riskā un samērīgumā. Article 21 paredz, ka pasākumi atspoguļo jaunākos sasniegumus, attiecīgos standartus, ieviešanas izmaksas, pakļautību riskam, lielumu, incidenta iespējamību un smaguma pakāpi, tostarp sociālo un ekonomisko ietekmi. Risku reģistrs bez īpašniekiem un apstrādes plāniem nevar pierādīt samērīgumu.

Uzņēmuma Informācijas drošības politika 6.6.1. punktā nostiprina pierādījumu principu:

Visiem ieviestajiem kontroles pasākumiem jābūt auditējamiem, atbalstītiem ar dokumentētām procedūrām un saglabātiem darbības pierādījumiem.

Tā ir atšķirība starp NIS2 programmu un NIS2 pierādījumu programmu.

Clarysec ceļš no kartēšanas uz darbību

Zenith Blueprint ir vērtīgs, jo tas atspoguļo auditoru domāšanu. Auditori nejautā tikai, vai kontroles pasākums pastāv. Viņi jautā, kāpēc tas tika izvēlēts, kur tas ir dokumentēts, kā tas darbojas, kam tas pieder, kādi pierādījumi to apliecina un kā organizācija to uzlabo.

Risku pārvaldības posmā Step 13 komandām norāda pievienot izsekojamību starp riskiem, kontroles pasākumiem un punktiem:

✓ Kartējiet kontroles pasākumus uz riskiem: savā Riska reģistra apstrādes plānā jūs uzskaitījāt noteiktus kontroles pasākumus katram riskam. Katram riskam varat pievienot kolonnu “Annex A kontroles pasākuma atsauce” un uzskaitīt kontroles pasākumu numurus.

NIS2 kontekstā tas nozīmē, ka risku reģistram un piemērojamības deklarācijai jāparāda, kāpēc ir piemērojami tādi kontroles pasākumi kā 8.8 Tehnisko ievainojamību pārvaldība, 5.19 Informācijas drošība piegādātāju attiecībās un 5.24 Incidentu pārvaldības plānošana un sagatavošana.

Zenith Blueprint Step 14 padara regulatīvo kartēšanu skaidru:

Katrai regulai, ja tā ir piemērojama, var izveidot vienkāršu kartēšanas tabulu (piemēram, pārskata pielikumu), kurā uzskaitītas regulas galvenās drošības prasības un atbilstošie kontroles pasākumi/politikas jūsu ISMS.

Tas novērš sadrumstalotību. GDPR personas datu drošība, NIS2 incidentu ziņošana, DORA IKT noturības testēšana un klientu drošības saistības var balstīties uz tiem pašiem pierādījumiem: piekļuves tiesību pārskatīšanu, ievainojamību novēršanu, žurnālfiksēšanas ierakstiem, rezerves kopiju testiem, piegādātāju pārskatīšanām un incidentu pārskatiem.

Step 19 pāriet no projektēšanas uz darbību:

Piesaistiet katru no šiem dokumentiem atbilstošajam kontroles pasākumam savā SoA vai ISMS rokasgrāmatā. Tie kalpos kā ieviešanas pierādījumi un iekšēja atsauce.

Step 19 dokumentācijas kopa ietver galiekārtu drošību, piekļuves pārvaldību, autentifikāciju, drošas pamatkonfigurācijas, žurnālfiksēšanu un uzraudzību, ielāpu pārvaldību, ievainojamību pārvaldību, jaudas plānošanu un IT operāciju ziņošanu. Tieši šie operacionālie dokumenti ir nepieciešami, lai NIS2 tehniskos pasākumus padarītu auditējamus.

Step 26 skaidro, kā jāvāc audita pierādījumi:

Vācot pierādījumus, reģistrējiet savus konstatējumus. Atzīmējiet, kur prasība ir izpildīta (pozitīvi konstatējumi), un kur tā nav izpildīta (iespējamās neatbilstības vai novērojumi).

NIS2 kontekstā tas nozīmē pierādījumu izlases pārbaudi, pirms to pieprasa regulators, klienta vērtētājs vai sertifikācijas auditors.

Zenith Controls loma savstarpējā atbilstībā

Zenith Controls nav atsevišķs kontroles ietvars. Tas ir Clarysec savstarpējās atbilstības ceļvedis ISO/IEC 27001:2022 un ISO/IEC 27002:2022 kontroles pasākumu kartēšanai uz saistītajiem kontroles pasākumiem, audita gaidām un ārējiem ietvariem. Tas palīdz komandām saprast, kā viens ISO 27001:2022 kontroles pasākums var atbalstīt NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT tipa apliecinājumu.

Trīs ISO 27001:2022 kontroles pasākumi ir īpaši svarīgi NIS2 pierādījumu kartēšanai.

Kontroles pasākums 5.1 Informācijas drošības politikas ir sākumpunkts, jo NIS2 Article 21 ietver risku analīzi un informācijas sistēmu drošības politikas. Ja NIS2 tehniskais pasākums nav atspoguļots politikā, to ir grūti pārvaldīt un konsekventi auditēt.

Kontroles pasākums 5.36 Atbilstība informācijas drošības politikām, noteikumiem un standartiem ir realitātes pārbaude. Tas savieno politikas prasības ar faktisko atbilstību iekšējiem noteikumiem, standartiem un ārējiem pienākumiem. NIS2 izpratnē šī ir vieta, kur organizācija jautā, vai tā dara to, ko paredz tās Article 21 kartējums.

Kontroles pasākums 8.8 Tehnisko ievainojamību pārvaldība ir viena no sarežģītākajām 2026. gada testēšanas jomām. Ievainojamību pārvaldība ir tieši saistīta ar drošu iepirkumu, izstrādi, uzturēšanu, ievainojamību apstrādi un izpaušanu. Tā atbalsta arī DORA testēšanu un novēršanu, GDPR drošības pārskatatbildību, NIST CSF Identify un Protect rezultātus un ISO 27001 audita izlases.

Atbalsta standarti var pilnveidot dizainu, neprasot papildu sertifikācijas. ISO/IEC 27002:2022 sniedz ieviešanas norādījumus Annex A kontroles pasākumiem. ISO/IEC 27005 atbalsta informācijas drošības risku pārvaldību. ISO/IEC 27017 atbalsta mākoņdrošību. ISO/IEC 27018 atbalsta personu identificējošas informācijas aizsardzību publiskā mākoņa apstrādātāja scenārijos. ISO 22301 atbalsta darbības nepārtrauktību. ISO/IEC 27035 atbalsta incidentu pārvaldību. ISO/IEC 27036 atbalsta piegādātāju attiecību drošību.

Mērķis nav vairāk standartu pašu standartu dēļ. Mērķis ir labāks pierādījumu dizains.

Praktisks piemērs: izveidojiet NIS2 ievainojamību pierādījumu paketi

Apsveriet Marijas SaaS platformu. Tā apkalpo ES ražošanas klientus un ir atkarīga no mākoņpakalpojumiem, atvērtā pirmkoda komponentiem, CI/CD cauruļvadiem un pārvaldītas uzraudzības. Viņas trūkumu pārskatā norādīts “ievainojamību pārvaldība ieviesta”, taču pierādījumi ir izkaisīti pa skeneriem, Jira, GitHub, mākoņvides konfigurācijas rīkiem un izmaiņu pieteikumiem.

NIS2 vajadzībām gatavu pierādījumu paketi var izveidot vienā fokusētā sprintā.

1. solis: definējiet riska scenāriju

Risks: izmantojama ievainojamība internetam pieejamā lietojumprogrammā, atkarībā vai mākoņkomponentā izraisa pakalpojumu darbības traucējumus, nesankcionētu piekļuvi vai klientu datu ekspozīciju.

Risku reģistrā jāiekļauj apraksts, iespējamība, ietekme, vērtējums, īpašnieks un apstrādes plāns. Apstrādes plānā jānorāda atsauce uz ISO 27001:2022 kontroles pasākumu 8.8 Tehnisko ievainojamību pārvaldība, kā arī saistītie kontroles pasākumi aktīvu uzskaitei, drošai izstrādei, žurnālfiksēšanai, piekļuves kontrolei, piegādātāju pārvaldībai un reaģēšanai uz incidentiem.

2. solis: kartējiet risku uz NIS2 Article 21

Risks atbalsta Article 21 prasības drošam iepirkumam, izstrādei un uzturēšanai, ievainojamību apstrādei un izpaušanai, risku analīzei, incidentu apstrādei, piegādes ķēdes drošībai un kontroles efektivitātes izvērtēšanai.

3. solis: nostipriniet darbības noteikumus politikā

Izmantojiet ievainojamību pārvaldības procedūru, drošas izstrādes standartu, ielāpu pārvaldības prasības, drošības testēšanas politiku un audita pierādījumu noteikumus.

Uzņēmuma Drošības testēšanas un red teaming politika, 6.1. punkts nosaka:

Testu veidi: drošības testēšanas programmai vismaz jāietver: (a) ievainojamību skenēšana, kas sastāv no automatizētas iknedēļas vai ikmēneša tīklu un lietojumprogrammu skenēšanas zināmu ievainojamību identificēšanai; (b) ielaušanās testēšana, kas sastāv no konkrētu sistēmu vai lietojumprogrammu manuālas padziļinātas testēšanas, ko veic kvalificēti testētāji, lai identificētu sarežģītas vājās vietas; un (c) red teaming vingrinājumi, kas sastāv no scenārijos balstītām reālu uzbrukumu simulācijām, tostarp sociālās inženierijas un citu taktiku izmantošanas, lai pārbaudītu organizācijas atklāšanas un reaģēšanas spējas kopumā.

Šis punkts rada aizstāvamu testēšanas pamatlīmeni. Tas arī atbilst DORA gaidām par atkārtotu, riskā balstītu digitālās darbības noturības testēšanu aptvertajām finanšu iestādēm.

4. solis: definējiet pierādījumu metadatus

Audita un atbilstības uzraudzības politika - SME, 6.2.3. punkts nosaka:

Metadati (piemēram, kas tos savāca, kad un no kuras sistēmas) ir jādokumentē.

Ievainojamību pierādījumu paketē jāfiksē:

• Skenera nosaukums un konfigurācija
• Skenēšanas datums un laiks
• Aktīvu darbības joma un izņēmumi
• Kritiskie un augstie konstatējumi
• Pieteikuma numurs un īpašnieks
• Ielāpa vai mazināšanas lēmums
• Riska pieņemšanas lēmums, ja piemērojams
• Novēršanas datums
• Validācijas skenēšana
• Saite uz izmaiņu ierakstu
• Izņēmuma īpašnieks un beigu datums

5. solis: pievienojiet žurnālfiksēšanas pierādījumus

Žurnālfiksēšanas un uzraudzības politika - SME, 5.4.4. punkts ietver sistēmas žurnālus, piemēram:

Sistēmas žurnāli: konfigurācijas izmaiņas, administratīvās darbības, programmatūras instalācijas, ielāpu uzstādīšanas darbība

Ar ielāpa pieteikumu vien var nepietikt, lai pierādītu, ka izmaiņa tiešām veikta. Konfigurācijas žurnāli, administratīvās darbības un programmatūras instalācijas ieraksti stiprina pierādījumu ķēdi.

6. solis: veiciet izlases auditu

Atlasiet piecas kritiskas vai augstas ievainojamības no iepriekšējā ceturkšņa. Katram vienumam pārbaudiet, vai aktīvs bija uzskaitē, skeneris konstatēja atradumu, pieteikums tika atvērts SLA ietvaros, tika piešķirts īpašnieks, novēršana atbilda smaguma pakāpei un izmantojamībai, žurnāli parāda izmaiņu, validācija apstiprina slēgšanu un jebkuram izņēmumam ir riska īpašnieka apstiprinājums ar beigu datumu.

Šis sprints rada NIS2 vajadzībām gatavu ievainojamību pierādījumu paketi un ISO 27001:2022 iekšējā audita izlasi.

Piegādātāju drošība ir ekosistēmas pārvaldība

NIS2 Article 21 prasa piegādes ķēdes drošību, tostarp drošības aspektus attiecībās ar tiešajiem piegādātājiem un pakalpojumu sniedzējiem. Tas arī paredz, ka organizācijas ņem vērā piegādātāju ievainojamības, produktu kvalitāti, piegādātāju kiberdrošības prakses un drošas izstrādes prakses.

Tieši šeit Marijas trūkumu pārskata pirmā versija bija vājākā. Tajā bija uzskaitīti piegādātāji, taču tas nepierādīja sākotnējo izpēti, līguma drošības klauzulas, uzraudzību vai gatavību izstāšanās procesam.

Trešo pušu un piegādātāju drošības politika nodrošina politikas enkuru. Saistīto ieviešanu var atbalstīt Drošas izstrādes politika, Informācijas drošības informētības un apmācības politika, Ievainojamību un ielāpu pārvaldības politika, Kriptogrāfisko kontroles pasākumu politika, Piekļuves kontroles politika un Attālinātās piekļuves politika.

Viens piegādātāju pierādījumu reģistrs var atbalstīt NIS2, DORA un ISO 27001:2022.

Šī tabula novērš dublētas anketas, dublētus reģistrus un pretrunīgu kontroles pasākumu īpašumtiesību sadalījumu.

Viena incidentu darbplūsma NIS2, DORA un GDPR vajadzībām

NIS2 Article 23 prasa paziņot par būtiskiem incidentiem bez nepamatotas kavēšanās. Tas nosaka pakāpenisku termiņu: agrīns brīdinājums 24 stundu laikā no apzināšanās brīža, incidenta paziņojums 72 stundu laikā ar sākotnējo smaguma pakāpes vai ietekmes izvērtējumu un pieejamajiem kompromitācijas indikatoriem, starpposma atjauninājumi pēc pieprasījuma un galīgais ziņojums ne vēlāk kā vienu mēnesi pēc incidenta paziņojuma.

DORA finanšu iestādēm paredz līdzīgu dzīves ciklu: atklāšana, klasifikācija, žurnālfiksēšana, smaguma pakāpes izvērtēšana, eskalācija, klientu komunikācija, ziņošana iestādei, pamatcēloņa analīze un novēršana. GDPR pievieno personas datu aizsardzības pārkāpuma analīzi, tostarp pārziņa un apstrādātāja lomas, ietekmi uz datu subjektiem un 72 stundu paziņošanas termiņu, ja piemērojams.

Pareizais dizains nav trīs incidentu procesi. Tā ir viena incidentu darbplūsma ar regulatīvo lēmumu atzariem.

Incidentu reaģēšanas politika - SME, 5.4.1. punkts nosaka:

Visas incidentu izmeklēšanas, konstatējumi un korektīvās darbības jāreģistrē incidentu reģistrā, ko uztur ģenerāldirektors.

Spēcīgam incidentu reģistram jāietver:

GDPR saikni nedrīkst novērtēt par zemu. NIS2 kompetentās iestādes var informēt GDPR uzraudzības iestādes, ja kiberdrošības risku pārvaldības vai ziņošanas trūkumi var izraisīt personas datu aizsardzības pārkāpumu. Tāpēc ISMS jāiekļauj privātuma izvērtēšana incidentu triāžā, nevis jāatstāj kā pēcdoma.

Kā auditori un regulatori testēs jūsu NIS2 pierādījumus

2026. gadam gatavai organizācijai jāparedz, ka viens un tas pats kontroles pasākums tiks testēts no dažādiem skatījumiem.

ISO 27001:2022 auditors sāks ar ISMS. Auditors jautās, vai NIS2 pienākumi ir identificēti kā ieinteresēto pušu prasības, vai ISMS darbības joma aptver attiecīgos pakalpojumus un atkarības, vai riski ir izvērtēti un apstrādāti, vai piemērojamības deklarācija pamato piemērojamos kontroles pasākumus un vai ieraksti pierāda darbību.

NIS2 kompetentā iestāde koncentrēsies uz juridiskajiem rezultātiem. Tā var jautāt, vai visi Article 21 pasākumi ir aptverti, vai kontroles pasākumi ir atbilstoši un samērīgi, vai vadība pasākumus ir apstiprinājusi un pārrauga, un vai incidentu ziņošana var izpildīt noteiktos termiņus.

DORA uzraugs aptvertajām finanšu iestādēm testēs IKT risku pārvaldību, incidentu klasifikāciju, noturības testēšanu, trešo pušu risku, līgumiskās vienošanās, koncentrācijas risku un izstāšanās stratēģijas.

GDPR pārskatītājs testēs, vai tehniskie un organizatoriskie pasākumi aizsargā personas datus, vai pārkāpuma izvērtēšana ir iestrādāta incidentu apstrādē, vai pārziņa un apstrādātāja lomas ir skaidras un vai pastāv pārskatatbildības ieraksti.

NIST CSF 2.0 vai COBIT 2019 tipa vērtētājs koncentrēsies uz pārvaldību, atbildību par risku, veiktspējas rādītājiem, pašreizējiem un mērķa rezultātiem, procesa spēju un saskaņošanu ar uzņēmuma riska apetīti.

Uzņēmuma Audita un atbilstības uzraudzības politika, 3.4. punkts formulē pierādījumu mērķi:

Radīt aizstāvamus pierādījumus un audita pēdu regulatīvo pieprasījumu, tiesvedības vai klientu apliecinājuma pieprasījumu atbalstam.

Tas ir operacionālais standarts, uz kuru NIS2 komandām jāvirzās.

Vadības pārskatatbildība: valde nevar deleģēt NIS2 prom

NIS2 Article 20 prasa būtisko un svarīgo subjektu vadības institūcijām apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt ieviešanu un saņemt apmācību. Vadības institūciju locekļi par pārkāpumiem var tikt saukti pie atbildības saskaņā ar nacionālajiem atbildības noteikumiem.

Tas atbilst ISO 27001:2022 līderības prasībām. Augstākajai vadībai jānodrošina, ka informācijas drošības politika un mērķi ir saskaņoti ar stratēģisko virzienu, ISMS prasības ir integrētas biznesa procesos, ir nodrošināti resursi, ir komunicēta nozīmība, piešķirtas atbildības un veicināta nepārtraukta uzlabošana.

Valdei nav vajadzīgi neapstrādāti skeneru eksporti vai pilni SIEM žurnāli. Tai ir vajadzīgs lēmumu pieņemšanai piemērots apliecinājums.

Ceturkšņa NIS2 valdes pierādījumu paketē jāiekļauj:

1. Darbības jomas un regulatīvā statusa izmaiņas
2. Būtiskākie NIS2 riski un apstrādes statuss
3. Article 21 kontroles efektivitātes informācijas panelis
4. Nozīmīgi incidenti, gandrīz notikuši gadījumi un ziņošanas lēmumi
5. Piegādātāju un mākoņpakalpojumu risku izņēmumi
6. Iekšējā audita konstatējumi, korektīvās darbības un nokavēti pierādījumi

Šī pakete sniedz vadībai informāciju, kas nepieciešama pasākumu apstiprināšanai, izņēmumu apstrīdēšanai un atlikušā riska pieņemšanai.

Clarysec 2026. gada darbības modelis

NIS2 tehnisko pasākumu ieviešanai ar ISO 27001:2022 nepieciešams vienkāršs, bet disciplinēts modelis:

• Iekļaujiet NIS2, DORA, GDPR un līgumiskos pienākumus ISMS darbības jomā
• Kartējiet pienākumus uz riskiem, politikām, kontroles pasākumiem, īpašniekiem un pierādījumiem
• Izmantojiet piemērojamības deklarāciju kā kontroles pasākumu patiesības avotu
• Veidojiet pierādījumu paketes augsta riska Article 21 jomām
• Integrējiet incidentu ziņošanu vienā regulatīvajā darbplūsmā
• Uztveriet piegādātāju drošību kā dzīves ciklu, nevis anketu
• Veiciet iekšējos auditus, izmantojot reālas izlases
• Ziņojiet kontroles efektivitāti vadības institūcijām
• Uzlabojiet, balstoties uz incidentiem, audita konstatējumiem, testiem un regulatīvajām izmaiņām

Marijai pagrieziena punkts bija atziņa, ka viņai nav vajadzīgs atsevišķs NIS2 projekts. Viņai bija vajadzīgs spēcīgāks ISMS pierādījumu dzinējs.

Clarysec politikas, Zenith Blueprint un Zenith Controls ir izstrādāti darbam kopā. Politikas definē sagaidāmo rīcību un ierakstus. Zenith Blueprint sniedz 30 soļu ieviešanas un audita ceļu. Zenith Controls nodrošina savstarpējās atbilstības kartējumu, lai NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF un COBIT tipa apliecinājumu varētu pārvaldīt kā vienotu, saskaņotu programmu.

Nākamais solis: izveidojiet NIS2 un ISO 27001:2022 pierādījumu karti

Ja jūsu NIS2 darbs joprojām dzīvo trūkumu izklājlapā, 2026. gads ir laiks to ieviest darbībā.

Sāciet ar vienu augsta riska tehnisko pasākumu, piemēram, ievainojamību pārvaldību, incidentu apstrādi vai piegādātāju drošību. Kartējiet to uz ISO 27001:2022 riskiem, politikām, Annex A kontroles pasākumiem, īpašniekiem, procedūrām un pierādījumiem. Pēc tam atlasiet pagājušā ceturkšņa ierakstus un uzdodiet sarežģītu jautājumu: vai tas apmierinātu regulatoru, klienta vērtētāju un ISO 27001:2022 auditoru?

Clarysec var palīdzēt jums izveidot šo atbildi, izmantojot politiku bibliotēku, Zenith Blueprint un Zenith Controls.

Mērķis nav vairāk dokumentācijas. Mērķis ir aizstāvami, atkārtojami pierādījumi, ka jūsu NIS2 tehniskie pasākumi faktiski darbojas.