Pregătirea pentru DORA a entităților financiare și a furnizorilor TIC

DORA se aplică din 17 ianuarie 2025. Pentru entitățile financiare, pregătirea înseamnă acum menținerea unui model operațional pentru reziliența operațională digitală, nu pregătirea pentru un termen viitor. Pentru furnizorii de tehnologie, înseamnă înțelegerea responsabilităților față de clienți și a faptului dacă li se aplică un regim separat de supraveghere directă.

Întrebarea pentru conducere este practică: poate organizația să explice ce servicii financiare depind de ce sisteme TIC, cum va fi gestionată o perturbare și ce dovezi susțin ipotezele sale de recuperare? Politicile contează, dar nu pot răspunde singure la această întrebare. Conducerea are nevoie de o imagine conectată a responsabilităților, dependențelor, contractelor, testelor, incidentelor și riscurilor nerezolvate.

Stabiliți-vă rolul înainte de a construi lista de verificare

Începeți cu o decizie documentată privind aplicabilitatea pentru fiecare entitate juridică relevantă. Articolul 2 din DORA identifică categoriile acoperite și excluderile. O companie care se descrie drept FinTech, startup sau IMM nu intră automat în domeniul de aplicare și nici nu este automat exceptată.

Exemple de entități financiare acoperite includ instituțiile de credit, instituțiile de plată, firmele de investiții și societățile de asigurare, sub rezerva regulilor detaliate privind domeniul de aplicare din regulament. Consemnați categoria aplicabilă, orice excludere sau exceptare, autoritatea competentă relevantă și raționamentul care stă la baza concluziei.

Pentru furnizori, distingeți trei poziții:

Un furnizor care sprijină o funcție financiară critică sau importantă nu este, doar din acest motiv, un furnizor terț critic de servicii TIC desemnat. Entitățile financiare evaluează importanța funcțiilor și dependențelor lor; desemnarea furnizorilor critici are loc prin cadrul de supraveghere prevăzut la articolul 31.

Locația nu tranșează chestiunea furnizorului. Un furnizor de cloud sau de software cu sediul în SUA se poate confrunta cu cerințe ale clienților legate de DORA atunci când deservește entități financiare din UE. Această relație comercială nu îl supune automat tuturor obligațiilor impuse unei entități financiare.

Și proporționalitatea necesită o evaluare motivată. Articolul 4 ia în considerare factori precum dimensiunea, profilul de risc general și natura, amploarea și complexitatea serviciilor. Articolul 16 prevede un cadru simplificat de gestionare a riscurilor TIC pentru anumite categorii. Acestea nu sunt concepte interschimbabile, iar statutul obișnuit de IMM nu este o scurtătură universală. Păstrați analiza eligibilității împreună cu decizia privind domeniul de aplicare.

Faceți vizibilă răspunderea conducerii

În temeiul articolului 5 din DORA, organul de conducere are responsabilitatea finală pentru gestionarea riscului TIC al entității financiare. Delegarea implementării către un CISO, o echipă de tehnologie sau un furnizor extern nu transferă această răspundere.

Conducerea ar trebui să stabilească cine propune deciziile, cine le aprobă și cine verifică dacă implementarea funcționează. Modelul operațional ar trebui să acopere continuitatea activității, răspunsul la incidente și recuperarea, aranjamentele cu terții, bugetul și cunoștințele necesare pentru o supraveghere reală.

O recomandare practică este să oferiți conducerii un pachet de raportare axat pe decizii, în locul unui dashboard cu procentul de finalizare. Includeți:

• Funcțiile critice sau importante cu ipoteze de recuperare netestate.
• Incidentele semnificative, efectele asupra clienților și acțiunile corective restante.
• Dependențele de furnizori cu contracte incomplete sau cu opțiuni de ieșire slabe.
• Lacunele semnificative în controale, responsabilii care răspund și termenele de remediere.
• Deciziile care necesită finanțare, schimbarea unui furnizor sau un răspuns explicit la risc.

