DORA intsidentidest teavitamine ja ISO 27001 kontrollimeetmed 2026. aastal

On 2026. aasta teisipäeva hommik kell 08:17. Euroopa finantstehnoloogia ettevõtte infoturbejuht Sarah näeb juhtpaneelil kollast, mitte punast hoiatust. Kriitiline maksete arveldusplatvorm aeglustub. Tehingud ei ebaõnnestu täielikult, kuid nende töötlemine võtab kolm korda kauem, kui teenustaseme leping lubab. SOC näeb administraatorikonto vastu ebatavalisi autentimiskatseid. Pilvetaristu pakkuja teatab teenuse kvaliteedi halvenemisest ühes käideldavustsoonis. Klienditugi hakkab saama kõnesid äriklientidelt, kes küsivad, miks maksefailid viibivad.

Keegi ei tea veel, kas tegemist on küberrünnaku, talitluspidevuse tõrke, tarnijapoolse katkestuse, privaatsusintsidendi või kõigega korraga.

Sarahil on DORA probleem juba enne, kui tehnilised faktid on täielikud. Kas see on oluline IKT-ga seotud intsident? Kas see mõjutab kriitilist või olulist funktsiooni? Kas sisemine tõsiduslävend on ületatud? Keda tuleb teavitada, millal ja millise tõendusmaterjaliga? Kui kaasatud on isikuandmed, kas ka GDPR teavitustähtaeg on alanud? Kui intsidendiahelas osaleb kolmandast isikust IKT-teenusepakkuja, kes vastutab faktide kogumise eest?

Just siin avastavad finantsüksused lõhe intsidendile reageerimise plaani olemasolu ja auditikõlbliku DORA intsidentidest teavitamise tegevusmudeli vahel.

DORA intsidentidest teavitamine 2026. aastal nõuab enamat kui kiiret eskaleerimist. Vaja on kaitstavat ahelat tuvastamisest klassifitseerimiseni, klassifitseerimisest järelevalvelise teavitamiseni, teavitamisest parandusmeetmeteni ning parandusmeetmetest õppetundideni. ISO/IEC 27001:2022 annab juhtimissüsteemi struktuuri. ISO/IEC 27002:2022 lisa A kontrollimeetmed annavad praktilised kontrolliootused. Clarysec poliitikad, 30-sammuline teekaart ja ristvastavuse juhend muudavad need ootused auditivalmis rakenduseks.

Miks DORA intsidentidest teavitamine surve all ebaõnnestub

Enamik DORA intsidentidest teavitamise ebaõnnestumisi ei alga hooletusest. Need algavad ebamäärasusest.

Turbeanalüütik näeb teavitust, kuid ei tea, kas see kvalifitseerub DORA mõistes IKT-ga seotud intsidendiks. IT-teenuse juht käsitleb teenuse halvenenud toimivust tehnilise teenuseprobleemina, samas kui vastavusüksus käsitleb seda regulatiivse sündmusena. Õigusüksus ootab enne eskaleerimist kinnitust. Äriomanik ei suuda veel kliendimõju kvantifitseerida. Infoturbejuht vajab tõendusmaterjali, kuid asjakohased logid paiknevad pilveteenustes, lõppseadmetes, identiteedisüsteemides, SIEM-is ja tarnijaplatvormidel.

Selleks ajaks, kui organisatsioon jõuab klassifitseerimises kokkuleppele, on teavitamise ajaraam juba surve all.

DORA Article 17 kuni Article 21 loovad struktureeritud ootuse IKT-ga seotud intsidendihaldusele, klassifitseerimisele, teavitamisele, teavituse sisule ja järelevalvelisele käsitlemisele. Finantsüksuste jaoks on praktiline nõue selge: IKT-ga seotud intsidente tuleb seirata, hallata, logida, klassifitseerida, neist teatada, neid ajakohastada ja neist õppida viisil, mida saab hiljem rekonstrueerida.

Clarysec Intsidentidele reageerimise poliitika [IRP] lõimib DORA otse viiteraamistikku:

EL DORA (2022/2554): Article 17: IKT-intsidentidest teavitamise nõuded finantsasutustele pädevate asutuste ees.

Sama poliitika seob intsidendihalduse ISO/IEC 27002:2022 kontrollimeetmetega 5.25 kuni 5.27, hõlmates vastutust intsidendi hindamise, reageerimise, kommunikatsiooni ja täiustamise eest.

