Registrul de informații DORA: ghid pentru ISO 27001

Este ora 09:15 într-o zi de marți. Sarah, CISO-ul unei companii fintech aflate în creștere rapidă, participă la o evaluare a gradului de pregătire împreună cu managerul de conformitate, consilierul juridic, responsabilul cu achizițiile și arhitectul de securitate cloud. Consultantul extern joacă rolul unui supraveghetor DORA.

„Vă mulțumesc pentru prezentare”, spune acesta. „Vă rog să furnizați Registrul de informații cerut de Articolul 28 din DORA, incluzând acordurile contractuale TIC care susțin funcții critice sau importante, vizibilitatea asupra subcontractării, responsabilitatea pentru active și dovezile că registrul este menținut în cadrul cadrului dumneavoastră de management al riscurilor TIC.”

Primul răspuns pare sigur: „Avem o listă de furnizori.”

Apoi încep întrebările.

Ce furnizori susțin autorizarea plăților? Ce contracte includ drepturi de audit, asistență în caz de incident, angajamente privind localizarea datelor, drepturi de încetare și suport pentru ieșire? Ce platforme SaaS prelucrează date cu caracter personal ale clienților? Ce servicii cloud susțin funcții critice sau importante? Ce subcontractori se află în spatele furnizorului de securitate administrată? Ce proprietar intern al activului a aprobat dependența? Ce riscuri din planul de tratare a riscurilor ISO/IEC 27001:2022 sunt legate de acești furnizori? Ce intrări din Declarația de aplicabilitate justifică controalele?

Până la 10:30, echipa a deschis patru foi de calcul, un export CMDB, un folder SharePoint cu contracte PDF, o listă de persoane împuternicite pentru prelucrarea datelor, un raport de facturare cloud și un instrument de urmărire SaaS menținut manual. Niciuna dintre surse nu coincide.

Aceasta este provocarea practică a Registrului de informații DORA în 2026. Implementarea DORA a trecut de la „avem nevoie de o foaie de parcurs” la „arătați-mi dovezile”. Pentru entități financiare, furnizori terți de servicii TIC, CISO, auditori interni și echipe de conformitate, registrul nu mai este un șablon administrativ. Este țesutul de legătură dintre contractele TIC, riscul asociat furnizorilor, lanțurile de subcontractare, serviciile cloud, activele TIC, funcțiile critice, responsabilitatea la nivel de guvernanță și dovezile ISO/IEC 27001:2022.

Abordarea Clarysec este simplă: nu construiți Registrul de informații DORA ca artefact de conformitate separat. Construiți-l ca strat viu de dovezi în interiorul SMSI, susținut de managementul activelor, securitatea furnizorilor, guvernanța utilizării serviciilor cloud, maparea obligațiilor legale și de reglementare, metadate de audit și trasabilitatea tratării riscurilor.

Zenith Controls: The Cross-Compliance Guide de la Clarysec Zenith Controls identifică trei controale ancoră din Anexa A ISO/IEC 27001:2022 ca fiind deosebit de relevante pentru acest subiect: A.5.9, inventarul informațiilor și al altor active asociate; A.5.19, securitatea informațiilor în relațiile cu furnizorii; și A.5.20, abordarea securității informațiilor în acordurile cu furnizorii. Aceste controale nu reprezintă documentație suplimentară. Ele sunt coloana vertebrală operațională pentru a demonstra că registrul este complet, are proprietari desemnați, este actual și poate fi auditat.

Ce așteaptă DORA de la Registrul de informații

DORA se aplică din 17 ianuarie 2025 și creează un cadru normativ de reziliență TIC pentru sectorul financiar, acoperind managementul riscurilor TIC, raportarea incidentelor, testarea rezilienței, riscul asociat terților, acordurile contractuale, supravegherea furnizorilor terți critici de servicii TIC și aplicarea de către autoritățile de supraveghere. Pentru entitățile financiare identificate și în temeiul transpunerii naționale a NIS2, DORA funcționează ca act juridic al Uniunii specific sectorului pentru cerințele corespunzătoare de management al riscurilor de securitate cibernetică și de raportare a incidentelor.