Fiecare lacună ar trebui să distingă cerința de reglementare, slăbiciunea operațională actuală și remedierea propusă. O evidență de aprobare lipsă este diferită de un backup care nu poate fi restaurat. Ambele pot necesita acțiuni, dar au nevoie de responsabili și priorități diferite.

Aprobarea de către conducere a unui plan de remediere nu este o permisiune de a amâna pe termen nelimitat obligațiile aplicabile. Acolo unde o lacună este semnificativă, luați în considerare garanții imediate, escaladarea și eventualele implicații de supraveghere, alături de remedierea pe termen lung.

Construiți programul în jurul funcțiilor financiare

Un inventar al activelor este necesar, dar planificarea rezilienței ar trebui să înceapă cu serviciul care trebuie să continue. Identificați funcția financiară, responsabilul ei de business, consecințele perturbării și sistemele și furnizorii care o susțin.

Pentru un serviciu de plată, cartografiați identitatea, infrastructura cloud, procesarea tranzacțiilor, monitorizarea și escaladarea către furnizori. Includeți dependențele mai puțin vizibile, cum ar fi DNS, conectivitatea, accesul privilegiat, cheile de criptare și instrumentele de suport. Un mediu de producție alternativ poate fi inutilizabil dacă depinde de același serviciu de identitate căzut.

Harta rezultată ar trebui să lege fiecare funcție de:

• Aplicațiile, infrastructura, activele informaționale și serviciile externe care o susțin.
• Contractele relevante și responsabilii serviciilor.
• Obiectivele de recuperare și analiza impactului asupra activității care le susține.
• Aranjamentele de detectare, răspuns, recuperare și comunicare.
• Testele, constatările și riscurile nerezolvate legate de dependențe.

Validați harta împreună cu echipele operaționale și cu cele de business. Evidențele achizițiilor arată ce a fost cumpărat; ele nu arată neapărat cum funcționează un serviciu astăzi.

Folosiți acest model pentru a organiza gestionarea riscurilor TIC, gestionarea și raportarea incidentelor, testarea rezilienței și riscul TIC legat de terți. DORA conține și dispoziții privind schimbul voluntar de informații despre amenințările cibernetice. Dacă participați, definiți calitatea de membru, confidențialitatea, utilizarea permisă și regulile de tratare, în loc să considerați schimbul ca pe o transmitere nerestricționată de date despre incidente.

Transformați gestionarea riscurilor TIC în muncă finanțată

Dispozițiile DORA privind gestionarea riscurilor TIC acoperă identificarea, protecția și prevenirea, detectarea, răspunsul și recuperarea, învățarea și comunicarea. Cadrul trebuie să conecteze aceste activități, în loc să le lase drept colecții separate de politici.

Începeți analiza lacunelor cu funcțiile cartografiate. Întrebați dacă controalele de acces le protejează sistemele, dacă vulnerabilitățile sunt tratate, dacă modificările sunt controlate, dacă activitatea suspectă este detectată și dacă aranjamentele de recuperare reflectă defecțiuni realiste. Luați în considerare defecțiunile tehnice și greșelile operaționale, nu doar atacurile rău intenționate.

Pentru fiecare slăbiciune semnificativă, creați o evidență de remediere care conține un responsabil, impactul asupra activității, acțiunea necesară, criteriile de finalizare și dovezile închiderii. Dependențele contează: îmbunătățirea procedurilor de restaurare poate necesita modificări ale accesului la backupuri, ale angajamentelor furnizorilor și ale instruirii personalului înainte ca un test reușit să fie posibil.