Väiksemate finantstehnoloogia ettevõtete ja piiratud ressurssidega reguleeritud üksuste jaoks muudab Clarysec Intsidentidele reageerimise poliitika - VKE [IRP-SME] kohustuse praktiliseks, rõhutades, et DORA nõuab finantsüksustelt IKT-ga seotud intsidentide ja häirete klassifitseerimist, neist teatamist ja nende jälgimist.

See sõnastus on oluline. DORA nõuetele vastavus ei ole üksnes teavitusvorm. Organisatsioon peab klassifitseerima, teavitama ja jälgima. See tähendab tõendusmaterjali esialgse sündmuse, otsustuskriteeriumide, tõsidustaseme, teavitamisotsuse, kommunikatsiooni, taastetegevuste, tarnija kaasatuse ja järeltegevuste kohta.

ISO/IEC 27001:2022 kui DORA intsidentide juhtimiskeskus

Küps ISO/IEC 27001:2022 infoturbe juhtimissüsteem (ISMS) ei tohi muutuda DORA kõrval eraldi vastavussiloks. Sellest peab saama DORA intsidentidest teavitamise juhtimiskeskus.

ISMS nõuab juba riskiomandit, kontrollimeetmete valikut, siseauditit, juhtkonna läbivaatust, dokumenteeritud teavet, pidevat täiustamist ja tõendusmaterjali kontrollimeetmete toimimise kohta. DORA lisab sektoripõhise teavitussurve, kuid ISO/IEC 27001:2022 annab juhtimisstruktuuri, mis muudab protsessi korratavaks.

Clarysec Zenith Blueprint: audiitori 30-sammuline teekaart [ZB] tugevdab seda integratsiooni sammus 13, riski käsitlemise planeerimine ja kohaldatavusdeklaratsioon. Blueprint soovitab jälgitavuse tagamiseks seostada kontrollimeetmed riskide ja klauslitega, sealhulgas lisada riskidele lisa A kontrollimeetme viide ning märkida, millal kontrollimeetmed toetavad GDPR, NIS2 või DORA nõudeid.

Sarahi maksete arveldusintsidendi puhul võib riskiregistri kirje olla:

„Maksete töötlemise platvormi häire või kompromiteerimine.“

Seostatud ISO/IEC 27001:2022 lisa A kontrollimeetmed hõlmaksid 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 ja 8.16, koos DORA märkusega olulise IKT-ga seotud intsidendi klassifitseerimise ja teavitamise kohta.

Clarysec Zenith Controls: ristvastavuse juhend [ZC] toimib seejärel ristvastavuse kompassina. Zenith Controls juhendis seostab Clarysec ISO/IEC 27002:2022 kontrollimeetmed teiste ISO/IEC 27001:2022 kontrollimeetmete, seotud standardite, auditiootuste ja regulatsioonidega, nagu DORA, GDPR ja NIS2. See ei loo eraldi „Zenith kontrollimeetmeid“. See näitab, kuidas olemasolevad ISO kontrollimeetmed koos toimivad ja kuidas neid testitakse.

DORA teavitamise töövoogu võib vaadelda kontrolliahelana:

Ei saa teatada sellest, mida ei tuvastatud. Ei saa klassifitseerida seda, mida ei hinnatud. Teavitamisotsust ei saa põhjendada ilma kirjeteta. Parandada ei saa ilma intsidendijärgse ülevaatuseta.

Kontrollimeede 6.8: DORA kell hakkab käima inimestest

Sarahi stsenaariumis ei pruugi esimene kasulik signaal tulla SOC-ist. See võib tulla kliendihaldurilt, kes kuuleb klientide kaebusi, finantskasutajalt, kes näeb ebaõnnestunud arvelduspakette, või insenerilt, kes märkab ebanormaalset latentsust.

Seetõttu on ISO/IEC 27001:2022 lisa A kontrollimeede 6.8, infoturbesündmustest teavitamine, DORA jaoks hädavajalik. See muudab teavitamise kogu töötajaskonna vastutuseks, mitte üksnes turbeoperatsioonide ülesandeks.

Zenith Blueprint sammus 16, inimressursside kontrollimeetmed II, ütleb Clarysec:

Tõhus intsidentidele reageerimise süsteem ei alga tööriistadest, vaid inimestest.