Obligația privind registrul se află în disciplina DORA de management al riscului asociat terților TIC. Articolul 28 din DORA impune entităților financiare să gestioneze riscul asociat terților TIC ca parte a cadrului de management al riscurilor TIC, să rămână pe deplin responsabile pentru conformitate chiar și atunci când utilizează furnizori TIC, să mențină un registru de informații pentru acordurile contractuale privind serviciile TIC și să distingă acordurile care susțin funcții critice sau importante.

Articolul 29 din DORA adaugă considerații privind riscul de concentrare și subcontractare. Acestea includ substituibilitatea, dependențele multiple de același furnizor sau de furnizori conectați, subcontractarea în țări terțe, constrângerile legate de insolvență, recuperarea datelor, conformitatea cu protecția datelor și lanțurile de subcontractare lungi sau complexe.

Articolul 30 din DORA definește apoi conținutul contractual pe care auditorii se vor aștepta să îl vadă. Acesta include descrieri ale serviciilor, condiții de subcontractare, locații de prelucrare a datelor, angajamente privind protecția datelor, obligații de acces și recuperare, niveluri de serviciu, suport pentru incidente, cooperarea cu autoritățile, drepturi de încetare, participarea la instruire, drepturi de audit și strategii de ieșire pentru acordurile care susțin funcții critice sau importante.

Un Registru de informații DORA matur trebuie să răspundă la patru întrebări practice.

Un registru slab este o foaie de calcul pe care achizițiile o actualizează o dată pe an. Un registru solid este un set de date guvernat care conectează portofoliul de furnizori, inventarul activelor, registrul cloud, depozitul de contracte, evidențele privind confidențialitatea, planurile de continuitate a activității, procedurile de răspuns la incidente, Registrul de riscuri și dovezile ISO/IEC 27001:2022.

De ce ISO 27001 este cea mai rapidă cale către un registru DORA defensabil

ISO/IEC 27001:2022 oferă organizațiilor structura de sistem de management care lipsește adesea dovezilor DORA. Clauzele 4.1 până la 4.4 impun organizației să definească contextul, părțile interesate, obligațiile legale, de reglementare și contractuale, domeniul de aplicare, interfețele și dependențele. Exact aici își are locul DORA în SMSI, deoarece registrul depinde de cunoașterea serviciilor financiare, furnizorilor TIC, clienților, autorităților, platformelor cloud și proceselor externalizate care intră în domeniul de aplicare.

Clauzele 5.1 până la 5.3 impun leadership, alinierea politicilor, resurse, responsabilități și raportare către conducerea de vârf. Acest lucru contează deoarece Articolul 5 din DORA plasează responsabilitatea asupra organului de conducere pentru definirea, aprobarea, supravegherea și asumarea răspunderii pentru cadrul de management al riscurilor TIC, inclusiv politicile privind furnizorii terți de servicii TIC și canalele de raportare.

Clauzele 6.1.1 până la 6.1.3 sunt locul în care registrul devine bazat pe risc. ISO/IEC 27001:2022 impune un proces repetabil de evaluare a riscurilor, proprietari de risc, analiza probabilității și consecințelor, tratarea riscului, selectarea controalelor, o Declarație de aplicabilitate și aprobarea riscului rezidual de către proprietarul riscului. Un registru DORA care nu este conectat la tratarea riscurilor devine o listă statică. Un registru conectat la scenarii de risc, controale și proprietari devine dovadă de audit.

Clauzele 8.1 până la 8.3 transformă planificarea în activități operaționale controlate. Ele susțin informațiile documentate, planificarea și controlul operațional, controlul schimbărilor, controlul proceselor furnizate extern, reevaluările planificate ale riscurilor, implementarea tratamentului și păstrarea dovezilor. Acest lucru este esențial pentru 2026, deoarece supraveghetorii nu întreabă doar dacă registrul a existat la un moment dat. Ei întreabă dacă noile contracte, serviciile modificate, noii subcontractori, migrările către cloud și evenimentele de ieșire sunt capturate în ciclul de guvernanță.

