Foaie de parcurs DORA 2026 pentru riscurile TIC, furnizori și TLPT

Panica legată de căutările DORA 2026 nu este, de fapt, despre reglementare, ci despre dovezi

Este luni, ora 08:15, iar directorul securității informației al unei instituții de plăți de dimensiune medie are deschise trei file în browser: „DORA RTS/ITS checklist”, „DORA ICT third-party register template” și „TLPT requirements financial entities”.

Managerul de conformitate a întrebat deja dacă pachetul pentru consiliul de administrație ar trebui să includă cel mai recent flux de clasificare a incidentelor. Achizițiile vor să integreze o nouă platformă de analiză găzduită în cloud. Directorul operațional (COO) solicită asigurări că furnizorul SaaS pentru core banking nu are expuneri ascunse la subcontractori din afara UE. Auditul intern cere un calendar de testare. Juridicul întreabă dacă termenele de notificare a încălcărilor conform GDPR au fost aliniate cu raportarea incidentelor DORA.

Nimeni nu pune o întrebare teoretică. Întrebarea reală este: „Putem demonstra acest lucru până vineri?”

Aceasta este problema reală DORA 2026. Majoritatea entităților financiare înțeleg obligațiile principale: managementul riscurilor TIC, raportarea incidentelor legate de TIC, testarea rezilienței operaționale digitale, managementul riscului asociat terților furnizori de servicii TIC și supravegherea mai riguroasă a furnizorilor critici de servicii TIC. Partea dificilă este transformarea standardelor tehnice de reglementare, a standardelor tehnice de punere în aplicare și a obligațiilor la nivel de articol în practici controlate, repetabile și verificabile prin audit.

Digital Operational Resilience Act impune entităților financiare să mențină capabilități robuste de management al riscurilor TIC, politici pentru gestionarea și raportarea incidentelor legate de TIC, testarea sistemelor, controalelor și proceselor TIC, precum și supravegherea structurată a terților furnizori de servicii TIC. De asemenea, DORA impune proporționalitate. O firmă de investiții mai mică și un grup bancar mare nu au nevoie de modele identice de dovezi, dar ambele trebuie să demonstreze că abordarea lor este adecvată dimensiunii, profilului de risc, complexității și funcțiilor critice.

Proiectele DORA eșuează, de obicei, din unul dintre trei motive. În primul rând, organizația tratează DORA ca pe un exercițiu de mapare juridică, nu ca pe un model operațional. În al doilea rând, riscul asociat furnizorilor este documentat ca o listă de furnizori, nu ca dependență, substituibilitate și risc de concentrare. În al treilea rând, testarea este tratată ca un test de penetrare anual, nu ca un program de reziliență care include scanări de vulnerabilitate, testare pe scenarii, exerciții de incident și, acolo unde este aplicabil, testare de penetrare bazată pe amenințări, căutată frecvent ca TLPT.

O abordare mai bună este construirea unui singur sistem de dovezi care conectează politici, registre, proprietari, riscuri, incidente, furnizori, testare, recuperare și revizuire de management. Aici Zenith Blueprint, politicile gata de utilizare și Zenith Controls de la Clarysec ajută entitățile financiare să transforme DORA dintr-un termen-limită într-un ritm operațional.

Începeți cu modelul operațional DORA, nu cu tabelul RTS/ITS

Multe echipe încep cu un tabel care listează articolele DORA și cerințele RTS/ITS. Acest lucru este util, dar nu suficient. Un tabel poate arăta ce trebuie să existe. Nu atribuie proprietari, nu definește frecvența revizuirii, nu păstrează dovezi și nu demonstrează că un control funcționează efectiv.

În Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului, Clarysec tratează acest aspect în faza de management al riscurilor, pasul 14, Politici de tratare a riscurilor și referințe încrucișate de reglementare:

„DORA: Pentru firmele din sectorul financiar, DORA impune un cadru de management al riscurilor TIC foarte bine aliniat cu ceea ce am realizat: identificarea riscurilor, implementarea controalelor (și politicilor) și testarea acestora. DORA pune accent și pe răspunsul la incidente și raportare, precum și pe supravegherea terților furnizori de servicii TIC.”

