Clasificarea datelor pentru ISO 27001, GDPR, NIS2 și DORA
Momentul auditului din 2026: „Arătați-mi dovezile”
Este februarie 2026, iar ședința trimestrială a consiliului de administrație într-o companie fintech SaaS aflată în creștere rapidă nu decurge atât de lin pe cât se aștepta CISO.
Compania a obținut recent certificarea ISO/IEC 27001:2022. Are MFA, protecție pentru punctele terminale, scanări de vulnerabilitate, revizuiri ale drepturilor de acces, proceduri de răspuns la incidente și un raport de pregătire DORA foarte bine prezentat. Apoi CEO adresează întrebarea care schimbă atmosfera din sală.
„Investitorul nostru principal întreabă cum putem demonstra că datele financiare ale clienților sunt protejate consecvent în AWS, Azure, platforma noastră SaaS de suport și depozitul de analiză. Dacă un auditor extrage un fișier din stocarea de obiecte și altul dintr-un folder de colaborare, cum știm că sunt guvernate de aceleași reguli?”
CISO deschide registrul activelor. Acesta listează baze de date, conturi cloud, aplicații, platforme SaaS și locații de stocare. Dar câmpul de clasificare este incomplet. Câteva foldere sunt denumite după departament, nu după sensibilitate. Exporturile de clienți se află lângă fișiere interne de raportare. Unele foi de calcul de suport conțin identificatori ai clienților, referințe de plată și note de caz, dar sunt etichetate „Intern”. Există reguli DLP, însă acestea se declanșează doar pe tipare evidente. Politica de utilizare a serviciilor cloud prevede că datele cu caracter personal din UE trebuie să rămână în regiuni aprobate, dar echipa nu poate demonstra că regulile de rezidență sunt determinate de metadatele de clasificare.
Apoi managerul de conformitate adaugă perspectiva de reglementare: „Va fi suficient pentru articolul 32 din GDPR, articolul 21 din NIS2 și dovezile privind riscurile TIC conform DORA?”
Răspunsul sincer este: încă nu.
Aceasta este lacuna cu care se confruntă multe organizații în 2026. Au controale de securitate, dar nu și stratul de guvernanță care indică fiecărui control ce trebuie protejat, cât de puternic trebuie protejat și cum se demonstrează protecția. Acest strat de guvernanță este clasificarea datelor și etichetarea informațiilor.
În termenii ISO/IEC 27001:2022, clasificarea și etichetarea nu sunt practici cosmetice de management al documentelor. Ele reprezintă puntea practică dintre evaluarea riscurilor, controlul accesului, criptare, retenție, DLP, rezidența în cloud, verificarea prealabilă a furnizorilor, monitorizare și raportarea incidentelor. În modelul de implementare Clarysec, acestea se află în centrul lanțului de dovezi al SMSI: inventariați activul, desemnați un proprietar, clasificați-l, etichetați-l, aplicați regulile de gestionare, monitorizați excepțiile și prezentați auditorilor trasabilitatea.
De ce clasificarea și etichetarea au devenit controale la nivelul consiliului de administrație
Autoritățile de reglementare și clienții se așteaptă tot mai mult ca organizațiile să demonstreze că măsurile de securitate sunt adecvate sensibilității datelor, criticității serviciului și impactului asupra organizației în cazul unui eșec.
GDPR face acest lucru explicit prin principiul responsabilității. Articolul 5 impune ca datele cu caracter personal să fie prelucrate legal, echitabil și transparent, limitate la ceea ce este necesar, păstrate numai atât timp cât este necesar și protejate prin măsuri tehnice și organizatorice adecvate. Operatorul trebuie, de asemenea, să poată demonstra conformitatea. Articolul 32 din GDPR devine dificil de susținut cu dovezi fără a ști ce sisteme prelucrează date cu caracter personal, ce date prezintă risc ridicat sau aparțin unor categorii speciale, unde sunt stocate și ce măsuri de protecție se aplică.
NIS2 ridică nivelul cerințelor de guvernanță. Articolul 20 impune organelor de conducere ale entităților esențiale și importante să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să beneficieze de instruire. Articolul 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale, inclusiv analiza riscurilor, politici de securitate, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, securitatea în achiziție și dezvoltare, evaluarea eficacității, igienă cibernetică, instruire, criptografie, securitatea resurselor umane, controlul accesului și managementul activelor. Clasificarea nu este o cerință separată în acea listă. Este mecanismul decizional care face aceste măsuri proporționale.
DORA aplică aceeași logică entităților financiare și ecosistemelor fintech. Din 17 ianuarie 2025, DORA impune un cadru documentat de management al riscurilor TIC, responsabilitatea organului de conducere, politici pentru confidențialitate, integritate, disponibilitate și autenticitate, clasificarea incidentelor, testarea rezilienței și managementul riscurilor asociate terților furnizori de servicii TIC. Pentru entitățile financiare reglementate de DORA, DORA poate funcționa ca act juridic sectorial al Uniunii în locul obligațiilor suprapuse din NIS2 privind managementul riscurilor și raportarea, dar așteptarea privind dovezile rămâne aceeași: arătați cum sunt identificate, protejate, testate, monitorizate și guvernate informațiile critice și activele TIC.
ISO/IEC 27001:2022 este foarte potrivit ca sistem operațional pentru aceste dovezi. Clauzele 4.1-4.4 impun organizației să înțeleagă aspectele interne și externe, cerințele părților interesate, obligațiile de reglementare și contractuale și interfețele cu alte organizații. Clauzele 6.1.1-6.1.3 impun evaluarea riscurilor, tratarea riscurilor, selectarea controalelor, o Declarație de aplicabilitate și păstrarea dovezilor. ISO/IEC 27001:2022
Dacă GDPR, NIS2 și DORA întreabă: „De ce ați aplicat aceste măsuri?”, ISO/IEC 27001:2022 vă ajută să răspundeți: „Pentru că aceste active, tipuri de date, riscuri, obligații și decizii de tratare ne-au condus aici.”
Clasificarea este decizia de risc. Etichetarea este semnalul operațional.
Clarysec separă clasificarea de etichetare deoarece și auditorii fac această distincție.
Clasificarea este acțiunea de a decide sensibilitatea, valoarea și criticitatea informațiilor. Etichetarea este acțiunea de a face această decizie vizibilă, persistentă și aplicabilă în activitățile operaționale zilnice.
Politica de clasificare și etichetare a datelor - IMM de la Clarysec formulează clar scopul:
Această politică definește modul în care toate informațiile gestionate de organizație trebuie clasificate și etichetate pentru a asigura menținerea confidențialității, integrității și disponibilității pe întregul lor ciclu de viață.
Aceeași Politică de clasificare și etichetare a datelor - IMM impune organizațiilor să:
Solicite ca fiecare activ de date să fie clasificat în funcție de sensibilitatea sa și etichetat corespunzător pentru a ghida gestionarea, stocarea și accesul adecvate.
Pentru organizațiile complexe, P13 Politica de clasificare și etichetare a datelor de la Clarysec definește modelul minim de clasificare:
Organizația trebuie să mențină o schemă de clasificare standardizată, cu niveluri clar definite. Cel puțin, trebuie utilizate următoarele niveluri de clasificare: 5.1.1 Public: Informații destinate publicării deschise și distribuirii nerestricționate 5.1.2 Intern: Informații de afaceri nepublice, care nu sunt destinate publicării externe 5.1.3 Confidențial: Date sensibile de afaceri, contractuale sau ale clienților, care necesită control strict al accesului 5.1.4 Restricționat (sau Strict confidențial): Informații critice sau reglementate pentru care divulgarea neautorizată ar putea produce prejudicii semnificative sau răspundere juridică
Această distincție contează. O clasificare „Confidențial” poate impune criptare, acces bazat pe roluri și măsuri contractuale de protecție. O clasificare „Restricționat” poate declanșa MFA, aprobarea CISO pentru partajare externă, jurnalizare extinsă, guvernanță mai strictă a retenției, segregare și escaladarea prioritară a incidentelor.
Politica pentru organizații complexe este explicită în privința etichetării operaționale:
Toate activele informaționale trebuie etichetate într-un mod care este: 6.2.1.1 Persistent: Nu poate fi eliminat sau suprascris cu ușurință 6.2.1.2 Vizibil: Clar pentru utilizatori la punctul de utilizare 6.2.1.3 Lizibil de sistem: Acolo unde este posibil, trebuie acceptată etichetarea bazată pe metadate
Etichetele lizibile de sistem sunt punctul în care programul se maturizează de la conștientizare la aplicare. Dacă etichetele sunt bazate pe metadate, platformele cloud, sistemele DLP, gateway-urile de e-mail, instrumentele de identitate, regulile SIEM, platformele CASB și motoarele de retenție pot acționa pe baza lor. Dacă etichetele sunt doar un subsol într-un document, pot ajuta utilizatorii, dar nu pot aplica în mod fiabil regulile la scară.
Unde se încadrează clasificarea în foaia de parcurs Clarysec
Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului de la Clarysec plasează clasificarea devreme în ciclul de viață al managementului riscurilor, nu după implementarea tehnologiei. În faza de management al riscurilor, pasul 9, „Identificarea activelor, amenințărilor și vulnerabilităților”, foaia de parcurs direcționează echipele să inventarieze activele informaționale și să înregistreze proprietarul, locația și clasificarea.
Acest lucru previne o deficiență frecventă: existența unui inventar cloud, dar nu și a unui inventar al informațiilor. O bază de date, un tenant SaaS sau un depozit de date este un activ tehnologic. Înregistrările despre clienți, dosarele angajaților, jurnalele de plată, seturile de date pentru antrenarea modelelor, transcrierile de suport și dovezile privind incidentele din interiorul acestora sunt active informaționale. Clasificarea se aplică la acest nivel al informației.
Îndrumările Zenith Blueprint privind controlul ISO/IEC 27002:2022 5.12, Clasificarea informațiilor, explică principiul:
Fiecare control de securitate a informației redactat vreodată, restricția de acces, criptarea, backup-ul, monitorizarea sau eliminarea, presupune un singur lucru: că organizația știe ce protejează. Controlul 5.12 impune ca informațiile să fie clasificate pe baza valorii, sensibilității și criticității lor, formând fundamentul tuturor deciziilor ulterioare din SMSI.
Pentru controlul ISO/IEC 27002:2022 5.13, Etichetarea informațiilor, aceeași foaie de parcurs transformă clasificarea în comportament zilnic:
Etichetarea este modul în care transformați politica abstractă în realitate operațională. Este momentul în care un utilizator, văzând un document, un e-mail, un câmp de bază de date sau un raport tipărit, poate înțelege dintr-o privire: ce este această informație, cât de sensibilă este și cum trebuie tratată.
Conexiunea finală din foaia de parcurs apare la pasul 13, „Planificarea tratării riscurilor și Declarația de aplicabilitate”. Zenith Blueprint descrie SoA ca puntea dintre riscuri, tratamente și controale. Aici clasificarea devine trasabilitate de audit. Un scenariu de risc precum „divulgarea neautorizată a datelor financiare ale clienților din spații de stocare cloud partajate” poate fi mapat la clasificare, etichetare, controlul accesului, criptare, jurnalizare, DLP, utilizarea serviciilor cloud, cerințe pentru furnizori și răspuns la incidente.
Relațiile dintre controale pe care auditorii se așteaptă să le vadă
În Zenith Controls: ghidul de conformitate transversală de la Clarysec, controlul ISO/IEC 27002:2022 5.12, Clasificarea informațiilor, este mapat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea. Este asociat cu conceptul de securitate cibernetică Identify, capabilitatea operațională de protecție a informațiilor și domeniile de securitate Protecție și apărare.
Pentru controlul ISO/IEC 27002:2022 5.13, Etichetarea informațiilor, Zenith Controls mapează controlul ca preventiv, axat pe Protect, cu aceleași proprietăți de securitate a informației și aceeași capabilitate operațională de protecție a informațiilor.
Ideea esențială este că clasificarea și etichetarea nu sunt izolate. Ele fac controalele din jur justificabile.
| Arie de control ISO/IEC 27002:2022 | De ce depinde de clasificare sau etichetare | Dovezi pe care le poate solicita un auditor |
|---|---|---|
| 5.9 Inventarul informațiilor și al altor active asociate | Metadatele de clasificare trebuie să fie un câmp de bază în inventarul activelor | Registrul activelor care arată proprietarul, locația, starea ciclului de viață și clasificarea |
| 5.12 Clasificarea informațiilor | Definește sensibilitatea, valoarea și criticitatea | Schemă de clasificare aprobată, criterii, exemple și înregistrări ale revizuirilor |
| 5.13 Etichetarea informațiilor | Face clasificarea vizibilă și aplicabilă | Configurația etichetelor, exemple de fișiere etichetate, etichete de e-mail, etichete SaaS și îndrumări pentru utilizatori |
| 5.14 Transferul informațiilor | Determină dacă sunt necesare aprobarea, criptarea sau restricționarea partajării externe | Reguli de transfer pe niveluri de clasificare, canale aprobate și înregistrări ale excepțiilor |
| 5.15 Controlul accesului | Permisiunile de acces trebuie să urmeze limitele de clasificare | Matrice de roluri, revizuiri ale drepturilor de acces, reguli privind accesul privilegiat și istoricul aprobărilor |
| 5.25 Evaluarea și decizia privind evenimentele de securitate a informației | Severitatea incidentului depinde parțial de sensibilitatea datelor afectate | Criterii de triaj al incidentelor care utilizează clasificarea și criticitatea serviciului |
| 5.34 Confidențialitatea și protecția informațiilor cu caracter personal (PII) | Categoriile de date cu caracter personal necesită gestionare specifică pentru protecția datelor | Registru PII, maparea temeiurilor juridice, reguli de retenție și controale pentru persoanele împuternicite |
| 8.15 Jurnalizare | Accesul la date Restricționate necesită trasabilitate mai puternică | Jurnale de acces la date, setări de păstrare a jurnalelor și dovezi ale revizuirii |
| 8.16 Activități de monitorizare | Prioritatea monitorizării se schimbă când sunt accesate date Restricționate | Cazuri de utilizare SIEM, praguri de alertare și înregistrări de escaladare |
Zenith Controls mapează controlul 5.12 la articolul 32 din GDPR și considerentul 83, articolul 21(2)(a) și 21(2)(f) din NIS2, ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 și PM-11, FIPS 199 și NIST SP 800-60, precum și COBIT 2019 DSS06.06 și APO13.01. Mapează controlul 5.13 la articolul 32 din GDPR, articolul 21(2)(a) și 21(2)(f) din NIS2, articolul 9(1) și 9(2) din DORA, NIST SP 800-53 MP-3 și COBIT 2019 DSS06.06.
Aceasta înseamnă că un singur set de dovezi poate răspunde mai multor întrebări de asigurare.
| Motor de conformitate | Contribuția clasificării și etichetării | Dovadă practică |
|---|---|---|
| Articolul 32 din GDPR | Arată ce date cu caracter personal necesită măsuri de protecție pentru confidențialitate, integritate, disponibilitate și reziliență | Clasificarea PII, reguli de criptare, restricții de acces, maparea retenției și criterii de triaj al încălcărilor |
| Articolul 21 din NIS2 | Susține analiza riscurilor, politicile de securitate, evaluarea eficacității, controlul accesului, managementul activelor și măsurile proporționale | Politică aprobată de conducere, inventarul activelor, instruire, metrici de revizuire și reguli de gestionare testate |
| Managementul riscurilor TIC conform DORA | Susține identificarea și protecția informațiilor și a activelor TIC, clasificarea incidentelor și riscul asociat terților furnizori de servicii TIC | Registrul activelor TIC, criticitatea datelor, cerințe contractuale pentru furnizori, domeniul de testare și criterii de severitate a incidentelor |
| NIST CSF 2.0 | Susține rezultatele GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER | Profiluri curente și țintă cu lacune de clasificare și acțiuni de remediere prioritizate |
| COBIT 2019 | Susține guvernanța și controalele de proces pentru securitate, gestionarea datelor și operarea controalelor | Obiective de control, responsabilitatea procesului, testarea de asigurare și gestionarea excepțiilor |
Registrul activelor este locul în care clasificarea devine dovadă
Multe programe de clasificare eșuează deoarece schema de clasificare există doar într-o politică. Abordarea Clarysec începe cu inventarul activelor.
P12 Politica de management al activelor de la Clarysec impune ca inventarul activelor să includă nivelul de clasificare ca un câmp minim:
Inventarul activelor trebuie să conțină, cel puțin: 5.3.1 ID-ul activului, categoria și tipul 5.3.2 Numărul de serie sau eticheta unică (pentru active fizice) 5.3.3 Versiunea software sau cheia de licență (pentru active software) 5.3.4 Proprietarul activului 5.3.5 Nivelul de clasificare (Public, Intern, Confidențial, Restricționat) 5.3.6 Locația (fizică, virtuală, cloud) 5.3.7 Starea ciclului de viață (activ, în mentenanță, scos din uz)
Acest lucru se aliniază direct cu planificarea riscurilor din ISO/IEC 27001:2022. Dacă nu puteți identifica activul informațional, proprietarul, locația și clasificarea, nu puteți evalua consecvent probabilitatea, impactul, prioritatea tratării sau riscul rezidual. De asemenea, nu puteți decide cu încredere dacă un aranjament cu un furnizor, un serviciu cloud sau o integrare SaaS afectează informații reglementate.
Pentru GDPR, acest lucru susține responsabilitatea. Evidențele activităților de prelucrare din articolul 30 și măsurile de securitate din articolul 32 devin mai credibile atunci când registrul activelor identifică unde sunt prelucrate datele cu caracter personal și cum sunt protejate. Pentru DORA, același registru susține criticitatea activelor și serviciilor TIC, domeniul testării rezilienței și analiza dependențelor de terți. Pentru NIS2, susține analiza riscurilor, controlul accesului și managementul activelor.
| Câmp | Exemplu de înregistrare |
|---|---|
| Numele activului | Baza de date pentru facturarea clienților |
| Proprietarul activului | Șeful departamentului Platform Engineering |
| Proces de afaceri | Facturarea abonamentelor și emiterea facturilor |
| Locație | Regiune cloud UE, serviciu de bază de date administrat |
| Clasificare | Restricționat |
| Categorii de date | Identificatori ai clienților, date de contact pentru facturare, referințe de tranzacții |
| Relevanță GDPR | Date cu caracter personal, contexte de operator și persoană împuternicită |
| Criticitate | Susține operațiunile de venituri și serviciul pentru clienți |
| Controale-cheie | MFA, criptare în repaus, criptare în tranzit, aprobarea accesului privilegiat, jurnalizare de audit, testarea backup-urilor |
| Dependență de furnizor | Furnizor de baze de date cloud, procesator de plăți |
| Cadența revizuirii | Revizuirea trimestrială a accesului, revizuirea anuală a clasificării, revizuire la schimbarea sistemului |
Acest tip de înregistrare schimbă tonul unui audit. În loc să spună „Credem că datele sensibile sunt protejate”, organizația poate arăta ce sunt datele, cine le deține, de ce sunt Restricționate, ce controale se aplică și când au fost revizuite ultima dată acele controale.
Etichetele trebuie să determine regulile de gestionare în cloud și SaaS
Majoritatea datelor sensibile circulă acum prin platforme cloud, aplicații SaaS, fluxuri de analiză și instrumente de colaborare. O politică ce le spune utilizatorilor să „gestioneze cu atenție datele confidențiale” nu este suficientă.
P27 Politica de utilizare a serviciilor cloud de la Clarysec conectează utilizarea serviciilor cloud direct la clasificare și rezidența datelor:
Clasificarea și rezidența datelor 6.6.1 Nicio dată nu poate fi mutată pe o platformă cloud fără clasificare conform Politicii de clasificare și etichetare a datelor (P13). 6.6.2 Cerințele privind rezidența datelor trebuie impuse contractual (de exemplu, stocare exclusiv în UE pentru date reglementate de GDPR). 6.6.3 Transferurile transfrontaliere de date trebuie să respecte capitolul V din GDPR și, după caz, articolul 28 din DORA.
Acest lucru contează deoarece riscul cloud apare adesea din comoditate. O echipă exportă un set de date către un nou instrument de analiză. Echipa de vânzări sincronizează liste de clienți într-o platformă de automatizare. Un dezvoltator copiază date de producție într-un mediu de testare. Fără clasificare și etichetare, aceste acțiuni pot să nu declanșeze revizuire juridică, aprobare de securitate sau verificări ale furnizorilor.
Politica de clasificare și etichetare a datelor - IMM oferă organizațiilor mai mici un model simplu de implementare:
Folderele partajate sau unitățile cloud trebuie să utilizeze nume de foldere sau etichete pentru a indica clasificarea (de exemplu, „/Clients_Confidential”).
Pentru medii mature, numele folderelor trebuie completate cu etichete lizibile de sistem, politici de acces condiționat, blocări ale partajării externe, criptare, etichete de retenție, reguli DLP și jurnalizare. Scopul nu este doar etichetarea informației. Scopul este ca eticheta să poată declanșa acțiuni de control.
O etichetă „Restricționat” poate declanșa blocarea partajării externe, criptare în repaus și în tranzit, MFA, restricții de descărcare pe dispozitive neadministrate, păstrarea jurnalelor de audit, alerte SIEM, reguli de retenție, limite privind locația furnizorilor și escaladarea severității incidentelor.
P13 Politica de clasificare și etichetare a datelor stabilește baza de referință:
Toate activitățile de gestionare, transmitere, acces, stocare și eliminare a informațiilor trebuie să fie aliniate nivelului lor de clasificare. Cel puțin: 6.3.1.1 Public: Poate fi divulgat liber; nu este necesară o gestionare specială 6.3.1.2 Intern: Partajat în cadrul organizației; stocat în sisteme interne securizate 6.3.1.3 Confidențial: 6.3.1.3.1 Acces restricționat numai la personal autorizat 6.3.1.3.2 Trebuie criptat în tranzit și în repaus 6.3.1.3.3 Poate fi partajat extern numai în baza unui NDA sau a unor măsuri contractuale echivalente de protecție 6.3.1.4 Restricționat: 6.3.1.4.1 Se aplică cele mai ridicate cerințe de securitate 6.3.1.4.2 Sunt necesare controale puternice de acces, autentificare multifactor (MFA) și jurnalizare de audit 6.3.1.4.3 Segregare fizică și logică acolo unde este fezabil 6.3.1.4.4 Partajarea externă este interzisă fără aprobarea CISO
Fiecare etichetă are un comportament. Fiecare comportament are un control. Fiecare control are dovezi.
Un exemplu practic de aplicare
Luați în considerare un analist fintech care creează Q3_2026_Customer_Churn_Analysis.xlsx. Foaia de calcul include ID-uri de clienți, volume de tranzacții și scorare predictivă a riscului de churn.
Analistul o clasifică drept Confidențial deoarece conține date despre clienți și analiză strategică. Utilizând instrumentul de protecție a informațiilor al companiei, analistul aplică eticheta Confidențial. Deoarece eticheta este persistentă, vizibilă și lizibilă de sistem, controalele se activează automat.
Fișierul este criptat în repaus pe dispozitiv și în stocarea cloud. Un antet vizibil îl marchează ca fiind Confidențial. Când analistul încearcă să îl sincronizeze cu o unitate cloud personală, o regulă DLP blochează acțiunea și jurnalizează tentativa. Când analistul încearcă să îl trimită prin e-mail către un domeniu extern care nu aparține unui partener, gateway-ul de e-mail plasează mesajul în carantină și alertează operațiunile de securitate. Dacă fișierul este ulterior reclasificat ca Restricționat deoarece conține date reglementate privind tranzacții financiare, partajarea externă este dezactivată, cu excepția cazului în care CISO sau proprietarul datelor aprobă excepția.
Aceasta este dovada pe care o dorea CEO. Este trasabilă, automatizată și legată de o politică aprobată de consiliul de administrație. De asemenea, este aliniată cu P27 Politica de utilizare a serviciilor cloud, deoarece nicio mutare în cloud nu este permisă fără clasificare, iar transferurile transfrontaliere trebuie să respecte capitolul V din GDPR și, după caz, articolul 28 din DORA.
Construiți într-o săptămână o matrice clasificare-control
Un program complet necesită timp, dar un sprint concentrat poate crea coloana vertebrală a dovezilor înaintea unui audit, a unei revizuiri de client sau a unei evaluări de reglementare.
Ziua 1: Confirmați schema de clasificare
Începeți cu patru niveluri: Public, Intern, Confidențial și Restricționat. Utilizați P13 Politica de clasificare și etichetare a datelor ca bază de referință. Definiți criteriile folosind impactul asupra organizației, impactul juridic, sensibilitatea contractuală, riscul privind datele cu caracter personal, criticitatea serviciului și prejudiciul financiar.
| Clasificare | Exemple tipice | Logica riscului |
|---|---|---|
| Public | Conținut de marketing aprobat, comunicate de presă, anunțuri de angajare | Destinat distribuirii nerestricționate |
| Intern | Proceduri interne, note de proiect, anunțuri interne | Informații de afaceri nepublice |
| Confidențial | Contracte cu clienții, dosare HR, raportare financiară nepublică | Date sensibile de afaceri, contractuale sau ale clienților |
| Restricționat | Date cu caracter personal din categorii speciale, date de plată, secrete de autentificare, baze de date de producție cu clienți | Informații critice sau reglementate cu impact juridic sau organizațional semnificativ |
Ziua 2: Selectați zece active informaționale critice
Utilizați pasul 9 din Zenith Blueprint. Includeți o bază de date cu clienți, un sistem de tichete de suport, o platformă HR, un furnizor de identitate, un export de plăți, un depozit de date, un bucket de stocare de obiecte, un folder de raportare pentru consiliul de administrație, un depozit de cod sursă și un depozit de dovezi privind incidentele. Înregistrați proprietarul, locația, clasificarea și relevanța GDPR.
Ziua 3: Mapați regulile de gestionare
Definiți cerințele de gestionare pentru acces, stocare, transfer, monitorizare și eliminare.
| Clasificare | Acces | Stocare | Transfer | Monitorizare | Eliminare |
|---|---|---|---|---|---|
| Public | Roluri deschise sau aprobate pentru publicare | Canale publice aprobate | Fără restricții speciale după aprobare | Monitorizare de bază a integrității | Ștergere standard |
| Intern | Angajați și contractori aprobați | Sisteme administrate | Canale interne | Jurnale de acces standard | Calendar de retenție standard |
| Confidențial | Acces pe principiul necesității de a cunoaște | Depozite securizate aprobate | Criptare și NDA sau măsuri contractuale de protecție | Revizuirea drepturilor de acces și alerte DLP | Ștergere securizată |
| Restricționat | Principiul privilegiului minim cu MFA și aprobarea proprietarului | Sisteme segregate sau securizate prin hardening | Partajare externă interzisă, cu excepția cazului în care este aprobată | Jurnalizare de audit extinsă și alertare SIEM | Distrugere securizată verificată |
Ziua 4: Configurați o cale de aplicare tehnică
Alegeți o platformă, cum ar fi un depozit de documente cloud, un sistem de e-mail sau un serviciu de stocare de obiecte. Implementați etichete vizibile și lizibile de sistem. Configurați o regulă pentru date Confidențiale și o regulă pentru date Restricționate. De exemplu, impuneți criptarea pentru e-mailurile externe Confidențiale și blocați partajarea externă a fișierelor Restricționate.
Ziua 5: Actualizați Registrul de riscuri și SoA
Utilizați pasul 13 din Zenith Blueprint. Adăugați controalele de clasificare și etichetare în Declarația de aplicabilitate. Legați-le de riscuri precum divulgarea neautorizată, configurarea greșită a serviciilor cloud, expunerea excesivă prin furnizori, eșecul retenției datelor și subraportarea incidentelor.
Ziua 6: Testați controlul
Creați un fișier de test etichetat Restricționat. Încercați să îl partajați extern de pe un dispozitiv neadministrat. Confirmați dacă instrumentul blochează, avertizează, jurnalizează sau escaladează. Capturați capturi de ecran, intrări în jurnale și dovezi din tichete. Dacă controlul eșuează, înregistrați excepția și planul de remediere.
Ziua 7: Instruiți utilizatorii din prima linie
Instruirea trebuie să fie specifică rolului. Dezvoltatorii trebuie să știe când datele de producție nu pot fi utilizate în medii de testare. HR trebuie să înțeleagă de ce dosarele angajaților sunt Confidențiale sau Restricționate. Echipa de vânzări trebuie să știe de ce exporturile de clienți nu pot fi încărcate în instrumente SaaS neaprobate. Conducerea executivă trebuie să înțeleagă de ce pachetele pentru consiliul de administrație, fișierele de achiziție și datele investitorilor necesită o gestionare mai strictă.
Acest sprint nu finalizează întregul program, dar creează coloana vertebrală a dovezilor: politică, inventar, etichete, reguli de gestionare, aplicare tehnică, trasabilitatea riscurilor și instruire.
Cum vor testa auditorii clasificarea și etichetarea
Auditorii testează rareori clasificarea în mod izolat. Ei urmăresc datele.
Un auditor ISO/IEC 27001:2022 va conecta clasificarea cu domeniul de aplicare al SMSI, cerințele părților interesate, obligațiile legale și contractuale, evaluarea riscurilor și Declarația de aplicabilitate. Va aștepta dovezi pentru controalele ISO/IEC 27002:2022 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 și controalele tehnice relevante. Dovezile tipice includ politici aprobate, înregistrări din inventarul activelor, intrări în Registrul de riscuri, eșantioane etichetate, reguli de gestionare, revizuiri ale drepturilor de acces, constatări de audit intern și acțiuni corective.
Un revizor GDPR se va concentra pe datele cu caracter personal. Va întreba dacă datele cu caracter personal sunt identificate, dacă datele din categorii speciale sunt distinse, dacă regulile de retenție se aliniază scopului și dacă măsurile de securitate din articolul 32 sunt adecvate. Clasificarea ajută la separarea informațiilor obișnuite de afaceri de datele cu caracter personal, datele sensibile cu caracter personal, datele confidențiale ale clienților și înregistrările reglementate. Etichetarea ajută echipele operaționale să evite divulgarea accidentală, păstrarea excesivă și transferul neautorizat.
Un evaluator NIST CSF 2.0 va încadra probabil clasificarea în GOVERN, IDENTIFY și PROTECT. Poate întreba dacă profilurile curente și țintă definesc identificarea datelor sensibile, dacă aplicarea etichetelor funcționează în sistemele SaaS și cloud, dacă furnizorii gestionează datele conform clasificării și dacă prioritățile de monitorizare se ajustează în funcție de sensibilitate.
Un auditor COBIT 2019 sau un auditor care utilizează abordări ISACA va accentua obiectivele de guvernanță, responsabilitatea proceselor, proiectarea controalelor și eficacitatea operațională. Zenith Controls mapează controlul de inventar 5.9 la COBIT 2019 BAI09.01, BAI09.02 și DSS05.04 și face referire la ISACA ITAF 2204 și 2301. Pentru clasificare, Zenith Controls mapează controlul 5.12 la COBIT 2019 DSS06.06 și APO13.01, în timp ce etichetarea este mapată la DSS06.06. Auditorul va întreba cine deține procesul, cum sunt aprobate excepțiile, dacă performanța este monitorizată și dacă managementul primește raportări.
Un revizor axat pe DORA va întreba ce active informaționale susțin funcții critice sau importante, ce date sunt Restricționate, ce furnizori terți de servicii TIC stochează sau transmit acele date, dacă contractele definesc locațiile și măsurile de securitate, dacă testarea este delimitată în funcție de datele critice și dacă incidentele sunt clasificate parțial în funcție de pierderea disponibilității, autenticității, integrității și confidențialității datelor.
Dacă răspunsurile provin dintr-un singur model de dovezi pentru active și furnizori, condus de clasificare, auditurile devin mai rapide, mai consecvente și mai justificabile.
Tipare frecvente de eșec
Eșecurile de clasificare apar de obicei deoarece organizațiile tratează etichetele ca instrumente de conștientizare, nu ca semnale de control.
În primul rând, clasifică documente, dar nu baze de date, API-uri, jurnale, backup-uri, exporturi sau înregistrări SaaS. Datele sensibile dintr-un jurnal de depanare pot produce la fel de multe prejudicii ca datele sensibile dintr-o foaie de calcul.
În al doilea rând, etichetează informații, dar nu conectează etichetele la controlul accesului. O etichetă Restricționat cu acces deschis demonstrează că organizația cunoștea sensibilitatea și nu a aplicat regula de gestionare.
În al treilea rând, migrările către cloud au loc înaintea clasificării. Echipele mută date în instrumente SaaS noi fără a confirma rezidența, clauzele furnizorului, accesul persoanelor subîmputernicite, cerințele privind transferurile transfrontaliere sau drepturile de ștergere. P27 Politica de utilizare a serviciilor cloud abordează direct acest aspect prin interzicerea mutării pe platforme cloud fără clasificare.
În al patrulea rând, planurile de răspuns la incidente ignoră clasificarea. Dacă criteriile de severitate nu includ sensibilitatea datelor, echipele de incidente pierd timp pentru a descoperi ce a fost afectat în timpul unei crize. Analiza încălcărilor GDPR, gestionarea incidentelor NIS2 și clasificarea incidentelor DORA beneficiază toate de context rapid privind datele.
În al cincilea rând, SoA nu explică de ce controalele de clasificare și etichetare sunt aplicabile. Organizația poate să fi implementat etichete, dar SoA nu le conectează la articolul 32 din GDPR, articolul 21 din NIS2, riscul TIC conform DORA, contractele cu clienții sau scenarii specifice de risc.
Raportarea către management: faceți clasificarea vizibilă
NIS2 și DORA transformă securitatea cibernetică într-o problemă de responsabilitate a managementului. ISO/IEC 27001:2022 impune, de asemenea, angajamentul conducerii, alinierea politicilor, resurse, roluri și raportarea performanței. Prin urmare, metricile de clasificare trebuie să ajungă în revizuirea de management.
Metrici utile includ:
- Procentul activelor informaționale critice cu proprietari desemnați.
- Procentul activelor cu clasificare aprobată.
- Numărul activelor Restricționate fără jurnalizare extinsă.
- Numărul depozitelor Confidențiale sau Restricționate cu partajare externă activată.
- Procentul furnizorilor care prelucrează date Confidențiale sau Restricționate cu clauze contractuale actualizate.
- Numărul excepțiilor de clasificare și al acțiunilor de remediere restante.
- Incidente DLP pe etichetă.
- Finalizarea revizuirii accesului pentru active Restricționate.
- Locațiile de stocare cloud pentru date reglementate de GDPR.
- Exerciții de răspuns la incidente care au utilizat criterii de severitate bazate pe clasificare.
Aceste metrici susțin revizuirea de management ISO/IEC 27001:2022, supravegherea managementului conform NIS2, raportarea de guvernanță DORA și programele de asigurare solicitate de clienți. De asemenea, fac clasificarea ușor de înțeles pentru conducerea executivă. Conducerea poate acționa mai rapid atunci când vede că mai multe depozite Restricționate nu au recuperare testată sau că furnizorii critici prelucrează date despre clienți fără stocare confirmată în UE.
De la politică la dovadă
Modelul de implementare Clarysec este condus de dovezi:
- Definiți schema de clasificare în P13 Politica de clasificare și etichetare a datelor sau începeți cu Politica de clasificare și etichetare a datelor - IMM.
- Adăugați clasificarea în inventarul activelor utilizând P12 Politica de management al activelor.
- Aplicați restricțiile cloud și cerințele de rezidență prin P27 Politica de utilizare a serviciilor cloud.
- Utilizați pasul 9 din Zenith Blueprint pentru a identifica activele informaționale, proprietarii, locațiile și sensibilitatea.
- Utilizați pasul 13 din Zenith Blueprint pentru a mapa riscurile la controale în SoA.
- Utilizați pasul 22 din Zenith Blueprint pentru a implementa controalele ISO/IEC 27002:2022 5.12 și 5.13 în activitățile operaționale zilnice.
- Utilizați Zenith Controls pentru a mapa aceleași dovezi la GDPR, NIS2, DORA, NIST CSF, COBIT 2019 și standardele suport.
- Testați aplicarea etichetelor, restricțiile de acces, jurnalizarea, DLP și triajul incidentelor.
- Raportați performanța clasificării către management.
- Revizuiți clasificarea după schimbări majore de sistem, proces, furnizor sau reglementare.
Acest lucru funcționează deoarece clasificarea devine limbajul comun dintre valoarea de business, obligația juridică, controlul tehnic și dovezile de audit.
Dacă organizația dumneavoastră se pregătește pentru certificarea ISO/IEC 27001:2022, asigurare GDPR, pregătire NIS2, verificare prealabilă DORA solicitată de clienți sau un audit combinat de conformitate, începeți cu o întrebare:
Puteți arăta, pentru fiecare activ informațional critic, ce este, cine îl deține, unde se află, cum este clasificat, cum este etichetat, cine îl poate accesa, cum este protejat, cât timp este păstrat, ce furnizor îl atinge și ce se întâmplă dacă este expus?
Dacă răspunsul este încă nu, Clarysec vă poate ajuta să construiți rapid și justificabil lanțul de dovezi.
Utilizați Politica de clasificare și etichetare a datelor - IMM, P13 Politica de clasificare și etichetare a datelor, P12 Politica de management al activelor, P27 Politica de utilizare a serviciilor cloud, Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului și Zenith Controls: ghidul de conformitate transversală pentru a transforma clasificarea dintr-o politică statică într-un strat operațional de control pentru articolul 32 din GDPR, managementul riscurilor de securitate cibernetică conform NIS2 și dovezile privind riscurile TIC conform DORA.
Cel mai bun moment pentru clasificarea datelor a fost înainte de sosirea solicitării de audit. Următorul cel mai bun moment este înainte de următoarea migrare către cloud, integrare a furnizorilor, chestionar de client sau incident.
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
