NIS2 ir LST EN ISO 27001: ką užtikrina sertifikatas ir ko dar trūksta atitikčiai KSC

Daugelyje įmonių diskusija apie NIS2 prasideda nuo klausimo dėl LST EN ISO 27001 sertifikato. Tai suprantama, tačiau vadovybės ir procesų savininkų požiūriu tai nėra tinkamas atspirties taškas. Pirmiausia reikia nustatyti, ar organizacijai taikomi atitinkami įpareigojimai, kokias paslaugas bei išteklius jie apima ir kas už juos atsako. Tik tada galima pagrįstai įvertinti, kuriuos reikalavimus esama informacijos saugumo valdymo sistema iš tikrųjų apima, o ko dar trūksta atitikčiai KSC. Praktikoje būtent čia išryškėja skirtumas tarp veikiančios sistemos ir brangiai kainuojančios pasirengimo iliuzijos.

Brangiausia klaida – sertifikatą prilyginti atitikčiai

Didžiausia pradinė klaida yra ne LST EN ISO 27001 sertifikato neturėjimas, o prielaida, kad sertifikatas savaime patvirtina atitiktį NIS2 ir nacionalinių KSC įgyvendinančių teisės aktų reikalavimams. Vadovybei svarbu klausti ne „ar turime LST EN ISO 27001“, bet „ar mums taikomi šie įpareigojimai, kokiu statusu ir kurių paslaugų, procesų bei išteklių atžvilgiu“. Tik nustačius subjekto statusą, reikalavimų apimamą veiklos sritį ir vadovybės atsakomybę galima įvertinti, kiek esama sistema realiai padeda užtikrinti atitiktį, o kur tik sukuria tvarkos įspūdį.

Šis skirtumas tiesiogiai veikia projekto apimtį ir biudžetą. Sertifikatas patvirtina, kad nustatytos sertifikavimo apimties valdymo sistema atitinka standarto reikalavimus. Ši apimtis paprastai nurodoma sertifikate ir detalizuojama taikomumo pareiškime. Tačiau sertifikatas nepakeičia teisinių įpareigojimų analizės, esminių paslaugų identifikavimo, priklausomybės nuo tiekėjų vertinimo ar formalių veiksmų, kuriuos privalo atlikti reguliavimo sričiai priskirta organizacija, nustatymo. Todėl vadovybė turėtų atskirti tris praktikoje dažnai painiojamas sritis: valdymo sistemą, reguliacinę atitiktį ir operacinį pasirengimą veikti incidento sąlygomis.

Brangiausiai kainuoja projektai, vykdomi priešinga seka. Organizacija pirmiausia sutvarko dokumentus ir kontrolės priemones sertifikavimo auditui, o tik vėliau nustato, kad į sistemos apimtį nepateko kritiniai procesai, incidentų pranešimo pareigos, reikalavimai tiekėjams, vadovybės atsakomybė ar sektoriaus reikalavimai. Tokiu atveju kelių procedūrų papildyti nepakanka – tenka keisti sistemos apimtį, sprendimų priėmimo vaidmenis ir reagavimo modelį.

Operaciniu požiūriu verta vertinti ne vien sertifikato turėjimą, bet tris konkrečius aspektus: ar sertifikavimo apimtis atitinka kritines paslaugas, kokie yra KSC taikymo savęs vertinimo rezultatai ir kiek nustatyta spragų tarp procedūrose aprašytų veiksmų bei realaus gebėjimo juos atlikti. Todėl pirmasis žingsnis turėtų būti ne dokumentacijos plėtra, o nustatymas, ar organizacija patenka į reikalavimų taikymo sritį ir kokių formalių veiksmų iš jos tikimasi. Tokią seką aiškiai atskleidžia ir tema NIS2: savęs vertinimas ir įtraukimas į KSC sąrašą – ką turi padaryti gamybos įmonė?, nes būtent šiame etape paaiškėja, ar sistema kuriama pagal realius įpareigojimus, ar pagal patogią, bet brangiai kainuojančią pasirengimo iliuziją.

Ką LST EN ISO 27001 apima praktiškai, o ne tik deklaratyviai

