NIS2 ieviešana pašu spēkiem vai ar konsultantu? Izmaksu, laika un risku salīdzinājums

Izvēli starp NIS2 ieviešanu pašu spēkiem un ārēja ieviešanas partnera piesaisti nevar pamatot tikai ar konsultanta atlīdzības un iekšējās komandas darba izmaksu salīdzinājumu. Projekta rezultātu nosaka pienākumu tvērums, lēmumu pieņēmēju pieejamība, procesu un resursu datu kvalitāte, kā arī organizācijas spēja pēc projekta uzturēt ieviestos risinājumus. Šķietami lētākais variants var izrādīties visdārgākais, ja tā dēļ organizācija kļūdaini nosaka savu statusu, atkārtoti veic analīzes vai izstrādā dokumentāciju, kas neatbilst faktiskajai darbībai. Tādēļ vispirms jānosaka tvērums un neatbilstības, pēc tam jāsalīdzina triju īstenošanas modeļu pilnās izmaksas, termiņi un riski un tikai tad jāizvēlas izpildītājs un darba organizācijas modelis.

Neizvēlieties izpildītāju, pirms nav noteikti pienākumi

Ieviešanu pašu spēkiem un ārēja atbalsta izmantošanu var korekti salīdzināt tikai pēc tam, kad ir noskaidrots, vai uz organizāciju attiecas NIS2 un attiecīgie nacionālie normatīvie akti, ar kuriem šīs prasības tiek ieviestas. Ja prasības ir piemērojamas, jānosaka, uz kuriem pakalpojumiem, struktūrvienībām, atrašanās vietām un resursiem attiecas novērtējums. Bez šādas kvalifikācijas nav iespējams ticami aplēst darba apjomu, izpildes laiku vai izmaksas. Vadībai jāieceļ arī projekta īpašnieks ar pilnvarām koordinēt lēmumus starp pamatdarbības struktūrvienībām, juridisko funkciju un IT.

Sākuma punkts nav dokumentu paketes vai IT rīka iegāde, bet gan organizācijas darbības modeļa apraksts. Jāidentificē sniegtie pakalpojumi, tos atbalstošie procesi, sistēmas un dati, kā arī piegādātāji un atkarības, no kurām ir atkarīga darbības nepārtrauktība. Tikai šāda karte ļauj noteikt, vai novērtējumā jāiekļauj viss uzņēmums vai tikai konkrēti pakalpojumi un atrašanās vietas. Pirmā posma rezultātam jābūt dokumentētam organizācijas statusa izvērtējumam, noteiktām tvēruma robežām un to jomu sarakstam, kurās nepieciešams novērtējums un korektīvi pasākumi.

Formāla pakļautība normatīvo aktu prasībām jānošķir no uzņēmējdarbības vajadzības paaugstināt noturību. Organizācija var neietilpt tiesību aktos noteiktajā tvērumā, tomēr tai var būt saistošas klientu, uzņēmumu grupas, apdrošinātāja vai piegādes ķēdes dalībnieku prasības. Šādu projektu nevajadzētu pasniegt kā juridiska pienākuma izpildi. Tas ir jāpozicionē kā atbilde uz konkrētām līgumiskām prasībām un darbības riskiem.

Piemērs ir ražošanas uzņēmums, kurā darbojas ugunsmūri, rezerves kopēšana un darbstaciju aizsardzība, bet nav iespējams nosaukt incidentu reaģēšanas procesa īpašnieku. Uzņēmums arī nav izvērtējis, kā ražošanas plānošanas sistēmas atteice ietekmēs pasūtījumu grafiku, materiālu pieejamību un piegāžu savlaicīgumu. Šādā situācijā problēma nav tikai tehnisko drošības pasākumu līmenis. Trūkst arī skaidri noteiktas atbildības un analīzes par IT sistēmas saistību ar pakalpojuma nodrošināšanu.

Pēc darbības modeļa aprakstīšanas jāveic juridiskais izvērtējums atbilstoši publicēšanas dienā aktuālajiem nozaru, subjektu un lieluma kritērijiem. Formālais secinājums jāapstiprina institūcijai vai personai, kura ir pilnvarota pārstāvēt organizāciju, iesaistot juridisko funkciju un pakalpojumu un procesu īpašniekus. IT funkcija nodrošina informāciju par sistēmām, taču tai nevajadzētu vienpersoniski lemt par organizācijas kvalifikāciju. Plašāk šis jautājums aplūkots materiālā „NIS2 direktīva — uz ko tā attiecas un kuriem uzņēmumiem jāizpilda jaunās prasības?”.

