NIS2 ir DORA kontaktų registrai ISO 27001 atitikčiai

02:17 incidentas: kai kontaktų sąrašas tampa valdymo priemone
Antradienį 02:17 SOC analitikas pastebi modelį, kurio niekas nenori matyti. Privilegijuotoji paslaugų paskyra autentifikavosi iš neįprastos geografinės vietos, klientų įrašai buvo nuosekliai užklausomi, o valdomo aptikimo teikėjas atidarė didelio kritiškumo užklausą. Per kelias minutes incidento vadovas patvirtina susirūpinimą: išpirkos reikalaujančios kenkimo programos indikatoriai plinta lateraliniu judėjimu, kritinė gamybinė paslauga veikia ribotai, o klientų duomenys gali būti paveikti.
Techninis reagavimas prasideda greitai. Galiniai įrenginiai izoliuojami, tapatybių žurnalai paimami, debesijos momentinės kopijos išsaugomos, o valdomų saugumo paslaugų teikėjas prisijungia prie konferencinio ryšio. Tada prasideda šaltesnė panika.
CISO klausia: „Ką turime informuoti?“
Teisininkai sako, kad gali reikėti įtraukti duomenų apsaugos instituciją. Duomenų apsaugos pareigūnas (DPO) klausia, ar tai yra asmens duomenų saugumo pažeidimas. COO teigia, kad debesijos paslaugų teikėją reikia eskaluoti pagal įmonės palaikymo sąlygą. Atitikties vadovas klausia, ar subjektas pagal NIS2 yra svarbus subjektas ir ar taikoma DORA, nes paslauga palaiko reguliuojamą finansų subjektą. Valdyba nori žinoti, kas privalo įvykti per pirmąsias 24 valandas.
Niekas neginčija būtinybės komunikuoti. Problema ta, kad kontaktiniai duomenys, tvirtinimo kelias, teisinės suaktyvinimo sąlygos ir įrodymų reikalavimai yra išmėtyti sename veiklos tęstinumo skaičiuoklės faile, tiekėjų sutartyse, el. pašto gijose, pasenusioje atitikties wiki ir vieno asmens telefone.
Tai nėra vien operacinis nepatogumas. 2026 m. tai yra atitikties spraga.
NIS2 etapais vykdomą pranešimą apie incidentus pavertė valdysenos įpareigojimu, įskaitant išankstinį perspėjimą per 24 valandas, pranešimą per 72 valandas ir galutinę ataskaitą per vieną mėnesį reikšmingų incidentų atveju. DORA sukūrė atskirą skaitmeninės operacinės atsparos režimą finansų subjektams, apimantį IRT incidentų valdymą, klasifikavimą, pranešimą priežiūros institucijoms, IRT trečiųjų šalių riziką ir krizių komunikaciją. GDPR išlieka aktualus visais atvejais, kai tvarkomi asmens duomenys. ISO/IEC 27001:2022 šiuos įpareigojimus paverčia audituojamais valdymo sistemos įrodymais.
Reguliacinių kontaktų registras gali skambėti administraciškai. Taip nėra. Tai jungiamasis audinys tarp reagavimo į incidentus, teisės aktuose nustatyto pranešimo, veiklos tęstinumo, tiekėjų koordinavimo, vadovybės atskaitomybės ir audito įrodymų.
Clarysec tai vertina kaip įrodymų problemą, o ne dokumentacijos pratimą. Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plane Zenith Blueprint, 22 žingsnyje „Controls in Action“ fazėje paaiškinama, kodėl ryšiai su institucijomis turi būti iš anksto apibrėžti:
Valdymo priemonė 5.5 užtikrina, kad organizacija būtų pasirengusi prireikus bendrauti su išorės institucijomis ne reaktyviai ar panikos sąlygomis, o per iš anksto apibrėžtus, struktūruotus ir gerai suprantamus kanalus.
Tai yra tikroji 02:17 incidento pamoka. Reguliavimo institucijos pranešimų portalą, CSIRT budėtojo telefoną, atsarginį DPO kontaktą, finansų priežiūros institucijos pranešimo kanalą ir tiekėjo eskalavimo kelią reikia rasti prieš incidentą, o ne tada, kai pranešimo terminas jau skaičiuojamas.
Kodėl reguliacinių kontaktų registrai tapo 2026 m. atitikties prioritetu
Daugelis organizacijų jau turi skubios pagalbos kontaktų sąrašus. Problema ta, kad NIS2 ir DORA reikalauja disciplinuotesnio sprendimo nei vardų ir telefono numerių sąrašas. Reikalinga tiksli, vaidmenimis pagrįsta, įrodymams parengta kontaktų valdysena, susieta su teisinėmis suaktyvinimo sąlygomis, eskalavimo įgaliojimais, pranešimų terminais ir tiekėjų priklausomybėmis.
NIS2 taikoma plačiam esminių ir svarbių subjektų ratui tokiuose sektoriuose kaip energetika, transportas, bankininkystė, finansų rinkų infrastruktūra, sveikatos priežiūra, geriamasis vanduo, nuotekos, skaitmeninė infrastruktūra, IRT paslaugų valdymas, viešasis administravimas ir kosmosas. Ji taip pat apima daug skaitmeninių paslaugų teikėjų, įskaitant debesijos paslaugas, duomenų centrų paslaugas, turinio pristatymo tinklus, valdomų paslaugų teikėjus, valdomų saugumo paslaugų teikėjus, internetines prekyvietes, interneto paieškos sistemas ir socialinių tinklų platformas. Valstybės narės privalėjo iki 2025 m. balandžio 17 d. sudaryti esminių ir svarbių subjektų sąrašus ir juos atnaujinti bent kas dvejus metus. Daugeliui debesijos, SaaS, valdomų paslaugų ir skaitmeninių platformų teikėjų reguliacinė ekspozicija iš teorinės tapo operacine.
DORA nuo 2025 m. sausio 17 d. taikoma finansų subjektams, pavyzdžiui, kredito įstaigoms, mokėjimo įstaigoms, elektroninių pinigų įstaigoms, investicinėms įmonėms, kriptoturto paslaugų teikėjams, prekybos vietoms, centriniams vertybinių popierių depozitoriumams, pagrindinėms sandorio šalims, draudimo ir perdraudimo įmonėms bei kitoms į taikymo sritį patenkančioms finansų sektoriaus organizacijoms. DORA taip pat labai aktuali IRT trečiųjų šalių ekosistemai, nes finansų subjektai privalo valdyti paslaugų teikėjus, palaikančius kritines ar svarbias funkcijas. DORA Article 17 reikalauja su IRT susijusių incidentų valdymo proceso, Article 18 nustato klasifikavimo lūkesčius, o Article 19 reglamentuoja pranešimą kompetentingai institucijai apie reikšmingus su IRT susijusius incidentus.
GDPR prideda privatumo aspektą. Kibernetinio saugumo incidentas gali tapti asmens duomenų saugumo pažeidimu, jei jis susijęs su atsitiktiniu ar neteisėtu asmens duomenų sunaikinimu, praradimu, pakeitimu, neautorizuotu atskleidimu arba prieiga prie jų. Duomenų valdytojas turi galėti įrodyti atskaitomybę, įvertinti riziką fiziniams asmenims ir, kai reikalaujama, informuoti priežiūros instituciją bei galimai paveiktus duomenų subjektus.
Brandus reguliacinių kontaktų registras spaudimo sąlygomis turi atsakyti į penkis klausimus:
- Kuris CSIRT, kompetentinga institucija, finansų priežiūros institucija, duomenų apsaugos institucija ir teisėsaugos kontaktas taikomas šiam juridiniam asmeniui, jurisdikcijai ir paslaugai?
- Kuris vidaus vaidmuo yra įgaliotas inicijuoti kontaktą, patvirtinti formuluotę ir pateikti pranešimus?
- Su kuriais tiekėjais reikia susisiekti dėl incidento suvaldymo, žurnalų, atkūrimo, įrodymų išsaugojimo ar sutartinio pranešimo?
- Koks klientų, sandorio šalių ar viešosios komunikacijos kelias suaktyvinamas kiekvienu kritiškumo lygiu?
- Kaip įrodome, kad registras buvo peržiūrėtas, patikrintas ir naudotas tinkamai?
Atsakymas negali būti tik teisininkų pašto dėžutėje ar CISO atmintyje. Tai turi būti kontroliuojamas ISVS įrašas.
Ką apima įrodymams parengtas NIS2 ir DORA kontaktų registras
Reguliacinių kontaktų registras turi būti projektuojamas naudoti realaus incidento metu. Jei incidento vadovas per kelias minutes turi priimti pirmąjį eskalavimo sprendimą, registras negali būti neapibrėžtas svetainių sąrašas. Jis turi būti struktūruotas, patikrintas ir susietas su reagavimo veiksmų planu.
| Registro laukas | Kodėl tai svarbu incidento metu | Įrodymų vertė |
|---|---|---|
| Institucijos arba suinteresuotosios šalies tipas | Atskiria CSIRT, kompetentingą instituciją, finansų priežiūros instituciją, duomenų apsaugos instituciją, teisėsaugą, tiekėją, klientų grupę ir vidaus vaidmenį | Parodo, kad suinteresuotosios šalys ir pranešimo kanalai buvo nustatyti |
| Konkrečios institucijos arba subjekto pavadinimas | Nurodo tikslų reguliavimo subjektą, priežiūros instituciją, teikėją, klientų grupę ar vidaus funkciją | Mažina netinkamo gavėjo ir netinkamos jurisdikcijos riziką |
| Jurisdikcija ir juridinis asmuo | Apsaugo nuo pranešimų netinkamai šaliai ar netinkamam subjektui tarpvalstybinėse grupėse | Palaiko taikymo sritį, taikytinumą ir reguliacinį susiejimą |
| Suaktyvinimo sąlyga | Susieja kontaktą su NIS2 reikšmingu incidentu, DORA reikšmingu su IRT susijusiu incidentu, GDPR asmens duomenų saugumo pažeidimu ar sutartiniu pranešimu | Parodo dokumentuotą sprendimo logiką |
| Pirminis kontaktinis kanalas | Pateikia portalą, el. paštą, telefoną, saugaus pranešimo kelią ar aukšto prioriteto palaikymo kanalą | Palaiko savalaikį pranešimą ir eskalavimą |
| Atsarginis kontaktinis kanalas | Užtikrina atsparumą, kai pagrindinis kanalas nepasiekiamas | Parodo komunikacijos tęstinumą |
| Įgaliotas vidaus savininkas | Apibrėžia, kas gali susisiekti, patvirtinti ar pateikti informaciją | Palaiko atskaitomybę ir pareigų atskyrimą |
| Prieš kontaktą reikalingi įrodymai | Išvardija faktus, kritiškumo vertinimą, paveiktas paslaugas, IOC, poveikį klientams ir teisinės peržiūros būseną | Palaiko savalaikį, bet kontroliuojamą pranešimą |
| Paskutinio patvirtinimo data ir tikrintojas | Patvirtina periodinę peržiūrą ir mažina pasenusių kontaktų riziką | Suteikia audito įrodymus dėl priežiūros |
| Testavimo arba pratybų nuoroda | Susieja kontaktą su stalo pratybomis, simuliacijomis ar naudojimu realaus incidento metu | Parodo operacinį veiksmingumą |
| Saugojimo vieta | Nurodo ISVS, GRC platformą, užklausų sistemą ar įrodymų saugyklą | Palaiko pakartojamumą ir paiešką audito metu |
Išsamus registras turėtų apimti bent šešias kontaktų grupes.
Pirma, oficialios kibernetinio saugumo institucijos: nacionaliniai CSIRT, kompetentingos institucijos, bendrieji kontaktiniai centrai, kai taikoma, ir sektorinės kibernetinio saugumo agentūros.
Antra, DORA finansų priežiūros institucijos: kompetentingos institucijos ir pranešimo kanalai, naudojami pradiniam, tarpiniam ir galutiniam pranešimui apie reikšmingus su IRT susijusius incidentus.
Trečia, privatumo institucijos: duomenų apsaugos institucijos, vadovaujančios priežiūros institucijos logika tarpvalstybiniam tvarkymui ir DPO eskalavimo keliai.
Ketvirta, teisėsauga: kibernetinių nusikaltimų padaliniai, sukčiavimo padaliniai ir skubūs kontaktai prievartavimo, išpirkos reikalaujančių kenkimo programų, neteisėtos prieigos ir įrodymų išsaugojimo atvejais.
Penkta, tiekėjai ir IRT trečiosios šalys: debesijos paslaugų teikėjai, valdomų saugumo paslaugų teikėjai, valdomų paslaugų teikėjai, tapatybės platformos, mokėjimų tvarkytojai, skaitmeninės kriminalistikos teikėjai ir teisininkai.
Šešta, vidaus eskalavimo vaidmenys: incidento vadovas, CISO, DPO, vyriausiasis teisininkas, komunikacijos vadovas, veiklos tęstinumo vadovas, vykdomasis tvirtintojas, ryšio su valdyba asmuo ir paslaugos savininkas.
Registras taip pat turėtų apimti specialių interesų grupes, kai aktualu, pavyzdžiui, ISAC ar sektorines informacijos dalijimosi bendruomenes. Tai nėra reguliavimo institucijos, tačiau jos gali tapti svarbiais grėsmių žvalgybos ir koordinuoto reagavimo kanalais.
Zenith Blueprint tai praktiškai apibrėžia 22 žingsnyje:
Sukurkite arba atnaujinkite bendravimo su institucijomis procedūras saugumo įvykių metu (5.5), įskaitant vietinių CERT, reguliavimo institucijų ir teisėsaugos kontaktinius duomenis. Palaikykite panašų kontaktų sąrašą dalyvavimui saugumo forumuose ar konkretaus sektoriaus grupėse (5.6). Šią informaciją saugokite prieinamoje, bet prieigos kontrole valdoma vietoje ir įtraukite ją į reagavimo į incidentus instrukcijas.
Paskutinis sakinys svarbus. Jei registro nėra reagavimo į incidentus instrukcijose, tikėtina, kad esant realiam spaudimui jis nebus naudojamas.
FinTech arba SaaS teikėjo kontaktų registro struktūros pavyzdys
Įsivaizduokite fintech SaaS teikėją, kuris ES klientams teikia mokėjimų analitikos paslaugas. Jis naudoja debesijos paslaugų teikėją, valdomo aptikimo teikėją, tapatybės platformą, klientų aptarnavimo platformą ir išorinį teisininką. Priklausomai nuo vaidmens, jis gali būti finansų subjektas, IRT trečiosios šalies paslaugų teikėjas, į NIS2 taikymo sritį patenkantis skaitmeninių paslaugų teikėjas arba asmens duomenų tvarkytojas pagal GDPR.
Praktinis registras galėtų prasidėti taip:
| Institucijos arba subjekto tipas | Konkreti institucija arba pavadinimas | Kontaktinis taškas | Pirminis metodas | Atsarginis metodas | Kontakto suaktyvinimo sąlyga | Savininkas |
|---|---|---|---|---|---|---|
| NIS2 CSIRT | Nacionalinis CSIRT | Reagavimo į incidentus priėmimas | Saugus portalas | Skubus el. paštas | Reikšmingas kibernetinis incidentas, paveikiantis paslaugas | CISO |
| DORA priežiūros institucija | Nacionalinė finansų priežiūros institucija | IRT incidentų pranešimų skyrius | Priežiūros institucijos portalas | Paskirtas telefonas | Reikšmingas su IRT susijęs incidentas | Atitikties vadovas |
| GDPR duomenų apsaugos institucija | Duomenų apsaugos institucija | Pažeidimų pranešimų padalinys | Žiniatinklio forma | DPO ryšys su institucija | Asmens duomenų saugumo pažeidimo rizikos vertinimas rodo, kad gali reikėti pranešti | DPO |
| Teisėsauga | Nacionalinis kibernetinių nusikaltimų padalinys | Budintis pareigūnas | Oficialioji pranešimo linija | Vietos ryšių pareigūnas | Įtariama nusikalstama veikla, prievartavimas arba įrodymų išsaugojimo poreikis | Teisės vadovas |
| Kritinis debesijos paslaugų teikėjas | Debesijos paslaugų teikėjo pavadinimas | Įmonės saugumo palaikymas | Aukšto prioriteto užklausų portalas | Techninis paskyros vadovas | Incidentas, veikiantis nuomos aplinką, žurnalus, suvaldymą ar atkūrimą | Debesijos operacijų vadovas |
| Valdomo aptikimo teikėjas | MDR teikėjo pavadinimas | SOC eskalavimo vadovas | 24x7 eskalavimo linija | Paskyros eskalavimo kontaktas | Patvirtintas didelio kritiškumo aptikimas arba kriminalistinės pagalbos poreikis | Incidento vadovas |
| Vidaus vadovas | CEO arba deleguotas vadovas | Vadovybės eskalavimas | Tiesioginis mobilusis | Vadovo asistentas | Bet kuris incidentas, kuriam reikia išorinio pranešimo arba sprendimo dėl viešo poveikio | CISO |
| Vidaus komunikacija | PR arba komunikacijos vadovas | Krizių komunikacijos vadovas | Tiesioginis mobilusis | Bendradarbiavimo kanalas | Gali reikėti klientų, žiniasklaidos ar rinkos komunikacijos | Vyriausiasis teisininkas |
Įrašuose neturėtų būti nereikalingų asmens duomenų. Kur įmanoma, naudokite vaidmenimis pagrįstus kontaktus, apsaugokite jautrius kontaktinius duomenis ir užtikrinkite pasiekiamumą neprisijungus didelio sutrikimo metu. Registras, pasiekiamas tik iš tų pačių sistemų, kurias paveikė išpirkos reikalaujančios kenkimo programos incidentas, nėra atsparus.
Registro susiejimas su ISO/IEC 27001:2022 įrodymais
Auditoriai retai nustato neatitiktį vien todėl, kad organizacija neturi skaičiuoklės. Neatitiktis atsiranda tada, kai organizacija negali įrodyti, kad skaičiuoklė yra išsami, aktuali, patvirtinta, apsaugota, patikrinta ir susieta su realiais procesais.
ISO/IEC 27001:2022 prasideda nuo organizacijos konteksto. 4.1–4.4 punktai reikalauja, kad organizacija suprastų vidaus ir išorės klausimus, nustatytų suinteresuotąsias šalis ir jų reikalavimus, apibrėžtų ISVS taikymo sritį ir suprastų sąsajas bei priklausomybes. Reguliacinių kontaktų registras yra stiprūs įrodymai, kad teisiniai, reguliavimo, sutartiniai ir suinteresuotųjų šalių reikalavimai paversti operaciniais santykiais.
Toliau eina lyderystė. 5.1–5.3 punktai reikalauja, kad aukščiausioji vadovybė demonstruotų lyderystę, priskirtų atsakomybes, užtikrintų komunikaciją ir palaikytų ISVS. Jei registre nurodyta, kas įgaliotas pranešti CSIRT, priežiūros institucijai ar duomenų apsaugos institucijai, kas tvirtina išorinę komunikaciją ir kas praneša incidento būseną aukščiausiajai vadovybei, jis palaiko lyderystės įrodymus.
Rizikos planavimas įpareigojimus paverčia veiksmais. 6.1.1–6.1.3 punktai reikalauja rizikos vertinimo ir tvarkymo proceso, palyginimo su A priedu, Taikomumo pareiškimo, Rizikos tvarkymo plano ir liekamosios rizikos priėmimo. Registras turėtų būti įtrauktas į tvarkymo planą tokioms rizikoms kaip teisės aktuose nustatyto pranešimo nesėkmė, pavėluotas incidento eskalavimas, tiekėjo reagavimo nesėkmė, tarpvalstybinio pranešimo klaida ir veiklos tęstinumo komunikacijos sutrikimas.
A priedo valdymo priemonių atramos aiškios:
| ISO/IEC 27001:2022 valdymo priemonė | Valdymo priemonės pavadinimas | Registro aktualumas |
|---|---|---|
| A.5.5 | Ryšiai su institucijomis | Nustato iš anksto apibrėžtus institucijų kontaktus incidentams ir reguliaciniams įvykiams |
| A.5.6 | Ryšiai su specialių interesų grupėmis | Palaiko sektorinį dalijimąsi informacija ir grėsmių žvalgybos koordinavimą |
| A.5.19 | Informacijos saugumas tiekėjų santykiuose | Susieja tiekėjų kontaktus su saugumo įsipareigojimais ir eskalavimo keliais |
| A.5.20 | Informacijos saugumo užtikrinimas tiekėjų susitarimuose | Užtikrina, kad pranešimo ir palaikymo kanalai būtų paremti sutartimis |
| A.5.21 | Informacijos saugumo valdymas IRT tiekimo grandinėje | Susieja kritinius IRT teikėjus su reagavimo ir atkūrimo darbo eigomis |
| A.5.22 | Tiekėjų paslaugų stebėsena, peržiūra ir pakeitimų valdymas | Užtikrina tiekėjų kontaktų aktualumą keičiantis paslaugoms ar teikėjams |
| A.5.23 | Informacijos saugumas naudojant debesijos paslaugas | Palaiko debesijos incidentų eskalavimą, prieigą prie įrodymų ir atkūrimą |
| A.5.24 | Informacijos saugumo incidentų valdymo planavimas ir pasirengimas | Integruoja registrą į reagavimo į incidentus planavimą |
| A.5.25 | Informacijos saugumo įvykių vertinimas ir sprendimas | Susieja suaktyvinimo sąlygas su praneštinumo vertinimu ir sprendimų žurnalais |
| A.5.26 | Reagavimas į informacijos saugumo incidentus | Palaiko išorinį koordinavimą reagavimo metu |
| A.5.27 | Mokymasis iš informacijos saugumo incidentų | Skatina registro atnaujinimus po incidentų ir pratybų |
| A.5.28 | Įrodymų rinkimas | Palaiko saugomus pranešimus, gavimo patvirtinimus, skambučių pastabas ir reguliavimo institucijos grįžtamąjį ryšį |
| A.5.29 | Informacijos saugumas sutrikimo metu | Užtikrina komunikacijos kanalų prieinamumą sutrikimo metu |
| A.5.30 | IRT pasirengimas veiklos tęstinumui | Susieja kontaktų valdyseną su tęstinumo ir atkūrimo planais |
| A.5.31 | Teisiniai, įstatyminiai, reguliavimo ir sutartiniai reikalavimai | Susieja kontaktus su teisinėmis ir sutartinėmis pranešimo pareigomis |
| A.5.34 | Privatumas ir PII apsauga | Užtikrina, kad DPO ir duomenų apsaugos institucijų keliai būtų integruoti asmens duomenų saugumo pažeidimams |
| A.8.15 | Žurnalų registravimas | Pateikia faktus ir įrodymus, reikalingus pranešimui |
| A.8.16 | Stebėsenos veikla | Leidžia anksti aptikti ir laiku eskaluoti į pranešimų darbo eigas |
Zenith Controls: kryžminės atitikties vadove Zenith Controls ryšiai su institucijomis vertinami kaip valdymo priemonė 5.5, turinti prevencinių ir korekcinių savybių. Ji palaiko konfidencialumą, vientisumą ir prieinamumą bei siejasi su kibernetinio saugumo sąvokomis Identify, Protect, Respond ir Recover. Zenith Controls susieja ją su incidentų planavimu, įvykių pranešimu, grėsmių žvalgyba, specialių interesų grupėmis ir reagavimu į incidentus. Vadove taip pat paaiškinama, kodėl iš anksto nustatyti kontaktai su reguliavimo institucijomis, teisėsauga, nacionaliniais CERT ar duomenų apsaugos institucijomis leidžia greičiau eskaluoti ir gauti gaires tokių įvykių kaip reikšmingi pažeidimai ar išpirkos reikalaujančių kenkimo programų atakos metu.
Valdymo priemonė nėra izoliuota. Zenith Controls taip pat susieja valdymo priemonę 6.8, informacijos saugumo įvykių pranešimą, kaip aptikimo valdymo priemonę, susietą su incidentų planavimu, įvykių vertinimu, reagavimu, įgyta patirtimi, informuotumu, stebėsena ir drausminėmis procedūromis. Valdymo priemonė 5.24, Informacijos saugumo incidentų valdymo planavimas ir pasirengimas, siejasi su įvykių vertinimu, įgyta patirtimi, žurnalų registravimu, stebėsena, saugumu sutrikimo metu, tęstinumu ir ryšiais su institucijomis. Audito istorija tampa stipresnė, kai įvykiai yra pranešami, vertinami, eskaluojami, komunikuojami, pagrindžiami įrodymais ir tobulinami.
NIS2, DORA ir GDPR: vienas registras, skirtingi teisiniai terminai
Vienas incidentas gali suaktyvinti kelias teisines darbo eigas. Neteisėta prieiga SaaS teikėjo aplinkoje gali būti NIS2 reikšmingas incidentas, GDPR asmens duomenų saugumo pažeidimas ir sutartinis pranešimo klientui įvykis. Finansų subjekto paslaugos nepasiekiamumas gali būti DORA reikšmingas su IRT susijęs incidentas, kartu reikalaujantis GDPR analizės ir tiekėjų koordinavimo.
NIS2 reikalauja, kad esminiai ir svarbūs subjektai be nepagrįsto delsimo praneštų savo CSIRT arba kompetentingai institucijai apie reikšmingus incidentus, paveikiančius paslaugų teikimą. Etapinis pranešimo modelis apima išankstinį perspėjimą be nepagrįsto delsimo ir per 24 valandas nuo sužinojimo, pranešimą apie incidentą be nepagrįsto delsimo ir per 72 valandas, tarpines būsenos ataskaitas paprašius ir galutinę ataskaitą per vieną mėnesį po pranešimo apie incidentą. Jei incidentas vis dar tęsiasi, taip pat gali reikėti pažangos ataskaitų.
DORA reikalauja, kad finansų subjektai palaikytų su IRT susijusių incidentų valdymo procesą, kuris aptinka, valdo ir praneša apie incidentus, registruoja incidentus ir reikšmingas kibernetines grėsmes, klasifikuoja sunkumą ir kritiškumą, priskiria vaidmenis, apibrėžia eskalavimą ir komunikaciją, praneša apie reikšmingus incidentus vyresniajai vadovybei ir palaiko savalaikį atkūrimą. Pranešimas apie reikšmingą su IRT susijusį incidentą vykdomas pagal pradinio, tarpinio ir galutinio pranešimo logiką, o klasifikavimas grindžiamas tokiais veiksniais kaip paveikti klientai, trukmė, geografinis paplitimas, duomenų praradimas, paslaugų kritiškumas ir ekonominis poveikis.
GDPR prideda asmens duomenų saugumo pažeidimo vertinimą. Kontaktų registras pats nenusprendžia teisinio praneštinumo. Jis užtikrina, kad tinkami asmenys galėtų greitai priimti sprendimą, naudodami aktualius kanalus ir dokumentuotus kriterijus.
Clarysec politikų biblioteka tai paverčia operacine praktika. MVĮ Reagavimo į incidentus politikoje Reagavimo į incidentus politika – MVĮ, 5.1.1 punkte nustatyta:
Generalinis vadovas (GM) yra atskaitingas už visų incidentų eskalavimo sprendimų, reguliacinių pranešimų ir išorinės komunikacijos autorizavimą.
Ta pati MVĮ politika, 7.4.1 punktas, papildo:
Kai dalyvauja klientų duomenys, Generalinis vadovas privalo įvertinti teisinius pranešimo įpareigojimus pagal GDPR, NIS2 arba DORA taikytinumą.
Įmonių aplinkoms Reagavimo į incidentus politika Reagavimo į incidentus politika, 5.5 punktas, nustato komunikacijos sistemą:
Visa su incidentais susijusi komunikacija turi vykti pagal komunikacijos ir eskalavimo matricą, užtikrinant:
6.4.2 punktas prideda įrodymų reikalavimą:
Visi pranešimai apie pažeidimus turi būti dokumentuoti ir patvirtinti prieš pateikimą, o kopijos turi būti saugomos ISVS.
Čia registras tampa ISO įrodymais. Tai ne tik žinojimas, kam skambinti. Tai gebėjimas parodyti, kas buvo įgaliotas, kas buvo įvertinta, kas patvirtinta, kas pateikta ir kur saugoma kopija.
Clarysec įrodymų modelis: keturi kartu veikiantys artefaktai
Stipriam reguliacinių kontaktų pajėgumui reikia keturių artefaktų, veikiančių kaip viena įrodymų grandinė.
Reguliacinių kontaktų registras nustato kontaktus, kanalus, suaktyvinimo sąlygas ir savininkus. Komunikacijos ir eskalavimo matrica apibrėžia, kas ką daro. Sprendimų žurnalas registruoja klasifikavimą, praneštinumo vertinimą, teisinę peržiūrą ir patvirtinimą. Pranešimų įrodymų paketas saugo pateiktus pranešimus, portalų gavimo patvirtinimus, el. laiškus, skambučių pastabas, reguliavimo institucijos grįžtamąjį ryšį, tiekėjų atsakymus ir galutines ataskaitas.
Clarysec Teisinės ir reguliacinės atitikties politika Teisinės ir reglamentavimo atitikties politika – MVĮ registro koncepciją apibrėžia aiškiai. 5.5.2 punkte nustatyta:
Pagrindinės atitikties sąlygos (pvz., pranešimų apie pažeidimus terminai ir duomenų tvarkymo sąlygos) turi būti išskirtos ir stebimos Atitikties registre.
Atitikties registras turėtų maitinti reguliacinių kontaktų registrą. Teisinis reikalavimas gali sakyti „NIS2 išankstinis perspėjimas per 24 valandas“, o kontaktų registras nurodo nacionalinį CSIRT portalą, atsarginį budėtojo numerį, įgaliotą pateikėją, teisinį peržiūrėtoją, reikalingus įrodymus ir saugojimo kelią.
Veiklos tęstinumo politikos sustiprina tą patį lūkestį. MVĮ Veiklos tęstinumo ir atkūrimo po katastrofos politika Veiklos tęstinumo ir atkūrimo po katastrofos politika – MVĮ, 5.2.1.1 punktas, nurodo:
kontaktų sąrašus ir alternatyvius komunikacijos planus
Įmonės Veiklos tęstinumo ir atkūrimo po katastrofos politika Veiklos tęstinumo ir atkūrimo po katastrofos politika, 5.3.3 punktas, reikalauja, kad tęstinumo priemonės būtų:
Palaikomos aktualiais kontaktų sąrašais ir eskalavimo srautais
Tiekėjų valdysena taip pat priklauso modeliui. MVĮ Trečiųjų šalių ir tiekėjų saugumo politikoje Trečiųjų šalių ir tiekėjų saugumo politika – MVĮ, 5.4.3 punktas, reikalauja:
Priskirto kontaktinio asmens
NIS2 ir DORA kontekste tas kontaktas negali būti bendrinis. Jei kritinis debesijos paslaugų teikėjas, valdomų saugumo paslaugų teikėjas, tapatybės teikėjas ar mokėjimų tvarkytojas palaiko reguliuojamą paslaugą, registras turėtų nustatyti operacinį kontaktą, saugumo incidento kontaktą, sutartinio pranešimo kanalą ir eskalavimo kelią įrodymų prašymams.
Sukurkite registrą per vieną darbo sesiją
Naudingą registrą galima sukurti greitai, jei patalpoje dalyvauja tinkami žmonės. Suplanuokite dviejų valandų sesiją su CISO, DPO, teisininku, tiekėjų valdytoju, veiklos tęstinumo vadovu, incidento vadovu ir atitikties savininku.
Pradėkite nuo Atitikties registro. Išskirkite NIS2, DORA, GDPR, sutartinius ir sektorinius pranešimo įpareigojimus. Užregistruokite terminus, praneštinumo kriterijus ir įrodymų reikalavimus.
Atverkite reagavimo į incidentus instrukcijas. Kiekvienai incidento kategorijai, pavyzdžiui, išpirkos reikalaujanti kenkimo programa, neteisėta prieiga, paslaugos nepasiekiamumas, duomenų iškėlimas, tiekėjo incidentas ir debesijos regiono sutrikimas, nustatykite reikalingus išorinius kontaktus.
Užpildykite reguliacinių kontaktų registrą institucija, jurisdikcija, suaktyvinimo sąlyga, pirminiu kanalu, atsarginiu kanalu, savininku, tvirtintoju, reikalingais įrodymais, paskutinio patvirtinimo data ir saugojimo vieta.
Susiekite tiekėjų kontaktus. Kiekvienai kritinei ar svarbiai funkcijai nustatykite teikėjo saugumo incidento kontaktą, sutartinio pranešimo kanalą, audito kontaktą ir skubaus eskalavimo kelią.
Peržiūrėkite pagal politikas. Patvirtinkite, kad eskalavimo įgaliojimai atitinka Reagavimo į incidentus politiką, pranešimų įrodymai saugomi ISVS, veiklos tęstinumo kontaktų sąrašai suderinti, o tiekėjų kontaktams priskirti savininkai.
Ištestuokite vieną scenarijų. Naudokite tikslines stalo pratybas: „02:17 aptiktas klientų duomenų atskleidimas, paveikiantis ES klientus ir galimai sukeltas kompromituotų tapatybės teikėjo prisijungimo duomenų.“ Paprašykite komandos nustatyti, ar gali reikėti CSIRT, duomenų apsaugos institucijos, finansų priežiūros institucijos, tiekėjo ir klientų pranešimų. Tikslas nėra pratybų metu priversti priimti galutinę teisinę išvadą. Tikslas yra įrodyti, kur randami kontaktai, kas patvirtina kontaktavimą, kokių įrodymų reikia ir kur registruojami sprendimai.
Sukurkite įrodymų paketą. Išsaugokite registro versiją, susitikimo dalyvius, patvirtinimus, scenarijaus pastabas, sprendimų žurnalą, veiksmų punktus ir atnaujintą instrukcijų nuorodą.
Čia praktiškas tampa Zenith Blueprint 23 žingsnis:
Užtikrinkite, kad turėtumėte aktualų reagavimo į incidentus planą (5.24), apimantį pasirengimą, eskalavimą, reagavimą ir komunikaciją. Apibrėžkite, kas laikoma praneštinu saugumo įvykiu (5.25) ir kaip suaktyvinamas bei dokumentuojamas sprendimų priėmimo procesas. Pasirinkite neseną įvykį arba surenkite stalo pratybas planui patvirtinti.
Pratybos neturi būti sudėtingos. Jos turi įrodyti pasirengimą.
Kryžminės atitikties susiejimas: vienas registras, daug sistemų
Reguliacinių kontaktų registro vertė yra ta, kad jis mažina dubliuojamą atitikties darbą. Vienas įrodymams parengtas artefaktas gali palaikyti ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT 2019 valdysenos lūkesčius.
| Sistema | Ką registras palaiko | Kokių įrodymų tikisi auditoriai arba vertintojai |
|---|---|---|
| ISO/IEC 27001:2022 | Suinteresuotosios šalys, teisiniai reikalavimai, ryšiai su institucijomis, incidentų valdymas, tiekėjų valdysena, tęstinumas ir įrodymų rinkimas | Taikymo sritis, Taikomumo pareiškimas, registras, patvirtinimai, peržiūrų istorija, stalo pratybų įrašai ir incidentų žurnalai |
| NIS2 | Ryšiai su CSIRT arba kompetentinga institucija, etapinis pranešimas apie reikšmingus incidentus, vadovybės atskaitomybė ir tiekimo grandinės koordinavimas | Praneštinumo sprendimas, 24 valandų išankstinio perspėjimo įrodymai, 72 valandų pranešimo įrodymai, galutinė ataskaita ir valdybos priežiūra |
| DORA | Pranešimas kompetentingai institucijai, incidentų klasifikavimas, reikšmingų IRT incidentų komunikacija, IRT trečiųjų šalių koordinavimas ir krizių komunikacija | Pradinio, tarpinio ir galutinio pranešimo įrašai, kritiškumo klasifikavimas, tiekėjų registras ir tęstinumo testų įrašai |
| GDPR | Duomenų apsaugos institucijos pranešimų darbo eiga, DPO eskalavimas, asmens duomenų saugumo pažeidimo vertinimas ir atskaitomybė | Pažeidimo vertinimas, duomenų valdytojo arba tvarkytojo vaidmens analizė, duomenų apsaugos institucijos kontaktas, pateikti pranešimai ir sprendimai dėl komunikacijos duomenų subjektams |
| NIST CSF 2.0 | GOVERN rezultatai suinteresuotosioms šalims, įpareigojimams, vaidmenims, politikai, priežiūrai ir tiekimo grandinės rizikos valdymui | Current Profile, Target Profile, spragų analizė, POA&M, suinteresuotųjų šalių žemėlapis ir tiekėjų koordinavimo įrodymai |
| COBIT 2019 | Suinteresuotųjų šalių poreikių, rizikos, atitikties, incidentų valdymo ir trečiųjų šalių susitarimų valdysena | RACI, proceso veiksmingumo įrodymai, valdymo priemonių stebėsena, patikinimo įrašai ir vadovybės peržiūros įrodymai |
NIST CSF 2.0 ypač naudingas kaip integracijos sluoksnis. Jo GOVERN funkcija tikisi, kad organizacijos supras suinteresuotąsias šalis, teisinius ir reguliavimo įpareigojimus, kritines paslaugas, priklausomybes, rizikos apetitą, vaidmenis, politikas, priežiūrą ir tiekėjų riziką. CSF profiliai padeda organizacijoms dokumentuoti Current Profile, apibrėžti Target Profile, analizuoti spragas ir sukurti prioritetizuotą veiksmų planą. Reguliacinių kontaktų registras gali būti konkretūs įrodymai, uždarantys spragą tarp esamos ir tikslinės incidentų valdysenos.
Tiekimo grandinei NIST CSF 2.0 tikisi, kad tiekėjai, klientai ir partneriai turės apibrėžtus kibernetinio saugumo vaidmenis ir atsakomybes, bus žinomas tiekėjų kritiškumas, kibernetinio saugumo reikalavimai bus įtraukti į susitarimus, tiekėjų rizikos bus vertinamos, o aktualūs tiekėjai bus įtraukti į incidentų planavimą, reagavimą ir atkūrimą. Tai tiesiogiai atitinka DORA IRT trečiųjų šalių riziką ir NIS2 tiekimo grandinės lūkesčius.
Kaip auditoriai ir priežiūros institucijos tikrins tą patį registrą
Gerai prižiūrimas registras bus nagrinėjamas skirtingai, priklausomai nuo vertintojo perspektyvos.
ISO/IEC 27001:2022 auditorius pradės nuo taikymo srities ir suinteresuotųjų šalių. Jis klaus, kaip organizacija nustatė taikomas institucijas, teisinius įpareigojimus, sutartines pranešimo pareigas ir išorines priklausomybes. Tada jis atseks registrą iki Taikomumo pareiškimo, reagavimo į incidentus plano, veiklos tęstinumo plano ir įrodymų saugojimo. Jis gali atrinkti vieną kontaktą ir paprašyti paskutinio patvirtinimo įrodymo.
NIS2 vertintojas sutelks dėmesį į tai, ar subjektas nustatė teisingą CSIRT arba kompetentingą instituciją ir ar reikšmingų incidentų slenksčiai pritaikyti operacinei praktikai. Jis ieškos proceso, galinčio palaikyti 24 valandų išankstinį perspėjimą, 72 valandų pranešimą ir galutinę ataskaitą. Jis taip pat vertins valdymo organo priežiūrą, nes NIS2 Article 20 kibernetinio saugumo valdyseną paverčia vadovybės atsakomybe.
DORA priežiūros institucija arba vidaus audito komanda tikrins, ar registras palaiko incidentų valdymą, klasifikavimą, pranešimą apie reikšmingus su IRT susijusius incidentus, krizių komunikaciją, pranešimą vyresniajai vadovybei, tiekėjų koordinavimą ir operacinį atkūrimą. Jie gali klausti, ar yra kontaktai IRT trečiųjų šalių paslaugų teikėjams, palaikantiems kritines ar svarbias funkcijas, ir ar komunikacijos įpareigojimai atsispindi sutartyse.
GDPR auditorius arba DPO peržiūra sutelks dėmesį į asmens duomenų saugumo pažeidimo vertinimą. Jie klaus, ar DPO ir privatumo teisės kontaktai įtraukiami anksti, ar aiškūs duomenų valdytojo ir tvarkytojo vaidmenys, ar nustatyta teisinga priežiūros institucija ir ar įrašomi sprendimai dėl komunikacijos duomenų subjektams.
NIST CSF vertintojas registrą laikys įrodymais GOVERN rezultatams: suinteresuotųjų šalių lūkesčiams, teisiniams įpareigojimams, vaidmenims, politikoms, priežiūrai ir tiekimo grandinės rizikai. COBIT 2019 arba ISACA tipo auditorius nagrinės, ar suinteresuotųjų šalių poreikiai paverčiami valdysenos ir valdymo praktikomis, ar priskirtos atsakomybės ir ar stebimas proceso veiksmingumas.
Tas pats artefaktas turi atlaikyti visus šiuos klausimus. Todėl registras turi būti kontroliuojamas, turėti savininką, būti peržiūrimas, valdomas prieigos kontrolės priemonėmis ir testuojamas.
Dažni kontaktų valdysenos nesėkmės modeliai
Organizacijos retai patiria nesėkmę todėl, kad visai neturi kontaktų. Jos patiria nesėkmę todėl, kad kontaktais negalima pasitikėti realaus incidento metu.
| Nesėkmės modelis | Kodėl tai sukuria riziką | Praktinis taisymas |
|---|---|---|
| Reguliavimo institucijos kontaktas yra tik viešas pradžios puslapis | Komandos praranda laiką ieškodamos tikro pranešimo kelio | Patvirtinkite portalą, el. paštą, telefoną ir atsarginius kanalus |
| DPO neturi pavaduotojo | Privatumo sprendimai ne darbo valandomis sustoja | Paskirkite ir apmokykite atsarginius privatumo kontaktus |
| Tiekėjų kontaktai paslėpti sutartyse | Incidentų komandos negali greitai eskaluoti | Ištraukite saugumo, sutartinius ir palaikymo kontaktus į registrą |
| BCDR sąrašas ir IR matrica nesutampa | Komandos vadovaujasi prieštaringais eskalavimo keliais | Suderinkite abu įrašus per vieną savininką ir peržiūros ciklą |
| Nėra paskutinės peržiūros datos | Auditoriai negali patikrinti priežiūros | Pridėkite patvirtinimo datas, tikrintojus ir tvirtinimo įrodymus |
| Teisėsauga neįtraukta | Reagavimui į išpirkos reikalaujančias kenkimo programas ar prievartavimą trūksta įrodymų palaikymo | Pridėkite kibernetinių nusikaltimų ir įrodymų išsaugojimo kontaktus |
| NIS2 ir DORA terminai neintegruoti | Tik GDPR darbo eigos praleidžia sektorinius įpareigojimus | Susiekite suaktyvinimo sąlygas su NIS2, DORA, GDPR ir sutartimis |
| Registras yra tik internete paveiktose sistemose | Paslaugos nepasiekiamumas ar išpirkos reikalaujanti kenkimo programa blokuoja prieigą | Palaikykite apsaugotus neprisijungus pasiekiamus ir alternatyvius prieigos kelius |
| Pranešimai nesaugomi | Atitiktis negali įrodyti, kas buvo pateikta | Saugokite pranešimus, gavimo patvirtinimus, patvirtinimus ir korespondenciją ISVS |
| Stalo pratybos praleidžia pranešimą | Procesas lieka teorinis | Testuokite kontaktų paiešką, tvirtinimą, pateikimą ir įrodymų saugojimą |
Kiekvienas klausimas sukuria nuspėjamą audito išvadą. Taisymas taip pat nuspėjamas: suderinti registrą su politika, integruoti jį į reagavimą į incidentus, patvirtinti kontaktus, testuoti darbo eigą ir saugoti įrodymus.
Valdybos ir vadovybės atskaitomybė
NIS2 reikalauja, kad valdymo organai tvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir dalyvautų mokymuose. DORA Article 5 nustato valdymo organo atsakomybę apibrėžti, patvirtinti, prižiūrėti ir būti atskaitingam už IRT rizikos priemones, įskaitant politikas, vaidmenis, IRT veiklos tęstinumą, reagavimo ir atkūrimo planus, IRT trečiųjų šalių politiką, informuotumą ir mokymus. ISO/IEC 27001:2022 reikalauja, kad vadovybė suderintų ISVS su strategine kryptimi, suteiktų išteklius, priskirtų atsakomybes ir palaikytų nuolatinį tobulinimą.
Valdybai nereikia mokėti CSIRT telefono numerio. Jai reikia patikinimo, kad pranešimų pasirengimas egzistuoja, turi savininką, yra testuojamas ir peržiūrimas.
Ketvirtinis vadovybės paketas turėtų apimti:
- Reguliacinių kontaktų registro peržiūros būseną
- Taikomų institucijų, priežiūros institucijų ar jurisdikcijų pokyčius
- Atviras tiekėjų incidentų kontaktų spragas
- Stalo pratybų rezultatus ir įgytą patirtį
- Pranešimų tvirtinimo darbo eigos testavimo įrodymus
- Rodiklius apie laiką nuo aptikimo iki eskalavimo sprendimo
- NIS2, DORA, GDPR ir sutartinių pranešimo įpareigojimų atnaujinimus
- Liekamąsias rizikas, kurioms reikia vadovybės priėmimo
Tai perkelia registrą iš operacinės skaičiuoklės į valdysenos valdymo priemonę.
Kaip Clarysec padeda sukurti auditui parengtą kontaktų valdyseną
Clarysec sujungia politikos tekstą, įgyvendinimo seką ir kryžminį valdymo priemonių susiejimą į vieną įrodymų kelią.
Politikų biblioteka apibrėžia atskaitomybę ir reikalingus įrašus. Reagavimo į incidentus politika nustato eskalavimo, pranešimų tvirtinimo ir saugojimo lūkesčius. Teisinės ir reguliacinės atitikties politika reikalauja stebėti atitikties sąlygas, pavyzdžiui, pranešimų apie pažeidimus terminus. Veiklos tęstinumo ir atkūrimo po katastrofos politika reikalauja aktualių kontaktų sąrašų ir alternatyvių komunikacijos planų. Trečiųjų šalių ir tiekėjų saugumo politika reikalauja priskirtų tiekėjų kontaktų.
Zenith Blueprint pateikia įgyvendinimo seką. 5 žingsnyje ISVS pagrindų ir lyderystės fazėje aptariama komunikacija, informuotumas ir kompetencija, įskaitant išorės suinteresuotąsias šalis, laiką, komunikuojančių asmenų vaidmenis ir komunikacijos planus. 22 žingsnyje institucijų ir specialių interesų kontaktai integruojami į organizacines valdymo priemones. 23 žingsnyje patvirtinamas incidentų valdymas, sprendimai dėl praneštinų įvykių, kriminalistinių įrodymų išsaugojimas ir įgyta patirtis.
Zenith Controls vadovas pateikia kryžminės atitikties kompasą. Jame parodoma, kaip ryšiai su institucijomis siejasi su incidentų planavimu, įvykių pranešimu, grėsmių žvalgyba, specialių interesų grupėmis ir reagavimu į incidentus. Jis taip pat parodo, kodėl informacijos saugumo įvykių pranešimas ir pasirengimas incidentams yra būtini palydovai. Kontaktų registras veiksmingas tik tada, kai įvykiai pranešami ir įvertinami pakankamai anksti, kad jis būtų suaktyvintas.
MVĮ tai reiškia glaustą, bet pagrįstą registrą, aiškią atskaitomybę ir proporcingumą atitinkančius įrodymus. Įmonėms tai reiškia integraciją per jurisdikcijas, juridinius asmenis, verslo vienetus, tiekėjus, reguliavimo institucijas, priežiūros institucijas, CSIRT ir valdybos ataskaitas.
Kiti žingsniai: sukurkite registrą prieš prasidedant laiko skaičiavimui
Jei jūsų organizacija rengiasi NIS2, DORA, GDPR pranešimų apie pažeidimus pasirengimui arba ISO/IEC 27001:2022 sertifikavimui, nelaukite gyvo incidento, kad sužinotumėte, ar jūsų kontaktų valdysena veikia.
Šią savaitę pradėkite nuo keturių veiksmų:
- Sukurkite arba atnaujinkite reguliacinių kontaktų registrą CSIRT, kompetentingoms institucijoms, finansų priežiūros institucijoms, duomenų apsaugos institucijoms, teisėsaugai, kritiniams tiekėjams ir vidaus eskalavimo vaidmenims.
- Kiekvieną kontaktą susiekite su suaktyvinimo sąlyga, savininku, tvirtinimo keliu, įrodymų reikalavimu ir saugojimo vieta.
- Surenkite vienas stalo pratybas, sutelktas į pranešimų sprendimus, kontaktą su institucija, tiekėjų koordinavimą ir įrodymų saugojimą.
- Atnaujinkite ISVS įrašus, įskaitant Atitikties registrą, reagavimo į incidentus instrukcijas, veiklos tęstinumo kontaktų sąrašus ir tiekėjų kontaktų įrašus.
Clarysec gali padėti tai greitai įgyvendinti naudojant Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls ir mūsų MVĮ bei įmonių politikų bibliotekas, įskaitant Reagavimo į incidentus politiką Reagavimo į incidentus politika, Teisinės ir reguliacinės atitikties politiką Teisinės ir reglamentavimo atitikties politika – MVĮ, Veiklos tęstinumo ir atkūrimo po katastrofos politiką Veiklos tęstinumo ir atkūrimo po katastrofos politika ir Trečiųjų šalių ir tiekėjų saugumo politiką Trečiųjų šalių ir tiekėjų saugumo politika – MVĮ.
24 valandų terminas nesustoja, kol jūsų komanda ieško teisingo kontakto. Sukurkite registrą dabar, ištestuokite jį ir paverskite ISO įrodymų dalimi anksčiau, nei kitas incidentas už jus nustatys laiko juostą.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