Didžiausia praktinė LST EN ISO 27001 vertė yra ne pats sertifikatas, o tai, kad tinkamai įdiegta sistema leidžia valdyti informacijos saugumą kaip integruotą organizacijos veiklos sritį. Ji ypač naudinga ten, kur būtinas procesinis požiūris: vertinant ir valdant riziką, nustatant politikas ir kontrolės principus, paskirstant vaidmenis bei atsakomybę, identifikuojant informacinį turtą, reaguojant į incidentus, valdant veiklos tęstinumą ir taikant peržiūros bei gerinimo mechanizmus. Jei šie elementai veikia kasdienėje veikloje, o ne tik audito metu, organizacija turi tvirtą pagrindą parodyti, kad saugumas nėra pavienių priemonių rinkinys, bet valdoma sistema, susieta su operaciniais sprendimais.

Vis dėlto vadovybė turėtų vertinti ne patį sertifikatą, o jo naudą paslaugoms, procesams ir priklausomybėms, kurios svarbios reguliaciniu požiūriu. Tas pats sertifikatas gali reikšti brandžią sistemą, apimančią kritinius procesus, reguliarias peržiūras, korekcinius veiksmus ir realią procesų savininkų kontrolę, arba siaurą sistemą, taikomą tik pasirinktai organizacijos daliai. Todėl prieš atliekant savęs vertinimą pagal NIS2 ir KSC verta patikrinti ne tik taikomumo pareiškimą, bet ir rizikos vertinimo apimamų procesų sąrašą, vidaus auditų rezultatus, vadovybinės vertinamosios analizės išvadas bei tai, ar sprendimai dėl rizikos atsispindi biudžete, sutartyse, paslaugų architektūroje ir reagavimo tvarkoje.

Tai ypač aiškiai matoma tiekimo grandinėse veikiančiose įmonėse. LST EN ISO 27001 paprastai padeda susisteminti sutartinius reikalavimus, informacijos klasifikavimą, prieigos taisykles, tiekėjų atsakomybę ir nukrypimų dokumentavimą. Tai naudingas pagrindas, ypač kai klientai reikalauja įrodyti partnerių kontrolę. Tačiau sertifikatas automatiškai neapima visų konkrečiam sektoriui būdingų lūkesčių ar kriterijų. Panašus klausimas nagrinėjamas straipsnyje LST EN ISO 27001 ar TISAX – ką rinktis, kai klientas reikalauja informacijos saugumo tiekimo grandinėje? Praktikoje sertifikatas padeda nustatyti santykius ir atsakomybę, tačiau nepakeičia vertinimo, kokius papildomus įpareigojimus reikia įtraukti į sutartis, eskalavimo procedūras ir išorinių paslaugų kontrolę.

Išvada paprasta: sertifikatas gali gerokai sutrumpinti kelią iki sistemiškai valdomo saugumo, tačiau pats savaime nėra KSC įpareigojimų įvykdymo įrodymas. Sertifikavimo auditas vertina nustatytos apimties valdymo sistemos atitiktį standarto reikalavimams. Tai nėra tas pats, kas teisinių įpareigojimų ir operacinio pasirengimo vertinimas. Todėl organizacija turėtų lygiagrečiai patikrinti, ar sistemos apimtis apima svarbius procesus, ar rizikos vertinimas atnaujintas pagal realias paslaugas ir priklausomybes bei ar reagavimo, tęstinumo ir tiekėjų kontrolės procedūros veikia praktiškai.

Kur sertifikato nepakanka

Pirmoji spraga susijusi su pačia reguliacine atitiktimi. Informacijos saugumo valdymo sistema nustato taisykles, vaidmenis ir kontrolę, tačiau savaime neatsako, ar subjektas tinkamai identifikuotas KSC įpareigojimų kontekste, kas atsako už oficialius pranešimus, ryšius su kompetentinga institucija ir sprendimų eskalavimą vadovybei. Tai ne pavienio dokumento trūkumas, o atsakomybės modelio projektavimo problema. Jei šie elementai neintegruoti į realų įmonės veiklos modelį, sertifikatas padeda palaikyti vidaus tvarką, tačiau dar neužtikrina reguliacinio valdomumo.

Antroji spraga yra sistemos apimtis. Daugelio organizacijų sertifikavimo apimtis apsiriboja pasirinkta vieta, viena grupės bendrove, konkrečiu padaliniu ar dalimi pagalbinių paslaugų. Tuo tarpu pasirengimas KSC turi būti vertinamas pagal realų paslaugų, kritinių procesų, išteklių ir priklausomybių žemėlapį, o ne pagal sertifikavimo audito ribas. Jeigu esminė ar svarbi paslauga teikiama kelių grupės bendrovių, išorinio duomenų centro, bendros priežiūros komandos ar decentralizuoto incidentų valdymo proceso pastangomis, formaliai tinkamas sertifikatas gali apimti tik dalį visos sistemos. Tokiu atveju vadovybės sprendimas neturėtų apsiriboti klausimu, ar plėsti sertifikavimo apimtį. Reikia nuspręsti, ar kurti vieną integruotą atitikties programą, ar vykdyti dvi suderintas kryptis – sertifikavimo ir reguliacinės atitikties.