Mesajul practic este simplu: nu construiți „conformitatea DORA” ca o birocrație paralelă. Construiți un strat de guvernanță TIC bazat pe risc, care mapează cerințele DORA la politici, registre, proprietari de control, înregistrări ale testării, dovezi privind furnizorii și revizuire de management.

Un model operațional DORA practic trebuie să aibă cinci piloni de dovezi:

Pentru entitățile financiare reglementate, această structură transformă implementarea RTS/ITS într-un sistem de dovezi pregătit pentru audit. Pentru entitățile care intră sub managementul simplificat al riscurilor TIC, același model poate fi redus la mai puține documente și registre mai simple. Disciplinele de bază rămân aceleași: identificare, protecție, detecție, răspuns, recuperare, testare și guvernanța furnizorilor.

Managementul riscurilor TIC: registrul este camera de control

Așteptările DORA privind managementul riscurilor TIC impun entităților financiare să identifice, să clasifice și să gestioneze riscurile TIC la nivelul sistemelor, datelor, proceselor, funcțiilor critice sau importante și dependențelor față de terți.

Eșecul frecvent nu este lipsa unui registru de riscuri. Problema este că registrul nu este conectat cu furnizorii, activele, incidentele și testele. DORA nu recompensează un tabel frumos dacă acesta nu poate explica de ce un furnizor cu risc ridicat nu are plan de ieșire sau de ce o platformă critică de plăți pentru clienți nu a fost testată.

Politica de management al riscurilor pentru IMM-uri de la Clarysec oferă entităților financiare mai mici o bază de dovezi concisă:

„Fiecare înregistrare de risc trebuie să includă: descriere, probabilitate, impact, scor, proprietar și plan de tratament.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.1.2.

Pentru entitățile financiare mai mari, Politica de management al riscurilor Enterprise de la Clarysec impune un proces mai formal:

„Trebuie menținut un proces formal de management al riscurilor în conformitate cu ISO/IEC 27005 și ISO 31000, acoperind identificarea, analiza, evaluarea, tratarea, monitorizarea și comunicarea riscurilor.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.1.

Această distincție contează. DORA este proporțională, dar proporționalitatea nu înseamnă informalitate. O firmă de plăți mică poate utiliza un registru simplificat, în timp ce un grup bancar poate utiliza instrumente GRC integrate. În ambele cazuri, auditorul va întreba: Care sunt riscurile dvs. TIC? Cine le deține? Care este planul de tratament? Ce dovezi arată progresul? Cum influențează furnizorii și funcțiile critice scorul?

Un registru solid de riscuri TIC pentru DORA trebuie să includă următoarele câmpuri:

Un exercițiu practic este să luați un serviciu TIC critic, cum ar fi o platformă de monitorizare a tranzacțiilor găzduită în cloud, și să creați o înregistrare de risc în 20 de minute. Descrieți scenariul de indisponibilitate sau compromitere, evaluați probabilitatea și impactul, atribuiți un proprietar, identificați furnizorii aferenți, definiți un plan de tratament și legați înregistrarea de dovezi precum verificarea prealabilă a furnizorilor, SLA, clauze privind incidentele, BIA, rezultatele testelor DR, tablouri de bord de monitorizare și revizuirea drepturilor de acces.

Acea singură înregistrare devine firul care conectează managementul riscurilor TIC DORA, supravegherea terților, detectarea incidentelor, continuitatea și testarea. Așa devine registrul de riscuri o cameră de control, nu un dosar de arhivă.

Pregătirea RTS/ITS: mapați obligațiile la politici, nu la promisiuni

Termenul practic de căutare „DORA RTS/ITS checklist” înseamnă, de regulă, „Ce documente vor aștepta supraveghetorii?” Entitățile financiare trebuie să evite promisiunile de conformitate prin declarații generice. Au nevoie de o mapare care leagă fiecare obligație de o politică, un control, un proprietar și un element de dovadă.

Politica de conformitate juridică și de reglementare pentru IMM-uri de la Clarysec stabilește o ancoră simplă de guvernanță:

„Conducerea generală trebuie să mențină un registru de conformitate simplu și structurat care listează:”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.1.1.

Pentru DORA 2026, registrul dvs. de conformitate trebuie să includă:

• Obligația DORA sau aria cerinței RTS/ITS.
• Aplicabilitatea, inclusiv justificarea proporționalității.
• Referința la politică sau procedură.
• Proprietarul controlului.
• Locația dovezilor.
• Frecvența revizuirii.
• Lacune deschise și termenul-limită de remediere.
• Statutul raportării către consiliul de administrație sau management.

Aceasta se aliniază cu abordarea Zenith Blueprint pasul 14: maparea cerințelor de reglementare la controalele și politicile SMSI, astfel încât nimic să nu fie omis. În loc să întrebe „Suntem conformi DORA?”, conducerea poate întreba „Ce elemente de dovezi DORA sunt restante, ce furnizori critici nu au planuri de ieșire și ce activități de testare nu au produs încă dovezi de remediere?”

Riscul asociat terților furnizori de servicii TIC: concentrare, substituibilitate și subcontractori

DORA a schimbat conversația despre furnizori în serviciile financiare. Nu mai este suficient să se întrebe dacă un furnizor are o certificare de securitate, asigurare sau un acord de prelucrare a datelor. Entitățile financiare trebuie să evalueze dacă un furnizor creează risc de concentrare, dacă furnizorul poate fi înlocuit realist, dacă mai multe servicii critice depind de același furnizor sau de furnizori afiliați și dacă subcontractarea introduce expuneri juridice sau de reziliență suplimentare.

Aceasta este problema care îi ține treji pe mulți CISO. O firmă se poate baza pe un furnizor major de servicii cloud pentru prelucrarea tranzacțiilor, analiza datelor, portaluri pentru clienți și colaborare internă. Dacă acel furnizor suferă o indisponibilitate prelungită, o dispută de reglementare sau un eșec al subcontractorului, întrebarea nu este doar „Avem un contract?” Întrebarea este „Putem continua serviciile critice, putem comunica cu clienții și putem demonstra că am înțeles dependența înainte ca aceasta să eșueze?”

Politica de securitate privind terții și furnizorii pentru IMM-uri de la Clarysec stabilește baza:

„Trebuie menținut și actualizat un registru al furnizorilor de către contactul administrativ sau de achiziții. Acesta trebuie să includă:”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.4.

Pentru programele enterprise, Politica de management al riscului de dependență față de furnizori de la Clarysec aprofundează dependența și substituibilitatea specifice DORA:

„Registrul dependențelor față de furnizori: Biroul de management al furnizorilor (VMO) trebuie să mențină un registru actualizat al tuturor furnizorilor critici, incluzând detalii precum serviciile/produsele furnizate; dacă furnizorul este furnizor unic; furnizori alternativi disponibili sau substituibilitate; 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ă).”
Din secțiunea „Cerințe de implementare”, clauza de politică 6.1.

Acestea sunt dovezile privind furnizorii pe care proiectele DORA le omit frecvent. Un registru al furnizorilor spune cine este furnizorul. Un registru al dependențelor spune ce se întâmplă când furnizorul eșuează.

Zenith Blueprint, faza Controale în acțiune, pasul 23, controale organizaționale, oferă un flux practic pentru supravegherea furnizorilor. Recomandă compilarea unei liste complete de furnizori, clasificarea furnizorilor în funcție de accesul la sisteme, date sau control operațional, verificarea faptului că așteptările de securitate sunt incluse în contracte, gestionarea riscului de subcontractor și a riscului din aval, definirea procedurilor de schimbare și monitorizare și crearea unui proces de evaluare a serviciilor cloud.

În Zenith Controls: ghidul de conformitate transversală, controlul ISO/IEC 27002:2022 5.21, Gestionarea securității informației în lanțul de aprovizionare TIC, este mapat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea. Acesta este asociat cu securitatea relațiilor cu furnizorii și cu funcția Identify din securitatea cibernetică. Se conectează la inginerie securizată, programare securizată, controlul accesului, testare de securitate, colectarea dovezilor, ciclul de viață al dezvoltării securizate și dezvoltare externalizată.

Aceasta este exact realitatea supravegherii terților conform DORA. Riscul asociat furnizorilor nu aparține doar achizițiilor. El atinge arhitectura, dezvoltarea, răspunsul la incidente, controlul accesului, continuitatea activității și juridicul.