Obiectivele de recuperare ar trebui să decurgă din nevoile de business și din analiza impactului, nu din nivelul standard de serviciu pe care se întâmplă să îl ofere un furnizor. Acolo unde capabilitatea tehnică nu poate atinge obiectivul, conducerea trebuie să decidă dacă îmbunătățește arhitectura, schimbă aranjamentul de servicii sau reconsideră modelul operațional. O țintă scrisă într-un plan de continuitate nu este o dovadă a capacității de recuperare.

Pregătiți deciziile privind incidentele înainte de perturbare

DORA impune entităților financiare să gestioneze incidentele legate de TIC și să raporteze incidentele majore autorității competente relevante. Articolele 17–23 stabilesc cadrul; standardele tehnice de reglementare și standardele tehnice de punere în aplicare aplicabile furnizează criteriile detaliate de clasificare, pragurile, conținutul raportărilor și procedurile.

Nu vă bazați pe o listă generică de verificare pentru incidente în privința calendarului detaliat de raportare. Mențineți o matrice de raportare actualizată care identifică standardele aplicabile, instrucțiunile autorității, canalul de transmitere, etapele raportării și modul de calcul al termenelor. Atribuiți responsabilitatea pentru menținerea ei la zi.

Procesul de răspuns ar trebui să facă executabile sub presiune mai multe decizii:

• Cine consemnează marcajele temporale ale detectării, evaluării și clasificării?
• Cine obține informațiile despre impact de la operațiuni și de la furnizori?
• Cine decide dacă sunt îndeplinite criteriile pentru un incident major?
• Cine aprobă și transmite raportările, inclusiv în afara programului normal de lucru?
• Cine se ocupă de comunicarea cu clienții și de alte notificări aplicabile?

Consemnați raționamentul clasificării chiar și atunci când un incident nu este raportat ca major. O imagine inițială incompletă ar trebui să declanșeze o reevaluare pe măsură ce informațiile evoluează, nu o presupunere permanentă că evenimentul este minor.

Angajamentele de notificare ale furnizorilor ar trebui să lase entității financiare suficient timp pentru a-și evalua și îndeplini propriile obligații. Sarcinile de raportare pot fi externalizate acolo unde este permis, dar responsabilitatea rămâne la entitatea financiară.

Atunci când un incident major legat de TIC afectează interesele financiare ale clienților, DORA impune entităților financiare să informeze acești clienți fără întârzieri nejustificate despre incident și despre măsurile luate pentru atenuarea efectelor sale negative. Evaluați separat obligațiile privind încălcarea securității datelor cu caracter personal și alte norme aplicabile. O singură perturbare poate genera mai multe decizii de notificare, cu destinatari și criterii juridice diferite.

Testați ipotezele pe care se bazează conducerea

Un program de testare a rezilienței operaționale digitale ar trebui să fie proporțional și bazat pe risc. Evaluările vulnerabilităților, exercițiile pe scenarii, testele de securitate și testele de recuperare răspund la întrebări diferite; niciunul nu ar trebui tratat ca substitut universal pentru celelalte.

Un exercițiu de simulare poate stabili dacă decidenții înțeleg escaladarea. El nu poate dovedi că datele tranzacțiilor pot fi restaurate corect. Un test de penetrare poate scoate la iveală slăbiciuni exploatabile fără a dovedi că un furnizor alternativ poate prelua un serviciu.

Pentru fiecare test, definiți funcția, scenariul, domeniul, criteriile de succes, aranjamentele de independență acolo unde sunt necesare și dovezile așteptate. Păstrați rezultatele, constatările, deciziile de remediere și rezultatele retestării. Verificați cerințele aplicabile privind acoperirea și frecvența în raport cu DORA și cu standardele relevante, inclusiv orice exceptări sau dispoziții privind cadrul simplificat.

Testarea de penetrare bazată pe amenințări este o cerință de supraveghere separată pentru anumite entități financiare în temeiul articolului 26. Ea nu este o obligație generală pentru orice business financiar sau furnizor TIC.

