Guvernanța ciclului de viață al datelor ISO 27001 pentru 2026

Maria, CISO-ul unei companii fintech aflate în creștere rapidă, a avut parte de genul de vineri după-amiază care transformă o lacună de conformitate într-o problemă la nivelul consiliului de administrație.

Compania tocmai se extinsese pe noi piețe din UE. Veniturile creșteau, integrarea clienților se accelera, iar noi instrumente SaaS erau adăugate săptămânal. Apoi au sosit, aproape simultan, trei mesaje.

Departamentul juridic a avertizat că autoritățile pentru protecția datelor intensificau aplicarea cerințelor GDPR privind limitarea stocării. Conformitatea i-a reamintit că obligațiile companiei privind riscul TIC conform DORA deveniseră o realitate operațională. Consiliul de administrație a întrebat dacă expunerea organizației la NIS2, inclusiv cerințele privind furnizorii și igiena cibernetică, este sub control.

Apoi, un client a solicitat ștergerea contului său și a tuturor datelor cu caracter personal asociate.

Solicitarea simplă s-a transformat într-o mobilizare interfuncțională. Departamentul juridic a spus că unele înregistrări ar putea fi necesare pentru un litigiu contractual. Departamentul financiar a spus că înregistrările statutare trebuie păstrate. Echipa de produs a confirmat că datele clientului existau în baza de date de producție, platforma de analiză, tichetele de suport, stocarea pe obiecte, jurnalele Kubernetes, instantaneele bazei de date și un instrument terț pentru succesul clienților. Echipa de inginerie cloud a întrebat ce backup-uri conțin datele. DPO-ul a întrebat dacă vreo copie este încă prelucrată în afara UE. Maria a cerut dovezi.

În cele din urmă, cineva a rostit propoziția care a expus problema reală:

„Nu avem un singur loc în care acest ciclu de viață să fie vizibil.”

Aceasta este problema guvernanței ciclului de viață al datelor în 2026. Nu este doar retenție de date. Este clasificare, proprietate, temei juridic, acces, locație, replicare, retenția backup-urilor, blocare legală, dezafectare cloud, ștergere la furnizor, revizuirea arhivei, dovezi privind incidentele și eliminare justificabilă.

Pentru IMM-uri, fintech-uri, furnizori de servicii administrate, companii cu strategie prioritar cloud și organizații reglementate, riscul nu mai este că datele lipsesc. Riscul este că datele sunt peste tot, duplicate, învechite, cu permisiuni excesive, insuficient clasificate și imposibil de demonstrat că au fost șterse.

Un program matur de guvernanță a ciclului de viață al datelor ISO 27001 transformă această mobilizare dezordonată într-un flux de lucru controlat.

De ce s-a schimbat guvernanța ciclului de viață al datelor în 2026

GDPR, NIS2 și DORA sunt tratate adesea ca trei liste de verificare separate pentru conformitate. Acesta este un model operațional greșit. Ele sunt expresii de reglementare diferite ale aceleiași cerințe organizaționale: cunoașteți-vă datele, protejați-le în funcție de risc, păstrați-le pentru motivul corect și demonstrați ce s-a întâmplat cu ele.

GDPR Article 5 impune ca datele cu caracter personal să fie prelucrate în mod legal, echitabil și transparent, colectate în scopuri determinate, limitate la ceea ce este necesar, exacte, păstrate numai atât timp cât este necesar și protejate împotriva prelucrării neautorizate sau ilegale, pierderii accidentale, distrugerii sau deteriorării. Article 5(2) adaugă responsabilitatea, ceea ce înseamnă că operatorul de date trebuie să poată demonstra conformitatea. Prin urmare, guvernanța retenției conform GDPR nu este un exercițiu în foaie de calcul. Necesită dovezi operaționale.

NIS2 transformă securitatea cibernetică într-o responsabilitate a organului de conducere. Article 20 stabilește așteptări de guvernanță pentru organele de conducere, iar Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale. Acestea includ analiza riscurilor, politici de securitate a sistemelor informatice, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, dezvoltarea securizată, evaluarea eficacității, igiena cibernetică, instruirea, criptografia, controlul accesului și managementul activelor. Datele necunoscute sau învechite nu reprezintă doar o problemă de confidențialitate. Ele reprezintă o problemă de suprafață de atac.

