Kāpēc organizācijas atkārto vienas un tās pašas kiberdrošības kļūdas: ko atklāj incidentu pēcanalīze?

Uzņēmums piedzīvo kiberincidentu. Izmeklēšanas laikā atklājas, ka būtiskam serverim jau vairākus mēnešus nav uzstādīts drošības labojums, lai gan ievainojamība iepriekš bijusi zināma. Pēcanalīzes ziņojumā norādīts, ka nepieciešams uzlabot atjauninājumu pārvaldību. Tiek mainīta procedūra, organizēta sanāksme un atbildīgajai komandai dots uzdevums nepieļaut līdzīgu situāciju atkārtošanos. Pēc gada tiek konstatēts jauns incidents. Šoreiz ievainojamība atrodas citā sistēmā, taču apstākļi ir pazīstami: labojums bija pieejams, risks bija reģistrēts, bet izmaiņas ieviešana tika atlikta. Iepriekšējā procedūra nav pietiekami mainījusi to, kā organizācija pieņem lēmumus par novēršanas prioritātēm.

Šis ir hipotētisks piemērs, taču tas precīzi ilustrē vienu no sarežģītākajām incidentu pēcanalīzes problēmām. Organizācija var pareizi identificēt tehnisko kļūdu, vienlaikus nepamanot procesu, kas šo kļūdu atkārtoti rada. Var vainot nepietiekamu disciplīnu, komandas noslodzi vai finansējumu. Dažkārt tie patiešām ir būtiski faktori. Taču šādi skaidrojumi kļūst mazvērtīgi, ja tie nepalīdz saprast, kāpēc konkrēts risks izdzīvoja cauri vairākām pārbaudēm, sanāksmēm, budžeta cikliem un apstiprinātiem uzdevumiem. 2023. gadā publicētā sistemātiskā akadēmiskās literatūras analīze par mācīšanos no kiberdrošības incidentiem identificēja vairākus šķēršļus: virspusēju cēloņu izpēti, nepietiekamu dalību mācīšanās procesā, vāju turpmāko darbību īstenošanu un ierobežotu pārbaudi, vai tās tiešām samazina nākotnes incidentu risku. No 3986 sākotnēji identificētām publikācijām sistemātiskai analīzei tika atlasīti 30 darbi. S01

Šie secinājumi nav pierādījums, ka visas organizācijas mācās vienādi slikti. Tomēr tie palīdz izvirzīt precīzākus jautājumus par to, kas notiek ar incidenta laikā iegūtajām zināšanām. Manuprāt, incidenta pēcanalīze jāuztver nevis kā atsevišķs ziņojums pēc krīzes, bet kā tests organizācijas spējai mainīt savu darbību. Ja konstatētā problēma atkārtojas, jāanalizē ne tikai iepriekšējais tehniskais defekts, bet arī pats lēmumu un uzdevumu izpildes mehānisms.

Pēc nopietna incidenta organizācijā parasti pieaug uzmanība drošībai. Vadība pieprasa informāciju, tehniskās komandas saņem papildu uzdevumus, tiek pārskatītas procedūras un plānoti jauni ieguldījumi. Taču šis uzmanības periods nav bezgalīgs. Atjaunojoties normālai uzņēmuma darbībai, kiberdrošības jautājumi atkal konkurē ar produktu attīstību, pakalpojumu pieejamību, izmaksu samazināšanu un citiem organizācijas mērķiem. Tas ir viens no iemesliem, kāpēc pēcincidenta ieteikums var būt pareizs, bet netikt pilnībā īstenots. Uzlabojuma izpildei nepieciešamie resursi, pilnvaras un termiņi ne vienmēr ir saskaņoti ar organizācijas ikdienas lēmumu pieņemšanas kārtību.

Piemēram, drošības komanda var identificēt novecojušu sistēmu, bet tās nomaiņa ir atkarīga no biznesa funkcijas, kurai prioritāte ir nepārtraukta pakalpojuma sniegšana. Ja nav noteikts lēmuma pieņemšanas mehānisms šādam konfliktam, drošības problēma var palikt neatrisināta arī tad, ja visi iesaistītie par to zina. Dažreiz trūkums ir vēl vienkāršāks: ieteikumam nav konkrēta īpašnieka. Ziņojumā ierakstīts, ka jāuzlabo uzraudzība, bet nav noteikts, kura komanda mainīs datu avotus, kas apstiprinās tehniskās prasības un kas nodrošinās uzturēšanu pēc sākotnējās ieviešanas.