Stratul de controale din Anexa A întărește aceeași idee. Relațiile cu furnizorii, acordurile cu furnizorii, riscul lanțului de aprovizionare TIC, monitorizarea serviciilor furnizorilor, achiziția și ieșirea din servicii cloud, gestionarea incidentelor, continuitatea activității, obligațiile legale și de reglementare, confidențialitatea, copiile de rezervă, jurnalizarea, monitorizarea, criptografia și managementul vulnerabilităților contribuie toate la calitatea registrului.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de la Clarysec Zenith Blueprint explică fundamentul activelor în faza Controls in Action, pasul 22:

În forma sa cea mai strategică, un inventar al activelor servește drept sistemul nervos central al SMSI. Acesta informează modul în care este alocat accesul (8.2), unde trebuie aplicată criptarea (8.24), ce sisteme necesită backup (8.13), ce jurnale sunt colectate (8.15) și chiar cum sunt aplicate politicile de clasificare și retenție (5.10, 8.10).

Acest citat surprinde punctul practic. Nu puteți menține un Registru de informații DORA fiabil decât dacă inventarul activelor de bază este fiabil. Dacă registrul spune „Core Banking SaaS”, dar inventarul activelor nu arată API-uri, conturi de serviciu, seturi de date, surse de jurnale, chei de criptare, dependențe de backup și proprietari, registrul este incomplet din perspectiva auditului.

Modelul de date Clarysec: un registru, mai multe perspective asupra dovezilor

Un Registru de informații DORA nu trebuie să înlocuiască registrul furnizorilor, Registrul activelor sau registrul cloud. Trebuie să le conecteze. Clarysec proiectează, de regulă, registrul ca strat principal de dovezi, cu relații controlate către înregistrările SMSI existente.

Modelul minim viabil are șapte obiecte conectate.

Această structură permite unui singur registru să susțină mai multe cereri de dovezi. Un supraveghetor DORA poate vizualiza acordurile contractuale care susțin funcții critice sau importante. Un auditor ISO poate urmări controalele furnizorilor până la referințele din Anexa A și la tratarea riscurilor. Un revizor GDPR poate vedea persoanele împuternicite, categoriile de date, locațiile și angajamentele privind protecția datelor. Un evaluator orientat spre NIST poate revizui guvernanța lanțului de aprovizionare, criticitatea furnizorilor, cerințele contractuale și monitorizarea ciclului de viață.

Registrul devine mai mult decât „cine sunt furnizorii noștri?”. Devine un grafic al dependențelor.

Fundamente de politică ce fac registrul verificabil în audit

Setul de politici Clarysec oferă registrului un cadru operațional. Pentru IMM-uri, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME începe cu o cerință clară privind registrul:

Trebuie menținut și actualizat un Registru al furnizorilor de către contactul administrativ sau de achiziții. Acesta trebuie să includă:

Aceeași politică pentru IMM-uri stabilește că obligațiile de securitate definite trebuie incluse în contracte:

Contractele trebuie să includă clauze obligatorii care acoperă:

Chiar dacă pasajele citate introduc liste de câmpuri și categorii de clauze obligatorii în politica propriu-zisă, mesajul de implementare este direct: guvernanța furnizorilor trebuie documentată, atribuită și impusă contractual.

Pentru medii enterprise, Supplier Dependency Risk Management Policy de la Clarysec Supplier Dependency Risk Management Policy este și mai apropiată de așteptările de supraveghere DORA:

Registrul dependențelor față de furnizori: VMO trebuie să mențină un registru actualizat al tuturor furnizorilor critici, incluzând detalii precum serviciile/produsele furnizate; dacă furnizorul este furnizor unic; furnizorii alternativi disponibili sau substituibilitatea; termenii contractuali curenți; și o evaluare a impactului în cazul în care furnizorul ar eșua sau ar fi compromis. Registrul trebuie să identifice clar furnizorii cu dependență ridicată (de exemplu, cei pentru care nu există o alternativă rapidă).

