Register informacij DORA: vodnik za ISO 27001

Torek je, 09:15. Sarah, vodja informacijske varnosti v hitro rastočem fintech podjetju, sedi na presoji pripravljenosti skupaj z vodjo skladnosti, pravnim svetovalcem, vodjo nabave in arhitektom za oblak. Zunanji svetovalec nastopa v vlogi nadzornika za DORA.

»Hvala za predstavitev,« pove. »Predložite svoj register informacij, kot ga zahteva DORA Article 28, vključno s pogodbenimi dogovori IKT, ki podpirajo kritične ali pomembne funkcije, preglednostjo podizvajanja, lastništvom sredstev in dokazili, da se register vzdržuje v okviru vašega okvira upravljanja IKT-tveganj.«

Prvi odgovor zveni samozavestno: »Imamo seznam dobaviteljev.«

Nato se začnejo vprašanja.

Kateri dobavitelji podpirajo avtorizacijo plačil? Katere pogodbe vključujejo pravice do presoje, podporo pri incidentih, zaveze glede lokacije podatkov, pravice do odpovedi in podporo pri izstopu? Katere platforme SaaS obdelujejo osebne podatke strank? Katere storitve v oblaku podpirajo kritične ali pomembne funkcije? Kateri podizvajalci stojijo za ponudnikom upravljanih varnostnih storitev? Kateri notranji lastnik sredstva je odobril odvisnost? Katera tveganja v načrtu obravnave tveganj ISO/IEC 27001:2022 so povezana s temi ponudniki? Kateri vnosi v izjavi o uporabljivosti (SoA) utemeljujejo kontrole?

Do 10:30 je ekipa odprla štiri preglednice, izvoz iz CMDB, mapo SharePoint s pogodbami PDF, seznam obdelovalcev za varstvo zasebnosti, poročilo o obračunu storitev v oblaku in ročno vzdrževano orodje za sledenje SaaS. Med njimi ni skladnosti.

To je praktični izziv registra informacij DORA v letu 2026. Implementacija DORA se je premaknila iz faze »potrebujemo časovni načrt« v fazo »pokažite dokazila«. Za finančne subjekte, tretje ponudnike storitev IKT, vodje informacijske varnosti, notranje revizorje in ekipe za skladnost register ni več administrativna predloga. Je povezovalno tkivo med pogodbami IKT, tveganjem dobaviteljev, verigami podizvajanja, storitvami v oblaku, sredstvi IKT, kritičnimi funkcijami, lastništvom upravljanja in dokazili ISO/IEC 27001:2022.

Pristop Clarysec je preprost: registra informacij DORA ne gradite kot ločenega artefakta skladnosti. Zgradite ga kot živo dokazilno plast znotraj ISMS, podprto z upravljanjem sredstev, varnostjo dobaviteljev, upravljanjem uporabe storitev v oblaku, mapiranjem zakonskih in regulativnih obveznosti, revizijskimi metapodatki in sledljivostjo obravnave tveganj.

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls opredeljuje tri sidrne kontrole iz Priloge A ISO/IEC 27001:2022 kot posebej relevantne za to temo: A.5.9, popis informacij in drugih povezanih sredstev; A.5.19, informacijska varnost v odnosih z dobavitelji; in A.5.20, obravnava informacijske varnosti v sporazumih z dobavitelji. Te kontrole niso dodatna dokumentacija. So operativna hrbtenica za dokazovanje, da je register popoln, da ima dodeljeno lastništvo, da je ažuren in preverljiv.

Kaj DORA pričakuje od registra informacij

DORA se uporablja od 17. januarja 2025 in vzpostavlja pravilnik za digitalno operativno odpornost v finančnem sektorju, ki zajema upravljanje IKT-tveganj, poročanje o incidentih, testiranje odpornosti, tveganje tretjih oseb, pogodbene dogovore, nadzor nad kritičnimi tretjimi ponudniki storitev IKT in nadzorno uveljavljanje. Za finančne subjekte, ki so opredeljeni tudi po nacionalnem prenosu NIS2, DORA deluje kot sektorsko specifičen pravni akt Unije za ustrezne zahteve glede upravljanja tveganj kibernetske varnosti in poročanja o incidentih.