Šādas situācijas rāda, kāpēc zināšanu iegūšana un organizatoriskā mācīšanās nav viens un tas pats. Zināšanas var palikt dokumentā, kamēr reālā darbības kārtība nemainās.

Pēcanalīzē nepieciešams nošķirt vairākus cēloņsakarību līmeņus. Pirmais ir novērotais incidents vai tā simptoms. Otrais ir konkrētais tehniskais mehānisms, kas ļāva apdraudējumam realizēties. Trešais ir organizatoriskie apstākļi, kuru dēļ šis mehānisms saglabājās vai netika savlaicīgi novērsts. Pieņemsim, ka uzbrucējs izmanto ievainojamu internetā pieejamu sistēmu. Tehniskais cēlonis var būt konkrēts neuzstādīts labojums. Taču sistēmiskā analīze turpinās ar jautājumiem, kāpēc attiecīgā sistēma nebija iekļauta atjauninājumu procesā, vai organizācijai bija precīza aktīvu uzskaite, kā tika pieņemti lēmumi par izmaiņu atlikšanu un vai iepriekš bija signāli par nepietiekamu kontroli.

Šajā piemērā jāuzmanās arī no pārspīlēšanas. Ja publiski vai iekšējā izmeklēšanā apstiprināts tikai ievainojamības izmantošanas fakts, nevar automātiski secināt, ka aktīvu inventarizācija bija nepilnīga vai vadība ignorēja brīdinājumus. Tie ir iespējamie izmeklēšanas jautājumi, nevis jau pierādīti cēloņi. Sistēmiskā analīze nedrīkst pārvērsties par neierobežotu minējumu ķēdi. Katram apgalvojumam vajadzīgi novērojumi, dokumenti, lēmumu vēsture vai citas pārbaudāmas liecības. Īpaši nozīmīgi ir apskatīt tehniskā procesa robežas. Vai kontrolē ietilpa tikai centrāli pārvaldītas sistēmas, bet ne piegādātāju komponenti? Vai drošības novērtējums aptvēra tikai sākotnējo ieviešanu, bet ne turpmākās izmaiņas? Vai risku reģistrs bija atjaunināts, taču no tā neizrietēja obligāta darbība?

Tikai analizējot šādus apstākļus, iespējams saprast, vai nākamais līdzīgais incidents būtu jānovērš ar tehnisku labojumu, atbildības pārdali, pārvaldības izmaiņu vai vairāku pasākumu kombināciju.

Pēcanalīzes ziņojums var būt tehniski precīzs un vienlaikus praktiski neefektīvs. Tas notiek, ja dokumenta sagatavošana kļūst par pēdējo formālo procesa soli, nevis sākumu lēmumiem, kuri maina organizācijas darbību. Parasti problēma nav tikai tā, ka ziņojumu neviens nelasa. Daudz biežāk tajā noteiktie ieteikumi nav pārvērsti izpildāmās saistībās. Formulējums “pilnveidot piekļuves pārvaldību” ļauj katrai iesaistītajai komandai saprast citu darba apjomu. Viena komanda pārskata administratoru kontus, cita uzlabo autentifikāciju, bet neviens nepārbauda, vai kopējais privileģēto piekļuves tiesību modelis joprojām rada sākotnēji konstatēto risku.

Pēcanalīzes ieteikumu kvalitāti tāpēc nevar vērtēt tikai pēc dokumenta apjoma vai izteikto rekomendāciju skaita. Nozīme ir tam, vai katrs būtiskais secinājums sasniedz konkrētu lēmumu un vai organizācijā ir mehānisms sekot līdzi tā īstenošanai. Kentas Universitātē 2025. gadā aizstāvētais pētījums par organizatorisko mācīšanos no kiberdrošības incidentiem analizē šo procesu plašāk nekā tikai cēloņu identificēšanu: no tā, kuri incidenti vispār tiek izvēlēti analīzei, līdz tam, vai iegūtās mācības kļūst par reālām drošības prakses izmaiņām. S02

Tas norāda uz vēl vienu risku. Organizācija var kvalitatīvi izmeklēt lielus incidentus, bet ignorēt mazākus brīdinājuma notikumus, kuros redzama tā pati sistēmiskā nepilnība. Ja analīzes process tiek aktivizēts tikai pēc ievērojama kaitējuma, daļa iespēju mācīties tiek palaista garām.