Samm 16 soovitab selgeid teavituskanaleid, teadlikkuse koolitust, süüdistamisvaba kultuuri, triaaži, konfidentsiaalsust ja perioodilisi simulatsioone. Kõige kasulikum praktiline sõnum on lihtne:

„Kahtluse korral teavita.“

See on DORA kontrollipõhimõte. Kui töötajad ootavad täieliku kindluseni, kaotab organisatsioon aega. Kui nad teavitavad varakult, saab organisatsioon hinnata, klassifitseerida ja otsustada.

Zenith Controls käsitleb 6.8 tuvastava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust. See seostub 5.24-ga, sest teavituskanalid peavad olema intsidendiplaani osa. See toidab 5.25-d, sest sündmusi saab hinnata ainult siis, kui neist on teatatud. See käivitab 5.26, sest ametlik reageerimine algab pärast teavituste hindamist.

DORA puhul toetab see Article 17 ja Article 18 nõudeid, mille kohaselt finantsüksused peavad olulisi IKT-ga seotud intsidente ja olulisi küberohte haldama, klassifitseerima ja neist teatama. See toetab ka GDPR Article 33 ja Recital 85 nõudeid, sest sisemine teavitamine määrab, kui kiiresti isikuandmetega seotud rikkumine tuvastatakse ja eskaleeritakse.

Praktiline Clarysec rakendus on üheleheküljeline juhis „Kuidas teatada IKT-intsidendist“. See peab sisaldama järgmist:

• Millest teatada, sealhulgas katkestused, kahtlased e-kirjad, kadunud seadmed, ebatavaline süsteemikäitumine, kahtlustatav tarnija kompromiteerimine, loata juurdepääs, andmeleke ja klienti mõjutav teenuse kvaliteedi halvenemine.
• Kuidas teatada, kasutades seiratavat postkasti, piletikategooriat, infoliini, koostöökanalit või SOC-portaali.
• Mida lisada, näiteks aeg, süsteem, kasutaja, äriprotsess, täheldatud mõju, ekraanitõmmised, kui see on ohutu, ning kas mõjutatud võivad olla kliendid või isikuandmed.
• Mida mitte teha, sealhulgas mitte kustutada logisid, mitte taaskäivitada kriitilisi süsteeme ilma juhiseta, mitte võtta klientidega väliselt ühendust ilma heakskiiduta ning mitte uurida juhtumit oma rollist kaugemale.
• Mis saab edasi, sealhulgas triaaž, klassifitseerimine, eskaleerimine, reageerimine, tõendusmaterjali säilitamine ja võimalik regulatiivne hindamine.

Eesmärk ei ole muuta iga töötajat uurijaks. Eesmärk on muuta iga töötaja usaldusväärseks signaaliallikaks.

Kontrollimeede 5.25: DORA klassifitseerimise otsustuspunkt

DORA olulise IKT-ga seotud intsidendi teavitamine sõltub klassifitseerimisest. Siin muutub keskseks ISO/IEC 27001:2022 lisa A kontrollimeede 5.25, infoturbesündmuste hindamine ja otsustamine.

Zenith Blueprint samm 23 selgitab praktilist väljakutset:

Mitte iga anomaalia ei ole katastroof. Mitte iga teavitus ei viita kompromiteerimisele.

Seejärel kirjeldatakse 5.25 eesmärki järgmiselt:

eristada kahjutut kahjulikust ja teada, mis nõuab eskaleerimist.

DORA puhul on see hetk, mil turbesündmust, teenuse kvaliteedi halvenemist, tarnijakatkestust, andmete avalikustumist või tegevushäiret hinnatakse olulise intsidendi kriteeriumide alusel. Organisatsioon peab arvestama operatiivset mõju, mõjutatud teenuseid, kriitilisi või olulisi funktsioone, mõjutatud kliente ja tehinguid, kestust, geograafilist ulatust, andmemõju, mainega seotud tagajärgi ja majanduslikku mõju.

Zenith Controls seostab 5.25 otse DORA Article 18 olulise IKT-intsidendi klassifitseerimise nõuetega. See on struktureeritud hindamisprotsess, millega määratakse, kas täheldatud sündmus kvalifitseerub turbeintsidendiks. See seostub ka 8.16-ga, seiretegevustega, sest teavitused ja logiandmed tuleb triaažida, ning 5.26-ga, sest klassifitseerimine käivitab reageerimise.