Obveznost registra je del discipline upravljanja IKT-tveganj tretjih oseb po DORA. DORA Article 28 od finančnih subjektov zahteva, da IKT-tveganje tretjih oseb upravljajo kot del okvira upravljanja IKT-tveganj, da ostanejo v celoti odgovorni za skladnost tudi pri uporabi ponudnikov IKT, da vzdržujejo register informacij za pogodbene dogovore o storitvah IKT in da razlikujejo dogovore, ki podpirajo kritične ali pomembne funkcije.

DORA Article 29 dodaja vidike tveganja koncentracije in podizvajanja. To vključuje zamenljivost, več odvisnosti od istega ali povezanih ponudnikov, podizvajanje v tretjih državah, omejitve zaradi insolventnosti, obnovitev podatkov, skladnost z varstvom podatkov ter dolge ali kompleksne verige podizvajanja.

DORA Article 30 nato opredeljuje pogodbeno vsebino, ki jo bodo presojevalci pričakovali. Ta vključuje opise storitev, pogoje podizvajanja, lokacije obdelave podatkov, zaveze glede varstva podatkov, obveznosti dostopa in obnovitve, ravni storitev, podporo pri incidentih, sodelovanje z organi, pravice do odpovedi, sodelovanje pri usposabljanju, pravice do presoje in strategije izstopa za dogovore, ki podpirajo kritične ali pomembne funkcije.

Zrel register informacij DORA mora odgovoriti na štiri praktična vprašanja.

Šibek register je preglednica, ki jo nabava posodobi enkrat letno. Močan register je upravljan podatkovni niz, ki povezuje portfelj dobaviteljev, evidenco sredstev, register storitev v oblaku, repozitorij pogodb, evidence zasebnosti, načrte neprekinjenega poslovanja, odzivne priročnike za incidente, register tveganj in dokazila ISO/IEC 27001:2022.

Zakaj je ISO 27001 najhitrejša pot do zagovorljivega registra DORA

ISO/IEC 27001:2022 organizacijam zagotavlja strukturo sistema upravljanja, ki dokazilom DORA pogosto manjka. Klavzule 4.1 do 4.4 od organizacije zahtevajo opredelitev konteksta, zainteresiranih strani, zakonskih, regulativnih in pogodbenih obveznosti, obsega, vmesnikov in odvisnosti. Prav tu DORA spada v ISMS, ker je register odvisen od poznavanja finančnih storitev, ponudnikov IKT, strank, organov, oblačnih platform in zunanje izvajanih procesov, ki sodijo v obseg.

Klavzule 5.1 do 5.3 zahtevajo voditeljstvo, uskladitev politik, vire, odgovornosti in poročanje najvišjemu vodstvu. To je pomembno, ker DORA Article 5 nalaga odgovornost upravljalnemu organu, da opredeli, odobri, nadzira in ostane odgovoren za okvir upravljanja IKT-tveganj, vključno s politikami za storitve IKT tretjih oseb in kanali poročanja.

Klavzule 6.1.1 do 6.1.3 so točka, kjer register postane zasnovan na tveganjih. ISO/IEC 27001:2022 zahteva ponovljiv proces ocenjevanja tveganj, lastnike tveganj, analizo verjetnosti in posledic, obravnavo tveganj, izbor kontrol, izjavo o uporabljivosti in odobritev preostalega tveganja s strani lastnika tveganja. Register DORA, ki ni povezan z obravnavo tveganj, postane statičen seznam. Register, povezan s scenariji tveganj, kontrolami in lastniki, postane revizijsko dokazilo.

Klavzule 8.1 do 8.3 nato načrtovanje pretvorijo v nadzorovano delovanje. Podpirajo dokumentirane informacije, operativno načrtovanje in nadzor, nadzor sprememb, nadzor zunanje zagotovljenih procesov, načrtovana ponovna ocenjevanja tveganj, izvedbo obravnave in hrambo dokazil. To je ključno za leto 2026, ker nadzorniki ne sprašujejo več samo, ali je register v nekem trenutku obstajal. Sprašujejo, ali so nove pogodbe, spremenjene storitve, novi podizvajalci, migracije v oblak in dogodki izstopa zajeti v ciklu upravljanja.