DORA face ca managementul riscurilor TIC, reziliența operațională și riscul TIC generat de terți să fie direct aplicabile entităților financiare. Articles 5 și 6 atribuie responsabilitatea organului de conducere și impun un cadru documentat de management al riscurilor TIC. DORA se așteaptă, de asemenea, ca entitățile financiare să protejeze disponibilitatea, autenticitatea, integritatea și confidențialitatea datelor, să mențină capabilități de gestionare a incidentelor, să testeze reziliența și să guverneze dependențele TIC față de terți.

DORA funcționează, în general, ca regim sectorial specific pentru obligațiile operaționale suprapuse de securitate cibernetică aplicabile entităților financiare, în timp ce NIS2 rămâne relevantă pentru ecosistemul mai larg, inclusiv furnizori cloud, furnizori de servicii administrate și multe organizații de infrastructură digitală. Acest lucru contează deoarece un fintech poate intra direct sub incidența DORA, în timp ce furnizorul său SaaS sau furnizorul de servicii administrate poate fi în perimetrul NIS2.

ISO/IEC 27001:2022 este sistemul de management care poate integra aceste obligații. Clauses 4.1 până la 4.4 impun organizației să își înțeleagă contextul, părțile interesate, cerințele legale și contractuale și domeniul de aplicare al SMSI. Clauses 5.1 până la 5.3 impun leadership, roluri și responsabilități. Clauses 6.1.2 și 6.1.3 impun evaluarea riscurilor de securitate a informației, tratamentul riscului, selectarea controalelor, comparația cu Anexa A și păstrarea informațiilor documentate.

Această structură explică de ce ISO 27001 nu este „încă o listă de verificare”. Este sistemul de operare pentru guvernanța ciclului de viață al datelor.

Modelul ciclului de viață: șapte întrebări la care fiecare proprietar de date trebuie să răspundă

Un model practic de guvernanță a ciclului de viață al datelor trebuie să răspundă la șapte întrebări pentru fiecare categorie importantă de date:

1. Ce reprezintă datele?
2. De ce le prelucrăm?
3. Cine le deține?
4. Cât de sensibile sunt?
5. Unde sunt stocate și unde se replică?
6. Cât timp trebuie păstrate sau suspendate de la ștergere?
7. Cum le protejăm, le revizuim, le ștergem și demonstrăm acest lucru?

Abordarea Clarysec conectează aceste întrebări la controalele ISO 27001 și la dovezi operaționale. În Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului, etapa Controale în acțiune tratează inventarul activelor și clasificarea drept baze operaționale, nu documentație formală. Pasul 22 explică faptul că inventarul trebuie să includă active fizice, active digitale, active logice, active aferente serviciilor și persoane, din perspectiva responsabilităților, accesului și expunerii.

Zenith Blueprint precizează:

„Fiecare activ trebuie să aibă un proprietar definit, nu persoana care îl utilizează, ci persoana responsabilă pentru utilizarea, protecția și ciclul său de viață.”

Această propoziție este punctul de pivot. Guvernanța ciclului de viață al datelor eșuează atunci când proprietatea este atribuită generic către „IT” sau „business”. Funcționează atunci când un proprietar nominal, responsabil, poate aproba clasificarea, retenția, accesul, deciziile de blocare legală, revizuirea arhivei și dovezile privind ștergerea.

Politica de management al activelor - IMM de la Clarysec consolidează aceeași disciplină:

„Proprietatea, scopul, privilegiile de acces și termenele de reînnoire trebuie documentate.”

Această cerință apare în Politica de management al activelor - IMM, secțiunea „Cerințe de implementare a politicii”, clauza 6.6.2. Fără proprietate și scop, retenția devine o estimare, iar ștergerea devine periculoasă.

Clasificarea este primul control de retenție

Multe organizații încearcă să construiască calendare de retenție înainte de a avea o clasificare fiabilă. De regulă, acest lucru eșuează.