Aceasta se mapează clar la riscul de concentrare și substituibilitate din Articolul 29 din DORA. Dacă un furnizor este furnizor unic, susține o funcție critică, operează într-o țară terță, folosește un lanț lung de subcontractare și nu are o cale de ieșire testată, registrul nu trebuie să ascundă acest risc într-o notă de text liber. Trebuie să îl marcheze, să atribuie un proprietar și să îl conecteze la tratarea riscului.

Politica enterprise Third party and supplier security policy de la Clarysec Third party and supplier security policy face domeniul de aplicare explicit:

Aceasta acoperă atât furnizorii direcți, cât și, acolo unde este aplicabil, subcontractorii acestora și include software terț, infrastructură, suport și servicii administrate.

Această propoziție indică o lacună DORA frecventă. Multe organizații capturează furnizorii TIC direcți, dar nu documentează subcontractorii, persoanele subîmputernicite, instrumentele serviciilor administrate, platformele de suport sau software-ul terț încorporat într-un serviciu.

Dovezile contractuale contează, de asemenea. Aceeași politică enterprise include:

Drepturi de audit, inspecție și solicitare de dovezi de securitate

Această formulare trebuie să fie vizibilă în lista de verificare pentru revizuirea contractelor. Dacă un contract cu un furnizor TIC critic nu include drepturi de audit sau drepturi de solicitare a dovezilor, registrul trebuie să marcheze o acțiune de remediere.

Dovezile privind activele sunt la fel de importante. Asset Management Policy pentru IMM-uri de la Clarysec Asset Management Policy - SME prevede:

Responsabilul IT trebuie să mențină un inventar structurat al activelor care să includă, cel puțin, următoarele câmpuri:

Politica enterprise Asset Management Policy Asset Management Policy prevede similar:

Inventarul activelor trebuie să conțină, cel puțin:

Registrul nu trebuie să dubleze fiecare câmp de activ, dar trebuie să facă referire la inventarul activelor. Dacă un SaaS de monitorizare a plăților susține detectarea fraudei, registrul DORA trebuie să fie conectat la activul aplicație, activul set de date, conturile de serviciu, integrările API, sursele de jurnale și proprietarul procesului.

Serviciile cloud merită o perspectivă dedicată. Cloud Usage Policy pentru IMM-uri de la Clarysec Cloud Usage Policy - SME cere:

Un Registru al serviciilor cloud trebuie menținut de furnizorul IT sau de directorul general. Acesta trebuie să înregistreze:

Acest lucru este deosebit de valoros pentru identificarea IT-ului din umbră. Un registru DORA care exclude servicii cloud achiziționate în afara procesului de achiziții va eșua testul practic de exhaustivitate.

În final, Legal and Regulatory Compliance Policy de la Clarysec Legal and Regulatory Compliance Policy transformă conformitatea transversală într-o cerință SMSI:

Toate obligațiile legale și de reglementare trebuie mapate la politici, controale și proprietari specifici în cadrul Sistemului de management al securității informației (SMSI).

Aceasta este puntea dintre registrul DORA și dovezile ISO 27001. Registrul nu trebuie să arate doar furnizorii. Trebuie să arate ce politici, controale și proprietari satisfac obligația de reglementare.

Maparea cerințelor DORA la ISO 27001 și la dovezile Clarysec

Tabelul de mai jos combină așteptările esențiale privind registrul cu controalele din Anexa A ISO/IEC 27001:2022 și artefactele practice de dovezi Clarysec.

Această mapare este locul în care registrul încetează să mai fie o foaie de calcul și devine un model de dovezi. Fiecare rând trebuie să aibă un proprietar de contract, proprietar de furnizor, proprietar de serviciu, proprietar de proces și proprietar de conformitate. Fiecare relație critică trebuie să aibă o înregistrare de risc, o listă de verificare a clauzelor contractuale, o legătură către active și o frecvență de monitorizare.

Exemplu practic: maparea unui contract TIC la dovezi ISO 27001