Kontrolna plast Priloge A utrjuje isto sporočilo. Odnosi z dobavitelji, sporazumi z dobavitelji, tveganje dobavne verige IKT, spremljanje storitev dobaviteljev, pridobivanje in izstop iz storitev v oblaku, upravljanje incidentov, neprekinjeno poslovanje, zakonske in regulativne obveznosti, zasebnost, varnostne kopije, beleženje, spremljanje, kriptografija in upravljanje ranljivosti vsi prispevajo h kakovosti registra.

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint razlaga temelje sredstev v fazi Controls in Action, Step 22:

V svoji najbolj strateški obliki evidenca sredstev deluje kot osrednji živčni sistem vašega ISMS. Določa, kako se dodeljuje dostop (8.2), kje je treba uporabiti šifriranje (8.24), kateri sistemi potrebujejo varnostno kopiranje (8.13), kateri dnevniki se zbirajo (8.15) ter celo kako se uveljavljajo politike razvrščanja in hrambe (5.10, 8.10).

Ta navedek povzema praktično bistvo. Zanesljivega registra informacij DORA ne morete vzdrževati, če osnovna evidenca sredstev ni zanesljiva. Če vaš register navaja »Core Banking SaaS«, evidenca sredstev pa ne prikazuje vmesnikov za aplikacijsko programiranje, storitvenih računov, podatkovnih nizov, virov dnevnikov, šifrirnih ključev, odvisnosti varnostnega kopiranja in lastnikov, je register z vidika presoje nepopoln.

Podatkovni model Clarysec: en register, več dokazilnih pogledov

Register informacij DORA ne sme nadomestiti evidence dobaviteljev, registra sredstev ali registra storitev v oblaku. Povezati jih mora. Clarysec register običajno zasnuje kot osrednjo dokazilno plast z nadzorovanimi povezavami do obstoječih zapisov ISMS.

Minimalno izvedljiv model ima sedem povezanih objektov.

Ta struktura omogoča, da en register podpre več zahtev za dokazila. Nadzornik DORA lahko pregleda pogodbene dogovore, ki podpirajo kritične ali pomembne funkcije. Presojevalec ISO lahko sledi kontrolam dobaviteljev do referenc Priloge A in obravnave tveganj. Pregledovalec GDPR lahko vidi obdelovalce, kategorije podatkov, lokacije in zaveze glede varstva podatkov. Ocenjevalec, usmerjen v NIST, lahko pregleda upravljanje dobavne verige, kritičnost dobaviteljev, pogodbene zahteve in spremljanje življenjskega cikla.

Register postane več kot vprašanje »kdo so naši dobavitelji?«. Postane graf odvisnosti.

Temelji politik, zaradi katerih je register preverljiv

Nabor politik Clarysec daje registru operativni dom. Za mala in srednja podjetja se Third-Party and Supplier Security Policy-sme Politika varnosti tretjih oseb in dobaviteljev - MSP začne z jasno zahtevo glede registra:

Register dobaviteljev mora vzdrževati in posodabljati administrativni ali nabavni kontakt. Vključevati mora:

Ista politika za mala in srednja podjetja določa, da morajo pogodbe vsebovati opredeljene varnostne obveznosti:

Pogodbe morajo vključevati obvezne klavzule, ki zajemajo:

Čeprav navedene klavzule v sami politiki uvajajo sezname polj in kategorije obveznih klavzul, je implementacijsko sporočilo neposredno: upravljanje dobaviteljev mora biti dokumentirano, dodeljeno in pogodbeno uveljavljeno.

Za poslovna okolja je Clarysecova Supplier Dependency Risk Management Policy Politika upravljanja tveganj odvisnosti od dobaviteljev še bližje nadzornim pričakovanjem DORA:

Register odvisnosti od dobaviteljev: VMO mora vzdrževati ažuren register vseh kritičnih dobaviteljev, vključno s podrobnostmi, kot so zagotovljene storitve/produkti; ali je dobavitelj edini vir; razpoložljivi alternativni dobavitelji ali zamenljivost; trenutni pogodbeni pogoji; ter ocena vpliva, če bi dobavitelj odpovedal ali bil kompromitiran. Register mora jasno opredeliti dobavitelje z visoko stopnjo odvisnosti (npr. tiste, za katere ne obstaja hitra alternativa).