Ieviešanas izmaksas nebeidzas ar konsultanta rēķinu

Ieviešana pašu spēkiem nav bezmaksas, un arī ieviešanas uzņēmuma atlīdzība neatspoguļo visas ārējā atbalsta izmaksas. Aprēķinā jāiekļauj vadības, procesu īpašnieku, IT, iepirkumu, personāla vadības, juridiskās funkcijas un vadības sistēmas koordinatora darbs. Šo cilvēku laiks jānovērtē pēc iekšējām izmaksu likmēm un faktiskajām darba stundām, ņemot vērā arī ikdienas pienākumus, kurus viņi projekta laikā nevarēs izpildīt. Darbietilpību galvenokārt nosaka tvērumā iekļauto atrašanās vietu, procesu, sistēmu, piegādātāju un uzņēmumu skaits.

Visbiežāk netiek pienācīgi novērtēta datu apkopošana, atbildību saskaņošana, aktīvu un piegādātāju inventarizācija, pierādījumu sagatavošana, testu un apmācību veikšana, kā arī pretrunīgu iekšējo noteikumu labošana. Ārējais ieviešanas partneris šos darbus var saīsināt tikai tad, ja spēj prasības sasaistīt ar organizācijā jau pastāvošajiem procesiem, lomām un rīkiem. Standarta politiku nodošana bez darbības izpratnes izmaksas nenovērš — tās tikai pārceļ uz saskaņošanas, ieviešanas un turpmāko aktualizāciju posmu.

Incidentu pārvaldības dokumentāciju var sagatavot ātri, taču tā būs formāla, ja nav saskaņotas dežūras, eskalācijas kārtība, pierādījumu saglabāšana un aizvietošana. Patiesās izmaksas kļūs redzamas testa vai reāla incidenta laikā, kad procedūra būs jāpārstrādā. Tādēļ budžetā jānošķir vienreizējie un pastāvīgie izdevumi un jāiekļauj konsultanta atlīdzība, tehniskie ieguldījumi, projekta izraisītā dīkstāve, labojumi un ikgadējā uzturēšana: pārskatīšana, testi, apmācības, dokumentācijas aktualizēšana, piegādātāju novērtēšana un incidentu apstrāde.

Darbojoša informācijas drošības pārvaldības sistēma vai sertifikāts var samazināt inventarizācijas, risku novērtēšanas, dokumentētās informācijas pārvaldības un auditu darba apjomu, ja risinājumi patiešām darbojas vērtētajā tvērumā. Tomēr tas neaizstāj konkrētu piemērojamo normatīvo pienākumu izvērtējumu un nepierāda, ka esošie drošības pasākumi ir atbilstoši aptvertajiem pakalpojumiem. Šī saistība izskaidrota materiālā NIS2 un LVS EN ISO 27001: ko nodrošina sertifikāts un kā vēl var trūkt atbilstībai KSC prasībām.

Termiņu nosaka organizācijas gatavība pieņemt lēmumus

Gatavojoties NIS2 prasībām, termiņu reti nosaka procedūru izstrādes ātrums. Galvenie ierobežojumi ir ticamu datu, procesu īpašnieku un izmaiņu apstiprināšanai pilnvaroto personu pieejamība. Plānā jāņem vērā šo personu faktiskā noslodze, vadības komitejas sanāksmju biežums un starpstruktūru lēmumiem nepieciešamais laiks. Solītais dokumentācijas nodošanas datums nav progresa mērs, ja organizācija vēl nav apstiprinājusi tvērumu, atbildības un prioritātes.

Darbi jāplāno atbilstoši savstarpējām atkarībām. Vispirms jānosaka tvērums, lomas, procesi un aktīvi, pēc tam jāveic risku analīze, jāapstiprina risku apstrādes plāns, jāievieš drošības pasākumi, jāveic testi un jāapkopo darbības pierādījumi. Paralēli var izpildīt uzdevumus, kuru pamatā ir vieni un tie paši apstiprinātie pieņēmumi, piemēram, līgumu inventarizāciju un esošo drošības pasākumu pārskatīšanu. Savukārt detalizētu risku analīzi nevajadzētu sākt, pirms nav identificēti vērtējumā iekļaujamie pakalpojumi, procesi, sistēmas, informācija un atkarības no piegādātājiem.

