DORA testēšanas programma: testu sasaiste ar ISO 27001

Ir 2026. gada februāris. Vidēja izmēra maksājumu iestādes informācijas drošības vadītājam (CISO) pēc divām dienām paredzēta valdes sēde, pēc sešām nedēļām — ISO/IEC 27001:2022 uzraudzības audits, un atbilstības iesūtnē jau gaida DORA uzraudzības pieprasījums.

Regulators neprasa iespaidīgu kiberdrošības stratēģiju. Pieprasījums ir praktisks:

• Iesniedziet savu 2026. gada digitālās darbības noturības testēšanas programmu.
• Parādiet, kuri testi aptver kritiskās vai svarīgās funkcijas.
• Pierādiet, kā konstatējumi tiek novērsti un atkārtoti testēti.
• Iesniedziet pierādījumus par vadības struktūras pārraudzību.
• Izskaidrojiet, kā programmā tiek iekļauti trešo personu IKT pakalpojumu sniedzēji.
• Iesniedziet ierakstus par ievainojamību novērtēšanu, scenārijos balstītiem testiem, veiktspējas un kapacitātes testēšanu un ielaušanās testēšanu.

CISO atver četras mapes. Ievainojamību skenēšanas rezultāti atrodas SOC pieteikumu sistēmā. Galda vingrinājumu piezīmes ir koplietojamā diskā. Slodzes testu rezultāti ir inženierijas komandas pārziņā. Ielaušanās testu pārskati glabājas Juridiskā dienesta ierobežotas piekļuves repozitorijā. Konstatējumu novēršanas izsekošana ir sadalīta starp Jira, e-pastu un izklājlapu, kas izveidota pagājušā gada ISO auditam.

Nekas nav izdomāts. Liela daļa ir kvalitatīvs darbs. Taču tā vēl nav pārvaldīta DORA digitālās darbības noturības testēšanas programma. Tā ir testu kopa.

2026. gadā šai atšķirībai ir nozīme. DORA ir piemērojama no 2025. gada 17. janvāra un izveido vienotu ES ietvaru digitālajai darbības noturībai IKT risku pārvaldības, incidentu ziņošanas, noturības testēšanas, kiberapdraudējumu un ievainojamību informācijas apmaiņas, trešo personu IKT riska pārvaldības, līgumisko prasību un kritisko trešo personu IKT pakalpojumu sniedzēju pārraudzības jomā. Tā aptver plašu finanšu vienību loku, tostarp kredītiestādes, maksājumu iestādes, ieguldījumu brokeru sabiedrības, kriptoaktīvu pakalpojumu sniedzējus, apdrošināšanas sabiedrības un citas regulētas vienības. DORA darbojas arī kā nozares specifiskais Savienības tiesību akts finanšu vienībām, uz kurām citādi attiektos līdzvērtīgi NIS2 kiberdrošības pienākumi.

Praktiskais jautājums valdēm, CISO, atbilstības vadītājiem un IKT pakalpojumu sniedzējiem vairs nav, vai testēšana notiek. Jautājums ir, vai testēšana ir plānota, uz risku balstīta, pamatota ar pierādījumiem, ar izsekotu konstatējumu novēršanu, pārskatīta un atkārtoti izmantojama DORA un ISO/IEC 27001:2022 vajadzībām.

Clarysec darbības modelis ir izveidots tieši šai problēmai. Izmantojot Zenith Blueprint: auditora 30 soļu ceļvedi, Clarysec ISO saskaņoto politiku kopu un Zenith Controls: savstarpējās atbilstības ceļvedi, organizācijas var pārvērst izkliedētas noturības aktivitātes kontrolētā ikgadējā testu katalogā, kas atbilst uzraugu, auditoru, klientu un valdes vajadzībām.

Kāpēc DORA padara testēšanu par pārvaldības jautājumu

DORA skaidri nosaka izpildvadības pārskatatbildību. Article 5 nosaka vadības struktūras atbildību par IKT risku pārvaldību. Article 6 prasa stabilu, visaptverošu un labi dokumentētu IKT risku pārvaldības ietvaru, kas integrēts organizācijas kopējā risku pārvaldības sistēmā. Article 4 pievieno proporcionalitātes principu, proti, prasības jāpiemēro, ņemot vērā lielumu, kopējo riska profilu un pakalpojumu, darbību un operāciju būtību, mērogu un sarežģītību.

Tas padara digitālās darbības noturības testēšanu par vairāk nekā tehnisku uzdevumu. Tā kļūst par pierādījumu tam, ka vadības struktūra izprot risku, ir apstiprinājusi stratēģiju, saņem jēgpilnu ziņošanu un virza konstatējumu novēršanu.