To se jasno ujema s tveganjem koncentracije in zamenljivosti iz DORA Article 29. Če je dobavitelj edini vir, podpira kritično funkcijo, deluje v tretji državi, uporablja dolgo verigo podizvajanja in nima preizkušene poti izstopa, register tega tveganja ne sme skriti v prostem besedilu opombe. Označiti ga mora, mu dodeliti lastnika in ga povezati z obravnavo tveganj.

Clarysecova poslovna Third party and supplier security policy Politika varnosti tretjih oseb in dobaviteljev jasno določa obseg:

Zajema neposredne dobavitelje in, kjer je ustrezno, njihove podizvajalce ter vključuje programsko opremo tretjih oseb, infrastrukturo, podporo in upravljane storitve.

Ta stavek naslavlja pogosto vrzel DORA. Številne organizacije zajamejo neposredne ponudnike IKT, ne dokumentirajo pa podizvajalcev, podobdelovalcev, orodij upravljanih storitev, podpornih platform ali programske opreme tretjih oseb, vgrajene v storitev.

Pomembna so tudi pogodbena dokazila. Ista poslovna politika vključuje:

Pravice do presoje, pregleda in zahteve za varnostna dokazila

Ta formulacija mora biti vidna v vašem kontrolnem seznamu pregleda pogodb. Če pogodba kritičnega ponudnika IKT ne vsebuje pravic do presoje ali dokazil, mora register označiti sanacijski ukrep.

Enako pomembna so dokazila o sredstvih. Clarysecova MSP Asset Management Policy Politika upravljanja sredstev - MSP določa:

Vodja IT mora vzdrževati strukturirano evidenco sredstev, ki vključuje najmanj naslednja polja:

Poslovna Asset Management Policy Politika upravljanja sredstev podobno določa:

Evidenca sredstev mora vsebovati najmanj:

Registru ni treba podvajati vsakega polja sredstva, vendar se mora sklicevati na evidenco sredstev. Če SaaS za spremljanje plačil podpira zaznavanje goljufij, mora register DORA povezati aplikacijsko sredstvo, podatkovni niz, storitvene račune, integracije API, vire dnevnikov in lastnika poslovnega procesa.

Storitve v oblaku si zaslužijo namenski pogled. Clarysecova MSP Cloud Usage Policy Politika uporabe storitev v oblaku - MSP zahteva:

Register storitev v oblaku mora vzdrževati ponudnik IT ali generalni direktor. Zabeležiti mora:

To je posebej dragoceno za odkrivanje senčnega IT. Register DORA, ki izključuje storitve v oblaku, kupljene zunaj nabave, ne bo prestal praktičnega testa popolnosti.

Nazadnje Clarysecova Legal and Regulatory Compliance Policy Politika pravne in regulativne skladnosti pretvori medokvirno skladnost v zahtevo ISMS:

Vse zakonske in regulativne obveznosti morajo biti mapirane na konkretne politike, kontrole in lastnike znotraj sistema upravljanja informacijske varnosti (ISMS).

To je most od registra DORA do dokazil ISO 27001. Register ne sme prikazovati samo dobaviteljev. Prikazati mora, katere politike, kontrole in lastniki izpolnjujejo regulativno obveznost.

Mapiranje zahtev DORA na ISO 27001 in dokazila Clarysec

Spodnja tabela združuje ključna pričakovanja glede registra s kontrolami iz Priloge A ISO/IEC 27001:2022 in praktičnimi dokazilnimi artefakti Clarysec.

Pri tem mapiranju register preneha biti preglednica in postane dokazilni model. Vsaka vrstica mora imeti lastnika pogodbe, lastnika dobavitelja, lastnika storitve, lastnika poslovnega procesa in lastnika skladnosti. Vsak kritičen odnos mora imeti zapis tveganja, kontrolni seznam pogodbenih klavzul, povezavo do sredstva in periodiko spremljanja.

Praktični primer: mapiranje ene pogodbe IKT na dokazila ISO 27001