Din perspectiva conformității transversale, Zenith Controls mapează securitatea lanțului de aprovizionare TIC la GDPR Articles 28 și 32, deoarece persoanele împuternicite și persoanele subîmputernicite trebuie selectate și supravegheate cu măsuri tehnice și organizatorice adecvate. Acest lucru susține așteptările NIS2 privind securitatea lanțului de aprovizionare, inclusiv măsurile de management al riscurilor de securitate cibernetică din Article 21 și evaluările coordonate ale riscurilor lanțului de aprovizionare din Article 22. Se mapează puternic la DORA Articles 28, 29 și 30, unde riscul asociat terților furnizori de servicii TIC, riscul de concentrare, subexternalizarea și prevederile contractuale sunt centrale.

Standardele suport consolidează dovezile. ISO/IEC 27036-3:2021 susține securitatea achizițiilor TIC și a selecției furnizorilor. ISO/IEC 20243:2018 susține integritatea produselor tehnologice de încredere și securitatea lanțului de aprovizionare. ISO/IEC 27001:2022 conectează aceste aspecte la tratarea riscurilor și la controalele pentru furnizori din Anexa A.

Raportarea incidentelor: construiți lanțul de escaladare înainte de incident

Raportarea incidentelor DORA nu înseamnă doar transmiterea unei notificări. Înseamnă detectare, clasificare, escaladare, comunicare și învățare din incidentele legate de TIC. Entitățile financiare trebuie să mențină procese pentru gestionarea incidentelor TIC și raportare, cu roluri definite, criterii de clasificare, rute de notificare și analiză post-incident.

Politica de răspuns la incidente pentru IMM-uri de la Clarysec conectează termenele de răspuns la incidente cu cerințele legale:

„Termenele de răspuns, inclusiv obligațiile de recuperare a datelor și de notificare, trebuie documentate și aliniate cu cerințele legale, cum ar fi cerința GDPR de notificare în 72 de ore a încălcărilor securității datelor cu caracter personal.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.2.

Pentru mediile enterprise, Politica de răspuns la incidente de la Clarysec adaugă perspectiva escaladării pentru date reglementate:

„Dacă un incident are ca rezultat expunerea confirmată sau probabilă a datelor cu caracter personal sau a altor date reglementate, juridicul și DPO trebuie să evalueze aplicabilitatea:”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.4.1.

Citatul se oprește exact la punctul declanșator, acolo unde multe procese de incident eșuează. Dacă declanșatorul este neclar, echipele dezbat obligațiile de notificare în timp ce ceasul deja curge.

Zenith Blueprint, faza Controale în acțiune, pasul 16, controale privind personalul II, pune accent pe raportarea incidentelor de către personal. Angajații, contractanții și părțile interesate trebuie să știe cum să recunoască și să raporteze potențiale incidente de securitate folosind canale simple, cum ar fi o căsuță poștală dedicată, un portal sau o linie telefonică de urgență. Blueprint leagă acest lucru de GDPR Article 33, NIS2 Article 23 și DORA Article 17, deoarece raportarea de reglementare începe cu conștientizarea internă și escaladarea.

În Zenith Controls, controlul ISO/IEC 27002:2022 5.24, Planificarea și pregătirea pentru managementul incidentelor de securitate a informațiilor, este mapat ca un control corectiv care susține confidențialitatea, integritatea și disponibilitatea, aliniat cu răspunsul și recuperarea. Acesta se leagă direct de evaluarea evenimentelor, învățarea din incidente, jurnalizare și monitorizare, securitatea în timpul întreruperilor, continuitatea securității informației și contactul cu autoritățile. Ghidul mapează acest lucru la DORA Articles 17 to 23 pentru gestionarea, clasificarea și raportarea incidentelor legate de TIC și notificarea voluntară a amenințărilor cibernetice, la GDPR Articles 33 and 34 pentru notificarea încălcărilor și la NIS2 Article 23 pentru notificarea incidentelor.

Un proces de incident pregătit pentru DORA trebuie să includă:

• Canale clare de primire a incidentelor.
• Criterii de triaj și clasificare a evenimentelor.
• Flux de escaladare a incidentelor majore legate de TIC.
• Puncte de decizie pentru notificare juridică, DPO și de reglementare.
• Declanșatoare pentru notificarea incidentelor furnizorilor.
• Cerințe de conservare a dovezilor.
• Reguli de comunicare pentru executivi și consiliul de administrație.
• Analiză post-incident și lecții învățate.
• Legătură cu actualizările registrului de riscuri și remedierea controalelor.