ISO/IEC 27001:2022 izmanto līdzīgu pārvaldības sistēmas loģiku. Clauses 4.1 līdz 4.4 prasa organizācijai izprast kontekstu, ieinteresētās puses, juridiskos un līgumiskos pienākumus, darbības jomu, saskarnes un atkarības. Clauses 5.1 līdz 5.3 prasa vadību, politiku saskaņošanu, resursus, komunikāciju, piešķirtas atbildības un ziņošanu augstākajai vadībai. Clause 6.1 prasa informācijas drošības risku novērtēšanu un risku apstrādi.

Tādēļ DORA testēšanas programmai jāsasaista:

• Biznesa pakalpojumi un kritiskās vai svarīgās funkcijas
• IKT aktīvi, dati un trešo personu atkarības
• Risku novērtēšana, riska īpašnieki un risku apstrādes plāni
• Testu veidi, biežums un aktivizējošie notikumi
• Autorizācija, neatkarība un iesaistes noteikumi
• Konstatējumi, novēršanas termiņi un atkārtota testēšana
• Pierādījumu glabāšana un piekļuves kontrole
• Vadības ziņošana un nepārtraukta pilnveide

Mazākām vai zemāka riska finanšu vienībām Article 16 paredz vienkāršotu IKT risku pārvaldības ietvaru, taču vienkāršots nenozīmē neformāls. Arī mērogotām programmām joprojām nepieciešama dokumentēta IKT risku pārvaldība, uzraudzība, noturīgas sistēmas, IKT riska avotu un anomāliju identificēšana, būtiskās trešo personu IKT atkarības, nepārtrauktības un atjaunošanas pasākumi, regulāra testēšana un gūtās mācības.

Citiem vārdiem sakot, DORA neatalgo testu apjomu. Tā novērtē pārvaldītu, uz risku balstītu testēšanu, kas pierāda noturību pakalpojumiem ar vislielāko nozīmi.

Kas jāiekļauj 2026. gada DORA testēšanas programmā?

Nobriedušai DORA testēšanas programmai jādarbojas kā ikgadējam testu katalogam. Tai nevajadzētu aprobežoties ar vienu ikgadēju ielaušanās testu vai ievainojamību skenēšanas eksportu kopumu. Tajā jāiekļauj pamata un paplašinātie testi, kas plānoti atbilstoši riskam, pakalpojuma kritiskumam, regulatīvajiem pienākumiem, piegādātāju atkarībām, būtiskām izmaiņām un iepriekšējiem konstatējumiem.

DORA Article 24 nosaka digitālās darbības noturības testēšanas programmu. Article 25 apraksta testu klāstu, tostarp ievainojamību novērtēšanu un skenēšanu, atklāto avotu analīzi, tīkla drošības novērtēšanu, nepilnību analīzi, fiziskās drošības pārskatīšanu, aptaujas anketas, skenēšanas programmatūras risinājumus, pirmkoda pārskatīšanu, ja iespējams, scenārijos balstītus testus, saderības testēšanu, veiktspējas testēšanu, no gala līdz galam testēšanu un ielaušanās testēšanu. Article 26 pievieno uz apdraudējumiem balstītu ielaušanās testēšanu finanšu vienībām, kuras identificējušas kompetentās iestādes.

Lielākajai daļai organizāciju praktiskais katalogs tiek veidots ap četrām testēšanas grupām.

Clarysec Drošības testēšanas un red teaming politika nodrošina stingru politikas pamatu šim katalogam:

“Testu veidi: drošības testēšanas programmā jāiekļauj vismaz: (a) ievainojamību skenēšana, kas sastāv no automatizētas iknedēļas vai ikmēneša tīklu un lietojumprogrammu skenēšanas zināmu ievainojamību identificēšanai; (b) ielaušanās testēšana, kas sastāv no konkrētu sistēmu vai lietojumprogrammu manuālas padziļinātas testēšanas, ko veic kvalificēti testētāji, lai identificētu sarežģītas vājās vietas; un (c) red teaming vingrinājumi, kas sastāv no scenārijos balstītām reālu uzbrukumu simulācijām, tostarp sociālās inženierijas un citām taktikām, lai pārbaudītu organizācijas atklāšanas un reaģēšanas spējas kopumā.”

Tā pati politika prasa regulāru plānošanu:

“Testēšanas grafiks: organizācijai jāveic drošības testēšana pēc regulāra grafika. Būtiskām internetam pieejamām sistēmām un kritiskām iekšējām lietojumprogrammām ielaušanās testēšana jāveic vismaz reizi gadā. Augsta riska izmaiņām, piemēram, jaunas kritiskas sistēmas ieviešanai vai būtiskiem jauninājumiem, nepieciešama ad hoc testēšana pirms nodošanas ražošanas vidē un/vai neilgi pēc tās.”