Ne visas kiberdrošības kļūdas rodas drošības komandā. Būtiska daļa var atrasties starp organizatoriskajām atbildības robežām. Piemēram, informācijas sistēmas īpašnieks atbild par pakalpojuma pieejamību, infrastruktūras komanda — par platformas uzturēšanu, bet drošības komanda — par risku identificēšanu. Ja nevienai no šīm funkcijām nav pilnvaru pieņemt galīgo lēmumu par nedrošas sistēmas nomaiņu, tehniskā problēma var saglabāties gadiem. Citā organizācijā drošības mērķi un darba novērtēšanas kritēriji var būt savstarpēji pretrunīgi. Komanda tiek vērtēta pēc pakalpojuma pieejamības, tāpēc kritiski drošības atjauninājumi tiek atkārtoti atlikti. Formāli tas var izskatīties pēc individuālu izmaiņu vadības lēmumu kopuma, bet faktiski liecināt par to, kā organizācija sadala prioritātes.

Šādu situāciju nevar atrisināt ar vienu atgādinājumu, ka drošība ir svarīga. Vajadzīgs vadības līmenī pieņemts lēmums par to, kā līdzsvarot riskus, kādos apstākļos izmaiņu atlikšana ir pieļaujama un kurš uzņemas atbildību par atlikušajām sekām. Līdzīga problēma rodas piegādes ķēdē. Organizācija var saņemt detalizētu audita atradumu par ārpakalpojuma sistēmu, bet tai nav pietiekamu līgumisku tiesību pieprasīt labojuma ieviešanu. Šādā gadījumā saknes cēlonis var būt nevis ievainojamību pārvaldības procedūra, bet sākotnējais piegādātāja līgums un piegādes pieņemšanas kritēriji.

Tie ir ilustratīvi mehānismi. Lai noteiktu, kurš no tiem izraisījis reālu incidentu, nepieciešams pārbaudīt konkrētās organizācijas dokumentus un darbību.

Nopietna incidenta laikā cilvēki izjūt spiedienu ātri noskaidrot, kas noticis un kurš par to atbild. Atbildības noteikšana atsevišķos gadījumos ir nepieciešama, it īpaši ja notikusi apzināta noteikumu pārkāpšana vai prettiesiska darbība. Tomēr pārāk agra koncentrēšanās uz vienu vainīgo var ierobežot izmeklēšanas kvalitāti. Pieņemsim, ka administrators kļūdaini apstiprina neatbilstošu piekļuves tiesību izmaiņu. Ja pēcanalīze noslēdzas ar secinājumu, ka administrators nav bijis pietiekami uzmanīgs, netiek pārbaudīts, kāpēc attiecīgā darbība bija iespējama bez papildu kontroles, vai saskarne bija maldinoša un vai citi speciālisti līdzīgā situācijā varētu pieļaut tādu pašu kļūdu.

Tas nenozīmē, ka individuāla atbildība nekad nav svarīga. Drīzāk tā jānošķir no sistēmas uzlabošanas. Organizācija var izvērtēt konkrētas personas rīcību un vienlaikus analizēt, kādas kontroles nepieciešamas, lai nākotnē kļūdai nebūtu tik smagas sekas. Ja incidentu pēcanalīze tiek uztverta tikai kā disciplinārs process, darbiniekiem var rasties motivācija noklusēt kļūdas, neprecizitātes un agrīnos brīdinājumus. Tas var pasliktināt informācijas kvalitāti, uz kuras pamata tiek veidoti turpmākie drošības pasākumi. Es izvēlētos procesu, kurā sākotnēji tiek nodrošināta faktu un apstākļu analīze, saglabāti nepieciešamie pierādījumi un tikai pēc tam tiek izdarīti atsevišķi secinājumi par pienākumu izpildi vai iespējamu atbildību, ievērojot piemērojamo tiesisko kārtību.

2024. gada martā ASV Cyber Safety Review Board publicēja neatkarīgu ziņojumu par 2023. gada Microsoft Exchange Online incidentu. Izvērtējums analizēja ne tikai uzbrukuma tehniskos apstākļus, bet arī operacionālos un stratēģiskos lēmumus, kas veicināja incidenta iespējamību un tā sekas. S03 Ziņojuma būtība šīs publikācijas kontekstā nav atkārtot visu uzbrukuma tehnisko hronoloģiju. Daudz nozīmīgāks ir jautājums, kā drošības kultūra, inženiertehniskās izvēles un organizācijas prioritātes var ietekmēt sistēmas spēju novērst vai savlaicīgi atklāt nopietnu kompromitēšanu.