Standardele suport adaugă structură. ISO/IEC 27035-1:2023 oferă principii de planificare și pregătire pentru managementul incidentelor. ISO/IEC 27035-2:2023 detaliază pașii de gestionare a incidentelor. ISO/IEC 22320:2018 susține comanda, controlul și comunicarea structurată în criză. Acest lucru contează atunci când o indisponibilitate TIC devine o criză cu impact asupra clienților, iar entitatea trebuie să arate că deciziile au fost luate la timp, coordonat și pe bază de dovezi.

Testarea rezilienței operaționale digitale și TLPT: nu lăsați testul să devină incidentul

Testarea este unul dintre cele mai căutate subiecte DORA 2026 deoarece este atât tehnică, cât și încărcată de guvernanță. Entitățile financiare trebuie să testeze sistemele, controalele și procesele TIC. Pentru entitățile desemnate, testarea avansată, precum TLPT, devine o cerință centrală conform DORA Article 26.

Întrebarea de audit nu este doar „Ați testat?” Este „Testul a fost bazat pe risc, autorizat, sigur, independent acolo unde era necesar, remediat și legat de obiectivele de reziliență?”

Politica de testare de securitate și red-teaming Enterprise de la Clarysec definește clar programul minim de testare:

„Tipuri de teste: Programul de testare de securitate trebuie să includă, cel puțin: (a) scanări de vulnerabilitate, constând în scanări automate săptămânale sau lunare ale rețelelor și aplicațiilor pentru identificarea vulnerabilităților cunoscute; (b) testare de penetrare, constând în testare manuală aprofundată a anumitor sisteme sau aplicații de către testeri calificați pentru identificarea punctelor slabe complexe; și (c) exerciții de tip red team, constând în simulări bazate pe scenarii ale unor atacuri reale, inclusiv inginerie socială și alte tactici, pentru a testa capabilitățile de detecție și răspuns ale organizației în ansamblu.”
Din secțiunea „Cerințe de implementare”, clauza de politică 6.1.

Aceasta este puntea dintre testarea de rutină și maturitatea TLPT. Scanările de vulnerabilitate identifică puncte slabe cunoscute. Testarea de penetrare validează exploatabilitatea. Exercițiile red team testează detecția și răspunsul ca sistem. TLPT, acolo unde este aplicabil, trebuie inclus într-un program de testare guvernat, cu control al domeniului de aplicare, reguli de siguranță, managementul riscului în producție, captarea dovezilor și urmărirea remedierii.

Zenith Blueprint, faza Controale în acțiune, pasul 21, tratează protecția sistemelor informatice în timpul auditului și testării. Acesta avertizează că auditurile, testele de penetrare, analizele criminalistice și evaluările operaționale pot introduce risc, deoarece pot implica privilegii ridicate, instrumente intruzive sau schimbări temporare ale comportamentului sistemelor. Blueprint mapează această preocupare la GDPR Article 32, așteptările DORA privind testarea rezilienței operaționale digitale, preocupările NIS2 privind continuitatea și practicile COBIT 2019 pentru executarea în siguranță a auditurilor și evaluărilor.

În Zenith Controls, controlul ISO/IEC 27002:2022 5.35, Revizuirea independentă a securității informațiilor, este mapat ca preventiv și corectiv, susținând confidențialitatea, integritatea și disponibilitatea. Acesta se leagă de respectarea politicilor, responsabilitățile managementului, învățarea din incidente, protecția înregistrărilor, ștergerea informațiilor, jurnalizare și monitorizare. Pentru DORA, obligațiile relevante de testare sunt în principal Articles 24 to 27, inclusiv Article 26 pentru TLPT. Acest lucru susține și GDPR Article 32(1)(d), care impune testarea și evaluarea periodică a măsurilor tehnice și organizatorice, și NIS2 Article 21, care impune măsuri de management al riscurilor de securitate cibernetică.

Un pachet de pregătire DORA TLPT trebuie să includă:

Lecția-cheie DORA este că dovezile de testare nu trebuie să se oprească la raport. Auditorii vor întreba dacă constatările au fost evaluate pe baza riscului, atribuite, remediate și retestate. De asemenea, pot verifica dacă testarea a acoperit funcțiile critice sau importante, nu doar activele expuse la internet.

