Registar informacija prema DORA-i: vodič za ISO 27001

Utorak je, 09:15. Sarah, CISO brzorastuće fintech tvrtke, sjedi na procjeni spremnosti sa svojim voditeljem usklađenosti, pravnim savjetnikom, voditeljem nabave i arhitektom sigurnosti oblaka. Vanjski konzultant preuzima ulogu nadzornika za DORA-u.
„Hvala na prezentaciji”, kaže. „Molim dostavite svoj registar informacija kako zahtijeva DORA Article 28, uključujući IKT ugovorne aranžmane koji podržavaju kritične ili važne funkcije, vidljivost podugovaranja, vlasništvo nad imovinom i dokaze da se registar održava u okviru vašeg okvira za upravljanje IKT rizicima.”
Prvi odgovor zvuči samouvjereno: „Imamo popis dobavljača.”
Zatim počinju pitanja.
Koji dobavljači podržavaju autorizaciju plaćanja? Koji ugovori uključuju prava na reviziju, pomoć pri incidentima, obveze u vezi s lokacijom podataka, prava raskida i podršku pri izlasku? Koje SaaS platforme obrađuju osobne podatke klijenata? Koje usluge u oblaku podržavaju kritične ili važne funkcije? Koji se podugovaratelji nalaze iza pružatelja upravljanih sigurnosnih usluga? Koji je interni vlasnik imovine odobrio tu ovisnost? Koji su rizici iz plana obrade rizika ISO/IEC 27001:2022 povezani s tim pružateljima? Koje stavke Izjave o primjenjivosti opravdavaju kontrole?
Do 10:30 tim je otvorio četiri proračunske tablice, izvoz iz CMDB-a, SharePoint mapu PDF ugovora, popis izvršitelja obrade za potrebe privatnosti, izvješće o naplati usluga u oblaku i ručno održavan alat za praćenje SaaS-a. Nijedan se izvor ne podudara.
To je praktični izazov registra informacija prema DORA-i u 2026. Provedba DORA-e prešla je iz faze „trebamo plan” u fazu „pokažite mi dokaze”. Za financijske subjekte, pružatelje IKT usluga trećih strana, CISO-e, interne revizore i timove za usklađenost, registar više nije administrativni predložak. On je poveznica između IKT ugovora, rizika dobavljača, lanaca podugovaranja, usluga u oblaku, IKT imovine, kritičnih funkcija, vlasništva nad upravljanjem i dokaza za ISO/IEC 27001:2022.
Clarysecov pristup jednostavan je: nemojte graditi registar informacija prema DORA-i kao zaseban artefakt usklađenosti. Izgradite ga kao živu dokaznu razinu unutar svojeg ISMS-a, poduprtu upravljanjem imovinom, sigurnošću dobavljača, upravljanjem korištenjem usluga u oblaku, mapiranjem pravnih i regulatornih obveza, revizijskim metapodacima i sljedivošću obrade rizika.
Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls identificira tri sidrene kontrole iz ISO/IEC 27001:2022 Annex A kao posebno relevantne za ovu temu: A.5.9, popis informacija i druge povezane imovine; A.5.19, informacijska sigurnost u odnosima s dobavljačima; i A.5.20, uređivanje informacijske sigurnosti u ugovorima s dobavljačima. Te kontrole nisu dodatna administracija. One su operativna okosnica za dokazivanje da je registar potpun, dodijeljen vlasnicima, ažuran i prikladan za reviziju.
Što DORA očekuje od registra informacija
DORA se primjenjuje od 17. siječnja 2025. i uspostavlja pravila digitalne operativne otpornosti u financijskom sektoru za upravljanje IKT rizicima, prijavljivanje incidenata, testiranje otpornosti, rizike trećih strana, ugovorne aranžmane, nadzor nad kritičnim pružateljima IKT usluga trećih strana i nadzornu provedbu. Za financijske subjekte koji su također obuhvaćeni nacionalnim prijenosom NIS2, DORA djeluje kao sektorski poseban pravni akt Unije za odgovarajuće zahtjeve upravljanja rizicima kibernetičke sigurnosti i prijavljivanja incidenata.
Obveza registra nalazi se unutar DORA discipline upravljanja IKT rizikom trećih strana. DORA Article 28 zahtijeva da financijski subjekti upravljaju IKT rizikom trećih strana kao dijelom okvira za upravljanje IKT rizicima, ostanu u potpunosti odgovorni za usklađenost čak i kada koriste IKT pružatelje, održavaju registar informacija za ugovorne aranžmane za IKT usluge i razlikuju aranžmane koji podržavaju kritične ili važne funkcije.
DORA Article 29 dodaje razmatranja rizika koncentracije i podugovaranja. To uključuje mogućnost zamjene, višestruke ovisnosti o istim ili povezanim pružateljima, podugovaranje u trećim zemljama, ograničenja povezana s insolventnošću, oporavak podataka, usklađenost sa zaštitom podataka te duge ili složene lance podugovaranja.
DORA Article 30 zatim definira sadržaj ugovora koji će revizori očekivati. To uključuje opise usluga, uvjete podugovaranja, lokacije obrade podataka, obveze zaštite podataka, obveze pristupa i oporavka, razine usluge, podršku pri incidentima, suradnju s nadležnim tijelima, prava raskida, sudjelovanje u obuci, prava na reviziju i izlazne strategije za aranžmane koji podržavaju kritične ili važne funkcije.
Zreo registar informacija prema DORA-i mora odgovoriti na četiri praktična pitanja.
| Pitanje registra | Što nadzorna tijela i revizori zapravo testiraju |
|---|---|
| Koje IKT usluge koristite? | Potpunost IKT ugovornih aranžmana, usluga u oblaku, SaaS platformi i upravljanih usluga |
| Tko ih pruža i tko stoji iza njih? | Vlasništvo dobavljača, lanci podugovaranja, podizvršitelji obrade i rizik koncentracije |
| Što podržavaju? | Povezanost s kritičnim ili važnim funkcijama, poslovnim procesima, IKT imovinom i podacima |
| Možete li dokazati upravljanje? | Ugovori, procjene rizika, kontrole, vlasnici, praćenje, prava na reviziju, spremnost za izlazak i metapodaci pregleda |
Slab registar je proračunska tablica koju nabava ažurira jednom godišnje. Kvalitetan registar je upravljani skup podataka koji povezuje portfelj dobavljača, popis imovine, registar usluga u oblaku, repozitorij ugovora, zapise o privatnosti, planove neprekidnosti poslovanja, operativne postupke za incidente, registar rizika i dokaze za ISO/IEC 27001:2022.
Zašto je ISO 27001 najbrži put do dokazivog registra prema DORA-i
ISO/IEC 27001:2022 organizacijama daje strukturu sustava upravljanja koja često nedostaje dokazima za DORA-u. Točke 4.1 do 4.4 zahtijevaju da organizacija definira kontekst, zainteresirane strane, pravne, regulatorne i ugovorne obveze, opseg, sučelja i ovisnosti. Upravo tu DORA pripada u ISMS-u jer registar ovisi o razumijevanju koje financijske usluge, IKT pružatelji, klijenti, nadležna tijela, platforme u oblaku i eksternalizirani procesi ulaze u opseg.
Točke 5.1 do 5.3 zahtijevaju vodstvo, usklađenost politika, resurse, odgovornosti i izvješćivanje prema najvišem rukovodstvu. To je važno jer DORA Article 5 odgovornost stavlja na upravljačko tijelo, koje mora definirati, odobriti, nadzirati i ostati odgovorno za okvir za upravljanje IKT rizicima, uključujući politike za pružatelje IKT usluga trećih strana i kanale izvješćivanja.
Točke 6.1.1 do 6.1.3 mjesto su na kojem registar postaje utemeljen na riziku. ISO/IEC 27001:2022 zahtijeva ponovljiv proces procjene rizika, vlasnike rizika, analizu vjerojatnosti i posljedica, obradu rizika, odabir kontrola, Izjavu o primjenjivosti i odobrenje vlasnika rizika za preostali rizik. Registar prema DORA-i koji nije povezan s obradom rizika postaje statičan popis. Registar povezan sa scenarijima rizika, kontrolama i vlasnicima postaje revizijski dokaz.
Točke 8.1 do 8.3 zatim planiranje pretvaraju u kontrolirane operacije. One podupiru dokumentirane informacije, operativno planiranje i kontrolu, kontrolu promjena, kontrolu eksterno pruženih procesa, planirana preispitivanja rizika, provedbu obrade rizika i čuvanje dokaza. To je ključno za 2026. jer nadzorna tijela ne pitaju samo je li registar postojao u nekom trenutku. Pitaju jesu li novi ugovori, promijenjene usluge, novi podugovaratelji, migracije u oblak i izlazni događaji obuhvaćeni ciklusom upravljanja.
Sloj kontrola iz Annex A dodatno potvrđuje istu poantu. Odnosi s dobavljačima, ugovori s dobavljačima, rizik IKT opskrbnog lanca, praćenje usluga dobavljača, nabava i izlazak iz usluga u oblaku, upravljanje incidentima, neprekidnost poslovanja, pravne i regulatorne obveze, privatnost, sigurnosne kopije, zapisivanje događaja, nadzor, kriptografija i upravljanje ranjivostima zajedno utječu na kvalitetu registra.
Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint objašnjava temelj imovine u fazi Controls in Action, Step 22:
U svom najstrateškijem obliku, popis imovine služi kao središnji živčani sustav vašeg ISMS-a. On određuje kako se pristup dodjeljuje (8.2), gdje se mora primijeniti šifriranje (8.24), koji sustavi zahtijevaju sigurnosnu kopiju (8.13), koji se zapisi dnevnika prikupljaju (8.15) pa čak i kako se provode politike klasifikacije i zadržavanja (5.10, 8.10).
Taj citat sažima praktičnu poantu. Ne možete održavati pouzdan registar informacija prema DORA-i ako temeljni popis imovine nije pouzdan. Ako vaš registar navodi „Core Banking SaaS”, ali popis imovine ne prikazuje API-je, servisne račune, skupove podataka, izvore dnevničkih zapisa, ključeve za šifriranje, ovisnosti o sigurnosnim kopijama i vlasnike, registar je iz revizijske perspektive nepotpun.
Clarysecov podatkovni model: jedan registar, više prikaza dokaza
Registar informacija prema DORA-i ne bi trebao zamijeniti vaš registar dobavljača, registar imovine ili registar usluga u oblaku. Trebao bi ih povezati. Clarysec registar obično projektira kao glavnu dokaznu razinu s kontroliranim odnosima prema postojećim zapisima ISMS-a.
Minimalno održiv model ima sedam povezanih objekata.
| Objekt | Primjeri polja | Vlasnik dokaza |
|---|---|---|
| IKT ugovorni aranžman | ID ugovora, opis usluge, datum početka, datum završetka, obnova, prava raskida, prava na reviziju | Pravni poslovi ili upravljanje dobavljačima |
| Pružatelj IKT usluga treće strane | Pravni subjekt, lokacija, kritičnost, certifikacije, status dubinske analize dobavljača, ocjena rizika | Upravljanje dobavljačima |
| Podugovaratelj ili podizvršitelj obrade | Uloga u usluzi, pristup podacima, država, status odobrenja, prenesene obveze | Upravljanje dobavljačima i privatnost |
| IKT usluga | SaaS, hosting u oblaku, upravljana sigurnost, platni pristupnik, analitika podataka | IT ili vlasnik usluge |
| Podržana funkcija | Oznaka kritične ili važne funkcije, poslovni proces, prioritet oporavka | Vlasnik poslovanja |
| Informacijska i IKT imovina | Aplikacije, skupovi podataka, API-ji, zapisi dnevnika, ključevi, računi, repozitoriji, infrastruktura | Vlasnik imovine |
| ISMS dokazi | Procjena rizika, SoA mapiranje, ugovorne odredbe, pregled nadzora, operativni postupci za incidente, test izlaska | CISO ili usklađenost |
Ova struktura omogućuje da jedan registar podrži više zahtjeva za dokazima. DORA nadzornik može pregledati ugovorne aranžmane koji podržavaju kritične ili važne funkcije. ISO revizor može pratiti kontrole dobavljača do referenci iz Annex A i obrade rizika. GDPR pregled može prikazati izvršitelje obrade, kategorije podataka, lokacije i obveze zaštite podataka. Procjenitelj usmjeren na NIST može pregledati upravljanje opskrbnim lancem, kritičnost dobavljača, ugovorne zahtjeve i nadzor životnog ciklusa.
Registar postaje više od odgovora na pitanje „tko su naši dobavljači?”. Postaje graf ovisnosti.
Temelji politika koji registar čine prikladnim za reviziju
Clarysecov skup politika daje registru operativno mjesto. Za mala i srednja poduzeća, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME počinje jasnim zahtjevom za registar:
Registar dobavljača mora održavati i ažurirati administrativni kontakt ili kontakt za nabavu. Mora uključivati:
Ista SME politika utvrđuje da ugovori moraju sadržavati definirane sigurnosne obveze:
Ugovori moraju uključivati obvezne odredbe koje obuhvaćaju:
Iako citirane odredbe u samoj politici uvode popise polja i kategorije obveznih odredbi, poruka provedbe je izravna: upravljanje dobavljačima mora biti dokumentirano, dodijeljeno i ugovorno provedeno.
Za velika poslovna okruženja, Clarysecova Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy još je bliža nadzornim očekivanjima prema DORA-i:
Registar ovisnosti o dobavljačima: VMO mora održavati ažuran registar svih kritičnih dobavljača, uključujući pojedinosti kao što su pružene usluge/proizvodi; je li dobavljač jedini izvor; dostupni alternativni dobavljači ili mogućnost zamjene; trenutačni ugovorni uvjeti; i procjena učinka ako dobavljač prestane pružati uslugu ili bude kompromitiran. Registar mora jasno identificirati dobavljače s visokom razinom ovisnosti (npr. one za koje ne postoji brza alternativa).
To se jasno mapira na DORA Article 29, rizik koncentracije i mogućnost zamjene. Ako je dobavljač jedini izvor, podržava kritičnu funkciju, posluje u trećoj zemlji, koristi dugi lanac podugovaranja i nema testiran izlazni put, registar taj rizik ne smije sakriti u slobodnoj tekstualnoj napomeni. Treba ga označiti, dodijeliti vlasnika i povezati s obradom rizika.
Clarysecova poslovna Third party and supplier security policy Third party and supplier security policy jasno definira opseg:
Obuhvaća izravne dobavljače i, gdje je primjenjivo, njihove podizvođače te uključuje softver trećih strana, infrastrukturu, podršku i upravljane usluge.
Ta rečenica predstavlja čest DORA nedostatak. Mnoge organizacije evidentiraju izravne IKT pružatelje, ali ne dokumentiraju podugovaratelje, podizvršitelje obrade, alate za upravljane usluge, platforme za podršku ili softver trećih strana ugrađen u uslugu.
Važni su i ugovorni dokazi. Ista poslovna politika uključuje:
Prava na reviziju, inspekciju i zahtijevanje sigurnosnih dokaza
Ta fraza treba biti vidljiva u vašem kontrolnom popisu pregleda ugovora. Ako ugovor s kritičnim IKT pružateljem nema prava na reviziju ili prava na dokaze, registar treba označiti korektivnu radnju.
Dokazi o imovini jednako su važni. Clarysecova SME Asset Management Policy Asset Management Policy - SME navodi:
Voditelj IT-a mora održavati strukturirani popis imovine koji uključuje najmanje sljedeća polja:
Poslovna Asset Management Policy Asset Management Policy slično navodi:
Popis imovine mora sadržavati najmanje:
Registar ne mora duplicirati svako polje imovine, ali mora upućivati na popis imovine. Ako SaaS za praćenje plaćanja podržava otkrivanje prijevara, registar prema DORA-i treba povezati aplikacijsku imovinu, skup podataka, servisne račune, API integracije, izvore dnevničkih zapisa i vlasnika poslovanja.
Usluge u oblaku zaslužuju poseban prikaz. Clarysecova SME Cloud Usage Policy Cloud Usage Policy - SME zahtijeva:
Registar usluga u oblaku mora održavati IT pružatelj ili GM. Mora bilježiti:
To je osobito vrijedno za otkrivanje neodobrenog IT-a. Registar prema DORA-i koji isključuje usluge u oblaku kupljene izvan nabave neće proći praktični test potpunosti.
Konačno, Clarysecova Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy pretvara unakrsnu usklađenost u zahtjev ISMS-a:
Sve pravne i regulatorne obveze moraju biti mapirane na određene politike, kontrole i vlasnike unutar sustava upravljanja informacijskom sigurnošću (ISMS).
To je most od registra prema DORA-i do dokaza za ISO 27001. Registar ne treba prikazivati samo dobavljače. Treba prikazivati koje politike, kontrole i vlasnici ispunjavaju regulatornu obvezu.
Mapiranje zahtjeva DORA-e na ISO 27001 i Clarysec dokaze
Tablica u nastavku povezuje ključna očekivanja registra s kontrolama ISO/IEC 27001:2022 Annex A i praktičnim Clarysec dokaznim artefaktima.
| Zahtjev registra prema DORA-i | Dokazno sidro ISO/IEC 27001:2022 | Clarysec politika ili alat | Praktični dokazni artefakt |
|---|---|---|---|
| Registar svih ugovornih aranžmana za IKT usluge | A.5.20, uređivanje informacijske sigurnosti u ugovorima s dobavljačima | Third-Party and Supplier Security Policy-sme | Registar ugovora s ID-jem ugovora, vlasnikom, datumima, statusom obnove i ključnim odredbama |
| Identifikacija kritičnih ili važnih funkcija | Točke 4.3, 6.1.2, 8.1 i A.5.9 | Supplier Dependency Risk Management Policy | Oznaka kritičnosti povezana s poslovnom funkcijom, procjenom rizika i vlasnikom imovine |
| Mapiranje dobavljača na imovinu | A.5.9, popis informacija i druge povezane imovine | Asset Management Policy | Zapisi popisa imovine povezani sa zapisima dobavljača i IKT usluge |
| Vidljivost lanca podugovaranja | A.5.19, odnosi s dobavljačima i A.5.21, upravljanje informacijskom sigurnošću u IKT opskrbnom lancu | Third party and supplier security policy | Zapisi dubinske analize dobavljača, zapisi podizvršitelja obrade i dokazi o prenesenim obvezama |
| Nadzor dobavljača | A.5.22, nadzor, pregled i upravljanje promjenama usluga dobavljača | Supplier Dependency Risk Management Policy | Tromjesečni pregledi, dokazi o dostavljenim potvrdama, SLA izvješćivanje i praćenje otvorenih pitanja |
| Upravljanje uslugama u oblaku i izlazak | A.5.23, informacijska sigurnost za korištenje usluga u oblaku | Cloud Usage Policy - SME | Registar usluga u oblaku, procjena rizika oblaka i plan izlaska |
| Prava na reviziju i inspekciju | A.5.20 i A.5.35, neovisni pregled informacijske sigurnosti | Third party and supplier security policy | Kontrolni popis ugovornih odredbi i prava zahtijevanja dokaza |
| Mapiranje pravnih i regulatornih obveza | Točke 4.2, 4.3, 6.1.3 i A.5.31, pravni, zakonski, regulatorni i ugovorni zahtjevi | Legal and Regulatory Compliance Policy | Mapa obveza prema DORA-i povezana s politikama, kontrolama i vlasnicima |
| Ažurnost dokaza i metapodaci | Točka 7.5 i točka 9.1 | Audit and Compliance Monitoring Policy - SME | Izvoz registra s izvornim sustavom, osobom koja je prikupila dokaz, datumom, pregledavateljem i statusom odobrenja |
Na ovom mapiranju registar prestaje biti proračunska tablica i postaje dokazni model. Svaki redak treba imati vlasnika ugovora, vlasnika dobavljača, vlasnika usluge, vlasnika poslovanja i vlasnika usklađenosti. Svaki kritični odnos treba imati zapis rizika, kontrolni popis ugovornih odredbi, poveznicu na imovinu i ritam nadzora.
Praktičan primjer: mapiranje jednog IKT ugovora na dokaze za ISO 27001
Zamislite da financijski subjekt koristi platformu za analitiku prijevara u oblaku. Usluga prikuplja metapodatke transakcija, podržava bodovanje prijevara u stvarnom vremenu, integrira se s platnom platformom, pohranjuje pseudonimizirane identifikatore klijenata, koristi podugovaratelja za hosting u oblaku i pruža upravljanu podršku s odobrene lokacije u trećoj zemlji.
Slab redak registra kaže: „Dobavljač: FraudCloud. Usluga: analitika prijevara. Ugovor potpisan. Kritično: da.”
Redak registra na razini nadzornog tijela izgleda znatno drukčije.
| Polje registra | Primjer unosa |
|---|---|
| IKT pružatelj | FraudCloud Ltd |
| IKT usluga | Analitika prijevara u oblaku i API za bodovanje |
| ID ugovora | LEG-ICT-2026-014 |
| Podržana funkcija | Otkrivanje prijevara u plaćanjima, kritična ili važna funkcija |
| Vlasnik poslovanja | Voditelj operacija plaćanja |
| IKT vlasnik | Voditelj platformskog inženjeringa |
| Poveznice na imovinu | APP-042 API za bodovanje prijevara, DATA-119 metapodaci transakcija, API-017 integracija platnog pristupnika, LOG-088 revizijski zapisi prijevara |
| Uloga u podacima | Izvršitelj obrade metapodataka transakcija i pseudonimiziranih identifikatora klijenata |
| Lokacije | Primarna obrada u regiji EU, pristup podrške s odobrene lokacije u trećoj zemlji |
| Podugovaratelji | Pružatelj hostinga u oblaku, platforma za zahtjeve za podršku |
| Ključne odredbe | Pomoć pri incidentima, prava na reviziju, obavješćivanje o podugovarateljima, povrat podataka, razine usluge, podrška pri izlasku |
| ISO dokazi | Procjena rizika dobavljača, zapis popisa imovine, SoA reference, kontrolni popis pregleda ugovora, procjena oblaka, pregled nadzora |
| DORA oznake rizika | Kritična funkcija, podrška iz treće zemlje, podugovaranje, rizik koncentracije ako nema alternative |
| Ritam pregleda | Tromjesečni pregled učinkovitosti, godišnja provjera dobavljača, pregled potaknut promjenom podugovaratelja ili arhitekture |
Tim za usklađenost sada može pripremiti koherentan dokazni paket. Registar dobavljača dokazuje da pružatelj postoji i ima vlasnika. Popis imovine dokazuje da su interni sustavi, API-ji, skupovi podataka i zapisi dnevnika poznati. Kontrolni popis ugovora dokazuje da su obvezne odredbe prema DORA-i pregledane. Procjena rizika dokazuje da su razmotreni koncentracija, podugovaranje, zaštita podataka i operativna otpornost. Izjava o primjenjivosti pokazuje koje su kontrole odabrane. Pregled nadzora dokazuje da aranžman nije zaboravljen nakon uvođenja dobavljača.
Zenith Blueprint, faza Risk Management, Step 13, preporučuje upravo takvu sljedivost:
Unakrsno referencirajte propise: ako su određene kontrole implementirane posebno radi usklađivanja s GDPR, NIS2 ili DORA, to možete zabilježiti ili u registru rizika (kao dio obrazloženja utjecaja rizika) ili u napomenama SoA-e.
Tako registar prema DORA-i postaje dokaz za ISO 27001 umjesto paralelne birokracije.
Lanac dobavljača i podugovaratelja mjesto je na kojem kvaliteta registra najčešće zakazuje
Najveći neuspjesi registra nisu uzrokovani nedostajućim glavnim dobavljačima. Uzrokuju ih skriveni lanci ovisnosti.
Pružatelj upravljanih sigurnosnih usluga može koristiti SIEM platformu, agenta za telemetriju krajnjih uređaja, sustav za evidentiranje zahtjeva i offshore tim za trijažu. Procesor plaćanja može ovisiti o hostingu u oblaku, uslugama identiteta, bazama podataka o prijevarama i povezivosti za namiru. SaaS pružatelj može se oslanjati na više podizvršitelja obrade za analitiku, e-poštu, opservabilnost, korisničku podršku i sigurnosne kopije.
DORA Article 29 usmjerava pozornost na rizik koncentracije i podugovaranja. NIS2 Article 21 također zahtijeva sigurnost opskrbnog lanca za izravne dobavljače i pružatelje usluga te očekuje da subjekti razmotre ranjivosti specifične za svakog izravnog dobavljača, ukupnu kvalitetu proizvoda, prakse kibernetičke sigurnosti dobavljača i postupke sigurnog razvoja. Za financijske subjekte obuhvaćene DORA-om, DORA djeluje kao sektorski poseban pravilnik za preklapajuće NIS2 zahtjeve upravljanja rizicima kibernetičke sigurnosti i prijavljivanja incidenata, ali logika opskrbnog lanca je usklađena.
Clarysecov Zenith Blueprint, faza Controls in Action, Step 23, daje praktičnu uputu:
Za svakog kritičnog dobavljača utvrdite koristi li podizvođače (podizvršitelje obrade) koji mogu pristupiti vašim podacima ili sustavima. Dokumentirajte kako se vaši zahtjevi informacijske sigurnosti prenose na te strane, bilo kroz ugovorne uvjete vašeg dobavljača ili kroz vaše izravne odredbe.
Upravo tu mnoge organizacije trebaju korektivne radnje u 2026. Ugovori potpisani prije pripreme za DORA-u možda ne uključuju transparentnost podugovaratelja, prava na revizijske dokaze, suradnju s nadležnim tijelima, pomoć pri incidentima, podršku pri izlasku ili obveze vezane uz lokaciju. Registar stoga treba uključivati status otklanjanja nedostataka ugovora, primjerice: dovršeno, praznina prihvaćena, ponovni pregovori u tijeku ili potrebna izlazna opcija.
Unakrsna usklađenost: DORA, NIS2, GDPR i NIST trebaju istu istinu o ovisnostima
Dobro osmišljen registar informacija prema DORA-i podržava više od DORA-e.
NIS2 Article 20 kibernetičku sigurnost čini odgovornošću upravljačkog tijela kroz odobravanje, nadzor i obuku. Article 21 zahtijeva analizu rizika, politike, postupanje s incidentima, kontinuitet, sigurnost opskrbnog lanca, sigurnu nabavu i održavanje, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom i MFA gdje je primjereno. Ta se područja snažno preklapaju s ISO/IEC 27001:2022 i dokaznim modelom registra.
GDPR dodaje odgovornost za privatnost. Njegov teritorijalni opseg može se primjenjivati na organizacije u EU i izvan EU koje obrađuju osobne podatke u kontekstu poslovnih nastana u EU, nude robu ili usluge pojedincima u EU ili prate njihovo ponašanje. GDPR definicije voditelja obrade, izvršitelja obrade, obrade, pseudonimizacije i povrede osobnih podataka izravno su relevantne za mapiranje IKT dobavljača. Ako registar prema DORA-i identificira IKT pružatelje i podugovaratelje, ali ne identificira uloge u obradi osobnih podataka, kategorije podataka, lokacije i zaštitne mjere, neće podržati GDPR dokaze.
NIST CSF 2.0 pruža još jednu korisnu perspektivu. Njegova funkcija GOVERN zahtijeva da organizacije razumiju misiju, očekivanja dionika, ovisnosti, pravne i ugovorne zahtjeve, usluge o kojima drugi ovise i usluge o kojima organizacija ovisi. Njegovi GV.SC ishodi opskrbnog lanca zahtijevaju program upravljanja rizicima opskrbnog lanca, definirane uloge dobavljača, integraciju u upravljanje rizicima organizacije, kritičnost dobavljača, ugovorne zahtjeve, dubinsku analizu dobavljača, nadzor životnog ciklusa, koordinaciju incidenata i planiranje nakon završetka odnosa.
Praktičan prikaz unakrsne usklađenosti izgleda ovako.
| Potreba za dokazom | DORA prikaz | ISO 27001 dokazni prikaz | NIST CSF 2.0 prikaz | GDPR prikaz |
|---|---|---|---|---|
| Potpunost IKT dobavljača | Registar ugovornih aranžmana za IKT usluge | Registar dobavljača i kontrola eksterno pruženih procesa | GV.SC identifikacija i prioritizacija dobavljača | Zapisi izvršitelja i podizvršitelja obrade |
| Kritičnost | Oznaka kritične ili važne funkcije | Procjena rizika, poslovni utjecaj i vlasništvo nad imovinom | Organizacijski kontekst i kritične usluge | Rizik za ispitanike gdje su uključeni osobni podaci |
| Ugovorne odredbe | Ugovorni sadržaj iz DORA Article 30 | Dokazi kontrola ugovora s dobavljačima | Ugovorni zahtjevi kibernetičke sigurnosti | Uvjeti obrade podataka i zaštitne mjere |
| Podugovaranje | Lanac podugovaratelja i rizik koncentracije | Nadzor dobavljača i prenesene obveze | Nadzor opskrbnog lanca kroz životni ciklus | Transparentnost podizvršitelja obrade i zaštitne mjere prijenosa |
| Izlazak | Raskid, prijelaz i povrat podataka | Izlazak iz oblaka, kontinuitet i dokazi životnog ciklusa imovine | Planiranje nakon završetka odnosa | Dokazi o povratu, brisanju i zadržavanju |
Poanta nije stvoriti pet radnih tokova usklađenosti. Poanta je stvoriti jedan dokazni model koji se može filtrirati za svaki okvir.
Iz perspektive revizora
DORA nadzornik usredotočit će se na potpunost, kritične ili važne funkcije, ugovorne aranžmane, podugovaranje, rizik koncentracije, upravljanje, izvješćivanje i održava li se registar. Može zatražiti uzorak kritičnih pružatelja i očekivati ugovorne odredbe, procjene rizika, izlazne strategije, uvjete podrške pri incidentima i dokaze nadzora rukovodstva.
Revizor za ISO/IEC 27001:2022 krenut će od opsega ISMS-a, zainteresiranih strana, regulatornih obveza, procjene rizika, Izjave o primjenjivosti, operativne kontrole i dokumentiranih informacija. Testirat će održavaju li se odnosi s dobavljačima i popisi imovine, kontroliraju li se eksterno pruženi procesi, pokreću li promjene preispitivanje i podupiru li dokazi tvrdnju o implementaciji kontrole.
Procjenitelj za NIST CSF 2.0 često će tražiti trenutačne i ciljne profile, očekivanja upravljanja, mapiranje ovisnosti, kritičnost dobavljača, integraciju ugovornih zahtjeva, nadzor životnog ciklusa i prioritizirane mjere poboljšanja.
Revizor usmjeren na COBIT 2019 obično će ispitivati vlasništvo nad upravljanjem, odgovornost za procese, prava odlučivanja, praćenje učinkovitosti, izvješćivanje o rizicima i pružanje jamstva. Pitat će je li registar ugrađen u korporativno upravljanje, a ne samo održavan u funkciji usklađenosti.
Zenith Controls pomaže prevesti ove perspektive tako što temu sidri u kontrolama ISO/IEC 27001:2022 Annex A A.5.9, A.5.19 i A.5.20, a zatim koristi tumačenje unakrsne usklađenosti za povezivanje imovine, odnosa s dobavljačima i ugovora s dobavljačima s regulatornim, upravljačkim i revizijskim očekivanjima. To je razlika između „imamo registar” i „možemo obraniti registar”.
Clarysecova SME Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy - SME također se bavi kvalitetom dokaza:
Metapodaci (npr. tko ih je prikupio, kada i iz kojeg sustava) moraju biti dokumentirani.
Taj je zahtjev malen, ali snažan. U zahtjevu za dokazima u 2026. proračunska tablica bez metapodataka o prikupljanju slaba je. Izvoz registra koji prikazuje izvorni sustav, datum izdvajanja, odgovornog vlasnika, status odobrenja i ritam pregleda znatno je snažniji.
Česti nalazi u registru informacija prema DORA-i u 2026.
Najčešći nalazi praktične su prirode.
Prvo, nepotpunost registra. Usluge u oblaku, alati za podršku, platforme za nadzor, razvojni alati, sustavi za evidentiranje zahtjeva i platforme za analitiku podataka često nedostaju jer ih nabava nije klasificirala kao IKT usluge.
Drugo, slaba logika kritičnosti. Neki timovi označavaju dobavljače kao kritične prema potrošnji, a ne prema poslovnom utjecaju. DORA zanima podržava li IKT usluga kritičnu ili važnu funkciju.
Treće, praznine u ugovornim dokazima. Stariji ugovori s dobavljačima često nemaju odredbe spremne za DORA-u koje obuhvaćaju prava na reviziju, pomoć pri incidentima, podugovaranje, suradnju s nadležnim tijelima, lokacije usluge, povrat podataka, raskid i podršku pri izlasku.
Četvrto, slaba povezanost s imovinom. Registri navode dobavljače, ali ih ne povezuju s aplikacijama, skupovima podataka, API-jima, identitetima, zapisima dnevnika, infrastrukturom ili poslovnim uslugama. To otežava analizu utjecaja tijekom incidenata i prekida rada dobavljača.
Peto, neprozirnost podugovaratelja. Organizacija poznaje glavnog pružatelja, ali ne može objasniti koji podizvršitelji obrade ili tehnički pružatelji podržavaju uslugu.
Šesto, nema okidača za promjene. Pružatelj dodaje novog podizvršitelja obrade, mijenja regiju hostinga, migrira arhitekturu ili mijenja pristup podršci, ali nitko ne ažurira registar niti ponovno procjenjuje rizik.
Sedmo, nema ritma dokaza. Nije definirana učestalost pregleda dobavljača, pregleda ugovora, provjere imovine, usklađivanja registra usluga u oblaku ili izvješćivanja rukovodstva.
Ti su problemi rješivi, ali samo ako registar ima vlasnike i radne tokove.
Praktičan 30-dnevni plan poboljšanja
Počnite s opsegom. Identificirajte sve poslovne funkcije koje bi prema DORA-i mogle biti kritične ili važne. Za svaku funkciju navedite IKT usluge o kojima ovisi. Nemojte početi od nabavne potrošnje. Počnite od operativne ovisnosti.
Uskladite ključne izvore podataka: registar dobavljača, repozitorij ugovora, popis imovine i registar usluga u oblaku. Dodajte zapise izvršitelja obrade za potrebe privatnosti i ovisnosti odgovora na incidente gdje je relevantno. Cilj nije savršenstvo prvog dana. Cilj je jedinstvena okosnica registra s jasno označenim nepoznanicama.
Klasificirajte dobavljače i usluge prema kriterijima kao što su podržana funkcija, osjetljivost podataka, operativna mogućnost zamjene, koncentracija, podugovaranje, lokacije, utjecaj incidenta, vrijeme oporavka i regulatorna relevantnost.
Pregledajte ugovore za svaki kritični ili važni IKT aranžman. Provjerite uključuje li ugovor opise usluga, uvjete podugovaranja, lokacije, obveze zaštite podataka, pristup i oporavak, razine usluge, podršku pri incidentima, prava na reviziju, suradnju s nadležnim tijelima, raskid, sudjelovanje u obuci i podršku pri izlasku.
Mapirajte ISO dokaze za svaki kritični aranžman. Povežite zapise imovine, stavke procjene rizika, SoA kontrole, dubinsku analizu dobavljača, preglede nadzora, planove kontinuiteta, operativne postupke za incidente i dokaze izlazne strategije.
Dodijelite ritam. Kritični pružatelji mogu zahtijevati tromjesečni pregled, godišnju provjeru, pregled ugovora prije obnove i trenutačno preispitivanje pri značajnoj promjeni. Nekritični pružatelji mogu se pregledavati godišnje ili nakon događaja koji pokreću pregled.
Upotrijebite ovaj kontrolni popis kako biste registar pretvorili u operativni proces:
- Uspostavite vlasnika registra prema DORA-i i zamjenskog vlasnika.
- Povežite svaki redak registra s ID-jem ugovora i vlasnikom dobavljača.
- Povežite svaku kritičnu ili važnu IKT uslugu s poslovnom funkcijom i zapisima imovine.
- Dodajte polja podugovaratelja i podizvršitelja obrade, čak i ako su inicijalno označena kao nepoznata.
- Dodajte status ugovornih odredbi za uvjete kritične prema DORA-i.
- Dodajte reference na rizike ISO/IEC 27001:2022 i SoA.
- Dodajte GDPR ulogu, osobne podatke i polja lokacije gdje je primjenjivo.
- Dodajte ritam pregleda i metapodatke zadnjeg pregleda.
- Uspostavite pravila eskalacije za nedostajuće odredbe, nepoznate podugovaratelje i visok rizik koncentracije.
- Izvješćujte rukovodstvo o metrikama kvalitete registra.
Tu Clarysecova metoda implementacije u 30 koraka, skup politika i Zenith Controls djeluju zajedno. Zenith Blueprint daje put implementacije, od obrade rizika i SoA sljedivosti u Step 13 do popisa imovine u Step 22 i kontrola dobavljača u Step 23. Politike definiraju tko mora održavati registre, koji ugovorni i imovinski dokazi moraju postojati i kako se bilježe metapodaci usklađenosti. Zenith Controls pruža kompas za unakrsnu usklađenost za mapiranje istih dokaza prema revizijskim očekivanjima DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST i COBIT 2019.
Pretvorite registar u dokaze prije nego što ih zatraži nadzorno tijelo
Ako je vaš registar informacija prema DORA-i i dalje proračunska tablica odvojena od ugovora, imovine, dobavljača, podugovaratelja i dokaza za ISO 27001, 2026. je godina da to ispravite.
Započnite korištenjem Zenith Blueprint Zenith Blueprint za povezivanje obrade rizika, popisa imovine i upravljanja dobavljačima. Upotrijebite Zenith Controls Zenith Controls za mapiranje kontrola ISO/IEC 27001:2022 Annex A A.5.9, A.5.19 i A.5.20 u dokaze unakrsne usklađenosti. Zatim provedite zahtjeve kroz Clarysecove politike za dobavljače, imovinu, oblak, pravnu usklađenost i praćenje revizije, uključujući Third-Party and Supplier Security Policy - SME, Supplier Dependency Risk Management Policy, Third party and supplier security policy, Asset Management Policy - SME, Asset Management Policy, Cloud Usage Policy - SME, Legal and Regulatory Compliance Policy i Audit and Compliance Monitoring Policy - SME.
Najbolje vrijeme za ispravljanje kvalitete registra jest prije zahtjeva nadležnog tijela, interne revizije, ispada dobavljača ili obnove ugovora. Sljedeće najbolje vrijeme je sada. Preuzmite relevantne Clarysec politike, mapirajte svoj trenutačni registar prema gore navedenom dokaznom modelu i dogovorite procjenu registra prema DORA-i kako biste raspršene podatke o dobavljačima pretvorili u dokaze na razini nadzornog tijela.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


