Modelarea amenințărilor pentru ISO 27001, NIS2 și DORA

Anya, CISO al unei companii fintech cu creștere rapidă, a fost rugată să aprobe planul de lansare pentru o nouă platformă B2B de evaluare a riscului de plată. Consiliul de administrație dorea intrarea pe piață înainte de sfârșitul trimestrului. Echipa de vânzări avea deja clienți bancari pregătiți. Inginerii schițaseră o arhitectură nativă cloud, cu atribute de identitate, semnale de la dispozitive, metadate ale tranzacțiilor, scoruri comportamentale de risc, o bază de date administrată și un furnizor terț de analiză.

Pe hârtie, platforma părea o reușită comercială majoră. Pentru Anya, părea cinci discuții de conformitate care ajungeau simultan la scadență.

Ca furnizor de tehnologie financiară, compania era sub presiunea DORA. Ca furnizor de servicii cloud și platformă digitală, trebuia să își înțeleagă expunerea în raport cu NIS2. Pentru că platforma prelucra date cu caracter personal ale unor persoane din UE, se aplica GDPR. Clienții enterprise se așteptau la certificare ISO/IEC 27001:2022. Dacă serviciul devenea parte a unui produs software conectat, cerințele din Actul privind reziliența cibernetică urmau să adauge dovezi de securitate prin proiectare la nivel de produs.

Echipa de dezvoltare a propus planul de securitate obișnuit: scanarea dependențelor, rularea unei scanări de vulnerabilități, programarea unui test de penetrare și remedierea constatărilor critice înainte de intrarea în producție. Anya știa că nu era suficient. Aceste activități testează ceea ce a fost deja construit. Ele nu demonstrează că arhitectura a fost securizată prin proiectare, că limitele de încredere au fost înțelese, că fluxurile de date cu caracter personal au fost minimizate, că ipotezele privind furnizorii au fost revizuite sau că scenariile de întrerupere a serviciului au fost analizate înainte de lansare.

Prin urmare, a întrerupt ritmul ședinței cu patru întrebări:

1. Unde sunt limitele de încredere?
2. Ce cazuri de abuz ar putea duce la fraudă, expunerea datelor sau întreruperea serviciului?
3. Ce decizii de proiectare reduc riscul înainte de scrierea codului?
4. Ce dovezi vor satisface evaluatorii ISO 27001, NIS2, DORA, CRA și GDPR peste șase luni?

A patra întrebare este punctul în care multe organizații eșuează. Modelarea amenințărilor este tratată adesea ca un atelier tehnic util, apoi îngropată într-o pagină wiki. În 2026, acest lucru nu mai este suficient. Pentru furnizorii SaaS, companiile fintech, platformele cloud, MSP, MSSP, operatorii de infrastructură digitală și producătorii de software, modelarea amenințărilor a devenit un motor de generare a dovezilor de conformitate.

Un proces matur de modelare a amenințărilor transformă constatările STRIDE, cazurile de abuz și deciziile de arhitectură în înregistrări în Registrul de riscuri, cerințe de securitate, planuri de tratare a riscurilor, cazuri de testare, sarcini de asigurare privind furnizorii, dovezi de protecție a datelor încă din faza de proiectare și trasabilitate în Declarația de aplicabilitate.

De ce contează acum dovezile de securitate prin proiectare

Reglementările moderne converg către aceeași așteptare: organizațiile trebuie să identifice din timp riscurile de securitate și de confidențialitate, să atribuie responsabilități, să implementeze controale proporționale și să păstreze dovezi.

ISO/IEC 27001:2022 impune un Sistem de management al securității informației bazat pe risc. Clauzele 6.1.2 și 6.1.3 cer evaluarea riscurilor de securitate a informației și tratarea riscurilor. Clauza 8.1 cere planificare și control operațional. Anexa A oferă controale care trebuie selectate prin Declarația de aplicabilitate, pe baza riscului, a cerințelor legale și a nevoilor organizației.