Continuitatea activității și recuperarea în caz de dezastru: reziliența trebuie să fie operațională

DORA este o reglementare privind reziliența operațională digitală. Recuperarea contează la fel de mult ca prevenirea. Un cadru documentat de riscuri TIC nu ajută dacă o indisponibilitate a platformei de plăți arată că obiectivele privind timpul de recuperare nu au fost niciodată testate, arborii de contact ai furnizorilor sunt învechiți, iar echipa de criză nu se poate pune de acord cine comunică cu clienții.

Politica privind continuitatea activității și recuperarea în caz de dezastru pentru IMM-uri de la Clarysec stabilește o bază clară:

„Organizația trebuie să testeze atât capabilitățile BCP, cât și capabilitățile DR cel puțin anual. Testele trebuie să includă:”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.4.1.

Politica privind continuitatea activității și recuperarea în caz de dezastru Enterprise începe cu impactul asupra activității:

„Analiza impactului asupra activității (BIA) trebuie efectuată cel puțin anual pentru toate unitățile de business critice și revizuită în urma schimbărilor semnificative ale sistemelor, proceselor sau dependențelor. Rezultatele BIA trebuie să definească:”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.2.

Pentru DORA, BIA trebuie conectată cu activele TIC, furnizorii, răspunsul la incidente și testarea. Dacă BIA identifică „plățile clienților” ca funcție critică, registrul dependențelor față de furnizori trebuie să identifice procesatorii, serviciile cloud și furnizorii de rețea care o susțin. Registrul de riscuri trebuie să includă scenarii de indisponibilitate. Planul de testare trebuie să includă validarea rezilienței. Planul de răspuns la incidente trebuie să includă escaladare și comunicare. Testul DR trebuie să producă dovezi, nu doar o notă de ședință.

Această trasabilitate transformă conformitatea DORA într-un sistem de reziliență operațională.

Conformitate transversală: un singur set de dovezi, multe întrebări de audit

Entitățile financiare rareori se confruntă doar cu DORA. Ele au adesea obligații GDPR, expunere NIS2, angajamente contractuale de securitate, obiective ISO/IEC 27001:2022, cerințe de audit intern, verificarea prealabilă a clienților, așteptări SOC și raportare a riscurilor către consiliul de administrație. Răspunsul nu este crearea unor silozuri separate de dovezi. Răspunsul este construirea unui model de dovezi pentru conformitate transversală.

Zenith Controls este busola Clarysec pentru conformitate transversală. Nu inventează obligații noi. Mapează standarde și cadre oficiale astfel încât organizațiile să poată înțelege cum o zonă de control susține mai multe rezultate de conformitate.

Acest lucru contează pentru buget și guvernanță. Un CISO poate explica consiliului de administrație că îmbunătățirea clasificării incidentelor susține raportarea DORA, notificarea încălcărilor conform GDPR, gestionarea incidentelor NIS2 și reziliența internă. Un lider de achiziții poate justifica maparea dependențelor față de furnizori deoarece susține riscul de concentrare DORA, verificarea prealabilă a persoanelor împuternicite conform GDPR și securitatea lanțului de aprovizionare NIS2. Un responsabil de testare poate arăta că exercițiile de tip red team și revizuirile independente susțin testarea DORA, evaluarea controalelor GDPR și asigurarea mai amplă.

Perspectiva de audit: cum vor testa evaluatorii dovezile dvs. DORA

Pregătirea DORA devine reală atunci când cineva solicită dovezi. Auditori și evaluatori diferiți vor aborda același subiect din unghiuri diferite.

Un auditor orientat pe ISO/IEC 27001:2022 va începe cu logica SMSI: domeniu de aplicare, evaluarea riscurilor, tratarea riscurilor, aplicabilitatea controalelor din Anexa A, audit intern, revizuire de management și dovezi că sunt implementate controalele. Pentru securitatea lanțului de aprovizionare TIC, va analiza politicile, clasificarea furnizorilor, clauzele contractuale, verificarea prealabilă și monitorizarea continuă. Pentru gestionarea incidentelor, va inspecta planul, rolurile, căile de escaladare, instrumentele și înregistrările. Pentru testare, se va aștepta la intervale planificate, independență acolo unde este cazul, remediere și intrări pentru revizuirea de management.