Conducerea ar trebui să analizeze ipotezele care s-au dovedit greșite, nu doar dacă testele au avut loc. Dacă un exercițiu arată că restaurarea depinde de un singur administrator indisponibil, rezultatul este un risc operațional care necesită acțiune, nu o etapă de testare finalizată.

Tratați riscul legat de terți ca pe o problemă de continuitate a serviciilor

În temeiul DORA, o entitate financiară rămâne responsabilă pentru obligațiile sale atunci când folosește furnizori TIC. Articolele 28–30 leagă evaluarea riscurilor legate de terți, aranjamentele contractuale, monitorizarea și planificarea ieșirii.

Mențineți registrul și imaginea operațională

Entitățile financiare trebuie să mențină un registru de informații privind aranjamentele contractuale TIC la nivelurile individual, subconsolidat și consolidat cerute. Folosiți standardele tehnice de punere în aplicare aplicabile pentru structura acestuia. O foaie de calcul de achiziții sau o listă de furnizori aprobați nu este automat suficientă.

Reconciliați registrul cu contractele, responsabilitatea pentru servicii și hărțile de dependențe. Mențineți distincțiile necesare pentru serviciile care susțin funcții critice sau importante. Un nou subcontractant, o nouă locație a serviciului sau un domeniu extins pot schimba imaginea riscului chiar dacă numele furnizorului rămâne același.

Analizați contractele în raport cu serviciul efectiv

Evaluați cerințele contractuale aplicabile, inclusiv descrierile serviciilor, locațiile, protecția datelor, accesul la date și recuperarea acestora, asistența în caz de incident, cooperarea, drepturile de reziliere și nivelurile de serviciu. Aranjamentele care susțin funcții critice sau importante necesită dispoziții suplimentare, inclusiv aranjamente relevante privind raportarea, continuitatea, accesul, inspecția, auditul și ieșirea.

Responsabilii din domeniul juridic, achiziții, tehnologie și business ar trebui să le analizeze împreună. Un drept contractual de audit poate fi greu de exercitat în practică; un aranjament de recuperare promis poate să nu acopere întregul lanț de servicii al clientului. Identificați aceste limitări înainte de a accepta aranjamentul.

Examinați concentrarea și capacitatea de ieșire

Riscul de concentrare nu se limitează la achiziția mai multor servicii de la o singură companie. Furnizori diferiți se pot baza pe aceeași platformă cloud, aceeași regiune, aceeași rețea sau același subcontractant. Evaluați substituibilitatea, complexitatea migrării și consecințele unei defecțiuni comune.

Un plan de ieșire ar trebui să trateze formatele de date, extragerea, accesul, dependențele migrării, sprijinul pe perioada tranziției, ștergerea și continuitatea pe durata mutării. Pentru funcțiile critice sau importante, tratați testarea și revizuirea ieșirii ca pe o muncă de fond, nu ca pe un exercițiu de redactare a unui document.

Furnizorii pot pregăti un pachet de asigurare consecvent care să conțină domeniul serviciului, limitele responsabilităților, contactele pentru incidente, dovezile de continuitate, informațiile despre subcontractare și pozițiile contractuale. Cerințele specifice ale clienților trebuie totuși analizate; un certificat nu le înlocuiește.

Înțelegeți unde se întâlnesc DORA și NIS2

DORA este un regulament al UE cu aplicabilitate directă. NIS2 este o directivă transpusă prin legislația națională, a cărei aplicabilitate depinde de sector, dimensiune, serviciu și regulile de includere. Termenul său de transpunere națională a fost 17 octombrie 2024; organizațiile trebuie să examineze legislația națională de transpunere aplicabilă, în loc să presupună un singur regim operațional identic.

Articolul 1 alineatul (2) din DORA, împreună cu articolul 4 din NIS2, stabilește relația sectorială specifică pentru entitățile financiare acoperite în domeniile relevante. Nu interpretați acest lucru ca pe o instrucțiune de a duplica controale echivalente de gestionare a riscurilor și de raportare a incidentelor. La fel, nu presupuneți că el elimină obligațiile pentru fiecare companie dintr-un grup financiar sau din lanțul său de aprovizionare.