Dacă un export din suportul pentru clienți, un document HR, o înregistrare de tranzacție sau un jurnal al unei aplicații nu este clasificat, organizația nu poate decide consecvent cine trebuie să îl acceseze, unde poate fi stocat, dacă poate fi utilizat în testare, cât de puternic trebuie criptat, dacă necesită protecție prin blocare legală sau cum trebuie șters.

Politica de clasificare și etichetare a datelor - IMM de la Clarysec este explicită:

„Toate documentele, fișierele și sistemele trebuie clasificate imediat ce sunt create sau primite.”

Aceasta apare în Politica de clasificare și etichetare a datelor - IMM, secțiunea „Cerințe de implementare a politicii”, clauza 6.1.1.

Politica de clasificare și etichetare a datelor pentru organizații mari conectează clasificarea la întregul lanț de gestionare:

„Toată gestionarea datelor, transmiterea, accesul, stocarea și eliminarea informațiilor trebuie aliniate la nivelul lor de clasificare. Cel puțin:”

Aceasta apare în Politica de clasificare și etichetare a datelor, secțiunea „Cerințe de implementare a politicii”, clauza 6.3.1.

Zenith Blueprint adaugă îndrumări de implementare pentru controlul ISO/IEC 27002:2022 5.12, Clasificarea informațiilor. O schemă de clasificare trebuie să definească niveluri precum Public, Intern, Confidențial și Restricționat, să includă criterii bazate pe prejudiciul produs de accesul neautorizat, pierderea sau modificarea informațiilor, să se aplice tuturor formelor de informații și să rămână independentă de formatul sau locația de stocare.

Pe scurt, clasificarea urmează conținutul, nu locația de stocare.

Un set de date restricționat nu devine mai puțin riscant deoarece a fost mutat dintr-o bază de date într-un instrument SaaS de analiză. O înregistrare aflată sub blocare legală nu își pierde statutul deoarece a fost exportată în CSV. Datele cu caracter personal nu încetează să fie reglementate deoarece apar într-un mesaj de jurnal.

Clasificarea trebuie să devină metadată în Registrul activelor, Registrul de retenție, maparea datelor, revizuirea drepturilor de acces, lista de verificare pentru integrarea în cloud și înregistrarea de eliminare.

Coloana vertebrală a controalelor ISO 27001 pentru guvernanța ciclului de viață

Cele mai eficiente programe privind ciclul de viață al datelor au o coloană vertebrală de controale. Aceasta conectează controalele ISO/IEC 27002:2022 la dovezi operaționale.

Zenith Controls: ghidul de conformitate transversală de la Clarysec oferă ghidul de conformitate transversală pentru această activitate. Pentru guvernanța ciclului de viață al datelor, trei controale sunt centrale: 5.33 Protecția înregistrărilor, 5.34 Protecția vieții private și protecția PII și 8.10 Ștergerea informațiilor.

În Zenith Controls, controlul ISO/IEC 27002:2022 5.33, Protecția înregistrărilor, este descris prin atribute de controale preventive care susțin confidențialitatea, integritatea și disponibilitatea, cu capabilități operaționale în zona juridică și conformitate, managementul activelor și protecția informațiilor. Acesta se conectează la backup, clasificare, eliminarea securizată a echipamentelor, cerințe legale și de reglementare, respectarea politicilor, controlul accesului și răspunsul la incidente.

Controlul 5.34, Protecția vieții private și protecția PII, susține confidențialitatea, integritatea și disponibilitatea. Zenith Controls îl corelează cu inventarul activelor, mascarea datelor, securitatea cloud, clasificarea, transferul informațiilor, controlul accesului, managementul identității și revizuirea securității proiectelor și schimbărilor.

Controlul 8.10, Ștergerea informațiilor, este preventiv și axat pe confidențialitate. Zenith Controls îl conectează la etichetare, transferul informațiilor, proprietate intelectuală, acces privilegiat, mascarea datelor, prevenirea scurgerii de date, protecția înregistrărilor, managementul configurației și respectarea politicilor și standardelor.

Împreună, aceste controale creează lanțul ciclului de viață.