Siin ebaõnnestuvad paljud organisatsioonid auditites. Neil on piletid, kuid mitte klassifitseerimiskirjed. Neil on tõsidusmärgised, kuid mitte kriteeriumid. Neil on regulatiivsed aruanded, kuid mitte otsustusjälg, mis tõendaks, miks intsidenti peeti või ei peetud oluliseks.

Clarysec lahendab selle, lõimides DORA klassifitseerimise intsidendi tõsidusmudelisse. Ettevõtte Intsidentidele reageerimise poliitika punkt 5.3.1 sisaldab selget 1. taseme näidet:

Tase 1: kriitiline (nt kinnitatud andmekaitserikkumine, lunavarapuhang, tootmiskeskkonna süsteemi kompromiteerimine)

Väiksemate organisatsioonide jaoks lisab Intsidentidele reageerimise poliitika - VKE range operatiivse ootuse:

Tegevjuht peab IT-teenusepakkuja sisendi alusel klassifitseerima kõik intsidendid tõsiduse järgi ühe tunni jooksul pärast teavitamist.

See ühe tunni klassifitseerimise eesmärk on mõjus, sest sunnib juhtimisdistsipliini. Väiksemal reguleeritud üksusel ei pruugi olla ööpäevaringset SOC-i, kuid ta saab siiski määrata, kes klassifitseerib, kes nõustab ja kui kiiresti otsus peab sündima.

DORA ja ISO vaheline intsidendi triaažikirje

Klassifitseerimise kaitstavaks muutmiseks looge DORA intsidendi triaažikirje oma piletihaldus-, GRC- või intsidendihaldussüsteemis. Kirje tuleb luua iga potentsiaalselt olulise IKT-sündmuse kohta, isegi kui see hiljem madalamale tasemele määratakse.

Lisage otsustusmärkus:

„Kriitilist äriprotsessi mõjutava makseteenuse häire, lahendamata algpõhjuse ja võimaliku kliendimõju tõttu eskaleeritakse sündmus võimaliku olulise IKT-ga seotud intsidendina. Vastavus- ja õigusüksus hindavad regulatiivse teavitamise nõudeid. Tõendusmaterjali säilitamine on algatatud.“

See üks kirje toetab DORA Article 17 jälgimist, Article 18 klassifitseerimist, Article 19 teavitamisotsuseid, ISO/IEC 27001:2022 lisa A 5.25 hindamist, 6.8 teavitamist, 5.26 reageerimist ja 5.28 tõendusmaterjali käitlemist.

Kontrollimeetmed 5.24 ja 5.26: planeerimine, rollid ja reageerimine

Kui DORA intsident toimub, peab reageerimisplaan juba vastama ebamugavatele küsimustele.

Kellel on volitus klassifitseerida? Kes võtab ühendust pädeva asutusega? Kes kinnitab esmase teavituse? Kes suhtleb klientidega? Kes võtab ühendust kolmandast isikust IKT-teenusepakkujaga? Kes otsustab, kas intsident käivitab ka GDPR teavituse? Kes säilitab tõendusmaterjali? Kes vastutab lõpparuande eest?

ISO/IEC 27001:2022 lisa A kontrollimeede 5.24, infoturbeintsidentide halduse planeerimine ja ettevalmistus, vastab neile küsimustele enne kriisi. Kontrollimeede 5.26, infoturbeintsidentidele reageerimine, tagab, et plaan muutub intsidendi ajal kontrollitud tegevuseks.

Zenith Controls seob 5.24 DORA Article 17 kuni Article 21 nõuetega, sest see viib praktikasse dokumenteeritud, testitud ja läbi vaadatud intsidentidele reageerimise, sealhulgas sisemise eskaleerimise, välise regulatiivse teavitamise, sidusrühmade kommunikatsiooni ja õppetunnid.

ISO/IEC 27035-1:2023 toetab seda, laiendades intsidendihalduse reageerimisprotseduuridest poliitika, planeerimise, võimekuste, suhete, tugimehhanismide, teadlikkuse, koolituse ja regulaarse testimiseni. ISO/IEC 27035-2:2023 kirjeldab täiendavalt intsidendihalduse protsessi ettevalmistusest õppetundideni.

Zenith Blueprint samm 23 annab otsese rakendusjuhise:

Veenduge, et teil on ajakohane intsidendile reageerimise plaan (5.24), mis hõlmab ettevalmistust, eskaleerimist, reageerimist ja kommunikatsiooni.

DORA-valmis intsidendile reageerimise plaan peab määratlema:

• IKT-intsidendile reageerimise meeskonna ja asendajad.
• Volitused tõsiduse klassifitseerimiseks ja DORA teavitamise eskaleerimiseks.
• Õigus-, vastavus-, privaatsus-, kommunikatsiooni-, IT-, turbe-, tarnija- ja äriomanike vastutused.
• Olulise IKT-ga seotud intsidendi klassifitseerimise kriteeriumid.
• Protseduurid esmaseks, vahepealseks ja lõplikuks regulatiivseks teavitamiseks.
• GDPR, NIS2, lepingulise, küberkindlustuse ja juhtkonna teavitamise hindamine.
• Ohjeldamise, kõrvaldamise, taastamise ja valideerimise sammud.
• Tõendusmaterjali säilitamise nõuded.
• Tarnija eskaleerimise ja logidele juurdepääsu protseduurid.
• Õppetundide ja parandusmeetmete jälgimine.

Intsidentidele reageerimise poliitika - VKE seob reageerimistähtajad ka õiguslike nõuetega:

Reageerimistähtajad, sealhulgas andmete taastamise ja teavitamiskohustused, tuleb dokumenteerida ja viia kooskõlla õiguslike nõuetega, näiteks GDPR 72-tunnise isikuandmetega seotud rikkumisest teavitamise nõudega.

See on oluline, sest üks IKT-intsident võib muutuda DORA oluliseks intsidendiks, GDPR isikuandmetega seotud rikkumiseks, NIS2 oluliseks intsidendiks, lepinguliseks klienditeavituse sündmuseks ja tarnijahaldusprobleemiks. Plaan peab need kihid koordineerima, mitte käsitlema neid eraldi maailmadena.

Kontrollimeetmed 8.15 ja 8.16: logid muudavad aruande kaitstavaks

DORA intsidentidest teavitamine sõltub faktidest. Faktid sõltuvad logimisest ja seirest.

Maksete arveldusstsenaariumis peab Sarah teadma, millal teenuse halvenemine algas, milliseid süsteeme see mõjutas, kas kasutati privilegeeritud kontosid, kas andmed lahkusid keskkonnast, kas pilveteenuse pakkuja katkestus kattub sisemise telemeetriaga ja millal taastamine lõppes.

ISO/IEC 27001:2022 lisa A kontrollimeede 8.15, logimine, ja 8.16, seiretegevused, toetavad seda tõendusbaasi. Zenith Controls seob mõlemad 5.24-ga, sest intsidentidele reageerimise planeerimine peab hõlmama kasutatavaid logiandmeid ja seirevõimekust. Kontrollimeede 8.16 seostub ka 5.25-ga, sest teavitused tuleb triaažida otsusteks.

Clarysec Logimis- ja seirepoliitika - VKE [LMP-SME] sisaldab praktilist eskaleerimisnõuet:

Kõrge prioriteediga teavitused tuleb 24 tunni jooksul eskaleerida tegevjuhile ja andmekaitsekoordinaatorile

DORA-reguleeritud üksuste puhul nõuavad potentsiaalselt olulised IKT-intsidendid tavaliselt kiiremat operatiivset eskaleerimismudelit, eriti kui mõjutatud on kriitilised või olulised funktsioonid. Siiski on juhtimismuster õige: kõrge prioriteediga teavitused ei tohi jääda üksnes IT sisse. Need peavad jõudma äri-, privaatsus- ja juhtimisrollideni.

DORA-valmis logimismudel peab hõlmama:

• Keskset logimist kriitiliste süsteemide, identiteediplatvormide, lõppseadmete, pilveteenuste, võrguturbe tööriistade ja ärirakenduste jaoks.
• Aja sünkroniseerimist süsteemide vahel, et intsidendi ajajooned oleksid usaldusväärsed.
• Teavituste kategoriseerimist kooskõlas intsidendi tõsiduse ja DORA klassifitseerimisega.
• Logide säilitamist kooskõlas regulatiivsete, lepinguliste ja kohtuekspertiisi vajadustega.
• Juurdepääsukontrolle, mis kaitsevad logide terviklust.
• Protseduure logiväljavõtete kogumiseks oluliste intsidentide ajal.
• Tarnija logidele juurdepääsu nõudeid kriitiliste IKT-teenuste jaoks.