Nosakot darbu secību, jānošķir nepilnības, kuru novēršanai nepieciešami iepirkumi, līgumu grozījumi, tehniskā integrācija vai testi. Katrai no šīm grupām ir atšķirīgs apstiprināšanas ceļš un izpildes termiņš. Ārējais atbalsts var paātrināt diagnostiku, padarīt darba sesijas efektīvākas un strukturēt rezultātus, taču konsultants vadības vietā nepieņems lēmumus par risku akceptēšanu, investīciju secību vai pieļaujamo pakalpojuma pārtraukuma ilgumu. Ja šādi lēmumi tiek atlikti līdz projekta beigām, dokumentācija apsteidz praktiskos risinājumus un daļa analīžu jāveic atkārtoti.

Tādēļ progresu vajadzētu mērīt pēc apstiprināto lēmumu, novērsto atkarību un pārbaudīto drošības pasākumu skaita, nevis pēc izstrādāto dokumentu apjoma. Pat dažu nedēļu grafiks nebūs izpildāms, ja organizācijai nav aktuāla sistēmu saraksta, piegādātāju līgumu reģistra un saskaņotu procesu īpašnieku. Šādā gadījumā komanda var aprakstīt deklarēto stāvokli, taču nespēs noteikt atbildību par darbības nepārtrauktību, pakalpojumu atjaunošanu un piegādātāju uzraudzību.

Procesu kartēšanai jāatbalsta tieši šādi lēmumi, nevis jāvairo dokumentu apjoms. Izvēlēties piemērotu detalizācijas pakāpi palīdz salīdzinājums „BPMN vai blokshēma — kurš rīks ir piemērotāks kvalitātes procesu kartēšanai?”. Šajā gadījumā piemērots ir rīks, kas nepārprotami parāda lomas, atbildības nodošanas punktus, informācijas atkarības un jomas, kurās vajadzīgi drošības vai aizvietošanas risinājumi.

Risks visbiežāk izriet no nepareiziem pieņēmumiem

Gatavošanās NIS2 prasībām rezultātu biežāk nosaka pieņēmumu pareizība, nevis izpildīto uzdevumu skaits. Pašu spēkiem īstenotā modelī lielākais risks ir saistīts ar nepareizu tvēruma interpretāciju, uzņēmējdarbības atkarību neievērošanu un kiberdrošības reducēšanu līdz IT funkcijas atbildībai. Organizācija var neiekļaut ražošanas procesus, loģistiku, tehnisko apkopi, piegāžu nepārtrauktību vai saistības pret klientiem. Trūkst arī neatkarīga skatījuma uz praksi, ko organizācija uzskata par pietiekamu tikai tādēļ, ka līdz šim tā nav izraisījusi acīmredzamus traucējumus.

Ārējais atbalsts šos riskus automātiski nenovērš. Risku palielina izpildītājs, kurš nodod standartizētu dokumentu paketi, neizprotot organizācijas pakalpojumus, procesus un atkarības, neiesaista procesu īpašniekus vai nenodod zināšanas, kas nepieciešamas risinājumu uzturēšanai. Rezultātā rodas sistēma, kas ir atkarīga no dokumentu autora, nevis no cilvēkiem, kuri atbild par ikdienas darbību.

Tādēļ darbu izpildi ir lietderīgi nošķirt no neatkarīga noslēguma novērtējuma, jo īpaši tad, ja viena un tā pati organizācija ir noteikusi tvērumu, novērtējusi riskus un izvēlējusies drošības pasākumus. Lēmumam par atlikušā riska akceptēšanu jāpaliek attiecīgās vadības kompetencē.

Formāla atbilstība atklājas neatbilstībā starp dokumentēto un faktisko praksi: politika apraksta citu rīcību nekā reālais process, risku reģistrs neietekmē prioritātes un investīcijas, bet incidentu pārvaldības procedūra nav izmēģināta. Dokumentācijas nepilnība ir vajadzīga dokumenta neesamība vai pretruna tajā. Operacionāla nepilnība pastāv, ja organizācija nespēj izpildīt darbību, noteikt atbildīgo vai uzrādīt pierādījumus par rezultativitāti. Veidlapas aizpildīšana var novērst pirmo nepilnību, taču tā neaizstāj testu, lēmumu vai darba metodes maiņu.