Tas ir kritiski DORA vajadzībām. Statisks ikgadējais plāns nav pietiekams, ja vienība ievieš jaunu maksājumu vārteju, migrē pamatsistēmu uz mākoņvidi, maina pārvaldīto pakalpojumu sniedzēju vai izlaiž jaunu klientu autentifikācijas plūsmu. Augsta riska izmaiņām jāaktivizē papildu testēšana.

Izveidojiet ikgadējo testu katalogu kā vienoto patiesības avotu

Efektīvākais veids, kā nodrošināt DORA un ISO/IEC 27001:2022 prasību izpildi, ir izveidot vienu kontrolētu ikgadējo testu katalogu. Tas var atrasties GRC platformā, pieteikumu darbplūsmā vai kontrolētā izklājlapā. Formāts ir mazāk svarīgs nekā izsekojamība.

Katram testam jāatbild uz pieciem audita jautājumiem:

1. Kurš pakalpojums, aktīvs, piegādātājs, lietojumprogramma vai process tika testēts?
2. Kurš risks, pienākums vai kontroles prasība aktivizēja testu?
3. Kas autorizēja un veica testu?
4. Kādi konstatējumi tika identificēti, pieņemti, novērsti vai atlikti?
5. Kādi pierādījumi apliecina, ka tests notika un rezultāts tika pārskatīts?

Praktisks Clarysec stila katalogs ietver šādus laukus.

Clarysec Audita un atbilstības uzraudzības politika MVU sniedz kodolīgu pārvaldības noteikumu, kas atbilst šai struktūrai:

“Katram auditam jāietver noteikta darbības joma, mērķi, atbildīgais personāls un nepieciešamie pierādījumi.”

Lai gan noteikums rakstīts auditiem, tam pašam principam jāattiecas uz noturības testiem. Ja ievainojamību skenēšanai, galda vingrinājumam, pārslēgšanās simulācijai vai ielaušanās testam nav noteiktas darbības jomas, mērķa, īpašnieka un nepieciešamo pierādījumu, tas būs vājš gan DORA, gan ISO audita pārbaudē.

Tajā pašā politikā noteikts:

“Pierādījumi jāglabā vismaz divus gadus vai ilgāk, ja to prasa sertifikācija vai klientu vienošanās.”

DORA regulētām finanšu vienībām un IKT pakalpojumu sniedzējiem divi gadi jāuzskata par minimumu. Līgumiskie pienākumi, uzraudzības gaidas, sertifikācijas cikli un incidentu izmeklēšana var prasīt ilgāku glabāšanu.

Sasaistiet DORA testu veidus ar ISO 27001 pierādījumiem

Integrētas programmas spēks ir tajā, ka viens tests var izpildīt vairākus pienākumus. Galvenais ir pareizi marķēt pierādījumus un sasaistīt tos ar ISMS.

Zenith Blueprint to skaidro audita, pārskatīšanas un pilnveides posmā, 24. solī:

“Jūsu SoA jābūt saskaņotai ar Risku reģistru un Risku apstrādes plānu. Vēlreiz pārbaudiet, vai katrs kontroles pasākums, ko izvēlējāties kā riska apstrādi, SoA ir atzīmēts kā “piemērojams”.”

DORA testēšanas programmā testu katalogs kļūst par tiltu starp risku apstrādi un operacionālajiem pierādījumiem. Piemērojamības deklarācijā nevajadzētu norādīt, ka kontroles pasākums ir piemērojams, ja testēšanas pierādījumi atrodas citur, nav sasaistīti un netiek pārvaldīti.

Šī tabula palīdz CISO atbildēt uz izpilddirektora bieži uzdoto jautājumu: “Vai mūsu ISO ielaušanās testi un ievainojamību skenēšana ir pietiekami DORA vajadzībām?”

Atbilde ir: tie var būt daļa no DORA atbilstības, bet tikai tad, ja tie ir uz risku balstīti, sasaistīti ar kritiskām vai svarīgām funkcijām, pārvaldīti ar politiku, izsekoti līdz konstatējumu novēršanai un ziņoti vadībai.

Ievainojamību novērtēšana: nepārtraukti pierādījumi, nevis tikai skenēšanas izvade

Ievainojamību novērtēšana bieži ir visvieglāk īstenojamā un visvieglāk nepareizi pārvaldāmā testēšanas aktivitāte. Daudzas organizācijas var sagatavot skenēšanas pārskatus. Mazāk organizāciju spēj pierādīt, ka skenēšana aptver pareizos aktīvus, prioritizē kritiskos pakalpojumus, rada savlaicīgu novēršanu un tiek izmantota risku apstrādes lēmumos.

Clarysec Ievainojamību un ielāpu pārvaldības politika MVU sākas ar pareizo mērķi:

“Savlaicīgi un konsekventi identificēt un izvērtēt zināmas ievainojamības visos IT aktīvos”