NIS2 aduce același principiu în guvernanța securității cibernetice. Article 20 cere organelor de conducere să aprobe măsurile de management al riscurilor de securitate cibernetică și să supravegheze implementarea acestora. Article 21 cere măsuri tehnice, operaționale și organizaționale adecvate și proporționale, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, securitatea în achiziție, dezvoltare și mentenanță, gestionarea vulnerabilităților, igiena cibernetică, criptarea, controlul accesului, managementul activelor și MFA, acolo unde este adecvat.

DORA aplică, de la 17 ianuarie 2025, o perspectivă de reziliență operațională specifică sectorului financiar. Aceasta cere entităților financiare acoperite să mențină un cadru de management al riscurilor TIC solid, cuprinzător și documentat, să identifice activele TIC și dependențele, să aplice măsuri de protecție și controale preventive, să detecteze activități anormale, să testeze reziliența operațională digitală, să gestioneze riscul asociat terților furnizori de servicii TIC și să pregătească capabilități de răspuns și recuperare. Pentru entitățile financiare acoperite, DORA este actul juridic sectorial al Uniunii pentru obligațiile NIS2 care se suprapun.

GDPR adaugă responsabilitatea și protecția datelor încă din faza de proiectare și în mod implicit. Orice sistem care prelucrează date cu caracter personal trebuie să poată demonstra o prelucrare legală, echitabilă, transparentă, limitată la scop, minimizată, limitată ca durată de stocare și securizată. Un model de amenințări care mapează fluxurile de date cu caracter personal, căile de acces, jurnalele, retenția, ștergerea și transferurile către terți este direct relevant pentru GDPR Articles 5, 25, 32 și 35.

Actul privind reziliența cibernetică adaugă presiune pentru produsele cu elemente digitale. Echipele de produs au nevoie de dovezi pe tot ciclul de viață care să arate că riscurile de securitate cibernetică, utilizarea abuzivă previzibilă, interfețele, mecanismele de actualizare, fluxurile de autentificare și ipotezele privind gestionarea vulnerabilităților au fost analizate din timp.

Lecția este clară: dacă o revizuire a arhitecturii nu poate fi trasată către riscuri, controale, responsabili, măsuri de atenuare și teste, va fi dificil de susținut într-un audit sau într-o revizuire de reglementare în 2026.

Modelul Clarysec: un singur model de amenințări, mai multe rezultate

Abordarea Clarysec pornește de la un principiu practic: un model de amenințări nu este complet până când nu produce decizii auditabile.

În Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului [ZB], faza de management al riscurilor, pasul 9, oferă echipelor un format simplu pentru conversia observațiilor tehnice în limbaj de risc:

„Acum combinați activul + amenințarea + vulnerabilitatea într-o descriere concisă a scenariului de risc. În esență, descrieți incidentul potențial. Acesta va deveni ulterior o linie în Registrul de riscuri. Folosiți un format simplu: «[Amenințarea] exploatează [vulnerabilitatea] pe [activ], ceea ce duce la [impact].»”

Această propoziție este puntea dintre inginerie și conformitate.

O notă de pe tablă, precum „risc de uzurpare a identității prin API-ul partenerului”, devine:

„Un atacator exploatează autentificarea slabă a API-ului partenerului pe API-ul de risc al tranzacțiilor, ceea ce duce la acces neautorizat la deciziile privind riscul de plată și la expunerea datelor cu caracter personal.”

Acum constatarea are un activ, o amenințare, o vulnerabilitate și un impact. Poate fi evaluată, atribuită, tratată, testată și acceptată.

Stratul de politici face acest proces repetabil. P24 Politica de dezvoltare securizată [P24] prevede:

„Toate aplicațiile noi și schimbările majore trebuie să treacă prin revizuirea arhitecturii de securitate și modelarea amenințărilor înainte de începerea dezvoltării.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.