Trečioji spraga susijusi su įrodymais ir paprastai išryškėja tik incidento, pratybų ar patikrinimo metu. Organizacija turi reagavimo, veiklos tęstinumo ir tiekėjų kontrolės procedūras, tačiau negali įrodyti, kad šie mechanizmai veikia praktiškai. Trūksta incidentų registro, vadovybės sprendimų atsekamumo, pratybų rezultatų, įvykių analizės, veiksmingumo rodiklių ir dokumentuotų korekcinių veiksmų. Tokia sistema yra aprašyta, bet jos veikimas neįrodytas. Būtent čia atsiranda brangiausi taisymai, nes tenka keisti ne tik procedūrų turinį, bet ir atskaitomybę vadovybei, peržiūrų periodiškumą bei procesų savininkų atsakomybę. Tas pats mechanizmas pastebimas ir kitose valdymo sistemose, pavyzdžiui, temoje IATF 16949 – kurie reikalavimai iš tiesų kelia sunkumų kasdienėje kokybės valdymo praktikoje ir kaip juos valdyti nekuriant formalios atitikties regimybės.

Ketvirtoji spraga apima tiekimo grandinę ir išorines priklausomybes. Standartas padeda nustatyti reikalavimus tiekėjams, tačiau atitiktis KSC gali pareikalauti išsamesnio žemėlapio: kurios išorinės paslaugos palaiko kritinės paslaugos teikimą, kur yra pavienių gedimo taškų, kokie galimi sutrikimų scenarijai ir ar įmanoma pakeisti tiekėją, darbuotojus ar veiklos vietą. Praktikoje verta vertinti ne vien sutarčių ir tiekėjų vertinimų buvimą, o sertifikavimo apimties atitiktį realiam kritinių paslaugų žemėlapiui, incidentų bei pratybų registro išsamumą ir tiekėjų bei priklausomybių peržiūrų aktualumą. Tik toks palyginimas parodo, ar organizacija turi veikiančią sistemą, ar tik formalų jos vaizdą.

Atitikties projektą reikia pradėti nuo paslaugų, o ne dokumentų

Dažniausia pradinė klaida – projektą pradėti nuo LST EN ISO 27001 politikų, procedūrų ir įrašų peržiūros, užuot pirmiausia nustačius, kurios paslaugos iš tiesų turi būti išlaikytos ir kokie reguliaciniai įpareigojimai su jomis susiję. Tinkama seka yra priešinga: pirmiausia identifikuojamos paslaugos, procesai, ištekliai ir priklausomybės, kritinės veiklos tęstinumo bei atsakomybės pagal KSC požiūriu, o tik tada joms priskiriami sistemos ir įrodymų reikalavimai. Tik taip galima atskirti reikalingus dokumentus nuo perteklinių.

Vadovybei tai reiškia sprendimą sudaryti kritinių paslaugų, priklausomybių nuo tiekėjų ir sistemų bei esamų procedūrų, kurias galima panaudoti nedubliuojant kontrolės mechanizmų, žemėlapį. Tik tuomet matyti, ar esama sistema apima tai, kas iš tiesų svarbu paslaugų tęstinumui ir atitikčiai, ar tik tai, kas istoriškai pateko į sertifikavimo apimtį.

Antrasis žingsnis – atsakomybės modelis. Jei informacijos saugumo atsakomybė išskaidyta tarp IT, kokybės, atitikties, techninės priežiūros ir pirkimų funkcijų, o vaidmenys aiškiai neatskirti, projektas greitai tampa vietinių iniciatyvų rinkiniu. Todėl reikia nustatyti, kas atsako už riziką, incidentų valdymą, santykius su tiekėjais, vadovybės sprendimus ir atitikties įrodymų priežiūrą. Praktikoje veiksmingas sprendimas yra paprasta vaidmenų bei atsakomybės matrica ir vienas vadovybės peržiūrų ciklas vietoje kelių lygiagrečių ataskaitų teikimo kanalų. Šiame etape taip pat reikia nuspręsti, ar steigti bendrą atitikties ir saugumo valdymo komitetą ir ar operacines technologijas įtraukti į tą patį rizikos valdymo modelį.