Acest tabel nu este doar pentru auditori. Este un model operațional pentru CISO, DPO, manageri de conformitate și proprietari de procese care au nevoie de un limbaj comun de guvernanță pentru confidențialitate, securitate cibernetică și reziliență.

Construiți Registrul de retenție înaintea procesului de ștergere

Un proces de ștergere fără Registrul de retenție este periculos. Poate elimina înregistrări care trebuie păstrate, poate rata date care trebuie șterse sau poate eșua în distingerea dintre ștergerea operațională și suspendarea prin blocare legală.

Politica de retenție a datelor și de eliminare securizată - IMM de la Clarysec stabilește baza:

„Un Registru de retenție este stabilit și menținut, listând categoriile-cheie de înregistrări, cerințele legale și perioadele de retenție atribuite.”

Aceasta apare în Politica de retenție a datelor și de eliminare securizată - IMM, secțiunea „Cerințe de guvernanță”, clauza 5.1.1.

Pentru programele organizațiilor mari, Politica de retenție și eliminare a datelor de la Clarysec definește obiectivul:

„Stabilirea și aplicarea unor calendare de retenție consecvente, bazate pe clasificarea informațiilor, tipul de activ, legile aplicabile și expunerea la risc.”

Aceasta apare în Politica de retenție și eliminare a datelor, secțiunea „Obiective”, clauza 3.3.

Un Registru de retenție utilizabil trebuie să conecteze realitățile juridice, operaționale, de securitate și cloud.

Un Registru de retenție pentru un fintech mic ar putea include:

Aspectul important este că retenția trebuie să fie bazată pe risc și susținută prin dovezi. Limitarea stocării din GDPR impune ca datele cu caracter personal să nu fie păstrate mai mult decât este necesar, dar permite, de asemenea, retenția atunci când există o obligație legală sau o nevoie legitimă. NIS2 se așteaptă la managementul activelor, controlul accesului și igiena cibernetică. DORA se așteaptă la management documentat al riscurilor TIC și disciplină privind continuitatea activității. Registrul de retenție este locul în care aceste obligații devin decizii.

Blocările legale trebuie integrate în sisteme, nu trimise prin e-mail

Un program matur privind ciclul de viață trebuie să șteargă datele atunci când nu mai sunt necesare, dar nu trebuie să șteargă înregistrări aflate sub blocare legală, investigație sau păstrare pentru audit.

Politica de retenție a datelor și de eliminare securizată - IMM este explicită:

„Nicio înregistrare supusă blocării legale și suspendării ștergerii nu poate fi distrusă sau modificată, chiar dacă perioada sa de retenție a expirat.”

Aceasta apare în Politica de retenție a datelor și de eliminare securizată - IMM, secțiunea „Cerințe de implementare a politicii”, clauza 6.3.4.

Politica de retenție și eliminare a datelor pentru organizații mari aplică același principiu de guvernanță:

„Dacă este emisă o blocare legală și o suspendare a ștergerii (de exemplu, pentru litigii, investigații sau audit în curs), datele care altfel ar fi supuse distrugerii trebuie păstrate dincolo de perioada normală de retenție.”

Aceasta apare în Politica de retenție și eliminare a datelor, secțiunea „Cerințe de implementare a politicii”, clauza 6.4.1.

Blocarea legală nu trebuie să fie un e-mail care poate ajunge sau nu la administratorii de sistem. Trebuie să fie un statut în Registrul de retenție, legat de sisteme, categorii de înregistrări, custozi și automatizări de ștergere.

Un flux de lucru defensabil pentru blocare legală include:

• Declanșator, precum litigiu, solicitare a autorității de reglementare, incident de securitate, audit sau investigație internă
• Proprietar al blocării, de regulă funcția juridică sau de conformitate
• Categorii de înregistrări, sisteme și custozi afectați
• Instrucțiuni de suspendare pentru sarcini de ștergere, expirarea backup-urilor și curățarea arhivelor
• Restricții de acces pentru păstrarea integrității
• Revizuire periodică a blocării
• Aprobare pentru ridicare și revenire documentată la retenția normală
• Dovezi privind ce a fost păstrat, de către cine și când