CSRB vērtēja Microsoft drošības praksi un secināja, ka uzbrukumu būtu bijis iespējams novērst. Ziņojumā uzsvērta drošības kultūras un organizatorisko lēmumu loma. Tas ir konkrētas izmeklēšanas secinājums, nevis vispārīga formula, ar kuru bez papildu analīzes varētu raksturot jebkuru tehnoloģiju uzņēmumu. Šis gadījums ir noderīgs arī tāpēc, ka parāda neatkarīga izvērtējuma nozīmi. Iekšējā incidenta analīze var precīzi izskaidrot konkrētu tehnisku kļūmi, bet ārējs izvērtējums var uzdot jautājumus par plašākiem organizatoriskajiem priekšnosacījumiem, kuriem uzņēmuma iekšienē pievērsta nepietiekama uzmanība.

Vienlaikus neatkarīgas komisijas secinājumi ir jālasa to faktiskajā tvērumā. Tie neļauj automātiski piedēvēt identiskus trūkumus citām organizācijām. Manuprāt, šis gadījums ilustrē svarīgu principu: nopietnas drošības problēmas ne vienmēr ir tikai atsevišķu tehnisku kļūdu summa. Tās var atspoguļot lēmumu un prioritāšu struktūru, kura ilgstoši pieļāvusi noteiktu risku uzkrāšanos.

Diviem incidentiem nav jāizmanto viena un tā pati ievainojamība, lai tiem būtu kopīgs sistēmisks cēlonis. Vienā gadījumā uzbrucējs izmanto novecojušu VPN komponentu, otrā — publiski pieejamu lietojumprogrammu. Ja abos gadījumos atklājas, ka organizācija nepārvalda visas ārēji pieejamās sistēmas, problēma var atrasties aktīvu pārvaldības līmenī. Līdzīgi divi atšķirīgi identitāšu incidenti var atklāt vienu un to pašu pārmērīgu piekļuves tiesību piešķiršanas procesu. Ja viens gadījums skar cilvēka kontu, bet otrs — automatizācijas identitāti, tehniskā atšķirība vēl nenozīmē, ka cēloņi ir neatkarīgi.

Šādai analīzei nepieciešama konsekventa incidentu un pēcanalīzes secinājumu klasifikācija. Katra būtiskā problēma jāapraksta tā, lai varētu noteikt, kādai kontrolei, procesam vai vadības lēmumam tā piesaistīta. Tomēr arī līdzīgu pazīmju automātiska grupēšana var būt maldinoša. Divas neatjauninātas sistēmas var būt radušās pilnīgi atšķirīgos apstākļos. Vienai labojums nav uzstādīts inventarizācijas problēmas dēļ, bet otrai — ārējā piegādātāja nepieejamas versijas dēļ. Kopīga kategorija var palīdzēt sākt analīzi, taču tā neapstiprina vienu saknes cēloni.

Es izmantotu kopīgu incidentu secinājumu reģistru, kurā katrs ieraksts sasaistīts ar pierādījumiem, konkrētu kontroles mērķi, iepriekšējiem līdzīgiem gadījumiem un lēmumu vēsturi. Šādi kļūst iespējams pārbaudīt, vai atkārtojas identisks tehnisks defekts, viens organizatorisks šķērslis vai tikai ārēji līdzīgs simptoms.

Piedāvāju septiņu jautājumu matricu, ar kuru pārbaudīt incidenta atkārtošanās risku. Tā ir autora analītiska metode, nevis oficiāla NIST vai ENISA veidlapa.

Šī matrica palīdz nošķirt situāciju, kurā kontrole nekad nav ieviesta, no situācijas, kurā kontrole sākotnēji strādājusi, bet vēlāk kļuvusi neefektīva. Tie ir atšķirīgi uzdevumi. Pirmajā gadījumā jānoskaidro ieviešanas šķēršļi, otrajā — uzturēšanas un izmaiņu pārvaldības problēmas. Vēl būtiskāks ir jautājums, vai organizācija jau iepriekš pieņēmusi lēmumu par attiecīgo risku. Ja līdzīga problēma ir dokumentēta vairākos neatkarīgos auditos, bet joprojām nav novērsta, pēcanalīzei vajadzētu izskatīt šo lēmumu vēsturi, nevis tikai atkārtot sākotnējo tehnisko rekomendāciju.