Imaginați-vă că o entitate financiară utilizează o platformă de analiză a fraudelor bazată pe cloud. Serviciul preia metadate ale tranzacțiilor, susține scorarea fraudei în timp real, se integrează cu platforma de plăți, stochează identificatori de clienți pseudonimizați, utilizează un subcontractor de găzduire cloud și oferă suport administrat dintr-o locație aprobată dintr-o țară terță.

Un rând slab din registru spune: „Furnizor: FraudCloud. Serviciu: analiză fraude. Contract semnat. Critic: da.”

Un rând de registru la nivel de supraveghere arată foarte diferit.

Acum echipa de conformitate poate produce un pachet coerent de dovezi. Registrul furnizorilor dovedește că furnizorul există și are un proprietar. Inventarul activelor dovedește că sistemele interne, API-urile, seturile de date și jurnalele sunt cunoscute. Lista de verificare contractuală dovedește că au fost revizuite clauzele DORA obligatorii. Evaluarea riscurilor dovedește că au fost luate în considerare concentrarea, subcontractarea, protecția datelor și reziliența operațională. Declarația de aplicabilitate arată ce controale au fost selectate. Revizuirea de monitorizare dovedește că acordul nu este uitat după înrolare.

Zenith Blueprint, faza Managementul riscurilor, pasul 13, recomandă exact acest tip de trasabilitate:

Referențiați încrucișat reglementările: dacă anumite controale sunt implementate în mod specific pentru conformarea cu GDPR, NIS2 sau DORA, puteți nota acest lucru fie în Registrul de riscuri (ca parte a justificării impactului riscului), fie în notele SoA.

Așa devine registrul DORA dovadă ISO 27001, în loc de birocrație paralelă.

Lanțul furnizorilor și subcontractorilor este locul în care eșuează calitatea registrului

Cele mai mari eșecuri ale registrului nu sunt cauzate de lipsa furnizorilor de nivel superior. Sunt cauzate de lanțuri de dependență ascunse.

Un furnizor de securitate administrată poate utiliza o platformă SIEM, un agent de telemetrie pentru stații de lucru și servere, un sistem de ticketing și o echipă offshore de triaj. Un procesator de plăți poate depinde de găzduire cloud, servicii de identitate, baze de date antifraudă și conectivitate de decontare. Un furnizor SaaS se poate baza pe mai multe persoane subîmputernicite pentru analiză, e-mail, observabilitate, suport pentru clienți și backup-uri.

Articolul 29 din DORA obligă organizațiile să acorde atenție riscului de concentrare și subcontractare. Articolul 21 din NIS2 impune, de asemenea, securitatea lanțului de aprovizionare pentru furnizorii direcți și furnizorii de servicii și se așteaptă ca entitățile să ia în considerare vulnerabilitățile specifice fiecărui furnizor direct, calitatea generală a produsului, practicile de securitate cibernetică ale furnizorului și procedurile de dezvoltare securizată. Pentru entitățile financiare acoperite de DORA, DORA acționează ca set de reguli sectoriale pentru cerințele NIS2 suprapuse privind managementul riscurilor de securitate cibernetică și raportarea incidentelor, însă logica lanțului de aprovizionare este aliniată.

Zenith Blueprint de la Clarysec, faza Controls in Action, pasul 23, oferă instrucțiuni practice:

Pentru fiecare furnizor critic, identificați dacă acesta utilizează subcontractori (persoane subîmputernicite) care vă pot accesa datele sau sistemele. Documentați modul în care cerințele dumneavoastră de securitate a informațiilor sunt transferate acestor părți, fie prin termenii contractuali ai furnizorului, fie prin propriile clauze directe.

Acesta este locul în care multe organizații au nevoie de remediere în 2026. Contractele semnate înainte de pregătirea pentru DORA pot să nu includă transparența subcontractorilor, drepturi privind dovezile de audit, cooperarea cu autoritățile, asistență în caz de incident, suport pentru ieșire sau angajamente privind locațiile. Prin urmare, registrul trebuie să includă un statut de remediere contractuală, precum complet, lacună acceptată, renegociere în curs sau opțiune de ieșire necesară.