Aceasta cere, de asemenea:

„Revizuirile de proiectare trebuie să documenteze diagramele de flux de date, limitele de încredere și măsurile de atenuare pentru riscurile identificate.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.2.

Aceste două clauze sunt repere puternice pentru audit. Ele arată că modelarea amenințărilor nu este opțională și că dovezile de proiectare trebuie să includă diagrame, limite și decizii de atenuare.

P06 Politica de management al riscurilor [P06] conectează modelarea amenințărilor la managementul riscurilor la nivelul organizației:

„Toate unitățile de business trebuie să identifice proactiv riscurile folosind tehnici structurate derivate din ISO/IEC 27005:2024, inclusiv modelarea amenințărilor, cartografierea dependențelor activelor și identificarea bazată pe scenarii.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.

Aceasta mai prevede:

„Riscurile identificate trebuie documentate prin referire la proprietarul activului, actorul de amenințare, vulnerabilitatea și impactul potențial asupra confidențialității, integrității și disponibilității (CIA).”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.4.

Acesta este lanțul de dovezi pe care auditorii vor să îl vadă: cerință de politică, activitate de proiectare, scenariu de risc, selectarea controalelor, implementare, testare și aprobare.

STRIDE asigură acoperirea sistematică, cazurile de abuz o fac realistă

STRIDE rămâne una dintre cele mai utile metode pentru modelarea amenințărilor în etapa de proiectare, deoarece obligă echipele să ia în considerare șase moduri comune de eșec:

• Uzurparea identității
• Alterarea
• Repudierea
• Divulgarea informațiilor
• Refuzul serviciului
• Escaladarea privilegiilor

Pentru platforma de risc al plăților a Anyei, echipa a folosit STRIDE pentru fiecare componentă, flux de date și limită de încredere.

Uzurparea identității a ridicat întrebarea dacă un client API al unui partener ar putea imita un client bancar atunci când autentificarea mutuală este slabă. Alterarea a evidențiat riscul ca semnalele de la dispozitive sau valorile tranzacțiilor să fie manipulate înainte de ingestie. Repudierea a evidențiat necesitatea jurnalelor de audit pentru administratori și tranzacții. Divulgarea informațiilor s-a concentrat pe scurgeri prin jurnale, exporturi către instrumente de analiză, instrumente de suport și API-uri de raportare. Refuzul serviciului a obligat echipa să analizeze ferestrele de vârf ale tranzacțiilor și avalanșele de cereri malformate. Escaladarea privilegiilor a expus riscuri în rolurile de suport, token-urile de sesiune și funcțiile administrative.

Cazurile de abuz au transformat aceste categorii în scenarii reale:

• Un fraudator încarcă semnale manipulate de la dispozitive pentru a influența un scor de risc.
• O credențială de partener compromisă inundă API-ul cu cereri frauduloase.
• Un dezvoltator folosește date cu caracter personal din producție într-un mediu de testare.
• O persoană internă rău-intenționată exportă identificatori ai clienților și logica de scorare.
• Indisponibilitatea unui furnizor cloud de analiză blochează deciziile de risc în timpul unei ferestre de plată.
• O configurare greșită a spațiului de stocare expune documente de identitate încărcate.
• Un flux de ștergere elimină înregistrarea aplicației, dar păstrează backup-uri și copii la furnizori.

Fiecare caz de abuz a devenit o înregistrare de risc de proiectare, cu activul afectat, actorul de amenințare, vulnerabilitatea, impactul, ipotezele existente, măsura de atenuare necesară, responsabilul pentru riscul rezidual, dovezile de testare și relevanța de reglementare.

Această structură previne constatările vagi, precum „risc de securitate API”. Ea produce enunțuri de risc la nivel de dovadă, precum:

„Un atacator folosește credențiale de partener furate pentru a transmite cereri frauduloase de scorare prin API-ul de risc al tranzacțiilor, ceea ce duce la compromiterea integrității deciziilor de risc, la posibile pierderi financiare pentru clienți și la prelucrarea neautorizată a datelor cu caracter personal.”