Un furnizor de servicii gestionate care deservește o bancă poate avea nevoie de propria evaluare NIS2, respectând în același timp angajamentele contractuale legate de DORA. O matrice a obligațiilor pe fiecare entitate ar trebui să consemneze temeiul juridic, domeniul de aplicare, autoritatea, calea de raportare și dovezile necesare.

Controalele comune pot sprijini DORA, ISO 27001, obligațiile privind protecția datelor și asigurarea față de clienți acolo unde domeniul și dovezile corespund. Reutilizați o revizuire a accesului sau un test de recuperare atunci când susține cu adevărat mai multe cerințe, păstrând detaliile specifice sectorului financiar. Un certificat ISO 27001 nu stabilește conformitatea cu DORA.

Și aplicarea diferă. Competențele de supraveghere și sancțiunile DORA pentru entitățile financiare depind de dispozițiile sale și de măsurile naționale aplicabile; furnizorii critici desemnați au un regim de supraveghere separat. Nu vă planificați bugetul pentru riscuri în jurul unei presupuse amenzi DORA universale. Evaluați expunerea juridică relevantă și consecințele operaționale ale unei reziliențe inadecvate.

Exemplu practic: revizuirea dependențelor unui serviciu de plată

Să luăm o instituție de plată ilustrativă care folosește o platformă cloud, un furnizor de identitate și un serviciu de monitorizare externalizat. Să presupunem că instituția intră în domeniul de aplicare DORA și că executarea plăților este clasificată drept funcție critică sau importantă.

Prima revizuire constată trei slăbiciuni: mediile de producție și de recuperare au aceeași dependență de identitate; procesul de escaladare a incidentelor al furnizorului de monitorizare este neclar; iar planul de ieșire din cloud menționează un furnizor alternativ fără a demonstra extragerea și migrarea datelor.

Conducerea comandă trei pachete de lucru legate între ele:

Responsabilul de business verifică dacă obiectivele de recuperare a plăților rămân realizabile. Conformitatea verifică dacă procedurile de raportare și înregistrările din registru reflectă aranjamentele. Conducerea aprobă finanțarea necesară și analizează limitările rămase.

Acest exemplu nu stabilește prin el însuși conformitatea. El arată cum o singură funcție poate scoate la iveală decizii care ar rămâne ascunse în liste de verificare separate pentru politici, furnizori și testare.

Stabiliți un ritm de revizuire bazat pe dovezi

DORA nu are un proces universal de certificare care să înlocuiască obligațiile continue. Asigurarea independentă poate informa conducerea, dar pregătirea trebuie demonstrată prin controale funcționale, evidențe și, acolo unde este necesar, prin interacțiunea cu autoritățile de supraveghere.

Un pas următor practic este să alegeți o funcție critică sau importantă și să reuniți decizia privind domeniul de aplicare, harta dependențelor, evaluarea riscurilor, contractele, procedurile privind incidentele, rezultatele testelor și acțiunile deschise. Analizați dacă aceste evidențe spun o poveste coerentă.

Secani sprijină acest flux de lucru prin modelarea sistemelor și serviciilor, conectarea dependențelor și păstrarea în context a cerințelor, dovezilor, responsabililor, sarcinilor și deciziilor de revizuire. Încărcați materialele existente în raport cu obiectele relevante, transformați lacunele în sarcini atribuite și păstrați aprobarea umană explicită pentru sugestiile și concluziile asistate de IA.

Extindeți-vă pornind de la această primă funcție după ce responsabilitățile și traseele dovezilor sunt clare. Conducerea ar trebui să poată vedea ce a fost demonstrat, ce rămâne incert și ce decizie este necesară în continuare.