DORA kontekstā tas atbalsta IKT riska avotu identificēšanu, noturīgas un atjauninātas sistēmas, uzraudzību, anomāliju noteikšanu un nepārtrauktu pilnveidi. ISO/IEC 27001:2022 kontekstā tas tieši kartējas uz 8.8 Tehnisko ievainojamību pārvaldību, kā arī balstās uz 5.9 Informācijas un citu saistīto aktīvu uzskaite, 8.16 Uzraudzības darbības un 8.32 Izmaiņu pārvaldība.

Spēcīgam ievainojamību novērtēšanas ierakstam jāietver:

• Aktīvu uzskaites momentuzņēmums, kas izmantots darbības jomas noteikšanai
• Skenēšanas datums, rīks un autentificēta vai neautentificēta metode
• Izņēmumi un biznesa pamatojums
• Konstatējumi pēc smaguma pakāpes, izmantojamības un biznesa pakalpojuma
• Kartējums uz kritiskām vai svarīgām funkcijām un datu tipiem
• Pieteikumu atsauces un riska īpašnieks
• Novēršanas SLA un noteiktais termiņš
• Atkārtotā testa rezultāts
• Izņēmumi ar atlikušā riska apstiprinājumu

Zenith Controls pozicionē 8.8 Tehnisko ievainojamību pārvaldību kā pamatpierādījumu jomu identificēšanai, novērtēšanai, prioritizācijai un novēršanas izsekošanai. Tas arī parāda, kāpēc auditori pārbaudīs saistītos procesus. Ja aktīvu uzskaite ir nepilnīga, ievainojamību pārklājums ir nepilnīgs. Ja izmaiņu pārvaldība tiek apieta, ielāpu ieviešana var radīt jaunu operacionālo risku. Ja uzraudzība ir vāja, izmantošanas mēģinājumi var netikt atklāti.

Scenāriju testi: pierādiet lēmumu pieņemšanu pirms īsta incidenta

Scenāriju testi ir vieta, kur darbības noturība kļūst redzama vadībai. Izspiedējprogrammatūras galda vingrinājums, mākoņreģiona atteices simulācija, priviliģētās piekļuves kompromitēšanas vingrinājums vai kritiska IKT pakalpojumu sniedzēja atteices scenārijs atklās vājās vietas, ko skenēšana nevar parādīt.

DORA Articles 17 līdz 20 prasa formālu ar IKT saistīta incidenta dzīves ciklu: atklāt, pārvaldīt, paziņot, reģistrēt, uzraudzīt, apstrādāt, sekot līdzi, dokumentēt pamatcēloni, novērst, klasificēt smaguma pakāpi, piešķirt lomas, eskalēt būtiskus incidentus un ziņot noteiktajos posmos. Ja tiek skartas klientu finansiālās intereses, klienti jāinformē bez nepamatotas kavēšanās.

NIS2 paredz līdzīgu steidzamību tās darbības jomā esošām vienībām, tostarp agrīno brīdinājumu, paziņošanu, starpziņošanu un galīgo ziņošanu. Darbības jomā esošām finanšu vienībām DORA ir nozares specifiskais tiesību akts līdzvērtīgiem kiberdrošības risku pārvaldības un ziņošanas pienākumiem. IKT pakalpojumu sniedzējiem, SaaS platformām, MSP un MSSP joprojām jāpārbauda, vai tie tieši ietilpst NIS2 darbības jomā vai arī regulētie klienti tos līgumiski iekļauj DORA apliecinājuma prasībās.

Zenith Blueprint kontroles pasākumu praktiskās ieviešanas posma 23. solī sniedz praktisku pierādījumu modeli:

“Izvēlieties nesenu notikumu vai veiciet galda vingrinājumu, lai validētu savu plānu. Fiksējiet un reģistrējiet žurnālā visus lēmumus, lomas un komunikāciju (5.26), un atjauniniet plānu ar gūtajām mācībām (5.27).”

DORA scenārija testam jāveido auditējami ieraksti, nevis tikai sanāksmes piezīmes:

• Scenārija apraksts un mērķi
• Dalībnieki un lomas, tostarp Juridiskais dienests, komunikācijas, IT, SOC, biznesa īpašnieks un piegādātāju kontaktpersonas
• Ievadnotikumu un lēmumu laika skala
• Klasifikācijas lēmums un ziņošanas sliekšņu analīze
• Iekšējās un ārējās komunikācijas melnraksti
• Pierādījumu saglabāšanas darbības
• Gūtās mācības
• Darbību īpašnieki un noteiktie termiņi
• Atjauninātas incidentu, nepārtrauktības vai komunikācijas procedūras

Clarysec Darbības nepārtrauktības un avārijas atjaunošanas politika MVU nostiprina ikgadējās testēšanas prasību:

“Organizācijai vismaz reizi gadā jātestē gan savas BCP, gan DR spējas. Testos jāiekļauj:”