Maparea modelării amenințărilor la ISO/IEC 27001:2022 și ISO/IEC 27002:2022

ISO/IEC 27001:2022 nu impune explicit modelarea amenințărilor sub această denumire. Impune evaluarea riscurilor și tratarea riscurilor într-un mod consecvent și documentat. Modelarea amenințărilor este una dintre cele mai solide metode de generare a acestor dovezi în medii software, cloud și de produs.

Cheia este trasabilitatea. În ZB, faza de management al riscurilor, pasul 13, recomandă maparea controalelor la riscuri și clauze, inclusiv referințe la Anexa A în planurile de tratare a riscurilor, precum și notarea situațiilor în care controalele susțin GDPR, NIS2 sau DORA.

Zenith Controls: ghidul de conformitate încrucișată [ZC] ajută la structurarea acestei trasabilități prin maparea controalelor ISO/IEC 27002:2022 la controale conexe, așteptări de audit și cadre externe.

Pentru modelarea amenințărilor, controlul ISO/IEC 27002:2022 5.8, securitatea informației în managementul proiectelor, este reperul de guvernanță a proiectului. El arată că securitatea este integrată în inițierea, planificarea, execuția și acceptarea proiectului.

Controlul 8.25, ciclul de viață al dezvoltării securizate, este reperul pentru SDLC. ZC conectează 8.25 la controale de susținere, precum 8.26 cerințe de securitate ale aplicațiilor, 8.27 arhitectură de sistem securizată și principii de inginerie, 8.28 programare securizată, 8.29 testare de securitate în dezvoltare și acceptare, 8.30 dezvoltare externalizată și 8.31 separarea mediilor de dezvoltare, testare și producție.

Această mapare ajută la transformarea unui atelier de proiectare în dovezi pentru Declarația de aplicabilitate. Ea susține și clauzele 4-6 din ISO/IEC 27001:2022, deoarece cerințele părților interesate, domeniul de aplicare al SMSI, angajamentele conducerii și deciziile de tratare a riscurilor sunt vizibile.

O hartă de conformitate încrucișată pentru NIS2, DORA, CRA, GDPR și NIST CSF

Un model de amenințări bine realizat nu ar trebui să producă cinci fluxuri de lucru de conformitate separate. Ar trebui să producă un singur pachet de dovezi privind riscurile de proiectare, reutilizabil în mai multe cadre.

NIST CSF 2.0 este deosebit de util pentru comunicarea cu conducerea executivă. Funcția GOVERN susține obligațiile legale, de reglementare, contractuale și de protecție a datelor, iar rezultatele privind lanțul de aprovizionare ajută la conectarea criticității furnizorilor, cerințelor contractuale, revizuirilor de due diligence, monitorizării și planificării incidentelor la aceleași dovezi din modelul de amenințări.

GDPR necesită atenție specială, deoarece modelarea amenințărilor și activitatea DPIA trebuie să se susțină reciproc. P17 Politica de protecție a datelor și confidențialitate [P17] prevede:

„Modelarea amenințărilor și evaluările impactului asupra protecției datelor (DPIA) sunt obligatorii pentru sistemele de prelucrare cu risc ridicat.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.4.

Pentru echipe mai mici, P17S Politica de protecție a datelor și confidențialitate - IMM [P17S] prevede:

„Protecția datelor încă din faza de proiectare și în mod implicit trebuie aplicată în toate sistemele și serviciile noi”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.1.

Rezultatul este un model operațional practic: folosiți aceleași diagrame de flux de date, limite de încredere și cazuri de abuz pentru riscul de securitate, riscul privind confidențialitatea, revizuirea furnizorilor și dovezile de reglementare.

Un sprint de 90 de minute privind riscul de proiectare pentru funcționalități cu risc ridicat