Conformitate transversală: DORA, NIS2, GDPR și NIST au nevoie de aceeași realitate a dependențelor

Un Registru de informații DORA bine proiectat susține mai mult decât DORA.

Articolul 20 din NIS2 face din securitatea cibernetică o responsabilitate a organului de conducere prin aprobare, supraveghere și instruire. Articolul 21 impune analiza riscurilor, politici, gestionarea incidentelor, continuitate, securitatea lanțului de aprovizionare, achiziție și mentenanță securizate, evaluarea eficacității, igienă cibernetică, criptografie, securitate HR, controlul accesului, managementul activelor și autentificare multifactor acolo unde este adecvat. Aceste domenii se suprapun puternic cu ISO/IEC 27001:2022 și cu modelul de dovezi al registrului.

GDPR adaugă responsabilitate privind protecția datelor cu caracter personal. Domeniul său teritorial se poate aplica organizațiilor din UE și din afara UE care prelucrează date cu caracter personal în contextul sediilor din UE, oferă bunuri sau servicii persoanelor din UE sau monitorizează comportamentul acestora. Definițiile GDPR privind operatorul, persoana împuternicită, prelucrarea, pseudonimizarea și încălcarea securității datelor cu caracter personal sunt direct relevante pentru maparea furnizorilor TIC. Dacă registrul DORA identifică furnizori TIC și subcontractori, dar nu identifică rolurile de prelucrare a datelor cu caracter personal, categoriile de date, locațiile și măsurile de protecție, acesta nu va susține dovezile GDPR.

NIST CSF 2.0 oferă o altă perspectivă utilă. Funcția GOVERN impune organizațiilor să înțeleagă misiunea, așteptările părților interesate, dependențele, cerințele legale și contractuale, serviciile de care depind alte părți și serviciile de care depinde organizația. Rezultatele GV.SC privind lanțul de aprovizionare solicită un program de management al riscului în lanțul de aprovizionare, roluri definite ale furnizorilor, integrare în managementul riscurilor la nivel de organizație, criticitatea furnizorilor, cerințe contractuale, verificare prealabilă, monitorizarea ciclului de viață, coordonarea incidentelor și planificarea post-relație.

O perspectivă practică de conformitate transversală arată astfel.

Scopul nu este crearea a cinci fluxuri de lucru de conformitate. Scopul este crearea unui singur model de dovezi care poate fi filtrat pentru fiecare cadru.

Prin ochii auditorului

Un supraveghetor DORA se va concentra pe exhaustivitate, funcții critice sau importante, acorduri contractuale, subcontractare, risc de concentrare, guvernanță, raportare și pe faptul că registrul este menținut. Poate solicita un eșantion de furnizori critici și se va aștepta să vadă clauze contractuale, evaluări ale riscurilor, strategii de ieșire, termeni de suport pentru incidente și dovezi ale supravegherii de către management.

Un auditor ISO/IEC 27001:2022 va porni de la domeniul de aplicare al SMSI, părțile interesate, obligațiile de reglementare, evaluarea riscurilor, Declarația de aplicabilitate, controlul operațional și informațiile documentate. Acesta va testa dacă relațiile cu furnizorii și inventarele activelor sunt menținute, dacă procesele furnizate extern sunt controlate, dacă schimbările declanșează reevaluare și dacă dovezile susțin implementarea declarată a controalelor.

Un evaluator NIST CSF 2.0 va solicita adesea profiluri curente și țintă, așteptări de guvernanță, maparea dependențelor, criticitatea furnizorilor, integrarea contractuală, monitorizarea ciclului de viață și acțiuni de îmbunătățire prioritizate.

Un auditor orientat către COBIT 2019 va examina, de regulă, responsabilitatea de guvernanță, răspunderea pentru procese, drepturile decizionale, monitorizarea performanței, raportarea riscurilor și asigurarea. Va întreba dacă registrul este integrat în guvernanța corporativă, nu doar menținut de conformitate.