Testēšanas katalogam šis pienākums jāpārvērš konkrētos vingrinājumos, piemēram, krīzes pārvaldības galda vingrinājumā, rezerves kopijas atjaunošanas testā, mākoņvides pārslēgšanās testā, kontaktu koka testā un piegādātāja darbības traucējumu simulācijā.

Veiktspējas, kapacitātes un atjaunošanas testi: nepietiekami izmantoti noturības pierādījumi

Veiktspējas testēšana bieži tiek uztverta kā inženierijas jautājums. DORA ietvarā tā kļūst par noturības pierādījumu.

Tirdzniecības platformai, maksājumu pakalpojumam, atlīdzību sistēmai, identitātes platformai vai klientu portālam nav nepieciešams kiberuzbrukums, lai radītu klientiem pakalpojuma atteici. Kapacitātes izsīkums, rindu piesātinājums, datubāzes sašaurinājumi, nepareizi konfigurēta automātiskā mērogošana vai bojāta pārslēgšanās uz rezerves vidi var radīt tādus pašus darbības traucējumus kā drošības incidents.

ISO/IEC 27001:2022 Annex A 8.6 Kapacitātes pārvaldība ir galvenais pamats. Pierādījumi var ietvert slodzes testēšanu, stresa testēšanu, pakalpojuma degradācijas testēšanu, infrastruktūras sliekšņu validāciju, rezerves kopiju atjaunošanas testus un pārslēgšanās simulācijas.

Labam veiktspējas un kapacitātes testa ierakstam jāfiksē:

• Normālās slodzes un maksimālās slodzes pieņēmumu bāzlīnija
• Testētie kritiskie darījumu ceļi
• Testētie infrastruktūras un mākoņvides ierobežojumi
• Uzraudzības paneļi un brīdinājumu sliekšņi
• Atteices režīmi, piemēram, rindu piesātinājums vai datubāzes sašaurinājumi
• RTO un RPO atbilstība, ja tiek testēta pārslēgšanās uz rezerves vidi vai atjaunošana
• Biznesa ietekme, ja sliekšņi tiek pārsniegti
• Novēršanas pasākumi, mērogošanas lēmumi vai arhitektūras izmaiņas
• Vadības piekrišana atlikušajam kapacitātes riskam

Zenith Blueprint 23. solis sasaista atjaunošanas gaidas ar pierādījumiem:

“Pārbaudiet, vai kritisko sistēmu atjaunošanas laika mērķi (RTO) un atjaunošanas punkta mērķi (RPO) ir saskaņoti ar darbības nepārtrauktības gaidām (5.30). Veiciet vismaz vienu tehnisku atjaunošanas testu vai pārslēgšanās simulāciju un dokumentējiet rezultātus.”

Tā ir atšķirība starp apgalvojumu “mums ir rezerves kopijas” un pierādījumu, ka kritisks pakalpojums tika atjaunots saskaņotajā tolerances robežā, ar dokumentētiem rezultātiem un vadības redzamību.

Ielaušanās testēšana un red teaming: spēcīgiem pierādījumiem vajadzīga stingra kontrole

Ielaušanās testēšana ir ļoti vērtīgs pierādījums, taču tā rada arī operacionālo risku. Nepietiekami pārvaldīta testēšana var ietekmēt ražošanas sistēmas, atklāt sensitīvus datus, izraisīt nekontrolētus brīdinājumus, radīt juridiskas problēmas vai traucēt klientiem.

Lietojumprogrammu drošības prasību politika MVU nosaka skaidru laidiena kontroles punktu:

“Pirms ieviešanas visām lietojumprogrammām jāveic drošības testēšana, lai pārbaudītu iepriekš uzskaitītās pamatprasību funkcijas.”

Kritiskām lietojumprogrammām tam jānonāk DORA katalogā kā pirmsprodukcijas drošības testēšanai, validācijai pēc nodošanas ražošanas vidē augsta riska izmaiņām un periodiskai ielaušanās testēšanai atbilstoši ekspozīcijai un kritiskumam.

Drošības testēšanas un red teaming politika nostiprina konstatējumu novēršanas ķēdi:

“Konstatējumu novēršana: visas identificētās ievainojamības vai vājās vietas jādokumentē konstatējumu pārskatā ar smaguma pakāpes vērtējumiem. Pēc pārskata saņemšanas sistēmu īpašnieki ir atbildīgi par novēršanas plāna izveidi ar noteiktiem termiņiem; piemēram, kritiskie konstatējumi jānovērš 30 dienu laikā un augstas smaguma pakāpes konstatējumi — 60 dienu laikā saskaņā ar organizācijas Ievainojamību un ielāpu pārvaldības politiku. STC jāizseko novēršanas progress. Jāveic atkārtota testēšana, lai apstiprinātu, ka kritiskās problēmas ir atrisinātas vai pienācīgi mazinātas.”

Tā pati politika nosaka ziņošanas prasības:

“Ziņošana: katra testa noslēgumā jāizdod formāls pārskats. Ielaušanās testēšanai pārskatā jāiekļauj vadības kopsavilkums, metodoloģija un detalizēti konstatējumi ar atbalstošiem pierādījumiem un ieteikumiem.”

Zenith Blueprint 21. solis arī uzsver aizsardzību audita un testēšanas laikā:

“Neviens tests vai audits nedrīkst notikt bez dokumentēta sistēmu īpašnieku vai attiecīgo iesaistīto pušu apstiprinājuma.”

Iesaistes noteikumi, testēšanas logi, ārkārtas kontakti, pagaidu piekļuve, datu apstrāde, žurnālfiksēšana, izmaiņu atcelšanas procedūras un juridiskie apstiprinājumi nav birokrātija. Tie ir noturības drošības pasākumi.

Iesaistiet trešo personu IKT pakalpojumu sniedzējus pirms testa neveiksmes

DORA padara trešo personu IKT risku par centrālu noturības jautājumu. Article 28 prasa finanšu vienībām pārvaldīt trešo personu IKT risku IKT risku pārvaldības ietvarā, saglabāt atbildību, izmantojot IKT pakalpojumus, uzturēt informācijas reģistru, ziņot par noteiktām vienošanām, veikt pirmslīguma novērtējumus un izmantot pakalpojumu sniedzējus, kas atbilst pienācīgiem informācijas drošības standartiem. Articles 29 un 30 attiecas uz koncentrācijas risku, apakšuzņēmējiem, datu atjaunošanu, līgumiskajām aizsardzībām, pakalpojumu līmeņiem, incidentu atbalstu, audita tiesībām, pakalpojumu sniedzēja ārkārtas situāciju testēšanu, dalību testēšanā attiecīgos gadījumos un izstāšanās kārtību.

ISO/IEC 27001:2022 Annex A nodrošina atbalstošus piegādātāju kontroles pasākumus, tostarp 5.19 Informācijas drošība piegādātāju attiecībās, 5.20 Informācijas drošības noteikšana piegādātāju līgumos, 5.21 Informācijas drošības pārvaldība IKT piegādes ķēdē, 5.22 Piegādātāju pakalpojumu uzraudzība, pārskatīšana un izmaiņu pārvaldība un 5.23 Informācijas drošība mākoņpakalpojumu izmantošanā.

DORA testu katalogam jāidentificē, kuriem testiem nepieciešama piegādātāja dalība vai piegādātāja pierādījumi. Piemēri:

• Mākoņpakalpojumu sniedzēja pārslēgšanās pieņēmumi
• Pārvaldīta SOC eskalācija un pierādījumu saglabāšana
• Pamatbankas platformas incidentu komunikācija
• Maksājumu apstrādātāja darbības traucējumu scenārijs
• Identitātes nodrošinātāja atjaunošanas tests
• SaaS piegādātāja ielaušanās testēšanas apliecinājumi
• Kritiskās apakšuzņēmēju ķēdes ietekmes novērtēšana

Programma, kas izslēdz kritiskos IKT pakalpojumu sniedzējus, neizturēs realitātes pārbaudi. Klientiem pieejamais pakalpojums var būt jūsu, bet noturības atkarība var atrasties mākoņreģionā, ārpakalpojumā sniegtā SOC, identitātes nodrošinātājā, programmatūras piegādātājā, maksājumu apstrādātājā vai datu centrā.

Savstarpējās atbilstības kartējums: viens pierādījumu kopums, daudz pienākumu

Labi izstrādāta DORA testēšanas programma mazina audita nogurumu. Tie paši pierādījumi var atbalstīt DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 un COBIT 2019 pārvaldības pārskatīšanu, ja tie ir pienācīgi marķēti, glabāti un ziņoti.

Nedrīkst aizmirst GDPR. Ja noturības testi ietver personas datus, žurnālus, klientu ierakstus, identitātes datus, HR ierakstus, biometriskos datus vai īpašu kategoriju datus, organizācijai jāievēro GDPR principi, tostarp likumīgums, godprātība, pārredzamība, datu minimizēšana, glabāšanas ierobežošana, integritāte, konfidencialitāte un pārskatatbildība. Testa datu kopijas, eksportēti žurnāli un ielaušanās testu pierādījumi var kļūt par reglamentētām datu glabātuvēm. Testēšanas programmai jānosaka, kas tiem drīkst piekļūt, cik ilgi tie tiek glabāti un kā tie tiek droši likvidēti.

Kā auditori pārbaudīs to pašu programmu

DORA uzraugs, ISO auditors, uz NIST balstīts vērtētājs, COBIT pārskatītājs un klienta auditors var pārbaudīt vienus un tos pašus pierādījumus caur dažādām prizmām.