Piemērs ir ražotne ar apstiprinātu incidentu ziņošanas procedūru, kuras ražošanas darbinieki nezina, kā ziņot par vadības vai plānošanas sistēmas nepieejamību. Vienlaikus ar pakalpojuma sniedzēju nav saskaņota eskalācijas kārtība, kontaktpersonas vai rīcība ārpus darba laika. Dokuments pastāv, taču traucējuma pirmajās minūtēs laiks tiek zaudēts, noskaidrojot atbildības. Šādu nepilnību atklās tikai mācību scenārijs, kurā piedalās lietotājs, procesa īpašnieks, IT, vadība un piegādātājs.

Gatavības auditā jāpārbauda spēja rīkoties un uzrādīt ticamus pierādījumus, nevis tikai dokumentācijas pilnīgums. Noderīgi rādītāji ir neizpildīto pasākumu skaits pēc iepriekšējiem auditiem un testiem, atjaunošanas pārbaužu rezultāti, incidentu un darbības traucējumu pārskatu secinājumi, kā arī to kritiski svarīgo piegādātāju īpatsvars, kuri ir novērtēti un ar kuriem saskaņotas prasības. Šie rādītāji vienmēr jābalsta organizācijas datos. Šādas pārbaudes veikšana plašāk aplūkota materiālā „NIS2 audits ražošanas uzņēmumā — kā pārbaudīt organizācijas gatavību jaunajiem pienākumiem”.

Jauktais modelis parasti nodrošina vislabāko kontroli

Ieviešanas modelis jāizvēlas, ņemot vērā organizācijas faktisko spēju izpildīt darbus, nevis tikai konsultantu likmju salīdzinājumu. Ieviešana pašu spēkiem ir pamatota, ja projektam ir kompetents īpašnieks, risku pārvaldības procesi ir pietiekami nobrieduši, resursu un atkarību inventarizācija ir aktuāla, bet galvenajiem darbiniekiem ir pieejams laiks un spēja interpretēt prasības. Plašāks ārējais atbalsts ir pamatots, ja pastāv būtisks kompetenču trūkums, izkliedēta struktūra, nozīmīgas tehnoloģiskās atkarības, īss sagatavošanās termiņš vai nav sakārtotas vadības sistēmas.

Visbiežāk labāko izmaksu, laika un risku kontroli nodrošina jauktais modelis. Organizācija saglabā atbildību par lēmumiem, sākotnējiem datiem, risku īpašumtiesībām un operacionālo pasākumu izpildi. Konsultants atbild par diagnostiku, metodiku, darba sesiju vadīšanu, analīzēm, kurām nepieciešamas specializētas zināšanas, un rezultātu kvalitātes kontroli.

Organizācijas kompetencē jāpaliek vismaz:

• procesu un pakalpojumu nozīmīguma noteikšanai;
• risku īpašnieku iecelšanai;
• atlikušā riska akceptēšanai;
• investīciju prioritāšu noteikšanai;
• apstiprinājumam, ka drošības pasākumi darbojas praksē.

Vadība nevar nodot ārējam izpildītājam atbildību par organizācijas noturību.

Uzņēmums ar vairākām ražotnēm var patstāvīgi apkopot informāciju par pakalpojumiem, resursiem, piegādātājiem un traucējumu sekām, jo ticamam novērtējumam ir vajadzīgas operacionālās zināšanas. Ārējais speciālists pēc tam var strukturēt novērtēšanas metodi, apstrīdēt nepamatotus vai pretrunīgus pieņēmumus, vadīt starpfunkcionālas darba sesijas un pārbaudīt pierādījumu pilnīgumu. Šāda sadalījuma lietderību nosaka faktiski pieejamo cilvēku skaits un kompetence, nevis formālais projekta komandas sastāvs.