Zenith Controls ajută la traducerea acestor perspective prin ancorarea subiectului în controalele din Anexa A ISO/IEC 27001:2022 A.5.9, A.5.19 și A.5.20, apoi prin utilizarea interpretării de conformitate transversală pentru a conecta activele, relațiile cu furnizorii și acordurile cu furnizorii la așteptările de reglementare, guvernanță și audit. Aceasta este diferența dintre „avem un registru” și „putem susține registrul în fața auditului”.

Audit and Compliance Monitoring Policy pentru IMM-uri de la Clarysec Audit and Compliance Monitoring Policy - SME abordează, de asemenea, calitatea dovezilor:

Metadatele (de exemplu, cine le-a colectat, când și din ce sistem) trebuie documentate.

Această cerință este mică, dar puternică. Într-o solicitare de dovezi din 2026, o foaie de calcul fără metadate de colectare este slabă. Un export al registrului care arată sistemul sursă, data extragerii, proprietarul responsabil, statutul de aprobare și frecvența de revizuire este mai solid.

Constatări frecvente privind Registrul de informații DORA în 2026

Cele mai frecvente constatări sunt practice.

În primul rând, incompletitudinea registrului. Serviciile cloud, instrumentele de suport, platformele de monitorizare, instrumentele pentru dezvoltatori, sistemele de ticketing și platformele de analiză a datelor lipsesc adesea deoarece nu au fost clasificate de achiziții ca servicii TIC.

În al doilea rând, logica slabă de criticitate. Unele echipe marchează furnizorii ca fiind critici pe baza cheltuielilor, nu a impactului asupra activității. DORA urmărește dacă serviciul TIC susține o funcție critică sau importantă.

În al treilea rând, lacune în dovezile contractuale. Acordurile mai vechi cu furnizorii nu includ adesea clauze pregătite pentru DORA privind drepturile de audit, asistența în caz de incident, subcontractarea, cooperarea cu autoritățile, locațiile serviciului, returnarea datelor, încetarea și suportul pentru ieșire.

În al patrulea rând, legături slabe cu activele. Registrele listează furnizori, dar nu fac legătura cu aplicații, seturi de date, API-uri, identități, jurnale, infrastructură sau servicii de activitate. Acest lucru face dificilă analiza impactului în timpul incidentelor și al indisponibilităților furnizorilor.

În al cincilea rând, opacitatea subcontractorilor. Organizația cunoaște furnizorul principal, dar nu poate explica ce persoane subîmputernicite sau furnizori tehnici susțin serviciul.

În al șaselea rând, lipsa declanșatorilor de schimbare. Un furnizor adaugă o nouă persoană subîmputernicită, schimbă regiunea de găzduire, migrează arhitectura sau modifică accesul de suport, dar nimeni nu actualizează registrul sau nu reevaluează riscul.

În al șaptelea rând, lipsa unei frecvențe pentru dovezi. Nu există o frecvență definită pentru revizuirea furnizorilor, revizuirea contractelor, validarea activelor, reconcilierea registrului cloud sau raportarea către management.

Aceste probleme pot fi rezolvate, dar numai dacă registrul are proprietari și fluxuri de lucru.

Un plan practic de îmbunătățire în 30 de zile

Începeți cu domeniul de aplicare. Identificați toate funcțiile de activitate care pot fi critice sau importante conform DORA. Pentru fiecare funcție, listați serviciile TIC de care depinde. Nu începeți cu cheltuielile de achiziții. Începeți cu dependența operațională.

Reconciliați sursele de date de bază: registrul furnizorilor, depozitul de contracte, inventarul activelor și registrul serviciilor cloud. Adăugați înregistrările privind persoanele împuternicite din perspectiva confidențialității și dependențele de răspuns la incidente, acolo unde sunt relevante. Obiectivul nu este perfecțiunea din prima zi. Obiectivul este o coloană vertebrală unică a registrului, cu necunoscutele marcate clar.