Predstavljajte si, da finančni subjekt uporablja platformo za analitiko goljufij v oblaku. Storitev zajema metapodatke transakcij, podpira točkovanje goljufij v realnem času, se integrira s plačilno platformo, hrani psevdonimizirane identifikatorje strank, uporablja podizvajalca za gostovanje v oblaku in zagotavlja upravljano podporo z odobrene lokacije v tretji državi.

Šibka vrstica registra se glasi: »Dobavitelj: FraudCloud. Storitev: analitika goljufij. Pogodba podpisana. Kritično: da.«

Vrstica registra na nadzorni ravni je videti bistveno drugače.

Ekipa za skladnost lahko zdaj pripravi usklajen sveženj dokazil. Register dobaviteljev dokazuje, da ponudnik obstaja in ima lastnika. Evidenca sredstev dokazuje, da so notranji sistemi, vmesniki za aplikacijsko programiranje, podatkovni nizi in dnevniki znani. Kontrolni seznam pogodbe dokazuje, da so bile obvezne klavzule DORA pregledane. Ocena tveganja dokazuje, da so bili upoštevani koncentracija, podizvajanje, varstvo podatkov in operativna odpornost. Izjava o uporabljivosti pokaže, katere kontrole so bile izbrane. Pregled spremljanja dokazuje, da dogovor po uvedbi ni bil pozabljen.

Zenith Blueprint, faza Risk Management, Step 13, priporoča prav takšno sledljivost:

Navzkrižno sklicevanje na predpise: Če so določene kontrole implementirane posebej za skladnost z GDPR, NIS2 ali DORA, lahko to zabeležite bodisi v registru tveganj (kot del utemeljitve vpliva tveganja) bodisi v opombah SoA.

Tako register DORA postane dokazilo ISO 27001 namesto vzporedne birokracije.

Veriga dobaviteljev in podizvajalcev je mesto, kjer kakovost registra odpove

Največjih pomanjkljivosti registra ne povzročajo manjkajoči glavni dobavitelji. Povzročajo jih skrite verige odvisnosti.

Ponudnik upravljane varnosti lahko uporablja platformo SIEM, agenta telemetrije končnih točk, sistem za upravljanje zahtevkov in oddaljeno ekipo za triažo v tujini. Obdelovalec plačil je lahko odvisen od gostovanja v oblaku, storitev identitete, baz podatkov o goljufijah in povezljivosti za poravnavo. Ponudnik SaaS se lahko zanaša na več podobdelovalcev za analitiko, e-pošto, opazljivost, podporo strankam in varnostne kopije.

DORA Article 29 usmerja pozornost na tveganje koncentracije in podizvajanja. NIS2 Article 21 zahteva tudi varnost dobavne verige za neposredne dobavitelje in ponudnike storitev ter od subjektov pričakuje, da upoštevajo ranljivosti, specifične za vsakega neposrednega dobavitelja, splošno kakovost produkta, prakse kibernetske varnosti dobaviteljev in postopke varnega razvoja. Za finančne subjekte, zajete z DORA, DORA deluje kot sektorsko specifičen pravilnik za prekrivajoče se zahteve NIS2 glede upravljanja tveganj kibernetske varnosti in poročanja o incidentih, vendar je logika dobavne verige usklajena.

Clarysecov Zenith Blueprint, faza Controls in Action, Step 23, daje praktična navodila:

Za vsakega kritičnega dobavitelja ugotovite, ali uporablja podizvajalce (podobdelovalce), ki bi lahko dostopali do vaših podatkov ali sistemov. Dokumentirajte, kako se vaše zahteve informacijske varnosti prenesejo na te strani, bodisi prek pogodbenih pogojev vašega dobavitelja bodisi prek vaših neposrednih klavzul.

Tu v letu 2026 številne organizacije potrebujejo odpravo pomanjkljivosti. Pogodbe, podpisane pred pripravljenostjo na DORA, morda ne vključujejo preglednosti podizvajalcev, pravic do revizijskih dokazil, sodelovanja z organi, podpore pri incidentih, podpore pri izstopu ali zavez glede lokacije. Register mora zato vključevati status odprave pogodbenih pomanjkljivosti, na primer dokončano, vrzel sprejeta, ponovna pogajanja v teku ali zahtevana izstopna možnost.