Audiitorid ei aktsepteeri piisava tõendusmaterjalina väidet „SIEM-is on see olemas“. Nad küsivad, kas õiged logid olid olemas, kas teavitused vaadati läbi, kas eskaleerimine toimus õigeaegselt ja kas logid säilitati pärast seda, kui intsident muutus potentsiaalselt teavitamiskohustuslikuks.

Kontrollimeede 5.28: tõendite kogumine ja tõendite valduse ahel

Olulise IKT-ga seotud intsidendi korral täidab tõendusmaterjal kolme eesmärki: tehniline uurimine, regulatiivne vastutus ja õiguslik kaitstavus.

Kui tõendusmaterjal on puudulik, üle kirjutatud, muudetud või dokumenteerimata, võib organisatsioonil olla keeruline tõendada, mis juhtus. Samuti võib olla keeruline põhjendada klassifitseerimisotsust.

Clarysec Tõendite kogumise ja kohtuekspertiisi poliitika [ECF] sätestab:

Tõendite valduse ahela logi peab saatma kõiki füüsilisi või digitaalseid tõendeid alates kogumise hetkest kuni arhiveerimise või üleandmiseni ning peab dokumenteerima:

VKE-versioon Tõendite kogumise ja kohtuekspertiisi poliitika - VKE [ECF-SME] hoiab nõude lihtsana:

Iga digitaalse tõendi ese tuleb logida koos järgmiste andmetega:

Operatiivne õppetund on otsene. Tõendusmaterjali käitlemine ei saa alata pärast seda, kui õigusüksus seda küsib. See peab olema lõimitud intsidendile reageerimisse.

ISO/IEC 27006-1:2024 tugevdab seda auditiootust, rõhutades protseduure infoturbeintsidentide tõendite tuvastamiseks, kogumiseks ja säilitamiseks. DORA puhul võib sama tõendusmaterjali kogum toetada esmast teavitust, vaheuuendusi, lõpparuannet, intsidendijärgset ülevaatust ja järelevalveasutuse küsimusi.

Praktiline tõendusmaterjali kontrollnimekiri DORA-ga seotud intsidentide jaoks peab hõlmama:

• Intsidendipiletit ja triaažimärkmeid.
• Tuvastamise, eskaleerimise, klassifitseerimise, teavitamise, ohjeldamise, taastamise ja sulgemise ajajoont.
• SIEM-i teavitusi ja korreleeritud logisid.
• Lõppseadmete ja serverite artefakte.
• Identiteedi ja privilegeeritud juurdepääsu logisid.
• Võrguliikluse kokkuvõtteid.
• Pilveteenuse pakkuja staatust ja auditilogisid.
• Tarnijatega peetud suhtlust ja intsidendiavaldusi.
• Ärimõju kirjeid, sealhulgas kliendid, teenused, tehingud ja seisakuaeg.
• Regulatiivsete teavituste mustandeid ja esitatud teavitusi.
• Juhtkonna otsuseid ja kinnitusi.
• Algpõhjuse analüüsi.
• Õppetunde ja parandusmeetmeid.

Tõendusmaterjal peab näitama nii tehnilisi fakte kui ka juhtimisotsuseid. DORA teavitamine ei puuduta ainult seda, mis süsteemidega juhtus. See puudutab ka seda, kuidas juhtkond intsidendi ära tundis, hindas, eskaleeris, kontrolli alla võttis ja sellest õppis.

Kontrollimeede 5.27: õppetunnid ja pidev täiustamine

DORA intsident ei ole suletud siis, kui lõpparuanne on esitatud. See on suletud siis, kui organisatsioon on sellest õppinud, määranud parandusmeetmed, uuendanud kontrollimeetmeid ja kontrollinud täiustamist.

ISO/IEC 27001:2022 lisa A kontrollimeede 5.27, infoturbeintsidentidest õppimine, seob DORA teavitamise ISO/IEC 27001:2022 pideva täiustamise tsükliga. Zenith Controls seob 5.24 5.27-ga, sest intsidendihaldus on puudulik ilma algpõhjuse analüüsi, õppetundide ja kontrollimeetmete täiustamiseta.