Gamybos ir keliose vietose veikiančioms organizacijoms ši logika ypač svarbi. Incidento poveikis jose neapsiriboja duomenų konfidencialumo praradimu – jis gali sustabdyti gamybos liniją, sutrikdyti planavimą, panaikinti partijų atsekamumą arba apriboti gebėjimą teikti paslaugą. Todėl informacijos saugumą reikia susieti su veiklos tęstinumu, technine priežiūra ir operacinių technologijų aplinka. Jeigu valdymo sistema apima tik biuro infrastruktūrą, tačiau neapima valdymo sistemų, nuotolinio aptarnavimo, priklausomybės nuo integratorių ar avarinių procedūrų gamybos vietoje, rizikos vaizdas bus formaliai tvarkingas, bet operaciniu požiūriu nepilnas. Toks pats projektinis nuoseklumas reikalingas ir kitose griežtai kontroliuojamose srityse, kuriose taikomos tokios nuorodos kaip ASME, NQA-1 ir ISO 19443 – trys santrumpos, kurias turi žinoti branduolinio sektoriaus tiekėjas.

Tik sukūrus šį pagrindą verta pasinaudoti esama LST EN ISO 27001 sistema kaip bazine valdymo struktūra ir atlikti atskirą spragų analizę pagal KSC. Jos tikslas nėra ginčyti sertifikato vertę. Analizė turi parodyti, kur reikalavimai jau įgyvendinti, o kur reikia papildomų procedūrų, registrų, eskalavimo kelių ar veikimo įrodymų. Toks požiūris mažina perteklinę dokumentaciją ir leidžia geriau užtikrinti mechanizmų nuoseklumą nei atskiri, tarpusavyje konkuruojantys diegimo projektai.

Kaip patikrinti faktinę būklę prieš auditą ar patikrinimą

Prieš auditą, savęs vertinimą ar patikrinimą reikėtų klausti ne to, ar organizacija „turi LST EN ISO 27001“, bet ar ji gali įrodyti realų pasirengimą veikti ir sprendimų atskaitomybę. Pasirengimą verta vertinti keturiais lygmenimis: pirmiausia nustatyti įpareigojimų apimtį ir organizacijos statusą, tada įvertinti valdymo sistemos struktūrą, procesų veiksmingumą ir galiausiai – įrodymų išsamumą. Tik tokia seka leidžia atskirti dokumentų tvarką nuo operacinio pajėgumo.

Naudingiausi klausimai yra ne „ar turime procedūrą“, o „ar žinome, kada ją taikyti, kas priima sprendimą, kokie yra eskalavimo kriterijai, kaip tai įrodysime ir ar šį scenarijų esame išbandę“. Jeigu incidentų valdymas priklauso nuo vieno žmogaus žinių, sutartyse su tiekėjais nėra nustatytų saugumo kriterijų, o vadovybė gauna tik bendro pobūdžio ataskaitas be sprendimų ir terminų, sistema gali formaliai atitikti savo pačios aprašą, tačiau vis tiek nebūti pasirengusi veikti esant spaudimui.

Todėl pasirengimo peržiūra turėtų apimti vadovybės, operacijų, IT, techninės priežiūros ir tiekėjų sąsajas, nes būtent jose dažniausiai aptinkamos vien procedūrose nematomos spragos. Praktikoje geriausiai veikia operaciniam auditui artima spragų analizė. Jos metu vertinamas ne tik dokumentų turinys, bet ir sprendimų priėmimo eiga, eskalavimo keliai, incidentų įrašai, bandymų ir pratybų rezultatai, neatitikčių bei pastebėjimų registrai ir korekciniai veiksmai.

Geras patikrinimo scenarijus yra paprastas: įvyksta incidentas pas pagrindinį tiekėją arba sutrikimas gamybos aplinkoje, todėl reikia nustatyti, kas klasifikuoja įvykį, kas pradeda komunikaciją, kas įvertina poveikį paslaugai ir kokie sprendimų įrodymai išliks. Jeigu atsakymai išskaidyti, o organizacija remiasi „nusistovėjusia praktika“, kurios niekas negali atkurti pagal įrašus, pasirengimas yra tik tariamas – net ir esant tinkamai prižiūrimai valdymo sistemai.