Medokvirna skladnost: DORA, NIS2, GDPR in NIST potrebujejo isto resnico o odvisnostih

Dobro zasnovan register informacij DORA podpira več kot DORA.

NIS2 Article 20 nalaga odgovornost za kibernetsko varnost upravljalnemu organu prek odobritve, nadzora in usposabljanja. Article 21 zahteva analizo tveganj, politike, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varno pridobivanje in vzdrževanje, oceno učinkovitosti, kibernetsko higieno, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev in MFA, kjer je to ustrezno. Ta področja se močno prekrivajo z ISO/IEC 27001:2022 in dokazilnim modelom registra.

GDPR dodaja odgovornost za zasebnost. Njegovo ozemeljsko področje uporabe se lahko nanaša na organizacije v EU in zunaj EU, ki obdelujejo osebne podatke v okviru poslovnih enot v EU, ponujajo blago ali storitve posameznikom v EU ali spremljajo njihovo vedenje. Opredelitve upravljavca, obdelovalca, obdelave, psevdonimizacije in kršitve varstva osebnih podatkov po GDPR so neposredno relevantne za mapiranje dobaviteljev IKT. Če register DORA opredeli ponudnike IKT in podizvajalce, ne opredeli pa vlog pri obdelavi osebnih podatkov, kategorij podatkov, lokacij in zaščitnih ukrepov, ne bo podpiral dokazil GDPR.

NIST CSF 2.0 ponuja še en uporaben pogled. Njegova funkcija GOVERN od organizacij zahteva razumevanje poslanstva, pričakovanj zainteresiranih strani, odvisnosti, zakonskih in pogodbenih zahtev, storitev, od katerih so odvisni drugi, in storitev, od katerih je odvisna organizacija. Njegovi izidi dobavne verige GV.SC zahtevajo program upravljanja tveganj dobavne verige, opredeljene vloge dobaviteljev, integracijo v upravljanje tveganj podjetja, kritičnost dobaviteljev, pogodbene zahteve, skrbni pregled, spremljanje življenjskega cikla, koordinacijo incidentov in načrtovanje po zaključku odnosa.

Praktičen medokvirni pogled je videti tako.

Namen ni ustvariti petih delovnih tokov skladnosti. Namen je ustvariti en dokazilni model, ki ga je mogoče filtrirati za vsak okvir.

Skozi oči revizorja

Nadzornik DORA se bo osredotočil na popolnost, kritične ali pomembne funkcije, pogodbene dogovore, podizvajanje, tveganje koncentracije, upravljanje, poročanje in vprašanje, ali se register vzdržuje. Lahko zahteva vzorec kritičnih ponudnikov in pričakuje pogodbene klavzule, ocene tveganj, strategije izstopa, pogoje podpore pri incidentih in dokazila o nadzoru vodstva.

Presojevalec ISO/IEC 27001:2022 bo izhajal iz obsega ISMS, zainteresiranih strani, regulativnih obveznosti, ocene tveganja, izjave o uporabljivosti, operativnega nadzora in dokumentiranih informacij. Preveril bo, ali se odnosi z dobavitelji in evidence sredstev vzdržujejo, ali so zunanje zagotovljeni procesi nadzorovani, ali spremembe sprožijo ponovno oceno in ali dokazila podpirajo zatrjevano implementacijo kontrol.

Ocenjevalec NIST CSF 2.0 bo pogosto zahteval trenutne in ciljne profile, pričakovanja upravljanja, mapiranje odvisnosti, kritičnost dobaviteljev, vključitev pogodb, spremljanje življenjskega cikla in prednostno razvrščene ukrepe izboljšav.

Revizor, usmerjen v COBIT 2019, bo običajno pregledal lastništvo upravljanja, odgovornost za procese, pravice odločanja, spremljanje uspešnosti, poročanje o tveganjih in zagotovila. Vprašal bo, ali je register vgrajen v korporativno upravljanje, ne samo vzdrževan s strani skladnosti.