Zenith Controls šeit ir noderīgs kā savstarpējās atbilstības kompass. DORA testēšanai Clarysec izceļ 5.35 Neatkarīgu informācijas drošības pārskatīšanu, 8.8 Tehnisko ievainojamību pārvaldību un 8.6 Kapacitātes pārvaldību kā īpaši svarīgus ISO/IEC 27001:2022 Annex A pamatus. Tie palīdz kontroles pasākumu īpašniekiem sasaistīt testēšanu ar neatkarīgu apliecinājumu, ievainojamību apstrādi un operacionālo kapacitāti.

Clarysec Informācijas drošības politika arī atbalsta audita pēdu:

“Kontroles pasākumu īpašniekiem jāuztur testu rezultāti, žurnāli un pārskatīšanas ieraksti, lai atbalstītu periodiskus auditus.”

Šim teikumam jākļūst par operacionālu noteikumu. Katram testa īpašniekam jāzina, kas jāglabā, kur tas jāglabā, kā tas jāaizsargā un kā tas sasaistās ar riska un kontroles pierādījumiem.

Izveidojiet DORA un ISO pierādījumu pakotni vienas nedēļas laikā

Finanšu vienība vai IKT pakalpojumu sniedzējs piecās darba dienās var panākt būtisku progresu.

1. diena: definējiet darbības jomu un kritiskumu

Izmantojiet ISO/IEC 27001:2022 Clauses 4.1 līdz 4.4 loģiku. Identificējiet ieinteresētās puses, regulatīvos pienākumus, līgumiskos pienākumus, saskarnes un atkarības. Uzskaitiet biznesa pakalpojumus, kritiskās vai svarīgās funkcijas, galvenos aktīvus, datu tipus un IKT pakalpojumu sniedzējus.

Rezultāts: DORA testēšanas darbības jomas reģistrs.

2. diena: izveidojiet ikgadējo testu katalogu

Izmantojiet četras testu grupas: ievainojamības, scenāriji, veiktspēja un ielaušanās. Katram pakalpojumam nosakiet, kuri testi ir piemērojami, to biežumu, īpašnieku, neatkarības līmeni un aktivizējošo notikumu. Iekļaujiet augsta riska izmaiņu aktivizējošos notikumus.

Rezultāts: 2026. gada digitālās darbības noturības testēšanas katalogs.

3. diena: sasaistiet kontroles pasākumus un pienākumus

Sasaistiet katru testu ar ISO/IEC 27001:2022 Annex A, risku reģistru, SoA, DORA pantiem, piegādātāju pienākumiem un attiecīgajiem Zenith Controls ierakstiem. Piemēram, ikmēneša ārējā ievainojamību skenēšana kartējas uz 8.8 Tehnisko ievainojamību pārvaldību, risku apstrādi, uzraudzību, DORA IKT risku pārvaldību un NIST CSF ievainojamību rezultātiem.

Rezultāts: kontroles kartējuma matrica.

4. diena: standartizējiet pierādījumu mapes

Izveidojiet kontrolētu pierādījumu struktūru:

• 01 Plāns un autorizācija
• 02 Darbības joma un iesaistes noteikumi
• 03 Neapstrādātie rezultāti
• 04 Gala pārskats
• 05 Konstatējumu reģistrs
• 06 Novēršanas pieteikumi
• 07 Atkārtotā testa pierādījumi
• 08 Vadības ziņošana
• 09 Gūtās mācības un politiku atjauninājumi

Rezultāts: pierādījumu repozitorijs ar glabāšanas noteikumiem.

5. diena: pārskatiet konstatējumus un ziņošanu

Konsolidējiet atvērtos konstatējumus pēc smaguma pakāpes, pakalpojuma, riska īpašnieka un noteiktā termiņa. Identificējiet nokavētu novēršanu, pieņemtos riskus un atkārtotas testēšanas trūkumus. Sagatavojiet vadības struktūras informācijas paneli, kurā redzams testu pārklājums, būtiskie konstatējumi, nokavētās darbības, trešo personu problēmas un atlikušais risks.

Rezultāts: valdei gatavs DORA un ISO testēšanas informācijas panelis.

Biežākās DORA testēšanas programmas kļūdas

Visbiežākā neveiksme nav testēšanas trūkums. Tā ir pārvaldības trūkums.

Pievērsiet uzmanību šādiem jautājumiem:

• Ielaušanās testi tiek veikti ik gadu, bet konstatējumi netiek izsekoti līdz slēgšanai
• Ievainojamību skenēšana tiek veikta bieži, bet kritiskie aktīvi nav iekļauti darbības jomā
• Galda vingrinājumi tiek rīkoti, bet nav lēmumu žurnāla vai gūto mācību rīcības plāna
• Rezerves kopiju atjaunošanas testi ir pabeigti, bet nav sasaistīti ar RTO un RPO
• Slodzes testus veic inženierija, bet par tiem netiek ziņots risku vai atbilstības funkcijai
• IKT pakalpojumu sniedzēji ir izslēgti no scenāriju un atjaunošanas testiem
• Pierādījumi tiek glabāti personīgās mapēs, tērzēšanas pavedienos vai nepārvaldītos diskos
• Valdes pārskati koncentrējas uz aktivitāšu skaitu, nevis neatrisinātu noturības risku
• SoA norāda, ka kontroles pasākums ir piemērojams, bet testēšanas pierādījumu nav
• Testēšana rada risku ražošanas videi, jo autorizācija un robežas nav skaidras

