08.09.2026

Vai uzņēmums ir gatavs IT incidentam?

6 lietas, kam jābūt rīcības plānā

IT incidenti reti notiek ērtā brīdī. Sistēma kļūst nepieejama, darbinieki netiek klāt nepieciešamajiem datiem, tiek konstatēta aizdomīga aktivitāte vai pārtrūkst uzņēmumam būtisks pakalpojums.

Šādā situācijā svarīgs ir ne tikai tehniskais risinājums. Tikpat būtiski ir zināt, kurš pieņem lēmumus, kam jābūt informētam, ko atjaunot vispirms un kā rīkoties, ja ierastie saziņas kanāli vairs nav pieejami.

Tieši tāpēc uzņēmumam ir nepieciešams skaidrs IT incidentu rīcības plāns.

Labs plāns nevar paredzēt katru iespējamo scenāriju. Tā uzdevums ir panākt, lai kritiskā brīdī nebūtu jāizdomā viss no jauna.

1. Skaidras lomas un atbildība

Incidenta laikā neskaidra atbildība var būtiski palēnināt rīcību.

Ja nav iepriekš noteikts, kurš koordinē situāciju, pieņem biznesa lēmumus vai komunicē ar darbiniekiem un partneriem, vairāki cilvēki var sākt risināt vienu un to pašu jautājumu, kamēr citi svarīgi uzdevumi paliek bez atbildīgā.

Rīcības plānā būtu skaidri jānosaka:

kurš koordinē incidenta vadību;
kurš atbild par tehnisko problēmu risināšanu;
kurš pieņem lēmumus vadības līmenī;
kurš informē darbiniekus;
kurš sazinās ar klientiem, piegādātājiem un partneriem;
kurš koordinē sadarbību ar ārējiem IT vai kiberdrošības speciālistiem.

Ir svarīgi definēt ne tikai kas ko dara, bet arī tikai kurš ko dara, bet arī kuram ir pilnvaras pieņemt nepieciešamos lēmumus.

Incidenta laikā ierastā vairāku līmeņu saskaņošana ir pārāk lēna un neefektīva.

2. Aktuāla un pieejama kontaktinformācija

Incidenta laikā nevajadzētu tērēt laiku, meklējot īsto telefona numuru vai mēģinot noskaidrot, ar kuru piegādātāja pārstāvi sazināties.

Rīcības plānā vai tam pievienotā kontaktu sarakstā būtu jāiekļauj:

uzņēmuma vadības un IT atbildīgo personu kontakti;
ārējā IT vai kiberdrošības pakalpojumu sniedzēja kontakti;
kritisko sistēmu un programmatūras piegādātāji;
apdrošinātājs, ja uzņēmumam ir kiberrisku apdrošināšana;
juridiskie konsultanti;
citi uzņēmuma darbībai būtiski partneri.

Šī informācija regulāri jāpārbauda. Mainās darbinieki, piegādātāji, līgumi un atbildīgās personas.

Jāpadomā arī par to, kur kontaktinformācija tiek glabāta..

Ja visi incidenta kontakti ir pieejami tikai uzņēmuma e-pastā vai sistēmā, kas incidenta laikā pati nav pieejama, labi sagatavots saraksts var izrādīties bezjēdzīgs.

3. Saziņas kārtība incidenta laikā

Viens no bieži nenovērtētiem incidenta aspektiem ir komunikācija.

Ikdienā uzņēmumi paļaujas uz e-pastu, Microsoft Teams un citām saziņas platformām. Taču incidenta laikā tieši šie rīki var nebūt pieejami.

Tāpēc rīcības plānam jāatbild arī uz praktiskiem jautājumiem:

Kā darbinieki sazināsies, ja e-pasts vai ierastā saziņas platforma nedarbosies?
Kurš informēs darbiniekus par notiekošo?
Kurš drīkst komunicēt ar klientiem un partneriem?
Kad par incidentu jāinformē ārējās puses?
Kā nodrošināt, lai dažādi cilvēki nesniegtu pretrunīgu informāciju?

Iepriekš noteikta komunikācijas kārtība palīdz nepieļaut, ka tehniskam incidentam pievienojas arī komunikācijas haoss.

Svarīgi ir arī izvairīties no pārsteidzīgiem secinājumiem, kamēr incidenta cēlonis un apmērs vēl nav pietiekami skaidrs.

4. Kritiskās sistēmas un biznesa prioritātes

Incidenta laikā ne vienmēr ir iespējams atjaunot visu vienlaikus.

Tāpēc jau iepriekš jābūt skaidram, kuras sistēmas un procesi uzņēmuma darbībai ir vissvarīgākie.