O perspectivă de audit ISO/IEC 19011:2018 se concentrează pe execuția auditului. În Zenith Controls, metodologia de audit pentru securitatea lanțului de aprovizionare TIC notează că auditorii examinează politicile de achiziții, șabloanele RFP și procesele de management al furnizorilor pentru a verifica dacă cerințele de securitate specifice TIC sunt integrate de la achiziție până la eliminare. Pentru managementul incidentelor, auditorii examinează planul de răspuns la incidente pentru completitudine și aliniere la bunele practici. Pentru revizuirea independentă, auditorii caută dovezi că au fost efectuate audituri sau revizuiri independente.

O perspectivă ISO/IEC 27007:2020 este mai specifică auditului SMSI. Zenith Controls notează că auditorii pot intervieva responsabili de achiziții, personal de securitate IT și manageri de furnizori pentru a evalua înțelegerea și executarea controalelor lanțului de aprovizionare TIC. Pentru pregătirea incidentelor, confirmă că există o echipă de răspuns la incidente și că aceasta este operațională. Pentru revizuirea independentă, verifică dacă programul de audit intern acoperă întregul domeniu de aplicare al SMSI și este dotat corespunzător cu resurse.

Un evaluator de testare informat de NIST SP 800-115 se va concentra pe metodologia de evaluări de vulnerabilitate și testare de penetrare. Poate examina dacă domeniul testului, regulile de angajament, constatările, ratingurile de severitate, remedierea și retestarea sunt documentate. Pentru DORA TLPT, aceasta înseamnă că evaluatorul nu va fi mulțumit cu un set de diapozitive red team. Va dori dovezi de guvernanță, siguranță, profunzime tehnică și închidere.

Un auditor de tip COBIT 2019 sau ISACA va întreba dacă obiectivele de guvernanță sunt îndeplinite: cine deține procesul, cum este măsurată performanța, cum sunt aprobate excepțiile și cum primește managementul asigurare.

Lista practică de verificare pentru pregătirea DORA 2026

Utilizați această listă de verificare ca bază de lucru pentru transformarea căutărilor DORA în acțiune.

Guvernanță și mapare RTS/ITS

• Mențineți un registru de conformitate DORA cu aria obligației, aplicabilitate, proprietar, dovezi, frecvența revizuirii și statutul lacunelor.
• Mapați cerințele DORA la politici, registre, controale și raportare către management.
• Definiți justificarea proporționalității pentru managementul simplificat sau scalat al riscurilor TIC, acolo unde este aplicabil.
• Atribuiți responsabilitate executivă pentru riscurile TIC, raportarea incidentelor, supravegherea terților și testare.
• Includeți statutul DORA în revizuirea de management și raportarea riscurilor către consiliul de administrație.

Managementul riscurilor TIC

• Mențineți un registru de riscuri TIC cu descriere, probabilitate, impact, scor, proprietar și plan de tratament.
• Legați riscurile de funcțiile critice sau importante.
• Legați riscurile de active TIC, furnizori și procese.
• Revizuiți riscurile după incidente majore, schimbări ale furnizorilor, schimbări tehnologice sau constatări ale testării.
• Urmăriți acțiunile de tratament până la închidere sau acceptarea formală a riscului.

Supravegherea terților furnizori de servicii TIC

• Mențineți un registru al furnizorilor și un registru al dependențelor față de furnizori.
• Identificați furnizorii care susțin funcții critice sau importante.
• Evaluați furnizorii unici și substituibilitatea.
• Revizuiți subcontractorii și relațiile de subexternalizare.
• Includeți în contracte clauze privind securitatea, accesul, raportarea incidentelor, auditul și ieșirea.
• Monitorizați furnizorii critici cel puțin anual sau după schimbări materiale.
• Mențineți planuri de ieșire și de contingență pentru furnizorii cu dependență ridicată.

Gestionarea și raportarea incidentelor

• Mențineți proceduri de gestionare a incidentelor cu roluri și căi de escaladare clare.
• Definiți criterii de clasificare a incidentelor TIC.
• Aliniați declanșatoarele de raportare DORA cu GDPR, NIS2 și obligațiile contractuale de notificare.
• Instruiți angajații și contractanții privind canalele de raportare a incidentelor.
• Mențineți jurnale ale incidentelor, înregistrări ale deciziilor și dovezi.
• Efectuați analize post-incident și actualizați riscurile și controalele.