Lai pārtrauktu atkārtošanos, ar jaunu kontroles ieviešanu vien var nepietikt. Ja risku rada lēmumu pieņemšanas kārtība, jāmaina arī šī kārtība. Piemēram, ja drošības atjauninājumi regulāri tiek atlikti tāpēc, ka produkcijas sistēmām nav pārbaudāmas izmaiņu ieviešanas vides, risinājums var ietvert testēšanas infrastruktūru un skaidrus izmaiņu logus. Ja problēma rodas no ārējiem piegādātājiem, nepieciešamas līgumiskas prasības un izpildes pārbaude. Ja drošības komanda atkārtoti konstatē vienus un tos pašus riskus, bet tai nav lēmuma eskalācijas iespējas, jāmaina pārvaldības modelis.

Tas nozīmē, ka pēcincidenta uzlabojumi nevar būt tikai kiberdrošības nodaļas iekšēja darba programma. Tajos jāiesaista cilvēki, kuri kontrolē attiecīgos tehniskos un biznesa procesus. Būtiski arī nenoteikt nereālus termiņus. Sistēmiska problēma dažkārt prasa arhitektūras pārbūvi vai ilgstošu piegādātāja nomaiņu. Ja to dokumentā pasludina par novēršamu vienas nedēļas laikā, var rasties formāls, nevis praktisks rezultāts. Līdz faktiskai novēršanai jābūt skaidram atlikušā riska novērtējumam un iespējamajām pagaidu kontrolēm. Ja sistēmiskais šķērslis ir novērsts, organizācijai vēl jānoskaidro, vai tā pati problēma nepastāv citās sistēmās. Viena aktīva labojums ne vienmēr atrisina kopējo ievainojamību pārvaldības defektu.

Šajā vietā būtiska ir ceturtajā portfeļa iterācijā analizētā uzlabojumu efektivitātes pārbaude. Taču devītās iterācijas jautājums ir iepriekšējais solis: vai organizācija vispār ir pieņēmusi tādus lēmumus, kas ļauj sākotnēji identificēto sistēmisko cēloni novērst.

Drošības komanda var identificēt apdraudējumu, rekonstruēt incidentu un ieteikt kontroles izmaiņas. Tomēr tā ne vienmēr kontrolē visu infrastruktūras attīstības budžetu, piegādātāju līgumus, biznesa procesa uzbūvi un uzņēmuma prioritātes. Vadībai tāpēc jānodrošina, lai sistēmiskie cēloņi tiktu izskatīti atbilstošā pilnvaru līmenī. Ja drošības problēma izriet no pretrunas starp pakalpojuma pieejamību un atjauninājumu ieviešanu, nepieciešams skaidrs lēmums par pieļaujamo risku un tā pārvaldību. Iekšējais audits var palīdzēt pārbaudīt, vai iepriekš apstiprinātās darbības tiešām mainījušas organizācijas procesu, ne tikai radījušas jaunus dokumentus. Auditora uzdevums nav aizstāt incidenta tehnisko izmeklēšanu, bet kritiski izvērtēt, vai organizācija mācās no identificētajām problēmām.

Noderīga var būt arī neatkarīga otra skatpunkta piesaiste būtiskiem incidentiem. Cita komanda vai ārējs speciālists var pārbaudīt, vai pēcanalīzes secinājumi nav pārāk šauri un vai netiek ignorēti organizatoriski faktori ārpus tehniskās izmeklēšanas tvēruma. Šāda pieeja nav jāpadara par nesamērīgi dārgu birokrātiju. Nelielā uzņēmumā pietiek ar īsu, bet konkrētu vadības lēmumu un pārbaudāmu turpmāko darbību. Lielā organizācijā var būt nepieciešama formālāka koordinācija starp vairākiem procesu īpašniekiem.

NIST SP 800-61 Rev. 3, kas publicēts 2025. gada aprīlī, incidentu reaģēšanu vairs neuztver kā izolētu procesu, kuru īsteno tikai incidentu komanda. Tas sasaista reaģēšanu ar organizācijas kopējo kiberdrošības risku pārvaldību un NIST CSF 2.0 funkcijām. Dokumentā uzsvērts, ka iegūtās mācības jāizmanto arī incidenta gaitā, ne vienmēr gaidot pilnīgu atkopšanas noslēgumu. S04 Tas ir būtisks processuāls princips. Ja organizācija jau incidenta laikā atklāj līdzīgas ievainojamības citās sistēmās, nav obligāti jāgaida gala ziņojums, lai sāktu to risku ierobežošanu, ja vien darbības ir saskaņotas ar izmeklēšanas un pakalpojumu drošības vajadzībām.