Modelarea amenințărilor nu trebuie să înceapă ca un program amplu. Pentru un API nou de plăți, un flux de integrare, o funcționalitate cu IA, un serviciu de identitate, o migrare către cloud sau o integrare externă, un sprint de 90 de minute privind riscul de proiectare poate produce dovezi valoroase.

1. Deschideți un punct de control de securitate al proiectului

Folosiți clauza 6.1.1 din P24 drept declanșator. Pentru fiecare aplicație nouă sau schimbare majoră, creați un dosar de dovezi care să includă:

• Diagramă de arhitectură
• Diagramă de flux de date
• Hartă a limitelor de încredere
• Listă de active
• Note privind datele cu caracter personal
• Listă de furnizori și dependențe TIC
• Cerințe inițiale de securitate
• Fișă de lucru pentru modelul de amenințări
• Înregistrări în Registrul de riscuri
• Trasabilitatea măsurilor de atenuare și a testelor
• Înregistrare de aprobare

Pentru organizații mai mici, P24S Politica de dezvoltare securizată - IMM [P24S] susține aceeași disciplină prin corelarea proceselor de dezvoltare securizată cu controlul accesului dezvoltatorilor, testarea, modelarea amenințărilor și documentația. Aceasta cere, de asemenea, păstrarea centralizată a listelor de verificare, aprobărilor rezultate din revizuire, rapoartelor de testare și inventarelor de componente în scop de audit. Clauza 11.3.1 face trimitere la SA-3 până la SA-15 pentru definirea proceselor de dezvoltare securizată, inclusiv modelarea amenințărilor.

2. Desenați fluxul minim viabil de date

Nu începeți cu o diagramă finisată. Începeți cu fluxurile care generează risc:

• Utilizatorul încarcă documente de identitate sau date despre tranzacții.
• Aplicația web trimite cereri către API.
• API-ul scrie în spații de stocare administrate sau într-o bază de date.
• Furnizorul primește date de verificare sau de analiză.
• Portalul intern al analiștilor afișează rezultatele.
• Sistemul clientului recuperează starea sau deciziile.
• Jurnalele, instrumentele de monitorizare și backup-urile primesc copii.

Marcați fiecare limită de încredere: internet către aplicație, aplicație către API, serviciu intern către furnizor, sistem de producție către analiză, administrator către funcție privilegiată și producție către mediu neproductiv.

3. Rulați împreună STRIDE și cazurile de abuz

Pentru fiecare limită, adresați întrebările STRIDE și scrieți cazuri de abuz într-un limbaj operațional clar. Scopul nu este să listați orice atac imaginabil. Scopul este să identificați scenarii plauzibile și semnificative care afectează confidențialitatea, integritatea, disponibilitatea, protecția datelor, reziliența sau siguranța.

4. Convertiți constatările în scenarii de risc

Folosiți formula de la pasul 9 din ZB:

„[Amenințarea] exploatează [vulnerabilitatea] pe [activ], ceea ce duce la [impact].”

De exemplu:

„Un atacator exploatează controale slabe de acces la stocarea de obiecte asupra depozitului de documente de identitate, ceea ce duce la divulgarea neautorizată a datelor cu caracter personal și la expunere la obligații de notificare reglementară.”

Apoi adăugați responsabilul, probabilitatea, impactul, riscul inerent, opțiunea de tratament, controlul-țintă, riscul rezidual și dovezile.

5. Derivați cerințe și teste

Un model de amenințări nu este finalizat atunci când riscurile sunt listate. Este finalizat atunci când măsurile de atenuare sunt implementate, testate sau acceptate formal.

Politica de management al schimbărilor - IMM oferă un declanșator practic:

„Dacă o schimbare implică date sensibile, drepturi de acces la sistem sau integrări externe, este necesară o revizuire a impactului asupra securității. Contactul desemnat pentru securitate sau conformitate trebuie să evalueze dacă schimbarea introduce riscuri suplimentare și să recomande măsuri suplimentare de protecție.”
Din secțiunea „Tratamentul riscului și excepții”, clauza de politică 7.5.1.