Acest aspect este deosebit de important în timpul răspunsului la incidente. Jurnalele, imaginile, exporturile și comunicările pot necesita păstrare chiar și atunci când retenția normală a expirat. Ștergerea trebuie să fie suficient de controlată încât să poată fi oprită, justificată și reluată.

Ștergerea în cloud și SaaS este locul în care guvernanța ciclului de viață se rupe

În 2026, majoritatea organizațiilor nu pierd controlul asupra ciclului de viață în baza lor de date principală. Îl pierd în bucket-uri de stocare cloud, exporturi SaaS, platforme de suport, atașamente CRM, spații de colaborare, jurnale API, depozite de date, instantanee și seifuri de backup.

Zenith Blueprint, etapa Controale în acțiune, Pasul 23, care acoperă controlul ISO/IEC 27002:2022 5.23, Securitatea informațiilor pentru utilizarea serviciilor cloud, avertizează că furnizorii cloud securizează infrastructura, dar clientul rămâne responsabil pentru date, configurații, politici de acces și pregătirea pentru răspuns la incidente. Bucket-urile configurate greșit, tablourile de bord publice și permisiunile IAM cloud excesive sunt eșecuri de guvernanță, nu eșecuri ale furnizorului.

De asemenea, precizează că utilizarea cloud trebuie tratată ca parte a SMSI. Organizațiile trebuie să clasifice serviciile cloud, să înțeleagă datele prelucrate sau stocate în acestea, să evalueze profilul furnizorului, să stabilească clauze contractuale și să gestioneze schimbările sau extinderea domeniului de aplicare.

Politica de utilizare a serviciilor cloud - IMM de la Clarysec transpune acest lucru în cerințe pentru încetarea utilizării:

„Confirmarea procedurilor de ștergere securizată înainte de închiderea contului”

Aceasta apare în Politica de utilizare a serviciilor cloud - IMM, secțiunea „Cerințe de implementare a politicii”, clauza 6.3.5.

Politica de utilizare a serviciilor cloud pentru organizații mari impune guvernanță asupra:

„Proprietatea asupra datelor și returnarea sau ștergerea acestora la încetare”

Aceasta apare în Politica de utilizare a serviciilor cloud, secțiunea „Cerințe de guvernanță”, clauza 5.4.1.

Pentru entitățile financiare reglementate de DORA, aceasta nu este o igienă opțională. DORA Article 28 impune managementul riscului TIC generat de terți, un registru al acordurilor contractuale TIC, due diligence precontractuală, analiza riscului de concentrare, drepturi de audit și acces, drepturi de încetare și strategii de ieșire pentru serviciile TIC care susțin funcții critice sau importante. Article 30 impune termeni contractuali care acoperă descrierea serviciilor, locațiile de prelucrare și stocare, protecția disponibilității, autenticității, integrității și confidențialității, accesul la date, recuperarea, returnarea, asistența pentru incidente și suportul pentru tranziție.

Pentru entitățile NIS2, deciziile privind furnizorii trebuie să ia în considerare securitatea cibernetică a lanțului de aprovizionare, vulnerabilitățile și reziliența produselor și serviciilor. Prin urmare, guvernanța ciclului de viață al datelor trebuie să se extindă la furnizori, nu să se oprească la aprobarea achiziției.

Un sprint de o săptămână pentru crearea unui pachet de controale privind ciclul de viață

Nu începeți încercând să mapați fiecare sistem din companie. Începeți cu un flux de date cu risc ridicat și creați un pachet de controale repetabil.

Ziua 1: Alegeți un flux de date cu risc ridicat

Selectați un flux de date relevant, precum integrarea clienților, încetarea colaborării cu angajații, gestionarea disputelor de plată, managementul tichetelor de suport sau jurnalizarea de securitate.

Pentru un fintech, integrarea clienților este un candidat solid deoarece poate include documente de identitate, PII, înregistrări de tranzacții, semnale de fraudă, furnizori terți de verificare, stocare cloud, acces pentru suport și retenție reglementară.