Clasificați furnizorii și serviciile folosind criterii precum funcția susținută, sensibilitatea datelor, substituibilitatea operațională, concentrarea, subcontractarea, locațiile, impactul incidentelor, timpul de recuperare și relevanța de reglementare.

Revizuiți contractele pentru fiecare acord TIC critic sau important. Verificați dacă contractul include descrieri ale serviciilor, condiții de subcontractare, locații, angajamente privind protecția datelor, acces și recuperare, niveluri de serviciu, suport pentru incidente, drepturi de audit, cooperare cu autoritățile, încetare, participare la instruire și suport pentru ieșire.

Mapați dovezile ISO pentru fiecare acord critic. Conectați înregistrările de active, intrările din evaluarea riscurilor, controalele SoA, verificarea prealabilă a furnizorilor, revizuirile de monitorizare, planurile de continuitate, procedurile de răspuns la incidente și dovezile privind strategia de ieșire.

Atribuiți frecvența. Furnizorii critici pot necesita revizuire trimestrială, asigurare anuală, revizuire contractuală înainte de reînnoire și reevaluare imediată la o schimbare materială. Furnizorii necritici pot fi revizuiți anual sau la evenimente declanșatoare.

Folosiți această listă de verificare pentru a transforma registrul într-un proces operațional:

• Creați un proprietar al registrului DORA și un proprietar de rezervă.
• Conectați fiecare rând din registru la un ID de contract și la un proprietar de furnizor.
• Conectați fiecare serviciu TIC critic sau important la funcția de activitate și la înregistrările de active.
• Adăugați câmpuri pentru subcontractori și persoane subîmputernicite, chiar dacă sunt marcate inițial ca necunoscute.
• Adăugați statutul clauzelor contractuale pentru termenii critici DORA.
• Adăugați referințe de risc și SoA ISO/IEC 27001:2022.
• Adăugați rolul GDPR, datele cu caracter personal și câmpurile de locație acolo unde este aplicabil.
• Adăugați frecvența de revizuire și metadatele ultimei revizuiri.
• Creați reguli de escaladare pentru clauze lipsă, subcontractori necunoscuți și risc ridicat de concentrare.
• Raportați către management metrici privind calitatea registrului.

Aici se îmbină metoda de implementare în 30 de pași Clarysec, setul de politici și Zenith Controls. Zenith Blueprint oferă traseul de implementare, de la tratarea riscurilor și trasabilitatea SoA în pasul 13 la inventarul activelor în pasul 22 și controalele furnizorilor în pasul 23. Politicile definesc cine trebuie să mențină registrele, ce dovezi contractuale și privind activele trebuie să existe și cum sunt capturate metadatele de conformitate. Zenith Controls oferă busola de conformitate transversală pentru maparea acelorași dovezi în funcție de așteptările de audit DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST și COBIT 19.

Transformați registrul în dovezi înainte să îl solicite supraveghetorul

Dacă Registrul de informații DORA este încă o foaie de calcul deconectată de contracte, active, furnizori, subcontractori și dovezi ISO 27001, 2026 este anul în care trebuie remediat.

Începeți prin a utiliza Zenith Blueprint Zenith Blueprint pentru a conecta tratarea riscurilor, inventarul activelor și guvernanța furnizorilor. Utilizați Zenith Controls Zenith Controls pentru a mapa controalele A.5.9, A.5.19 și A.5.20 din Anexa A ISO/IEC 27001:2022 în dovezi de conformitate transversală. Apoi operaționalizați cerințele prin politicile Clarysec privind furnizorii, activele, cloud-ul, conformitatea juridică și monitorizarea auditului, inclusiv 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.

Cel mai bun moment pentru a remedia calitatea registrului este înainte de o solicitare a autorității, un audit intern, o indisponibilitate a unui furnizor sau o reînnoire contractuală. Următorul cel mai bun moment este acum. Descărcați politicile Clarysec relevante, mapați registrul actual la modelul de dovezi de mai sus și programați o evaluare a registrului DORA pentru a transforma datele dispersate despre furnizori în dovezi la nivel de supraveghere.