Guvernanța proiectelor TIC bazată pe securitate prin proiectare în 2026
Proiectul era în grafic, până când auditul a pus o singură întrebare
CISO al unei companii de tehnologie pentru plăți, aflată în creștere rapidă, avea vești bune pentru consiliul de administrație. Noua platformă de onboarding al clienților era pregătită pentru lansare. Echipa de produs livrase experiența mobilă, echipa de inginerie integrase verificarea identității, departamentul juridic semnase contractele cu furnizorii cloud și API, iar echipa de operațiuni repetase planul de trecere în producție.
Apoi auditorul intern a pus o întrebare simplă:
„Arătați-mi unde au fost analizate securitatea și confidențialitatea în fiecare etapă a proiectului.”
În sala de proiect s-a făcut liniște.
Exista un raport de testare de penetrare, dar fusese realizat târziu. Exista o diagramă de arhitectură cloud, dar nu exista nicio dovadă că fluxurile de date fuseseră revizuite în raport cu principiile GDPR. Exista un chestionar de verificare prealabilă a furnizorilor, dar nu fusese corelat cu registrul riscurilor. Exista un tichet de schimbare pentru implementarea în producție, dar aprobarea nu menționa impactul asupra serviciilor critice, raportarea incidentelor, testarea rezilienței, notificarea clienților sau escaladarea unei încălcări a securității datelor cu caracter personal. Existau note de sprint, dar cerințele de securitate erau dispersate în povești de utilizator și mesaje de chat.
Nimic nu părea evident neglijent. Totul arăta ca un proiect TIC modern, derulat într-un ritm intens. Dar, pentru o entitate financiară supusă DORA, un furnizor SaaS potențial aflat în domeniul de aplicare al NIS2 și un operator de date sau o persoană împuternicită în temeiul GDPR, problema nu mai era doar dacă securitatea exista. Problema era dacă securitatea prin proiectare putea fi demonstrată.
Aceasta este problema anului 2026. Proiectele TIC nu mai sunt evaluate doar după viteza de livrare, controlul costurilor și calitatea tehnică. Sunt evaluate pe baza dovezilor de guvernanță: evaluări ale riscurilor, decizii de proiectare, verificarea prealabilă a furnizorilor, înregistrări de dezvoltare securizată, aprobări ale schimbărilor, decizii privind confidențialitatea, rezultatele testelor și supravegherea conducerii.
ISO/IEC 27001:2022 oferă organizațiilor o structură practică de sistem de management pentru rezolvarea acestei probleme. Ajută CISO, managerii de conformitate, sponsorii de proiect, DPO, arhitecții, echipele de achiziții și auditorii să transforme proiectele TIC semnificative în dovezi justificabile de securitate prin proiectare.
De ce guvernanța proiectelor TIC este acum o problemă de dovezi de reglementare
O migrare în cloud, un portal pentru clienți, o platformă de plăți, o implementare CRM, o schimbare de furnizor de identitate, un flux de analiză, o integrare API, un flux de lucru SaaS, o aplicație low-code sau o tranziție către un serviciu administrat pot modifica profilul de risc al organizației. În 2026, aceste schimbări au loc sub obligații suprapuse.
NIS2 se aplică pe scară largă entităților esențiale și importante din sectoarele Anexei I și Anexei II, inclusiv infrastructurii digitale, furnizorilor de servicii administrate, furnizorilor de servicii de securitate administrate și furnizorilor digitali. NIS2 Article 20 face organismele de conducere responsabile pentru aprobarea măsurilor de management al riscurilor de securitate cibernetică și pentru supravegherea implementării acestora. NIS2 Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale pentru managementul riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția securizată, dezvoltarea securizată, gestionarea vulnerabilităților, evaluarea eficacității, igiena cibernetică, criptografie, controlul accesului, managementul activelor și comunicații securizate.
DORA se aplică entităților financiare și se concentrează pe reziliența operațională digitală. DORA Article 5 plasează responsabilitatea pentru managementul riscurilor TIC asupra organismului de conducere. DORA Article 6 impune un cadru de management al riscurilor TIC solid, cuprinzător și bine documentat. DORA acoperă, de asemenea, raportarea incidentelor legate de TIC, testarea rezilienței operaționale, continuitatea activității TIC, răspunsul și recuperarea, partajarea informațiilor privind amenințările cibernetice, managementul riscurilor TIC asociate terților, acordurile contractuale și supravegherea furnizorilor terți critici de servicii TIC.
GDPR adaugă stratul de responsabilitate pentru datele cu caracter personal. GDPR Article 25 impune protecția datelor încă din faza de proiectare și în mod implicit. Operatorii de date trebuie să poată demonstra conformitatea cu principii precum legalitatea, echitatea, transparența, limitarea scopului, minimizarea datelor, limitarea stocării, integritatea, confidențialitatea și responsabilitatea. Atunci când prelucrarea este susceptibilă să genereze un risc ridicat, poate fi necesară și o evaluare de impact asupra protecției datelor (DPIA) în temeiul GDPR Article 35.
Elementul comun este dovada. Autoritățile de reglementare și auditorii nu întreabă doar dacă o platformă a fost criptată, actualizată cu patch-uri, scanată sau testată. Ei întreabă dacă organizația poate arăta că securitatea, confidențialitatea, riscul asociat furnizorilor și reziliența au făcut parte din procesul decizional încă de la început.
De aceea guvernanța proiectelor conform ISO/IEC 27001:2022 este atât de puternică. Permite organizației să gestioneze NIS2, DORA, GDPR, NIST CSF 2.0, obligațiile contractuale și programele de asigurare solicitate de clienți printr-un singur proces SMSI repetabil, nu prin mai multe liste de verificare deconectate.
Coloana vertebrală a guvernanței proiectelor ISO 27001
ISO/IEC 27001:2022 este adesea înțeles greșit ca un exercițiu de certificare. Pentru proiectele TIC, valoarea sa operațională este mai largă. Oferă o coloană vertebrală de guvernanță pentru schimbările organizației.
Clauzele 4.1–4.4 impun organizațiilor să înțeleagă aspectele interne și externe, părțile interesate, cerințele legale, de reglementare și contractuale, domeniul de aplicare al SMSI, interfețele și dependențele. În termeni de proiect, aceasta înseamnă că mandatul proiectului trebuie să identifice serviciile afectate, clienții, furnizorii, reglementările, procesele de afaceri, datele cu caracter personal, operațiunile critice și serviciile externalizate.
Clauzele 5.1–5.3 impun angajamentul conducerii, alinierea la politici, resursele, integrarea în procesele de afaceri și responsabilitățile atribuite. Acest lucru contează deoarece atât NIS2, cât și DORA plasează securitatea cibernetică și riscul TIC sub responsabilitatea organismului de conducere. Un proiect care modifică o platformă critică pentru clienți nu se poate baza pe un comentariu informal de securitate într-un fir de chat. Are nevoie de responsabilitate clară.
Clauzele 6.1.1–6.1.3 impun un proces repetabil de evaluare și tratare a riscurilor, criterii de risc, proprietari de risc, evaluarea confidențialității, integrității și disponibilității, planuri de tratare a riscurilor, Declarația de aplicabilitate și aprobarea riscului rezidual. Aici riscul de proiect devine dovadă de audit.
Clauzele 7.1–7.5 impun resurse, competență, conștientizare, comunicare și controlul informațiilor documentate. Acesta este modul în care înregistrările de proiect devin dovezi fiabile, nu artefacte dispersate.
Clauza 8.1 impune planificare și control operațional, informații documentate care arată că procesele au fost desfășurate conform planului, controlul schimbărilor planificate, revizuirea schimbărilor neintenționate, atenuarea efectelor adverse și controlul proceselor, produselor sau serviciilor furnizate extern care sunt relevante pentru SMSI. Clauzele 8.2 și 8.3 impun evaluări ale riscurilor de securitate a informației și tratarea acestora la intervale planificate sau atunci când apar schimbări semnificative.
Anexa A conectează apoi acest ciclu de management la controale practice. Pentru securitatea prin proiectare în proiectele TIC, trei controale din Anexa A a ISO/IEC 27001:2022 sunt centrale:
| Control ISO/IEC 27001:2022 | Denumirea controlului | De ce contează pentru proiectele TIC |
|---|---|---|
| A.5.8 | Securitatea informației în managementul proiectelor | Integrează securitatea în toate fazele proiectului și creează dovezi de guvernanță înainte să apară expunerea |
| A.8.25 | Ciclul de viață al dezvoltării securizate | Integrează cerințele de securitate, proiectarea securizată, programarea securizată, testarea și disciplina implementării |
| A.8.32 | Managementul schimbărilor | Asigură că schimbările în producție sunt planificate, evaluate din perspectiva riscului, testate, aprobate, monitorizate și revizuibile |
Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori de la Clarysec tratează securitatea informației în managementul proiectelor ca pe o preocupare de guvernanță pentru toate tipurile de proiecte, nu doar pentru dezvoltarea software:
„Orice proiect — migrarea unui sistem de marketing, relocarea unei clădiri, reproiectarea unui proces de afaceri, o platformă HR de onboarding al personalului, chiar și o fuziune sau achiziție — poate afecta confidențialitatea, integritatea sau disponibilitatea informațiilor. Iar atunci când se întâmplă acest lucru, securitatea trebuie să aibă un loc la masa deciziilor.”
Aceeași secțiune surprinde lecția principală de implementare:
„Scopul acestui control nu este să îngreuneze proiectele cu birocrație. Scopul este să asigure că securitatea este tratată ca o intrare de proiectare, nu ca o fază de testare.”
Această distincție separă teatrul conformității de securitatea prin proiectare care poate fi susținută în audit.
Cum arată securitatea prin proiectare într-un proiect TIC
Securitatea prin proiectare începe înainte de primul sprint, solicitare de achiziție, diagramă de arhitectură sau procedură operațională de migrare. Pune o întrebare simplă: ce ar putea schimba acest proiect în privința riscului?
Un model practic de guvernanță a proiectelor folosește șapte porți de dovezi.
| Poartă de proiect | Dovezi de securitate prin proiectare | Proprietar tipic | Valoare pentru conformitatea transversală |
|---|---|---|---|
| Inițiere | Clasificarea de securitate a proiectului, servicii afectate, aplicabilitatea reglementărilor, categorii de date, criticitate | Sponsorul de proiect și CISO | Susține domeniul de aplicare ISO, măsurile de risc NIS2, analiza funcțiilor critice DORA și responsabilitatea GDPR |
| Cerințe | Cerințe de securitate, cerințe de confidențialitate, cerințe de reziliență, cerințe privind furnizorii | Proprietar de produs, responsabil cu securitatea, DPO, achiziții | Susține achiziția securizată, protecția datelor încă din faza de proiectare și clauzele privind terții |
| Proiectare | Revizuirea arhitecturii, modelarea amenințărilor, maparea fluxului de date, limite de încredere, decizii criptografice | Echipele de arhitectură și securitate | Susține dezvoltarea securizată, protecția datelor conform GDPR și controalele DORA privind riscul TIC |
| Dezvoltare sau configurare | Înregistrări de programare securizată, inventarul componentelor, risc de dependență, configurații de referință | Echipa de inginerie sau de platformă | Susține gestionarea vulnerabilităților și securitatea lanțului de aprovizionare software |
| Testare | Rezultatele testelor de securitate, cazuri de abuz, scanări de vulnerabilitate, teste de backup și recuperare unde este relevant | QA, securitate, operațiuni | Susține testarea DORA, evaluarea eficacității NIS2 și dovezile ISO |
| Aprobarea schimbării | Acceptarea riscului, plan de revenire, plan de monitorizare, actualizări privind escaladarea incidentelor | Comitetul consultativ pentru schimbări (CAB) sau aprobatori delegați | Susține controlul schimbărilor ISO, raportarea de guvernanță DORA și reziliența operațională |
| Post-implementare | Lecții învățate, revizuirea riscului rezidual, monitorizarea furnizorilor, revizuirea eficacității controalelor | Proprietar de serviciu și manager SMSI | Susține îmbunătățirea continuă și pregătirea pentru audit |
Scopul nu este birocrația. Scopul este ca securitatea să fie vizibilă acolo unde se iau efectiv deciziile de proiect.
Politica de securitate a informației Clarysec Enterprise exprimă acest lucru direct:
„Guvernanța securității trebuie integrată cu guvernanța corporativă, managementul proiectelor, achizițiile și funcțiile de supraveghere juridică, pentru a asigura că securitatea informației nu este izolată, ci integrată în întregul proces decizional al organizației.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.5.
Aceasta tratează și ciclurile de viață ale proiectelor ca pe o preocupare de implementare:
„Ciclurile de viață ale proiectelor (de exemplu, dezvoltare securizată, modelarea amenințărilor)”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.1.1.
Și afirmă principiul de audit pe care multe organizații îl descoperă prea târziu:
„Toate controalele implementate trebuie să fie verificabile, susținute de proceduri documentate și de dovezi păstrate privind funcționarea acestora.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.6.1.
Cu alte cuvinte, activitatea de securitate care nu este guvernată, păstrată și mapată va eșua adesea la audit, chiar dacă echipele tehnice au luat decizii rezonabile.
De la modelarea amenințărilor la dovezi: un exemplu practic fintech
Luați în considerare un proiect de lansare a unui nou portal de onboarding al clienților din UE pentru o companie fintech. Portalul colectează documente de identitate, efectuează verificare biometrică printr-un terț, stochează starea onboardingului, se integrează cu CRM, declanșează notificări către clienți și alimentează scorarea riscurilor.
O abordare de securitate prin proiectare ar construi dovezile pe măsură ce proiectul avansează.
Mai întâi, deschideți o înregistrare de clasificare a securității proiectului. Identificați dacă proiectul afectează funcții critice sau importante, date cu caracter personal, categorii speciale de date cu caracter personal, autentificare, disponibilitatea serviciilor destinate clienților, servicii TIC externalizate, procese de raportare reglementate sau comunicări cu clienții. În temeiul GDPR, datele biometrice utilizate pentru identificare unică reprezintă o categorie specială de date cu caracter personal, cu excepția cazului în care se aplică o excepție specifică. Aceasta ridică imediat nivelul necesar de analiză juridică și măsuri de protecție.
În al doilea rând, creați o evaluare a riscurilor pentru proiect. Politica de management al riscurilor Clarysec SME face din managementul riscurilor o parte a planificării, nu un exercițiu trimestrial într-un tabel:
„1.2 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.
Pentru medii enterprise, Politica de management al riscurilor Clarysec Enterprise definește domeniul de aplicare la nivel strategic, operațional, de proiect și tehnic:
„Acoperă riscurile de securitate a informației la nivel strategic, operațional, de proiect și tehnic și este obligatorie pentru întregul personal, contractori și furnizori de servicii implicați în activitățile Sistemului de management al securității informației (SMSI).”
Din secțiunea „Domeniu de aplicare”, clauza de politică 2.3.
În al treilea rând, realizați un model al amenințărilor înainte de începerea dezvoltării. Politica de dezvoltare securizată Enterprise este explicită:
„Toate aplicațiile noi și schimbările majore trebuie să fie supuse unei revizuiri a arhitecturii securizate și modelării amenințărilor înainte de începerea dezvoltării.”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.1.1.
Pentru portalul de onboarding, modelarea amenințărilor trebuie să acopere interfețele expuse, fluxurile de identitate, limitele de privilegii, cazurile de abuz API, falsificarea webhook-urilor, atacurile de tip replay, credențialele compromise, căile de scurgere de date, riscul de dependență, cerințele de jurnalizare, ipotezele privind backup-ul, cerințele de recuperare și modurile de eșec ale furnizorului.
În al patrulea rând, actualizați dovezile privind confidențialitatea. Politica de protecție a datelor și confidențialitate Clarysec SME stabilește cerința de bază:
„5.3.1. 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.
Înregistrarea de proiect trebuie să includă scopul, temeiul juridic, rolul de operator de date sau persoană împuternicită, deciziile privind minimizarea datelor, regulile de retenție, rolurile de acces, opțiunile de criptare, considerațiile privind impactul asupra persoanelor vizate, cerințele de transparență, termenii aplicabili persoanelor împuternicite și căile de notificare a încălcărilor securității datelor cu caracter personal.
În al cincilea rând, înregistrați dovezile de dezvoltare securizată. Politica de dezvoltare securizată Clarysec SME oferă o listă concisă de dovezi care funcționează pentru echipe mici și medii:
„5.3 Directorul general (GM) trebuie să păstreze înregistrări privind: 5.3.1 Toate proiectele active de dezvoltare software și dezvoltatorii sau furnizorii responsabili 5.3.2 Listele de verificare de securitate utilizate pentru fiecare proiect 5.3.3 Revizuirile de cod efectuate și persoanele care le-au efectuat 5.3.4 Rezultatele testării înainte de implementare 5.3.5 Componentele terțe și statutul lor asociat privind licențierea sau riscul”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.
În al șaselea rând, controlați implementarea ca schimbare. Politica de management al schimbărilor Clarysec SME precizează:
„1.1 Această politică asigură că toate schimbările aduse sistemelor IT, configurațiilor, aplicațiilor de afaceri sau serviciilor cloud sunt planificate, evaluate din perspectiva riscului, testate și aprobate înainte de implementare.”
Din secțiunea „Scop”, clauza de politică 1.1.
Pentru portalul de onboarding, tichetul de schimbare trebuie să includă serviciile afectate, evaluarea riscurilor, rezultatele testelor, planul de revenire, planul de monitorizare, aprobările de securitate, aprobarea privind confidențialitatea, pregătirea furnizorilor, actualizările privind escaladarea incidentelor și declanșatoarele de comunicare cu clienții.
În final, mapați obligațiile. Politica de conformitate juridică și de reglementare Clarysec SME oferă regula operațională:
„5.2.2 Atunci când o reglementare se aplică în mai multe domenii (de exemplu, GDPR se aplică retenției, securității și confidențialității), acest lucru trebuie mapat clar în Registrul de conformitate și în materialele de instruire.”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.2.2.
Acest registru de conformitate devine puntea dintre controalele ISO/IEC 27001:2022, măsurile NIS2 Article 21, obligațiile DORA privind riscul TIC, responsabilitatea GDPR și angajamentele contractuale față de clienți.
Maparea unui singur pachet de dovezi de proiect la NIS2, DORA, GDPR și NIST CSF 2.0
Cea mai eficientă strategie de conformitate nu este duplicarea muncii. Este maparea unui set solid de dovezi la mai multe obligații.
Zenith Blueprint, în faza de management al riscurilor, Pasul 14, recomandă acest tip de activitate de corelare:
„Pentru fiecare reglementare, dacă este aplicabilă, puteți crea un tabel simplu de mapare (care poate fi o anexă într-un raport) ce listează cerințele-cheie de securitate ale reglementării și controalele/politicile corespunzătoare din SMSI.”
Acesta adaugă că este util deoarece le arată auditorilor și evaluatorilor „că nu gestionați securitatea în vid, ci sunteți conștienți de contextul juridic.”
Zenith Controls: ghidul de conformitate transversală de la Clarysec susține aceeași abordare integrată prin maparea controalelor ISO/IEC 27001:2022 la alte cadre, așteptări de audit și nevoi de conformitate. Pentru guvernanța proiectelor TIC, acesta poziționează A.5.8, A.8.25 și A.8.32 ca controale preventive care protejează confidențialitatea, integritatea și disponibilitatea în raport cu guvernanța, securitatea aplicațiilor, ecosistemul, protecția și preocupările privind securitatea sistemelor și rețelelor.
| Artefact de dovadă | Scop ISO/IEC 27001:2022 | Valoare NIS2 | Valoare DORA | Valoare GDPR |
|---|---|---|---|---|
| Clasificarea de securitate a proiectului | Definește domeniul de aplicare, părțile interesate, dependențele și controlul operațional | Arată identificarea bazată pe risc a sistemelor și serviciilor afectate | Identifică impactul asupra funcțiilor critice sau importante | Identifică datele cu caracter personal, rolurile și contextul prelucrării |
| Modelarea amenințărilor | Susține evaluarea riscurilor și controalele de dezvoltare securizată | Susține achiziția securizată, dezvoltarea și gestionarea vulnerabilităților | Susține cadrul de risc TIC și strategia de reziliență | Susține protecția datelor încă din faza de proiectare și măsurile de protecție adecvate |
| Verificarea prealabilă a furnizorilor și revizuirea contractelor | Susține controalele privind furnizorii și lanțul de aprovizionare TIC | Susține securitatea lanțului de aprovizionare și evaluarea directă a furnizorilor | Susține riscul TIC asociat terților, drepturile de audit și planificarea ieșirii | Susține măsurile de protecție ale persoanelor împuternicite și instrucțiunile de prelucrare |
| Înregistrări de dezvoltare securizată și testare | Susține SDLC securizat, managementul vulnerabilităților și pregătirea pentru schimbare | Susține dezvoltarea securizată și evaluarea eficacității | Susține testarea rezilienței și remedierea | Susține securitatea prelucrării și reducerea riscului de încălcare |
| Înregistrarea aprobării schimbării | Susține schimbările planificate, revizuirea și atenuarea efectelor adverse | Susține implementarea gestionată pe bază de risc | Susține raportarea de guvernanță și reziliența operațională | Susține responsabilitatea pentru schimbările de sistem care afectează datele cu caracter personal |
| Actualizare privind incidentul și monitorizarea | Susține jurnalizarea, monitorizarea, planificarea incidentelor și colectarea dovezilor | Susține gestionarea incidentelor și pregătirea pentru raportare | Susține clasificarea și escaladarea incidentelor TIC majore | Susține detectarea și răspunsul la încălcările securității datelor cu caracter personal |
| Maparea registrului de conformitate | Susține cerințele legale și de reglementare și informațiile documentate | Demonstrează alinierea la Article 21 | Demonstrează integrarea cadrului DORA | Demonstrează responsabilitatea la nivelul principiilor |
Acest tabel nu înlocuiește analiza juridică. Este un accelerator de guvernanță. Asigură că CISO, DPO, sponsorul de proiect, responsabilul de achiziții, proprietarul de sistem și auditorul intern privesc aceleași dovezi.
NIST CSF 2.0 se potrivește, de asemenea, în mod natural în acest model. Funcția GOVERN ajută organizațiile să stabilească politici, roluri, apetitul la risc, supravegherea și conștientizarea obligațiilor legale sau contractuale. Funcțiile IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER ajută echipele să discute despre active, serviciile furnizorilor, controlul accesului, securitatea datelor, securitatea platformelor, dezvoltarea software securizată, monitorizare, răspuns la incidente și recuperare într-un limbaj operațional comun.
| Cerință de reglementare sau de cadru | Cum oferă dovezi guvernanța proiectelor ISO 27001 |
|---|---|
| DORA Article 5, guvernanță și organizare | Arată supravegherea conducerii, responsabilitățile definite, căile de escaladare și aprobarea deciziilor privind riscul TIC |
| DORA Article 6, cadrul de management al riscurilor TIC | Produce evaluări ale riscurilor TIC la nivel de proiect, înregistrări de tratare, cerințe de reziliență și dovezi privind controalele |
| DORA Article 28, riscul TIC asociat terților | Documentează verificarea prealabilă a furnizorilor, măsurile contractuale de protecție, drepturile de audit, planificarea ieșirii și monitorizarea continuă |
| NIS2 Article 20, guvernanță | Arată aprobarea și supravegherea de către conducere a măsurilor de management al riscurilor de securitate cibernetică |
| NIS2 Article 21(2)(d), securitatea lanțului de aprovizionare | Înregistrează evaluarea furnizorilor, criteriile de achiziție, riscurile furnizorilor de servicii și cerințele contractuale de securitate |
| NIS2 Article 21(2)(e), achiziție, dezvoltare și mentenanță securizate | Capturează cerințele securizate, revizuirea arhitecturii, gestionarea vulnerabilităților, testarea și dovezile de remediere |
| GDPR Article 25, protecția datelor încă din faza de proiectare și în mod implicit | Arată cerințele de confidențialitate, minimizarea, retenția, controlul accesului, măsurile de protecție ale persoanelor împuternicite și rezultatele DPIA acolo unde sunt necesare |
| NIST CSF 2.0 GV.PO-01 and GV.PO-02 | Demonstrează că politicile de securitate cibernetică sunt stabilite, comunicate, aplicate, revizuite și actualizate prin execuția proiectului |
Un singur proces aliniat la ISO 27001, centrat pe Anexa A.5.8, poate genera dovezi care pot fi susținute pentru toate aceste așteptări.
Dezvoltarea securizată este mai amplă decât scrierea codului
Multe eșecuri ale proiectelor TIC apar deoarece organizația tratează dezvoltarea securizată ca pe o activitate realizată doar de dezvoltatori. În 2026, dezvoltarea securizată include și configurarea SaaS, automatizarea fluxurilor de lucru, infrastructura ca cod, integrările API, regulile de identitate, zonele de bază cloud, fluxurile de analiză, automatizarea robotică a proceselor și aplicațiile de afaceri low-code.
Zenith Blueprint, în faza „Controale în acțiune”, Pasul 20, abordează controlul 8.25 Secure Development Life Cycle din ISO/IEC 27002:2022:
„Acest control se aplică indiferent dacă scrieți propriile aplicații, configurați platforme precum sisteme ERP sau CRM, personalizați fluxuri de lucru SaaS sau administrați medii de infrastructură ca cod.”
Acesta explică, de asemenea, că cerințele de securitate trebuie să stea alături de cerințele funcționale și că modelarea amenințărilor ajută la identificarea părților expuse ale sistemului, a rolurilor de utilizator riscante și a fluxurilor de date care necesită protecție mai ridicată.
Pentru un proiect modern, dovezile de dezvoltare securizată pot include:
- Cerințe de securitate corelate cu cerințele de business
- Modelarea amenințărilor sau revizuirea arhitecturii de securitate
- Listă de verificare pentru programare securizată sau configurare securizată
- Înregistrări de revizuire a codului sau revizuire inter pares
- Inventarul componentelor și statutul riscului de dependență
- Decizii privind instrumentele de gestionare a secretelor
- Proiectarea controlului accesului și a principiului privilegiului minim
- Cerințe de jurnalizare și monitorizare
- Rezultatele scanărilor de vulnerabilitate și înregistrări de remediere
- Testare de securitate în preproducție
- Testare de backup, recuperare și reziliență unde este relevant
- Dovezi privind aprobarea implementării și revenirea
Scopul nu este să forțăm fiecare proiect prin același proces greoi. Scopul este proporționalitatea. O schimbare minoră într-un flux de lucru intern nu necesită aceleași dovezi ca migrarea unei platforme de plăți de bază. Dar fiecare proiect trebuie clasificat, evaluat din perspectiva riscului și guvernat în funcție de impact.
Managementul schimbărilor protejează proiectul de propriile riscuri
Cel mai riscant moment în multe proiecte nu este proiectarea sau scrierea codului. Este implementarea.
O echipă poate realiza modelarea amenințărilor, revizuirea codului, evaluarea furnizorilor și revizuirea confidențialității, dar poate totuși produce o indisponibilitate sau o încălcare printr-o schimbare grăbită în producție. Un indicator de depanare rămâne activat. O regulă de firewall este mai largă decât cea aprobată. Un script de migrare copiază date cu caracter personal într-un mediu care nu este de producție. Un URL de webhook al unui terț este implementat fără autentificare. O schimbare de jurnalizare înregistrează numerele documentelor de identitate. O sarcină de backup eșuează silențios după trecerea în producție.
Zenith Blueprint, în faza „Controale în acțiune”, Pasul 21, descrie controlul 8.32 Change Management din ISO/IEC 27002:2022 în termeni direcți:
„Schimbarea este inevitabilă, dar în securitatea cibernetică schimbarea necontrolată este periculoasă.”
Continuă astfel:
„În esență, managementul eficace al schimbărilor este un flux de lucru repetabil. Începe cu o propunere clară, care descrie ce se schimbă, de ce, când și care sunt riscurile potențiale.”
O înregistrare solidă a schimbării TIC trebuie să răspundă la următoarele întrebări:
- Ce sistem, serviciu, flux de date, furnizor sau configurație se schimbă?
- Ce riscuri au fost identificate și cine le deține?
- Schimbarea afectează date cu caracter personal, servicii critice, autentificarea, jurnalizarea, backup-urile sau răspunsul la incidente?
- Ce verificări de securitate, confidențialitate, reziliență și furnizori au fost efectuate?
- Ce teste au fost finalizate înainte de implementare?
- Ce monitorizare va confirma comportamentul așteptat?
- Ce plan de revenire sau recuperare există?
- Cine a aprobat riscul rezidual?
- Ce dovezi vor fi păstrate?
Pentru DORA, aceasta susține managementul riscurilor TIC documentat, reziliența, continuitatea, clasificarea incidentelor și lecțiile învățate. Pentru NIS2, susține măsurile de management al riscurilor, dezvoltarea securizată, prevenirea incidentelor și continuitatea. Pentru GDPR, ajută la demonstrarea faptului că schimbările care afectează datele cu caracter personal au fost revizuite în raport cu principiile privind scopul, minimizarea, retenția, accesul și securitatea.
Deciziile privind furnizorii și cloud-ul trebuie să facă parte din proiectare
În proiectele TIC moderne, decizia de proiectare cu cel mai ridicat risc este adesea „cumpără”, nu „construiește”. Serviciile cloud, furnizorii API, platformele de verificare a identității, procesatorii de plăți, furnizorii de analiză, furnizorii de servicii administrate și furnizorii de servicii de securitate administrate devin parte a suprafeței de risc.
NIS2 include explicit securitatea lanțului de aprovizionare, vulnerabilitățile directe ale furnizorilor și furnizorilor de servicii, practicile de securitate cibernetică ale furnizorilor, procedurile de dezvoltare securizată și rezultatele evaluărilor coordonate ale riscului lanțului de aprovizionare. DORA merge mai departe pentru entitățile financiare. Impune managementul riscurilor TIC asociate terților ca parte a cadrului de management al riscurilor TIC, responsabilitate continuă chiar și atunci când serviciile TIC sunt externalizate, registre de informații, evaluări precontractuale, analiza riscului de concentrare, controale contractuale, drepturi de audit și inspecție, declanșatori de încetare și strategii de ieșire testate pentru funcții critice sau importante.
Pentru portalul de onboarding, furnizorul de verificare biometrică nu poate fi aprobat doar pentru că achizițiile apreciază prețul și documentația API este bună. Proiectul are nevoie de dovezi privind verificarea prealabilă de securitate, rolul în prelucrare, locația datelor, subcontractanții, angajamentele de disponibilitate, suportul pentru incidente, drepturile de audit, asistența la încetare, fezabilitatea ieșirii și obligațiile de monitorizare.
Într-un model matur de dovezi, deciziile privind furnizorii și cloud-ul se află în pachetul de dovezi al proiectului, nu într-un dosar de furnizori deconectat. Când auditorul întreabă de ce a fost acceptat un terț, răspunsul trebuie să includă nevoia de business, evaluarea riscurilor, măsurile contractuale de protecție, revizuirea privind protecția datelor, impactul asupra rezilienței și monitorizarea continuă.
Cum vor revizui auditorii dovezile de securitate prin proiectare
Auditori diferiți privesc același proiect TIC din unghiuri diferite. Un auditor de certificare, auditor intern, revizor DORA, autoritate competentă NIS2, auditor de confidențialitate, evaluator orientat spre NIST sau auditor de tip COBIT/ISACA poate solicita dovezi similare, dar le poate interpreta diferit.
| Perspectivă de audit | Ce va întreba auditorul | Dovezi care, de regulă, răspund întrebării |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | A fost securitatea informației integrată în managementul proiectelor și în planificarea operațională, iar deciziile de tratare a riscurilor sunt documentate? | Mandat de proiect, evaluarea riscurilor, maparea SoA, plan de tratare, aprobări pe etape, controale ale informațiilor documentate |
| Evaluator NIST CSF 2.0 | Rezultatele privind guvernanța, riscul, furnizorii, protecția, detectarea, răspunsul și recuperarea sunt reflectate în deciziile de proiect? | Profil curent și profil țintă, plan de remediere a lacunelor, inventarul furnizorilor, proiectarea accesului, plan de monitorizare, proceduri de incident și recuperare |
| Auditor de tip COBIT sau ISACA | Obiectivele, proprietatea, controalele de proces, drepturile decizionale și monitorizarea performanței sunt clare? | RACI, procese-verbale de guvernanță, deținerea controalelor, rapoarte KPI și KRI, aprobări de schimbare, constatări de audit intern |
| Revizor DORA | Proiectul afectează funcții critice sau importante, dependențe TIC de terți, testarea rezilienței sau raportarea incidentelor? | Evaluare a criticității, înregistrare de risc TIC, registrul furnizorilor, clauze contractuale, rezultatele testelor, actualizări privind clasificarea incidentelor |
| Auditor GDPR sau de confidențialitate | Proiectul a aplicat protecția datelor încă din faza de proiectare, temeiul juridic, minimizarea, retenția, securitatea și responsabilitatea? | Mapare a fluxului de date, înregistrare privind temeiul juridic, DPIA unde este cazul, matrice de acces, reguli de retenție, termeni aplicabili persoanelor împuternicite, actualizări ale procedurii de încălcare |
Auditorii nu caută un set frumos de diapozitive de proiect. Caută trasabilitate. Vor să vadă că cerințele au condus la riscuri, riscurile au condus la controale, controalele au condus la dovezi de implementare, iar implementarea a condus la revizuire.
De aceea Zenith Controls este util în pregătirea pentru audit. Ajută echipele să explice de ce Anexa A.5.8, A.8.25 și A.8.32 sunt controale preventive care protejează confidențialitatea, integritatea și disponibilitatea înainte ca eșecurile previzibile să ajungă în producție.
Pachetul minim Clarysec de dovezi de proiect
Un pachet solid de dovezi pentru securitate prin proiectare nu trebuie să fie enorm. Trebuie să fie consecvent, proporțional și mapat.
Pentru un proiect TIC cu risc mediu, Clarysec recomandă de obicei următorul pachet minim:
- Înregistrare de clasificare a securității proiectului
- Notă privind aplicabilitatea reglementărilor, acoperind NIS2, DORA unde este relevant, GDPR și obligațiile contractuale
- Hartă a impactului asupra fluxurilor de date și activelor
- Evaluarea riscurilor de proiect și planul de tratare
- Modelarea amenințărilor sau revizuirea arhitecturii de securitate
- Evaluarea furnizorilor și a serviciilor cloud, unde este aplicabil
- Listă de verificare pentru dezvoltare securizată sau configurare
- Rezultatele testelor de securitate și dovezi de remediere
- Aprobarea schimbării cu plan de revenire și monitorizare
- Înregistrare privind protecția datelor încă din faza de proiectare, inclusiv temeiul juridic și retenția atunci când sunt implicate date cu caracter personal
- Actualizări privind răspunsul la incidente și monitorizarea
- Revizuire post-implementare și lecții învățate
- Maparea registrului de conformitate la controale și obligații
Zenith Blueprint oferă logica foii de parcurs. Pasul 22 introduce securitatea informației în toate etapele proiectului. Pasul 20 integrează dezvoltarea securizată în planificare, proiectare, cod, testare și implementare. Pasul 21 face managementul schimbărilor structurat, trasabil și revizuibil. Pasul 14 recomandă corelarea GDPR, NIS2, DORA și a altor obligații, astfel încât cerințele de conformitate să nu fie omise.
Politicile oferă regulile de funcționare. Politica de securitate a informației integrează securitatea cu managementul proiectelor, achizițiile și supravegherea juridică. Politica de management al riscurilor face ca riscurile de proiect să fie parte din activitatea SMSI. Politica de dezvoltare securizată impune modelarea amenințărilor. Politica de management al schimbărilor impune schimbări planificate, evaluate din perspectiva riscului, testate și aprobate. Politica de protecție a datelor și confidențialitate impune protecția datelor încă din faza de proiectare și în mod implicit. Politica de conformitate juridică și de reglementare impune ca reglementările aplicabile în mai multe domenii să fie mapate în registrul de conformitate.
Împreună, aceste instrumente transformă securitatea prin proiectare dintr-o aspirație într-un model operațional care poate fi auditat.
Tipare frecvente de eșec în proiectele TIC
Eșecurile sunt, de obicei, previzibile.
Primul este implicarea târzie a securității. Revizuirile de securitate au loc după ce arhitectura este fixată, contractele sunt semnate și datele de livrare sunt publice. În acel moment, securitatea devine un blocaj, nu o intrare de proiectare.
Al doilea este fragmentarea dovezilor. Proiectul are rezultatele testelor într-un instrument, revizuirea furnizorului în altul, comentariile privind confidențialitatea în e-mail, acceptarea riscului într-un proces-verbal de ședință și aprobarea schimbării într-un tichet. Niciun fir unic nu demonstrează guvernanța.
Al treilea este lipsa de vizibilitate asupra furnizorilor. Proiectul se bazează pe un serviciu cloud sau pe un furnizor API, dar nimeni nu verifică subcontractanții, locația datelor, drepturile de audit, suportul pentru incidente, planurile de ieșire sau riscul de concentrare.
Al patrulea este deriva confidențialității. Un sistem construit pentru un scop începe să susțină analize, experimente IA, exporturi de marketing sau monitorizare operațională fără reevaluarea temeiului juridic, transparenței, minimizării sau retenției.
Al cincilea este schimbarea nerevizuită. O implementare în producție este aprobată pentru funcționalitate, dar nu este evaluată pentru impact asupra accesului, jurnalizării, criptării, backup-ului, rezilienței, datelor cu caracter personal sau raportării.
Al șaselea este supravegherea slabă a conducerii. Riscurile de proiect cu impact ridicat sunt acceptate la un nivel prea scăzut, fără dovezi că proprietarul de risc responsabil a înțeles consecințele de reglementare.
Aceste probleme nu se rezolvă prin achiziția unui alt scanner. Se rezolvă prin integrarea guvernanței securității în modul în care proiectele sunt propuse, proiectate, achiziționate, construite, testate, schimbate și revizuite.
Concluzia pentru CISO în 2026
Securitatea prin proiectare în proiectele TIC este acum o problemă pentru consiliul de administrație, audit și reglementare. NIS2 face din managementul riscurilor de securitate cibernetică o responsabilitate a organismului de conducere. DORA transformă riscul TIC, testarea rezilienței, gestionarea incidentelor și supravegherea terților într-o obligație structurată pentru sectorul financiar. GDPR impune responsabilitate pentru prelucrarea datelor cu caracter personal și securitate adecvată. ISO/IEC 27001:2022 oferă structura de sistem de management care face aceste obligații operaționale.
Pentru CISO, oportunitatea este să nu mai se confrunte cu echipele de proiect la finalul livrării. Introduceți securitatea în inițiere, cerințe, proiectare, selecția furnizorilor, dezvoltare, testare, aprobarea schimbării și revizuirea post-implementare.
Pentru managerii de conformitate, oportunitatea este să înlocuiască dovezile dispersate cu un singur pachet mapat de dovezi de proiect.
Pentru auditori, oportunitatea este să testeze ciclul de viață al proiectului, nu doar sistemul final.
Pentru proprietarii de business, oportunitatea este livrarea mai rapidă și mai sigură. Securitatea prin proiectare reduce refacerea muncii, previne surprizele de conformitate, îmbunătățește deciziile privind furnizorii și oferă conducerii o narațiune de risc care poate fi susținută.
Dacă proiectele dvs. TIC se mișcă mai repede decât modelul dvs. de dovezi, începeți cu un proiect-pilot. Folosiți Zenith Blueprint de la Clarysec pentru a defini porțile de securitate ale proiectului, aplicați politicile Clarysec pentru managementul riscurilor, dezvoltare securizată, managementul schimbărilor și confidențialitate și utilizați Zenith Controls pentru a mapa guvernanța proiectelor ISO/IEC 27001:2022 la NIS2, DORA, GDPR și NIST CSF 2.0.
Clarysec vă poate ajuta să construiți un pachet reutilizabil de dovezi de proiect pentru securitate prin proiectare, să îl aliniați cu SMSI și să îl pregătiți pentru audit intern, audit de certificare, pregătire DORA, guvernanță NIS2 și responsabilitate GDPR.
Începeți cu următorul proiect TIC semnificativ. Dacă schimbă sisteme, furnizori, date, acces, reziliență sau încrederea clienților, merită securitate prin proiectare din prima zi.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