Ziua 2: Construiți mini-inventarul activelor și al datelor

Utilizați Zenith Blueprint, etapa Controale în acțiune, Pasul 22, controlul ISO/IEC 27002:2022 5.9, pentru a captura active fizice, digitale, logice, aferente serviciilor și bazate pe responsabilități.

Documentați categoriile de date colectate, sistemele de înregistrare, platformele SaaS care primesc copii, API-urile, integrările, rolurile de utilizator, rolurile privilegiate, locațiile backup-urilor, locațiile arhivelor, proprietarul de date, proprietarul de sistem, clasificarea, marcajele PII și dependențele față de furnizori.

Scopul nu este perfecțiunea. Scopul este să evidențieze punctele ascunse de replicare.

Ziua 3: Aplicați logica de clasificare și acces

Aplicați Politica de clasificare și etichetare a datelor și clasificați fiecare categorie de date. Apoi verificați dacă permisiunile de acces reflectă clasificarea.

Documentele de identitate ale clienților cu clasificare restricționată nu trebuie să fie accesibile pe scară largă prin instrumentele de suport. Jurnalele de securitate care conțin identificatori nu trebuie exportate informal în foi de calcul neadministrate. Accesul trebuie corelat cu rolul, scopul, aprobarea și dovezile revizuirii.

Ziua 4: Creați intrări de retenție și blocare legală

Utilizați Politica de retenție și eliminare a datelor și Politica de retenție a datelor și de eliminare securizată - IMM pentru a crea intrări de retenție pentru fiecare categorie de înregistrări. Includeți temeiul juridic, scopul de afaceri, cerința legală, perioada de retenție, metoda de ștergere și statutul de blocare legală.

Dacă există un litigiu, incident sau investigație activă, marcați suspendarea ștergerii și înregistrați aprobatorul.

Ziua 5: Verificați ștergerea în cloud și la furnizori

Utilizați Politica de utilizare a serviciilor cloud și Politica de utilizare a serviciilor cloud - IMM pentru a verifica fiecare furnizor cloud sau SaaS din flux.

Confirmați termenii privind proprietatea asupra datelor, returnarea sau ștergerea la încetare, termenele de ștergere, comportamentul ștergerii din backup-uri, implicațiile persoanelor subîmputernicite, dovezile de ștergere și obligațiile de asistență în caz de incident.

Pentru medii DORA, actualizați registrul terților TIC și planul de ieșire. Pentru medii NIS2, documentați considerațiile privind riscul furnizorilor și dependențele de igienă cibernetică.

Ziua 6: Definiți dovezile și monitorizarea

Dovezile nu trebuie create după solicitarea de audit. Definiți-le în timpul proiectării procesului.

Politica de retenție și eliminare a datelor impune ca eliminarea să fie:

„Jurnalizată în Registrul de eliminare, incluzând ID-ul activului, clasificarea, metoda și operatorul”

Aceasta apare în Politica de retenție și eliminare a datelor, secțiunea „Cerințe de implementare a politicii”, clauza 6.5.3.2.

Un pachet solid de dovezi include intrări în Registrul de retenție, rezultatele revizuirii drepturilor de acces, tichete de ștergere, jurnale din Registrul de eliminare, confirmări de ștergere în cloud, aprobări de blocare legală, setări de retenție a backup-urilor, clauze contractuale cu furnizorii și înregistrări ale revizuirii arhivei.

Ziua 7: Actualizați riscurile și Declarația de aplicabilitate

Actualizați Registrul de riscuri ISO 27001 și Declarația de aplicabilitate. Dacă revizuirea ciclului de viață a identificat exporturi SaaS neadministrate, retenție nelimitată a backup-urilor, acces excesiv, termeni neclari de ștergere sau lipsa proprietății, acestea sunt riscuri care necesită tratament.

Acest sprint de o săptămână creează un pachet repetabil de controale privind ciclul de viață. Repetați-l pentru următorul flux de date, apoi pentru următorul.

Maparea de conformitate transversală: un singur program de ciclu de viață, mai multe obligații