Datele sensibile, drepturile de acces și integrările externe sunt exact schimbările care impun revizuirea riscului de proiectare.

Ce vor întreba diferiți auditori

Un auditor ISO/IEC 27001:2022 va întreba dacă modelarea amenințărilor face parte dintr-un proces definit de evaluare a riscurilor, dacă criteriile sunt consecvente, dacă proprietarii de risc au aprobat riscurile reziduale, dacă planurile de tratament sunt corelate cu SoA și dacă dovezile sunt păstrate. Va căuta repetabilitate, istoric al versiunilor, vizibilitate în analiza efectuată de management și acoperire prin audit intern.

Pentru Anexa A, auditorul va conecta dovezile la 5.8, 8.25, 8.26, 8.27 și 8.29. Pasul 21 din ZB, controale în practică, evidențiază arhitectura de sistem securizată și principiile de inginerie, întrebând ce principii ghidează arhitectura securizată. Auditorii pot întreba dacă modelarea amenințărilor este realizată în etapa de proiectare folosind metode precum STRIDE sau arbori de atac și dacă deciziile de arhitectură sunt revizuite înainte de implementare.

Un evaluator NIS2 se va concentra pe guvernanță și proporționalitate. Poate întreba dacă managementul a aprobat abordarea de management al riscurilor de securitate cibernetică, dacă achiziția, dezvoltarea și mentenanța securizate sunt acoperite, dacă vulnerabilitățile furnizorilor sunt luate în considerare, dacă scenariile de incident sunt corelate cu fluxurile de raportare și dacă scenariile de continuitate sunt analizate. Raportarea etapizată din NIS2 Article 23 pentru incidente semnificative, inclusiv avertizarea timpurie în termen de 24 de ore, notificarea în termen de 72 de ore și raportul final în termen de o lună, face claritatea scenariilor deosebit de valoroasă.

Un examinator DORA se va concentra pe guvernanța riscurilor TIC, funcțiile critice, activele TIC, dependențele externe, testarea rezilienței și serviciile TIC furnizate de terți. Dacă sistemul susține o funcție critică sau importantă, se va aștepta la dovezi mai solide care leagă scenariile de amenințare de inventarele de active, hărțile de dependență, planurile de testare, contractele cu terții și măsurile de recuperare.

Un evaluator de confidențialitate va analiza fluxurile de date și va întreba dacă prelucrarea datelor cu caracter personal este necesară, legală, minimizată și protejată. Va întreba dacă sunt implicate categorii speciale de date, dacă se utilizează pseudonimizare sau criptare, dacă retenția este justificată și dacă este necesară o DPIA. Modelarea amenințărilor și DPIA sunt activități diferite, dar ar trebui să partajeze diagrame, scenarii și măsuri de atenuare.

Un evaluator orientat spre NIST CSF sau COBIT 2019 va căuta guvernanță, deținerea procesului, performanță, responsabilitate și îmbunătățire continuă. Este posibil să fie mai puțin interesat de fișa STRIDE în sine și mai mult de faptul că procesul este fiabil, măsurat, aprobat și îmbunătățit.

Eșecuri frecvente ale dovezilor din modelarea amenințărilor

Cele mai frecvente eșecuri nu sunt tehnice. Sunt eșecuri ale dovezilor.

Echipele realizează modelarea amenințărilor prea târziu, după ce sistemul a fost deja construit. În acel moment, atelierul devine o informare înainte de testul de penetrare, nu un control de proiectare.

Constatările nu sunt convertite în limbaj de risc. „Adăugați auth” sau „problemă de jurnalizare” îi pot ajuta pe ingineri, însă auditorii au nevoie de activ, amenințare, vulnerabilitate, impact, proprietar, tratament și risc rezidual.