Prioritāti nevajadzētu noteikt tikai pēc tā, cik tehniski svarīga sistēma šķiet. Lietderīgāks jautājums ir:

Kas notiek ar uzņēmumu, ja šī sistēma nav pieejama?

Vienam uzņēmumam kritiskākā var būt noliktavas vadības sistēma, citam — klientu apkalpošanas platforma, finanšu sistēma vai ražošanas vide.

Rīcības plānā jābūt definētām:

kritiskās sistēmas un lietojumprogrammas;
būtiskākie biznesa procesi;
sistēmu savstarpējās atkarības;
sistēmu atjaunošanas secība;
pieļaujamais dīkstāves laiks.

Ja prioritātes nav noteiktas iepriekš, incidenta laikā var rasties vēlme atjaunot visu uzreiz. Rezultātā resursi tiek izkliedēti un uzņēmumam svarīgāko pakalpojumu atjaunošana var aizkavēties.

5. Skaidra incidenta vadības un atjaunošanas kārtība

Rīcības plānam nav jābūt simtiem lappušu garam tehniskam dokumentam.

Tam gan jābūt pietiekami konkrētam, lai incidenta laikā cilvēkiem būtu skaidrs nākamais solis.

Vienkāršoti incidenta vadības procesu var iedalīt vairākos posmos:

identificēt → izvērtēt → ierobežot → atjaunot → pārbaudīt.

Vispirms jāsaprot, kas ir noticis un kāda var būt incidenta ietekme. Pēc tam jāierobežo tā tālāka izplatīšanās, jānosaka atjaunošanas prioritātes un kontrolēti jāatgriež sistēmas darbībā.

Tas ir īpaši svarīgi kiberdrošības incidentos.

Pārāk ātra sistēmas atjaunošana, pirms ir saprasts incidenta cēlonis, var nozīmēt, ka kopā ar sistēmu tiek atjaunota arī sākotnējā problēma.

Tāpēc rīcības plānā būtu jāparedz:

sākotnējās darbības pēc incidenta konstatēšanas;
eskalācijas kārtība;
lēmumu pieņemšanas process;
sistēmu atjaunošanas secība;
sistēmu pārbaude pēc darbības atjaunošanas.

6. Regulāra pārbaude un plāna aktualizēšana

Ar rīcības plāna izveidi darbs nebeidzas.

Mainās darbinieki, sistēmas, infrastruktūra, piegādātāji un uzņēmuma procesi. Tas, kas bija aktuāls pirms diviem gadiem, šodien var vairs neatspoguļot reālo situāciju.

Tāpēc plāns regulāri jāpārskata un jāpārbauda praksē.

Tas var ietvert:

kontaktinformācijas pārbaudi;
atbildīgo personu un lomu pārskatīšanu;
rezerves kopiju atjaunošanas testus;
incidenta izspēli jeb tabletop vingrinājumu;
alternatīvo saziņas kanālu pārbaudi;
secinājumu izvērtēšanu pēc reāliem incidentiem.

Testēšana palīdz pamanīt trūkumus, kurus dokumentā vien nevar ieraudzīt.

Daudz labāk ir kontrolētas pārbaudes laikā atklāt, ka kāds kontakts vairs nav aktuāls vai atjaunošanas process nedarbojas kā paredzēts, nekā to uzzināt brīdī, kad uzņēmuma darbība jau ir traucēta.

Ar plānu vien nepietiek

Incidentu rīcības plāns nav tikai dokuments, kas glabājas uzņēmuma iekšējā sistēmā.

Cilvēkiem, kuriem incidenta laikā būs jāpieņem lēmumi vai jāveic konkrēti uzdevumi, jāzina par plāna esamību, jāizprot sava loma un jābūt gataviem rīkoties.

Jo vairāk ir sagatavots iepriekš, jo mazāk jāimprovizē brīdī, kad incidents jau ir sācies.

Gatavību incidentam veido pirms tas notiek

Labs incidentu rīcības plāns nemēģina paredzēt pilnīgi visus iespējamos scenārijus.

Tā uzdevums ir nodrošināt, lai kritiskā brīdī būtu skaidrs:

kurš pieņem lēmumus, kas jādara vispirms, kā turpināt komunikāciju un kā pēc iespējas ātrāk atjaunot uzņēmumam svarīgāko sistēmu un procesu darbību.

Ja neesat pārliecināti, cik gatavs uzņēmums ir IT incidentam, Datakom var palīdzēt izvērtēt esošo situāciju, identificēt būtiskākās nepilnības un noteikt praktiskus soļus IT noturības uzlabošanai.

Sazinieties ar Datakom un noskaidrojiet, cik gatava jūsu IT vide ir neparedzētai situācijai.