Valoarea guvernanței ciclului de viață al datelor ISO 27001 constă în faptul că aceleași dovezi pot susține așteptări privind confidențialitatea, igiena cibernetică, riscul TIC și auditul.

NIST CSF 2.0 este util pentru comunicarea cu conducerea executivă deoarece funcția sa GOVERN se așteaptă ca obligațiile legale, de reglementare, contractuale și de confidențialitate să fie înțelese și gestionate, apetitul la risc să fie stabilit, responsabilitatea conducerii să fie clară, politicile să fie aplicate, iar rezultatele să fie revizuite. Rezultatele sale privind managementul activelor impun inventare și managementul ciclului de viață pentru hardware, software, sisteme, servicii și date.

COBIT 2019 adaugă limbaj de guvernanță pentru consiliile de administrație și comitetele de audit. Zenith Controls mapează Protecția înregistrărilor la procese COBIT precum gestionarea backup-urilor și restaurării, gestionarea securității informațiilor în repaus și gestionarea înregistrărilor. Mapează Protecția vieții private și protecția PII la confidențialitate, protecția informațiilor și guvernanța programului de confidențialitate. Mapează Ștergerea informațiilor la obiective de risc și operațiuni, consolidând ștergerea ca proces guvernat, nu ca activitate ad-hoc de curățare.

Ce vor testa efectiv auditorii

Un program de guvernanță a ciclului de viață este credibil doar dacă rezistă testării de audit.

Un auditor ISO/IEC 27001:2022 va începe cu domeniul de aplicare, cerințele părților interesate, riscurile, Declarația de aplicabilitate, informațiile documentate și dovezile de control operațional. Pentru guvernanța ciclului de viață, așteptați-vă la eșantionare. Auditorul poate selecta un contract, o înregistrare HR, un set de jurnale sau o evidență financiară și o poate urmări de la creare, stocare, backup și acces până la eliminare.

Folosind perspectiva de audit din Zenith Controls pentru Protecția înregistrărilor, auditorii verifică dacă înregistrările din domeniul de aplicare sunt identificate, dacă există calendare de retenție, cum sunt stocate înregistrările, cum este controlat accesul și cum este protejată integritatea.

Pentru Ștergerea informațiilor, Zenith Controls explică faptul că auditorii revizuiesc politicile de retenție și ștergere, metodele de ștergere, responsabilitățile, jurnalele de ștergere, pistele de audit, certificatele de distrugere a mediilor și dovezile generate de instrumentele de sanitizare. Ei verifică, de asemenea, dacă backup-urile și arhivele sunt acoperite.

Un auditor de confidențialitate sau PII va revizui politicile de confidențialitate, inventarele de date, DPIA sau PIA, registrele de instruire și măsuri tehnice precum criptarea datelor în repaus și în tranzit. Poate eșantiona o cerere a persoanei vizate, confirma unde există datele relevante, verifica dacă s-a aplicat ștergerea sau restricționarea și verifica dacă excepțiile precum blocarea legală sunt justificate.

Un evaluator orientat spre NIST poate examina alinierea la rezultatele NIST CSF și controale tehnice precum NIST SP 800-53 AU-11 Audit Record Retention, precum și practici de sanitizare a mediilor informate de NIST SP 800-88. Poate testa restaurarea backup-urilor, inspecta regulile de retenție a jurnalelor, verifica criptarea și controla dacă PII nenecesar este minimizat.

Un auditor COBIT sau ISACA se va concentra pe procesele de guvernanță și calitatea dovezilor. Va întreba cine deține înregistrările, dacă controalele proceselor de afaceri păstrează integritatea, dacă monitorizarea conformității detectează retenția excesivă și dacă operațiunile includ sarcini de ștergere securizată.

Tipare frecvente de eșec în guvernanța ciclului de viață

Clarysec observă frecvent aceleași tipare în IMM-uri și organizații reglementate.

Primul este clasificarea fără aplicare. Datele sunt etichetate confidențial, dar drepturile de acces, partajarea SaaS, exporturile și metodele de ștergere nu se schimbă.

Al doilea este retenția fără replici. Calendarul acoperă sistemul principal, dar nu jurnalele, backup-urile, depozitele de date, exporturile de suport, foile de calcul sau platformele terțe.