Jeigu organizacija jau vykdo LST EN ISO 27001 vidaus auditus, juos verta panaudoti tokiai patikrai, tačiau audito kriterijus reikia papildyti reguliaciniais įpareigojimais ir KSC požiūriu reikalingais įrodymais. Auditorių kompetencija čia labai naudinga, kaip ir žinios, kurias plėtoja vadovaujančiojo ar vidaus auditoriaus funkcijai besirengiantys specialistai. Tinkamas atskaitos taškas gali būti straipsnis LST EN ISO 27001 vadovaujantysis auditorius: išsamus sertifikavimo ir standarto reikalavimų vadovas. Vis dėlto svarbu laikytis tinkamos sekos: audito kompetencija padeda patikrinti sistemą, tačiau nepakeičia analizės, kokie teisiniai ir organizaciniai įpareigojimai iš tikrųjų taikomi konkrečiai įmonei.

Vadovybės sprendimas: sertifikatas kaip pagrindas, o ne pasiteisinimas

Racionaliausia LST EN ISO 27001 vertinti kaip valdymo tvarkos pagrindą, bet ne kaip savarankišką visų NIS2 ir KSC įpareigojimų įvykdymo įrodymą. Sertifikatas padeda susisteminti atsakomybę, rizikos vertinimą, incidentų kontrolę, auditus ir gerinimą, tačiau neatleidžia nuo pareigos nustatyti, kokie įpareigojimai taikomi konkrečiai organizacijai, kokia jų apimtis ir kokių įrodymų reikės veiksmingumui pagrįsti.

Vadovybės požiūriu pavojingiausia yra ne dokumentacijos spraga, o pasirengimo iliuzija – įsitikinimas, kad sertifikuota sistema savaime reiškia pasirengimą nacionalinių teisės aktų reikalavimams. Todėl sprendimas neturėtų apsiriboti klausimu, ar išlaikyti arba plėsti sertifikavimo apimtį. Pirmiausia būtina išspręsti tris valdymo klausimus:

• patvirtinti organizacijos statusą ir jai taikomų įpareigojimų apimtį,
• atlikti esamos sistemos ir KSC reikalavimų spragų analizę,
• nustatyti veiksmų įgyvendinimo ir veiksmingumo įrodymų kontrolės modelį.

Tik tada galima pagrįstai nuspręsti, ar įmonei reikia plėsti sertifikavimo apimtį, ar pakanka nekeisti dabartinės LST EN ISO 27001 sistemos apimties ir papildyti ją trūkstamais organizaciniais, teisiniais bei operaciniais mechanizmais. Praktikoje naudingi trys paprasti valdymo įrankiai: dabartinės sertifikavimo apimties palyginimas su kritinių procesų žemėlapiu, spragų sąrašas su poveikio rizikai ir atitikčiai vertinimu bei veiksmų planas, kuriame nurodyti savininkai, terminai ir užbaigimo kriterijai.

Jeigu organizacija tik renkasi veiksmų kryptį, darbų seka nėra universali. Kai didelį spaudimą daro klientai ar pirkimų reikalavimai, sistemos kūrimas sertifikavimui gali būti pagrįstas pirmasis žingsnis, jei kartu neatidedama reguliacinių įpareigojimų analizė. Įmonėse, kuriose operacinė rizika yra didelė arba atsakomybės modelis išskaidytas, tikslingiau pirmiausia pašalinti reguliacinės atitikties spragas ir tik tada tvarkyti sertifikavimo apimtį. Tai nėra ginčas dėl formalumų eiliškumo – tai sprendimas, kokia tvarka mažinti riziką. Todėl ir temą ISO sertifikatas: nauda ir diegimo procesas verta vertinti neatsiejant nuo įmonės veiklos modelio, o kaip platesnio sprendimo dėl atitikties valdymo dalį.

Geriausių rezultatų pasiekiama įgyvendinant vieną nuoseklią programą, kurioje informacijos saugumas, veiklos tęstinumas, tiekėjų kontrolė ir reguliaciniai įpareigojimai valdomi kaip įmonės veiklos modelio dalis, o ne kaip atskiros skirtingų padalinių iniciatyvos. Lenkijos sąlygomis būtent suskaidyta atsakomybė dažniausiai silpnina organizacijos gebėjimą pateikti įrodymus ir įgyvendinti sprendimus. Galutinė išvada paprasta: sertifikatas padeda ir gali reikšmingai sutrumpinti sistemos sutvarkymo kelią, tačiau atitiktį vis tiek reikia suprojektuoti, įgyvendinti ir pagrįsti įrodymais NIS2 bei KSC taikymo sąlygomis.