Zenith Blueprint samm 23 juhendab organisatsioone uuendama plaani õppetundide alusel ning pakkuma sihipärast koolitust intsidentidele reageerimise ja tõendusmaterjali käitlemise kohta. See on DORA puhul eriti oluline, sest korduvad klassifitseerimisviivitused, puuduv tarnija tõendusmaterjal, nõrgad logid või ebaselge kommunikatsioon võivad muutuda järelevalveasutuse murekohaks.

Õppetundide mall peab koguma:

• Mis juhtus ja millal.
• Millised kriitilised või olulised funktsioonid olid mõjutatud.
• Kas klassifitseerimine oli õigeaegne ja täpne.
• Kas DORA teavitamisotsused tehti piisava tõendusmaterjali alusel.
• Kas GDPR, NIS2, lepingulised või klienditeavituse käivitajad hinnati.
• Kas tarnijad reageerisid kokkulepitud tähtaegadel.
• Kas logid ja kohtuekspertiisi tõendusmaterjal säilitati.
• Millised kontrollimeetmed ebaõnnestusid või puudusid.
• Milliseid poliitikaid, tööjuhiseid, koolitusi või tehnilisi kontrollimeetmeid tuleb täiustada.
• Kes vastutab iga parandusmeetme eest ja mis tähtajaks.

See toidab ka ISO/IEC 27001:2022 juhtkonna läbivaatust. Intsidentide suundumusi peab läbi vaatama juhtkond, mitte peitma neid tehnilistesse intsidendijärgsetesse analüüsidesse.

Ristvastavus: DORA, GDPR, NIS2, NIST ja COBIT 2019

DORA on finantsüksuste jaoks keskne raamistik, kuid intsidentidest teavitamine kuulub harva ainult ühte raamistikku.

Üks IKT-intsident võib hõlmata DORA olulise IKT-ga seotud intsidendi teavitamist, GDPR isikuandmetega seotud rikkumisest teavitamist, NIS2 olulise intsidendi teavitamist, kliendilepingutest tulenevaid kohustusi, küberkindlustuse teavitamist ja juhtkonna aruandlust.

Zenith Controls aitab seda keerukust vähendada, seostades ISO/IEC 27002:2022 kontrollimeetmed eri raamistikega. Näiteks:

NIST vaates toetab sama mudel tuvastamise, reageerimise ja taastamise tulemusi. COBIT 2019 ja ISACA auditi vaates on keskne küsimus valitsemine: kas intsidendihaldus, talitluspidevus, risk, vastavus, tarnijate vastutused ja toimivuse seire on kontrolli all.

Kõige küpsemad organisatsioonid ei loo iga raamistiku jaoks eraldi töövooge. Nad loovad ühe intsidendihalduse protsessi koos regulatiivsete kihtidega. Pilet kogub samad põhifaktid ühe korra ja hargneb seejärel vajaduse korral DORA, GDPR, NIS2, lepingulise, kindlustuse või sektoripõhise teavitamise suunas.

Kuidas audiitorid teie DORA intsidendiprotsessi testivad

DORA-valmis intsidentidest teavitamise protsess peab vastu pidama erinevatele auditivaadetele.

ISO/IEC 27001:2022 audiitor kontrollib, kas ISMS on valinud ja rakendanud asjakohased lisa A kontrollimeetmed, kas kohaldatavusdeklaratsioon toetab neid kontrollimeetmeid, kas intsidendikirjed on olemas ning kas siseaudit ja juhtkonna läbivaatus hõlmavad intsidendihalduse toimivust.

Zenith Controls viitab ISO/IEC 19011:2018 auditimetoodikale 5.24, 5.25 ja 6.8 puhul. 5.24 puhul uurivad audiitorid intsidendile reageerimise plaani intsidenditüüpide, tõsiduse klassifikatsioonide, määratud rollide, kontaktloendite, eskaleerimisteede, regulatiivse teavitamise juhiste ja kommunikatsioonivastutuste osas. 5.25 puhul kontrollivad nad, kas dokumenteeritud klassifitseerimiskriteeriumid on olemas, näiteks tõsidusmaatriksid või otsustuspuud, mis põhinevad süsteemimõjul, andmete tundlikkusel ja kestusel. 6.8 puhul hindavad nad teavitusmehhanisme, teavitamisaja mõõdikuid ja tõendusmaterjali selle kohta, et teatatud sündmused logitakse, triaažitakse ja lahendatakse.