Piedāvājumi jāsalīdzina pēc vienāda nodevumu tvēruma un pieņemšanas kritērijiem. Izpildītāja atsauksmes jāvērtē pēc nozares, mēroga, procesu un tehnoloģiskās vides līdzības, nevis tikai pēc īstenoto projektu skaita. Līgumā nepārprotami jānosaka darba rezultāti, pieņemšanas kritēriji, pienākums risinājumus sasaistīt ar faktiskajiem procesiem, zināšanu nodošana, konfidencialitātes un piekļuves sensitīviem datiem noteikumi, atbildība par labojumiem un atbalsta tvērums pēc ieviešanas. Atlīdzības modelim nevajadzētu stimulēt dokumentu skaita palielināšanu, bet gan saskaņotu un pārbaudāmu rezultātu sasniegšanu.

Vadības, procesu īpašnieku un atbalsta funkciju praktiskās atbildības robežas plašāk aplūkotas materiālā NIS2 vadības praksē: kā prasības pārvērst lēmumos, atbildībā un organizācijas faktiskā noturībā.

Balstiet lēmumu pierādījumos un spējā sistēmu uzturēt

Pirms ieviešanas modeļa izvēles jāveic īsa organizatoriskā diagnostika. Jāapstiprina projekta tvērums, jāieceļ tā īpašnieks, jānovērtē kompetenču pieejamība, jāinventarizē esošie darbības pierādījumi un jāaplēš būtiskākās nepilnības. Tikai pēc tam var noteikt, kurus darbus organizācija veiks pati un kuros ārēja speciālista iesaiste samazinās kļūdainas interpretācijas, izlaidumu vai atkārtota darba risku.

Vadības lēmumā jāsalīdzina trīs varianti: ieviešana pašu spēkiem, jauktais modelis un plašāks ārējais atbalsts. Katrs variants jāvērtē pēc vienādiem kritērijiem:

• pilnās izmaksas, tostarp personāla darbs, labojumi un uzturēšana;
• laiks, kas vajadzīgs operacionālās gatavības sasniegšanai;
• kļūdu un atkārtota darba risks;
• kompetenču faktiskā pieejamība;
• organizācijas spēja risinājumus turpmāk uzturēt patstāvīgi.

Valdes lēmumā vai citā vadības apstiprinājumā jānorāda izvēlētais variants, atbildības tvērums, projekta īpašnieks, resursi, ziņošanas kārtība, pieņemšanas kritēriji un efektivitātes rādītāji, kas izriet no organizācijas procesiem, nevis no universālām robežvērtībām bez konteksta.

Ieviešanu nevajadzētu pieņemt, pamatojoties uz sagatavoto politiku skaitu. Rezultātam jābūt atkārtojamai darbībai: noteiktām lomām, dokumentētiem risku lēmumiem, ieviestiem drošības pasākumiem, pārbaudītai reaģēšanai uz traucējumiem un incidentiem, piegādātāju uzraudzībai un ticamiem ierakstiem. Apstiprināta reaģēšanas procedūra nepierāda gatavību, ja tests atklāj novecojušu kontaktinformāciju, neskaidru eskalācijas kārtību vai tādas personas neesamību, kura ir pilnvarota pieņemt lēmumu.

Pieņemšanas kritērijiem jāaptver dokumentu atbilstība faktiskajai praksei, saskaņoto nepilnību novēršana, testu rezultāti, zināšanu nodošana un nepārprotams turpmākās pilnveidošanas plāns, tostarp iekšējo auditu programma. Pieņemšanas pierādījumi var ietvert apstiprinājumus, reģistrus, testu rezultātus, apmācību protokolus, lēmumus par riskiem un pasākumu izpildes apliecinājumus. Šādu pierādījumu sagatavošana un uzturēšana plašāk skaidrota materiālā NIS2 un KSC dokumentācija pirms pārbaudes: kādas politikas, reģistri un pierādījumi patiešām ir nepieciešami.

Risinājuma ilgtspēju var novērtēt tikai pēc konsultanta iesaistes samazināšanas. Procesu īpašniekiem tad jāspēj patstāvīgi aktualizēt reģistrus, pieņemt ar riskiem saistītus lēmumus, analizēt testu rezultātus un ierosināt korektīvās darbības. Ja sistēma darbojas tikai ārējā izpildītāja zināšanu dēļ, projekts nav pabeigts: organizācija ir saņēmusi dokumentāciju, bet nav izveidojusi spēju to uzturēt.