Zenith Controls pomaga prevesti te poglede tako, da temo zasidra v kontrole Priloge A ISO/IEC 27001:2022 A.5.9, A.5.19 in A.5.20, nato pa z medokvirno razlago poveže sredstva, odnose z dobavitelji in sporazume z dobavitelji z regulativnimi, upravljavskimi in revizijskimi pričakovanji. To je razlika med »imamo register« in »register lahko utemeljimo«.

Clarysecova MSP Audit and Compliance Monitoring Policy Politika spremljanja presoje in skladnosti - MSP obravnava tudi kakovost dokazil:

Metapodatki (npr. kdo jih je zbral, kdaj in iz katerega sistema) morajo biti dokumentirani.

Ta zahteva je majhna, vendar močna. Pri zahtevi za dokazila v letu 2026 je preglednica brez metapodatkov zbiranja šibka. Izvoz registra, ki prikazuje izvorni sistem, datum izvlečka, odgovornega lastnika, status odobritve in periodiko pregleda, je močnejši.

Pogoste ugotovitve glede registra informacij DORA v letu 2026

Najpogostejše ugotovitve so praktične.

Prvič, nepopolnost registra. Storitve v oblaku, podporna orodja, platforme za spremljanje, orodja razvijalcev, sistemi za upravljanje zahtevkov in platforme za podatkovno analitiko pogosto manjkajo, ker jih nabava ni razvrstila kot storitve IKT.

Drugič, šibka logika kritičnosti. Nekatere ekipe dobavitelje označijo kot kritične na podlagi porabe, ne na podlagi vpliva na poslovanje. DORA zanima, ali storitev IKT podpira kritično ali pomembno funkcijo.

Tretjič, vrzeli v pogodbenih dokazilih. Starejši sporazumi z dobavitelji pogosto nimajo klavzul, pripravljenih za DORA, glede pravic do presoje, podpore pri incidentih, podizvajanja, sodelovanja z organi, lokacij storitev, vračila podatkov, odpovedi in podpore pri izstopu.

Četrtič, slaba povezava s sredstvi. Registri navajajo dobavitelje, vendar jih ne povezujejo z aplikacijami, podatkovnimi nizi, vmesniki za aplikacijsko programiranje, identitetami, dnevniki, infrastrukturo ali poslovnimi storitvami. To otežuje analizo vpliva med incidenti in odpovedmi dobaviteljev.

Petič, nepreglednost podizvajalcev. Organizacija pozna glavnega ponudnika, ne zna pa pojasniti, kateri podobdelovalci ali tehnični ponudniki podpirajo storitev.

Šestič, ni sprožilcev sprememb. Ponudnik doda novega podobdelovalca, spremeni regijo gostovanja, migrira arhitekturo ali spremeni podporni dostop, vendar nihče ne posodobi registra ali ponovno oceni tveganja.

Sedmič, ni periodike dokazil. Ni opredeljene pogostosti za pregled dobaviteljev, pregled pogodb, preverjanje sredstev, usklajevanje registra storitev v oblaku ali poročanje vodstvu.

Te težave so rešljive, vendar le, če ima register lastnike in delovne tokove.

Praktičen 30-dnevni načrt izboljšav

Začnite z obsegom. Opredelite vse poslovne funkcije, ki so lahko kritične ali pomembne po DORA. Za vsako funkcijo navedite storitve IKT, od katerih je odvisna. Ne začnite z nabavno porabo. Začnite z operativno odvisnostjo.

Uskladite ključne vire podatkov: register dobaviteljev, repozitorij pogodb, evidenco sredstev in register storitev v oblaku. Dodajte zapise obdelovalcev za zasebnost in odvisnosti odziva na incidente, kjer je ustrezno. Cilj prvega dne ni popolnost. Cilj je enotna hrbtenica registra z jasno označenimi neznankami.

Razvrstite dobavitelje in storitve z merili, kot so podprta funkcija, občutljivost podatkov, operativna zamenljivost, koncentracija, podizvajanje, lokacije, vpliv incidenta, čas obnovitve in regulativna relevantnost.