Katru trūkumu var novērst. Risinājums nav vairāk nejaušas testēšanas. Risinājums ir viena kontrolēta programma, kas sasaista risku, testēšanas aktivitāti, konstatējumu novēršanu, pierādījumus un vadības pārraudzību.

Ko valdei patiesībā vajadzētu redzēt

DORA padara IKT noturību par vadības struktūras atbildību. Noderīgam valdes ziņojumam nevajadzētu ietvert katru tehnisko konstatējumu. Tam jāatbild, vai organizācija ir pietiekami noturīga pret savu riska apetīti un darbības traucējumu toleranci.

Spēcīgs ceturkšņa vai pusgada ziņojums ietver:

• Testu pārklājumu pret kritiskām vai svarīgām funkcijām
• Pabeigtos testus salīdzinājumā ar plānotajiem testiem
• Kritiskos un augstos konstatējumus pēc pakalpojuma
• Nokavētu novēršanu pēc īpašnieka
• Atkārtotu testu sekmības rādītāju
• Ar piegādātājiem saistītus konstatējumus un koncentrācijas bažas
• Scenāriju testu mācības, kas ietekmē krīzes vai incidentu plānus
• Kapacitātes riskus pret biznesa izaugsmi un pīķa periodiem
• Atlikušos riskus, kam nepieciešama vadības piekrišana
• Budžeta, resursu vai rīku ierobežojumus

Šis ziņojums kļūst par ISO vadības pārskatīšanas ievaddatiem, DORA pārvaldības pierādījumiem un praktisku lēmumu pieņemšanas rīku.

No izkliedētiem testiem līdz stratēģiskai noturībai

CISO sākotnējā problēma nebija testēšanas neesamība. Organizācijai bija skenēšanas rezultāti, galda vingrinājumi, slodzes pārskati un ielaušanās testu PDF faili. Problēma bija tā, ka šīs aktivitātes vēl neveidoja vienotu un saskanīgu pierādījumu stāstu.

Vienota DORA un ISO/IEC 27001:2022 testēšanas programma to maina. Risku novērtēšana nosaka katalogu. Katalogs nosaka autorizētu testēšanu. Testēšana rada konstatējumus. Konstatējumi virza novēršanu un atkārtotu testēšanu. Rezultāti nonāk vadības ziņošanā. Gūtās mācības atjaunina politikas, procedūras, līgumus un kontroles pasākumus.

Tā atbilstības slogs kļūst par stratēģisku spēju.

Clarysec palīdz organizācijām izvairīties no paralēlām atbilstības programmām. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 un COBIT 2019 nav vajadzīgas atsevišķas pierādījumu pasaules. Tām nepieciešams vienots, pārvaldīts darbības modelis, ko var prezentēt caur dažādām audita prizmām.

Mūsu pieeja apvieno:

• Zenith Blueprint pakāpeniskai ISO ieviešanai un gatavībai auditam
• Zenith Controls savstarpējās atbilstības kartēšanai starp kontroles pasākumiem, ietvariem un audita gaidām
• Uzņēmumu un MVU politikas drošības testēšanai, audita uzraudzībai, ievainojamību pārvaldībai, lietojumprogrammu drošībai, nepārtrauktībai un informācijas drošībai
• Praktiskus reģistrus, pierādījumu struktūras un vadības ziņošanas veidnes

Ja jūsu 2026. gada DORA testēšanas pierādījumi ir izkliedēti pa skenēšanas rīkiem, inženierijas mapēm, galda vingrinājumu piezīmēm un ielaušanās testu PDF failiem, tagad ir laiks tos konsolidēt.

Sāciet ar vienu ikgadējo testu katalogu, kas sasaistīts ar ISO/IEC 27001:2022 risku apstrādi, jūsu SoA, kritiskām vai svarīgām funkcijām, trešo personu IKT pakalpojumu sniedzējiem un vadības ziņošanu. Pēc tam izmantojiet Clarysec Zenith Blueprint, Zenith Controls un politiku rīkkopu, lai pārvērstu šo katalogu pamatotos audita pierādījumos.

Clarysec var palīdzēt izstrādāt programmu, kartēt kontroles pasākumus, strukturēt pierādījumu pakotni un sagatavot valdes līmeņa noturības ziņojumu pirms nākamā uzraudzības pieprasījuma saņemšanas.