ENISA 2026. gada kiberdrošības mācību metodoloģijā paredzēts pēc mācībām atšķirt atklātos organizācijas spēju trūkumus no pašas mācību norises nepilnībām. Abām kategorijām nepieciešami konkrēti turpmākie uzdevumi, un ieviestajiem uzlabojumiem pēc tam jābūt pārbaudāmiem. S05 Mācību metodoloģija nav identiska reāla incidenta izmeklēšanai, bet tā palīdz izprast plašāku ciklu: problēmu identificēšana, lēmumu pieņemšana, uzdevumu īstenošana un pārbaude. 2026. gada Cyber Europe mācībās ENISA uzsvēra, ka mācībām jābūt daļai no nepārtrauktas sagatavotības pilnveidošanas. Organizatori paredzēja pēcanalīzes ziņojumus ar secinājumiem un uzlabojumu priekšlikumiem. No šāda paziņojuma vien nevar apgalvot, ka visi ieteikumi jau īstenoti vai ka reālās organizāciju spējas pēc mācībām obligāti uzlabojās. S06

Viens un tas pats tehniskais simptoms var rasties dažādu sistēmisku cēloņu dēļ. Neieviests drošības labojums var nozīmēt nepietiekamu aktīvu uzskaiti, neskaidru atbildību, neatbilstošu izmaiņu pārvaldību vai apzinātu, bet slikti kontrolētu riska izņēmumu. Bez šo mehānismu nošķiršanas nākamās pēcanalīzes rīcības plāns tikai atkārtos prasību «uzlabot atjaunināšanu». Es katram atkārtotajam incidentu modelim meklētu iepriekš pieņemtu vadības lēmumu, kurš to padarīja iespējamu vai atstāja neatrisinātu. Tad noteiktu pārbaudāmu pretfaktu: kā mainītos situācija, ja konkrēta kontrole būtu darbojusies paredzētajā laikā? Pārbaudei nepieciešams gan tehnisks pierādījums, gan procesa īpašnieka skaidrojums par ierobežojumiem. Šī pieeja ļauj kritiski vērtēt organizācijas sistēmu, nepiešķirot individuālu vainu cilvēkiem, par kuru faktiskajām pilnvarām un informētību mums trūkst datu.

Incidenta pēcanalīzes dokuments var pamatot secinājumu par konstatētu procesu vai lēmumu nepilnību, taču rekomendācijas esamība nav tās izpildes pierādījums. Šī atšķirība ir īpaši svarīga, salīdzinot organizācijas: bez ieviešanas žurnāliem, termiņiem un atkārtotu testu rezultātiem nevar aprēķināt noturības pieaugumu tikai no publicēto secinājumu skaita.

Organizācija var atkārtot vienas un tās pašas kiberdrošības kļūdas pat tad, ja tās speciālisti ir kompetenti, incidentu izmeklēšana bijusi tehniski precīza un pēcanalīzes ziņojumā konstatēti pareizie trūkumi. Iemesls var būt nepietiekama pilnvaru sadale, savstarpēji pretrunīgas biznesa prioritātes, neizpildīti iepriekšējie lēmumi vai kontroles, kuras netiek uzturētas pēc sākotnējās ieviešanas. Šos faktorus nevar identificēt, analizējot tikai uzbrucēja izmantoto ievainojamību vai galiekārtā redzamo darbību secību. Manuprāt, atkārtota incidenta laikā vienmēr jāuzdod papildu jautājums: vai organizācija līdzīgu problēmu jau iepriekš bija identificējusi, un kas notika ar attiecīgo secinājumu?

Ja atbilde ir atrodama senā audita ziņojumā, neizpildītā uzdevumā vai lēmumā bez pārskatīšanas termiņa, incidenta pēcanalīzei jāturpina skatīties tālāk par tehnisko saknes cēloni. Tas ir punkts, kur kiberdrošība kļūst par pārvaldības kvalitātes pārbaudi. Zināt par risku, pieņemt lēmumu un faktiski izmainīt organizācijas darbību ir trīs atšķirīgas lietas.