Preglejte pogodbe za vsak kritičen ali pomemben dogovor IKT. Preverite, ali pogodba vključuje opise storitev, pogoje podizvajanja, lokacije, zaveze glede varstva podatkov, dostop in obnovitev, ravni storitev, podporo pri incidentih, pravice do presoje, sodelovanje z organi, odpoved, sodelovanje pri usposabljanju in podporo pri izstopu.

Mapirajte dokazila ISO za vsak kritičen dogovor. Povežite zapise sredstev, vnose ocen tveganja, kontrole SoA, skrbni pregled dobaviteljev, preglede spremljanja, načrte neprekinjenega poslovanja, odzivne priročnike za incidente in dokazila strategije izstopa.

Določite periodiko. Kritični ponudniki lahko zahtevajo četrtletni pregled, letno zagotovilo, pregled pogodbe pred podaljšanjem in takojšnjo ponovno oceno ob pomembni spremembi. Nekritični ponudniki se lahko pregledajo letno ali ob sprožilnih dogodkih.

Uporabite ta kontrolni seznam, da register pretvorite v operativni proces:

• Določite lastnika registra DORA in namestnika lastnika.
• Vsako vrstico registra povežite z ID pogodbe in lastnikom dobavitelja.
• Vsako kritično ali pomembno storitev IKT povežite s poslovno funkcijo in zapisi sredstev.
• Dodajte polja za podizvajalce in podobdelovalce, tudi če so na začetku označena kot neznana.
• Dodajte status pogodbenih klavzul za kritične zahteve DORA.
• Dodajte reference tveganj ISO/IEC 27001:2022 in SoA.
• Dodajte vlogo po GDPR, osebne podatke in lokacijska polja, kjer je ustrezno.
• Dodajte periodiko pregleda in metapodatke zadnjega pregleda.
• Ustvarite pravila eskalacije za manjkajoče klavzule, neznane podizvajalce in visoko tveganje koncentracije.
• Poročajte kazalnike kakovosti registra vodstvu.

Tu skupaj delujejo Clarysecova 30-koračna metoda implementacije, nabor politik in Zenith Controls. Zenith Blueprint daje implementacijsko pot, od obravnave tveganj in sledljivosti SoA v Step 13 do evidence sredstev v Step 22 in kontrol dobaviteljev v Step 23. Politike določajo, kdo mora vzdrževati registre, katera pogodbena dokazila in dokazila o sredstvih morajo obstajati ter kako se zajemajo metapodatki skladnosti. Zenith Controls zagotavlja medokvirni kompas za mapiranje istih dokazil prek revizijskih pričakovanj DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST in COBIT 2019.

Register pretvorite v dokazila, preden jih zahteva nadzornik

Če je vaš register informacij DORA še vedno preglednica, nepovezana s pogodbami, sredstvi, dobavitelji, podizvajalci in dokazili ISO 27001, je leto 2026 čas, da to popravite.

Začnite z uporabo Zenith Blueprint Zenith Blueprint, da povežete obravnavo tveganj, evidenco sredstev in upravljanje dobaviteljev. Uporabite Zenith Controls Zenith Controls, da kontrole Priloge A ISO/IEC 27001:2022 A.5.9, A.5.19 in A.5.20 mapirate v medokvirna dokazila skladnosti. Nato zahteve operacionalizirajte prek Clarysecovih politik za dobavitelje, sredstva, oblak, pravno skladnost in spremljanje presoje, vključno s Politika varnosti tretjih oseb in dobaviteljev - MSP, Politika upravljanja tveganj odvisnosti od dobaviteljev, Politika varnosti tretjih oseb in dobaviteljev, Politika upravljanja sredstev - MSP, Politika upravljanja sredstev, Politika uporabe storitev v oblaku - MSP, Politika pravne in regulativne skladnosti in Politika spremljanja presoje in skladnosti - MSP.

Najboljši čas za izboljšanje kakovosti registra je pred zahtevo organa, notranjo revizijo, izpadom dobavitelja ali podaljšanjem pogodbe. Naslednji najboljši čas je zdaj. Prenesite ustrezne politike Clarysec, mapirajte svoj trenutni register glede na zgornji dokazilni model in rezervirajte presojo registra DORA, da razpršene podatke o dobaviteljih pretvorite v dokazila na nadzorni ravni.