DORA järelevalveline läbivaatus keskendub sellele, kas olulised IKT-ga seotud intsidendid tuvastatakse, klassifitseeritakse, neist teatatakse, neid ajakohastatakse ja need suletakse regulatiivsete ootuste kohaselt. Läbivaataja võib küsida näidisintsidenti ja jälgida seda esimesest teavitusest lõpparuandeni.

Privaatsusaudiitor keskendub sellele, kas hinnati isikuandmetega seotud rikkumise riski ja kas GDPR Article 33 ja Article 34 kohustused käivitusid. BS EN 17926:2023 on siin asjakohane, sest see lisab privaatsusintsidentide vastutused, teavitamiskriteeriumid, ajastuse ja kooskõla järelevalvelise avalikustamise ootustega.

Sama tõendusmaterjal võib vastata mitmele auditiküsimusele, kui see on algusest peale õigesti struktureeritud.

DORA intsidentidest teavitamise valmisoleku kontrollnimekiri 2026. aastaks

Enne järgmist lauaõppust, siseauditit või järelevalvelist läbivaatust testige oma organisatsiooni selle kontrollnimekirja alusel:

• Kas töötajad teavad, kuidas teatada kahtlustatavatest IKT-intsidentidest?
• Kas olemas on eraldi intsidendite teavituskanal?
• Kas turbesündmusi logitakse ja triaažitakse järjepidevalt?
• Kas dokumenteeritud on tõsiduse ja DORA olulise intsidendi klassifitseerimise maatriks?
• Kas klassifitseerimine on nõutud määratud aja jooksul pärast teavitamist?
• Kas kriitilised või olulised funktsioonid on seostatud süsteemide ja tarnijatega?
• Kas DORA, GDPR, NIS2, lepingulise, kindlustuse ja klienditeavituse käivitajaid hinnatakse ühes töövoos?
• Kas intsidendirollid on määratletud IT, turbe, õigus-, vastavus-, privaatsus-, kommunikatsiooni- ja äriomanike lõikes?
• Kas logid on piisavad intsidendi ajajoone rekonstrueerimiseks?
• Kas tõendusmaterjali säilitatakse koos tõendite valduse ahelaga?
• Kas tarnijate intsidendikohustusi ja logidele juurdepääsu õigusi testitakse?
• Kas lauaõppusi tehakse realistlike DORA stsenaariumidega?
• Kas õppetunnid seotakse parandusmeetmetega?
• Kas intsidendimõõdikuid vaadatakse läbi juhtkonna läbivaatusel?
• Kas kohaldatavusdeklaratsioon on seostatud DORA jaoks asjakohaste ISO/IEC 27001:2022 kontrollimeetmetega?

Kui vastus mõnele neist on „osaliselt“, ei ole probleem üksnes vastavuses. See on talitluspidevuse probleem.

Loo auditivalmis DORA intsidentidest teavitamise mudel

DORA intsidentidest teavitamine 2026. aastal on juhtimise test surve all. Hästi toimivad organisatsioonid ei ole need, kellel on kõige pikemad intsidendile reageerimise dokumendid. Need on organisatsioonid, kellel on selged teavituskanalid, kiire klassifitseerimine, usaldusväärsed logid, säilitatud tõendusmaterjal, koolitatud inimesed, testitud tarnija eskaleerimine ja raamistikülese vastavuse jälgitavus.

Clarysec saab aidata selle tegevusmudeli üles ehitada.

Alustage intsidendiriskide ja kohaldatavusdeklaratsiooni kaardistamisest, kasutades Zenith Blueprint: audiitori 30-sammuline teekaart. Seejärel viige intsidendi kontrollimeetmed kooskõlla juhendiga Zenith Controls: ristvastavuse juhend. Rakendage protsess Clarysec Intsidentidele reageerimise poliitika, Intsidentidele reageerimise poliitika - VKE, Logimis- ja seirepoliitika - VKE, Tõendite kogumise ja kohtuekspertiisi poliitika ning Tõendite kogumise ja kohtuekspertiisi poliitika - VKE abil.

Kui teie juhtkond soovib kindlust enne järgmist tegelikku intsidenti, viige Clarysec tööriistakomplekti abil läbi DORA olulise IKT-ga seotud intsidendi lauaõppus ja koostage tõenduspakett, mida audiitor või järelevalveasutus eeldaks näha.