Al treilea este dezafectarea cloud fără dovezi. Contractul spune că datele vor fi șterse, dar nimeni nu cunoaște metoda de ștergere, termenul, comportamentul backup-urilor sau formatul dovezilor.

Al patrulea este blocarea legală prin e-mail. Departamentul juridic trimite instrucțiuni, dar sarcinile de ștergere continuă deoarece niciun sistem operațional nu consumă statutul blocării.

Al cincilea este producerea dovezilor de audit după fapt. Echipele reconstruiesc manual dovezile privind ștergerea și retenția, creând inconsistență și îndoială evitabilă.

Al șaselea este reapariția din backup. Datele șterse din producție reapar în timpul restaurării sau testării deoarece logica de retenție și curățare a backup-urilor nu a fost niciodată aliniată cu Politica de retenție a datelor.

Fiecare eșec poate fi prevenit atunci când clasificarea, inventarul, retenția, guvernanța cloud, ștergerea și dovezile sunt proiectate ca un singur ciclu de viață.

Modelul operațional Clarysec pentru guvernanța ciclului de viață al datelor

Modelul Clarysec este direct: stabiliți o coloană vertebrală de controale pentru ciclul de viață, apoi atașați la aceasta obligațiile de reglementare și dovezile.

Coloana vertebrală a controalelor include:

• Inventarul activelor și al datelor
• Proprietate și scop
• Clasificare și etichetare
• Temei juridic și scop de prelucrare
• Registru de retenție
• Blocare legală și suspendarea ștergerii
• Clauze privind ciclul de viață în cloud și la furnizori
• Controlul accesului și guvernanța accesului privilegiat
• Reguli de backup și arhivare
• Ștergere securizată și Registrul de eliminare
• Jurnalizare, monitorizare și dovezi privind incidentele
• Revizuire periodică și actualizări ale tratamentului riscurilor

Zenith Blueprint oferă foaia de parcurs de implementare prin pașii Controale în acțiune pentru inventar, clasificare, guvernanță cloud și ștergerea informațiilor. Zenith Controls oferă ghidul de conformitate transversală care arată cum controalele ISO/IEC 27002:2022 se conectează la GDPR, NIS2, DORA, NIST, COBIT, ISO/IEC 27701, ISO/IEC 27018, ISO/IEC 27017, ISO/IEC 27040, ISO 15489 și ISO 22301. Politicile Clarysec oferă clauzele operaționale pe care echipele le pot implementa imediat.

Guvernanța ciclului de viață nu poate exista doar în confidențialitate, securitate sau IT. Trebuie să fie un sistem de management comun.

Dacă organizația dumneavoastră nu poate răspunde unde se află datele reglementate, cine le deține, cât timp sunt păstrate, ce previne ștergerea în timpul blocării legale, cum sunt eliminate datele SaaS și ce dovezi demonstrează eliminarea, acum este momentul să remediați situația.

Începeți cu un flux de date cu risc ridicat. Utilizați Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului pentru a construi baza de inventar și clasificare. Utilizați Zenith Controls: ghidul de conformitate transversală pentru a mapa Protecția înregistrărilor, Protecția vieții private și protecția PII și Ștergerea informațiilor în GDPR, NIS2, DORA, NIST și COBIT. Apoi implementați politicile Clarysec relevante, inclusiv Politica de clasificare și etichetare a datelor, Politica de retenție și eliminare a datelor, Politica de utilizare a serviciilor cloud și echivalentele lor pentru IMM-uri, acolo unde este cazul.

Obiectivul practic nu este să păstrați mai puține date în mod orbește. Este să păstrați datele corecte, pentru motivul corect, sub controalele corecte, pentru perioada corectă, cu dovezi care rezistă în fața clienților, autorităților de reglementare, auditorilor și consiliului de administrație.

Descărcați seturile de politici Clarysec, mapați-vă controalele cu Zenith Controls sau utilizați Zenith Blueprint pentru a derula primul sprint de controale privind ciclul de viață înainte ca următoarea cerere de ștergere să devină o constatare de audit.