Confidențialitatea și securitatea sunt separate. O echipă documentează riscuri de uzurpare a identității și injectare, în timp ce alta documentează retenția și temeiul juridic. Responsabilitatea impusă de GDPR funcționează mai bine atunci când fluxurile de date, cazurile de abuz și declanșatorii DPIA sunt conectați.

Ipotezele privind furnizorii rămân nedocumentate. NIS2, DORA și NIST CSF ridică toate așteptările pentru riscul asociat lanțului de aprovizionare TIC. Dacă o măsură de atenuare depinde de criptarea, jurnalizarea, ștergerea, reziliența sau răspunsul la incidente ale unui furnizor, colectați dovezile.

Testele nu sunt mapate înapoi la amenințări. Un raport de testare de penetrare poate fi util, dar este posibil să nu demonstreze că riscurile specifice de proiectare au fost atenuate. Fiecare constatare majoră privind amenințările ar trebui să aibă dovezi de validare.

Acceptarea riscului rezidual este informală. „Acceptăm acest lucru pentru MVP” nu este suficient. ISO/IEC 27001:2022 așteaptă acceptarea riscului rezidual de către proprietarii de risc adecvați, ca informații documentate.

Pachetul dumneavoastră de dovezi pentru modelarea amenințărilor în 2026

Pentru fiecare sistem major sau schimbare semnificativă, păstrați un pachet standard de dovezi care poate susține ISO 27001, NIS2, DORA, CRA, GDPR și programe de asigurare solicitate de clienți.

Politica de management al riscurilor - IMM surprinde bine modelul operațional:

„Aceasta asigură că managementul riscurilor este o componentă activă a planificării, execuției proiectelor, selecției furnizorilor și răspunsului la incidente, în aliniere cu ISO 27001, ISO 31000 și cerințele de reglementare aplicabile.”
Din secțiunea „Scop”, clauza de politică 1.2.

Acesta este obiectivul corect. Modelarea amenințărilor trebuie să influențeze planificarea, ingineria, selecția furnizorilor, răspunsul la incidente și pregătirea pentru audit.

Pregătiți modelarea amenințărilor pentru audit înainte de următoarea lansare

Organizațiile care vor gestiona cel mai bine presiunea de conformitate din 2026 nu sunt cele cu cele mai multe diagrame. Sunt cele care pot demonstra un lanț simplu:

Riscul de proiectare a fost identificat. Riscul a fost evaluat. Controalele au fost selectate. Măsurile de atenuare au fost implementate. Testele au validat măsurile de atenuare. Riscul rezidual a fost aprobat. Dovezile sunt mapate la cadrele relevante.

Începeți cu o singură schimbare cu risc ridicat: o integrare de plăți, un API nou, un flux de lucru cu IA, o funcționalitate de identitate, o migrare către cloud, o lansare de produs destinată clienților sau un serviciu conectat la furnizori. Rulați un sprint de 90 de minute privind riscul de proiectare. Folosiți ZB pentru a converti constatările în scenarii de risc, planuri de tratament și trasabilitate SoA. Folosiți ZC pentru a mapa controalele ISO/IEC 27002:2022, precum 5.8, 8.25, 8.26, 8.27 și 8.29, la controale de susținere, risc asociat furnizorilor, confidențialitate, testare și dovezi de audit. Aliniați P24, P06, P17, P24S și procedura de management al schimbărilor astfel încât modelarea amenințărilor să devină obligatorie, repetabilă și verificabilă.

Dacă doriți sprijin din partea Clarysec, începeți cu o revizuire a dovezilor de modelare a amenințărilor. Vom evalua un proiect real, vom identifica lacunele față de așteptările ISO/IEC 27001:2022, NIS2, DORA, CRA și GDPR și vă vom oferi o foaie de parcurs practică pentru remediere, pe care inginerii, auditorii și consiliul de administrație o pot înțelege.