Testare, red-teaming și TLPT

• Mențineți un calendar de testare bazat pe risc.
• Efectuați scanări de vulnerabilitate și testare de penetrare la intervale definite.
• Utilizați exerciții de tip red team bazate pe scenarii pentru a testa detecția și răspunsul.
• Pentru pregătirea TLPT, definiți domeniul de aplicare, regulile de angajament, controalele de siguranță și coordonarea furnizorilor.
• Protejați sistemele de producție în timpul testării.
• Urmăriți constatările, remedierea, retestarea și lecțiile învățate.
• Raportați rezultatele testării către management.

Continuitate și recuperare

• Efectuați anual BIA pentru unitățile de business critice și actualizați după schimbări semnificative.
• Definiți obiective de recuperare pentru funcțiile critice și serviciile TIC suport.
• Testați capabilitățile BCP și DR cel puțin anual.
• Includeți scenarii de indisponibilitate a furnizorilor și incidente cibernetice.
• Păstrați dovezile testelor, lacunele, acțiunile de remediere și rezultatele retestării.
• Aliniați planurile de continuitate cu răspunsul la incidente și comunicările de criză.

Cum ajută Clarysec entitățile financiare să treacă de la rezultate de căutare la dovezi pregătite pentru audit

Pregătirea DORA 2026 nu se obține descărcând o listă de verificare și sperând că organizația va completa lacunele mai târziu. Este necesar un model operațional structurat care conectează riscurile, furnizorii, incidentele, testarea, continuitatea și dovezile de audit.

Abordarea Clarysec combină trei straturi.

În primul rând, Zenith Blueprint oferă foaia de parcurs pentru implementare. Pasul 14 ajută organizațiile să creeze referințe încrucișate între cerințele de reglementare, tratamentul riscului și politici. Pasul 16 consolidează raportarea incidentelor de către personal. Pasul 21 asigură că auditurile și testele nu pun în pericol sistemele de producție. Pasul 23 transformă supravegherea furnizorilor într-un flux practic care acoperă clasificarea, contractele, subcontractorii, monitorizarea și evaluarea cloud.

În al doilea rând, politicile Clarysec oferă guvernanță gata de operaționalizare. Politica de management al riscurilor, Politica de conformitate juridică și de reglementare, Politica de securitate privind terții și furnizorii, Politica de management al riscului de dependență față de furnizori, Politica de răspuns la incidente, Politica de testare de securitate și red-teaming și Politica privind continuitatea activității și recuperarea în caz de dezastru oferă echipelor clauze concrete, modele de responsabilitate și așteptări privind dovezile.

În al treilea rând, Zenith Controls oferă harta de conformitate transversală. Arată cum securitatea lanțului de aprovizionare TIC, planificarea managementului incidentelor și revizuirea independentă se conectează la DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 și practicile de testare NIST.

Rezultatul este un program de conformitate DORA care este defensabil în audit și util în timpul unui incident real, al unui eșec al furnizorului sau al unui test de reziliență.

Pasul următor: construiți pachetul de dovezi DORA înainte de următoarea solicitare de audit

Dacă echipa dvs. încă mai caută „DORA RTS/ITS checklist”, „DORA ICT risk management template”, „DORA third-party oversight” sau „DORA TLPT requirements”, pasul următor este transformarea acestor căutări în dovezi controlate.

Începeți cu patru acțiuni în această săptămână:

1. Creați sau actualizați registrul de conformitate DORA folosind modelul de politici Clarysec.
2. Selectați o funcție critică și urmăriți-o prin registrul de riscuri, registrul dependențelor față de furnizori, fluxul de incident, BIA și planul de testare.
3. Revizuiți primii cinci furnizori TIC pentru substituibilitate, subcontractori, clauze privind incidentele și opțiuni de ieșire.
4. Construiți un pachet de dovezi pentru testare cu domeniu de aplicare, autorizare, rezultate, remediere și retestare.

Clarysec vă poate ajuta să implementați acest lucru utilizând Zenith Blueprint, șabloane de politici și Zenith Controls, astfel încât programul dvs. DORA 2026 să fie practic, proporțional și pregătit pentru audit.