Gestionarea cheilor criptografice pentru ISO 27001, NIS2 și DORA

La ora 08:17, într-o dimineață de luni, CISO-ul unei companii SaaS europene primește un mesaj de la responsabilul de inginerie: „Am rotit cheia de criptare a bazei de date în weekend, dar o integrare nu mai poate decripta înregistrările. Am revenit la o cheie veche din seif.”

Zece minute mai târziu, DPO-ul întreabă dacă înregistrările afectate includ date cu caracter personal din UE. Departamentul financiar întreabă dacă situația ar putea deveni un incident operațional raportabil pentru un client reglementat. Achizițiile întreabă dacă furnizorul cloud sau compania deține cheia gestionată de client. CEO-ul pune singura întrebare care contează în consiliul de administrație: „Putem demonstra că am gestionat corect situația?”

Acesta este momentul în care „folosim criptare” încetează să mai fie o formulare liniștitoare și devine o problemă de dovezi.

În 2026, gestionarea cheilor criptografice se află la intersecția dintre controalele ISO/IEC 27001:2022, igiena cibernetică NIS2, gestionarea riscurilor TIC conform DORA, dovezile privind securitatea prelucrării din GDPR Article 32, responsabilitatea partajată în cloud și planificarea agilității criptografice post-cuantice. Problema reală nu este dacă există criptare. Problema reală este dacă organizația poate demonstra, prin înregistrări, că cheile sunt generate securizat, au proprietari desemnați, sunt stocate în medii KMS sau HSM aprobate, sunt rotite conform calendarului, sunt recuperate în siguranță, sunt revocate atunci când sunt compromise și sunt mapate la riscurile organizației.

Clarysec observă în mod repetat același tipar în activitățile de pregătire. Criptarea este implementată sistem cu sistem, dar guvernanța cheilor este fragmentată. Certificatele sunt ținute în foi de calcul. Permisiunile KMS din cloud sunt moștenite din proiecte vechi. Dezvoltatorii știu ce secrete contează, dar SMSI nu le reflectă. Auditorii primesc capturi de ecran în loc de dovezi privind ciclul de viață. Echipele NIS2 și DORA discută despre reziliență, echipele de protecția datelor discută despre criptarea și pseudonimizarea din GDPR, iar nimeni nu deține cap-coadă planul de control criptografic.

Un răspuns matur nu înseamnă mai multă criptografie izolată. Înseamnă gestionarea guvernată a cheilor criptografice, conectată la tratarea riscurilor, arhitectura cloud, supravegherea furnizorilor, controlul accesului, jurnalizare, răspuns la incidente și dovezi de reglementare.

De ce gestionarea cheilor este acum o problemă de guvernanță

NIS2 include politicile privind criptografia și criptarea în setul minim de măsuri de gestionare a riscurilor de securitate cibernetică pentru entitățile esențiale și importante. Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea, securitatea lanțului de aprovizionare, dezvoltarea securizată, igiena cibernetică, controlul accesului, politica de gestionare a activelor și politici privind criptografia și criptarea. De asemenea, impune organelor de conducere să aprobe și să supravegheze măsurile de gestionare a riscurilor de securitate cibernetică.

Pentru furnizorii SaaS, cloud, servicii administrate și securitate cibernetică, aplicabilitatea poate fi mai largă decât presupun multe echipe. NIS2 acoperă sectoare precum infrastructura digitală, furnizorii de servicii de cloud computing, furnizorii de centre de date, furnizorii DNS, furnizorii de servicii de încredere, furnizorii de servicii administrate, furnizorii de servicii de securitate administrate, piețele online, motoarele de căutare și platformele de rețele sociale, atunci când sunt îndeplinite pragurile de dimensiune sau criticitate.

DORA ridică nivelul cerințelor pentru entitățile financiare. Din 17 ianuarie 2025, DORA impune un cadru documentat de gestionare a riscurilor TIC, responsabilitate la nivelul consiliului, continuitatea activității TIC și planuri de răspuns și recuperare, testarea rezilienței operaționale digitale, gestionarea riscurilor TIC asociate terților și raportarea incidentelor. Pentru entitățile financiare identificate conform normelor naționale NIS2, DORA funcționează ca act juridic sectorial al Uniunii pentru obligațiile echivalente NIS2. O companie fintech nu trebuie să opereze guvernanță criptografică separată pentru NIS2, DORA și ISO. Are nevoie de un singur model de control defensabil.

GDPR adaugă dimensiunea dovezilor privind protecția datelor. GDPR Article 32 este cadrul în care criptarea este evaluată frecvent ca măsură de protecție pentru securitatea prelucrării, dar „datele sunt criptate” nu este un răspuns complet. Autoritățile de reglementare și auditorii întreabă cine controlează cheile, cum este restricționat accesul, cum este detectată compromiterea, cum funcționează recuperarea și dacă proiectarea corespunde riscului pentru persoanele vizate.

ISO/IEC 27001:2022 oferă organizațiilor sistemul de management care leagă aceste obligații. Clauzele 4.1–4.4 impun contextul, cerințele părților interesate, domeniul de aplicare al SMSI și procesele care interacționează. Clauzele 5.1–5.3 impun leadership, politică, resurse și responsabilități alocate. Clauzele 6.1.1–6.1.3 impun evaluarea riscurilor, tratarea riscurilor, selectarea controalelor, o Declarație de aplicabilitate și aprobarea proprietarului de risc. Clauzele 8.1–8.3 impun operarea controlată, reevaluarea riscurilor atunci când apar schimbări, implementarea planurilor de tratare și păstrarea rezultatelor documentate.

Pentru gestionarea cheilor criptografice, SMSI trebuie să răspundă la cinci întrebări:

1. Ce active informaționale, fluxuri de date și servicii necesită protecție criptografică?
2. Ce chei, certificate, secrete și servicii criptografice le protejează?
3. Cine deține, administrează, aprobă și monitorizează aceste active criptografice?
4. Cum sunt controlate generarea, stocarea, utilizarea, rotația, escrow-ul, recuperarea, revocarea și distrugerea?
5. Ce dovezi arată că aceste controale au funcționat conform proiectării?

Coloana vertebrală a controalelor ISO 27001 pentru gestionarea cheilor criptografice

Clarysec tratează gestionarea cheilor criptografice ca un lanț de controale, nu ca un control unic. În Zenith Controls: The Cross-Compliance Guide Zenith Controls, subiectul se mapează în principal la controlul 8.24 din ISO/IEC 27002:2022, utilizarea criptografiei, cu relații de suport importante cu 5.17, informații de autentificare, și 5.23, securitatea informației pentru utilizarea serviciilor cloud.

Această relație contează. Un eșec de gestionare a cheilor este rareori doar „criptare slabă”. Este adesea o problemă de autentificare, o problemă de guvernanță cloud, o problemă de furnizor, o lacună de jurnalizare sau un eșec de management al schimbărilor.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint transformă acest lucru în practică în faza de gestionare a riscurilor, pasul 14, politici de tratare a riscurilor și referințe încrucișate de reglementare. Exemplul său de politică de criptografie afirmă că organizația trebuie să definească unde este necesară criptografia, să aprobe algoritmi și protocoale, să definească gestionarea cheilor, să acopere cazuri de utilizare precum criptarea completă a discului și comunicațiile securizate și să conecteze politica la GDPR Article 32.

„Cheile de criptare trebuie stocate în siguranță (de exemplu, într-un seif de chei/HSM), iar accesul trebuie limitat la personalul autorizat.”
Atribuire: Zenith Blueprint, faza de gestionare a riscurilor, pasul 14, politici de tratare a riscurilor și referințe încrucișate de reglementare Zenith Blueprint

În faza de controale în acțiune, pasul 20, Zenith Blueprint merge mai în profunzime. Criptografia nu înseamnă „activarea criptării”. Înseamnă integrarea criptografiei în proiectare, politică și managementul ciclului de viață. Aceasta include date în repaus, date în tranzit, autentificarea identităților și tranzacțiilor, algoritmi aprobați, seifuri pentru chei, HSM, rotație programată, revocare și validare prin testare de penetrare și revizuirea codului.

Ce așteaptă auditorii atunci când solicită dovezi privind cheile

Cele mai multe constatări de audit încep cu o solicitare simplă: „Arătați-mi politica de criptare și înregistrările de gestionare a cheilor.”

Răspunsurile slabe includ:

• „Furnizorul cloud criptează totul implicit.”
• „Folosim TLS.”
• „Secretele sunt în seif.”
• „Echipa de inginerie se ocupă de rotație.”
• „Cheia este gestionată de aplicație.”

Aceste afirmații pot fi adevărate tehnic, dar nu reprezintă dovezi complete. Un auditor ISO va lega gestionarea cheilor de evaluarea riscurilor, Declarația de aplicabilitate, cerințele de politică, controlul operațional și documentația păstrată. Un evaluator NIST CSF va întreba dacă activele criptografice sunt identificate, protejate, monitorizate și recuperate. Un auditor DORA va căuta guvernanță a riscurilor TIC aprobată de consiliu, dependențe de terți, gestionarea incidentelor și testarea rezilienței. Un revizor GDPR va întreba dacă criptarea și separarea cheilor reduc riscul pentru persoanele vizate și dacă operatorul poate demonstra responsabilitatea.

Politica privind controalele criptografice pentru întreprinderi a Clarysec Politica privind controalele criptografice tratează direct lacuna de dovezi:

„Trebuie menținut un Registru centralizat de gestionare a cheilor pentru a înregistra toate cheile criptografice, starea ciclului lor de viață, custozii desemnați și contextele de utilizare.”
Atribuire: politică pentru întreprinderi, Politica privind controalele criptografice, Cerințe de guvernanță, clauza 5.2 Politica privind controalele criptografice

Această frază schimbă conversația de audit. În loc să urmărească informații deținute informal de echipe, organizația poate prezenta un registru care leagă cheile de active, proprietari, clasificări ale datelor, sisteme, conturi cloud, date de rotație, contexte de utilizare și dovezi.

Pentru IMM-uri, Cryptographic Controls Policy-sme a Clarysec Cryptographic Controls Policy-sme - IMM adaptează aceeași așteptare:

„Furnizorul de suport IT trebuie să mențină un inventar actualizat al instrumentelor criptografice și al certificatelor utilizate”
Atribuire: politică pentru IMM, Cryptographic Controls Policy-sme, Cerințe de guvernanță, clauza 5.1.2 Cryptographic Controls Policy-sme - IMM

O instituție financiară reglementată poate avea nevoie de ceremonii HSM, cunoaștere împărțită, control dual, desemnări formale ale custozilor și revizuirea trimestrială a accesului. Un furnizor SaaS mic poate începe cu un inventar menținut, algoritmi aprobați, proprietate KMS documentată și dovezi de rotație. Ambele au nevoie de guvernanță proporțională cu riscul.

Ciclul de viață al cheilor pe care SMSI trebuie să îl controleze

Un program practic de gestionare a cheilor urmează ciclul de viață. Fiecare etapă are nevoie de un proprietar, o metodă aprobată, un control tehnic, o înregistrare de schimbare și dovezi de audit.

Politica privind controalele criptografice pentru întreprinderi consolidează generarea securizată:

„Generarea cheilor: efectuată utilizând module hardware sau software securizate (de exemplu, HSM, sisteme validate FIPS 140-2).”
Atribuire: politică pentru întreprinderi, Politica privind controalele criptografice, Cerințe de implementare a politicii, clauza 6.3.1 Politica privind controalele criptografice

Aceasta specifică și rotația:

„Rotația cheilor: obligatorie la intervale definite sau imediat după compromitere ori schimbarea rolului.”
Atribuire: politică pentru întreprinderi, Politica privind controalele criptografice, Cerințe de implementare a politicii, clauza 6.3.4 Politica privind controalele criptografice

Pentru IMM-uri, același principiu apare într-un limbaj operațional mai simplu:

„Rotația cheilor trebuie efectuată conform calendarelor de expirare sau la suspiciunea de compromitere”
Atribuire: politică pentru IMM, Cryptographic Controls Policy-sme, Cerințe de implementare a politicii, clauza 6.3.4 Cryptographic Controls Policy-sme - IMM

Aceste clauze contează pentru NIS2 și DORA deoarece cheile învechite sau guvernate deficitar nu sunt doar puncte slabe de confidențialitate. Ele pot deveni blocaje în răspunsul la incidente, probleme de risc de dependență față de furnizori, eșecuri de recuperare în caz de dezastru și probleme de notificare a clienților.

KMS cloud, HSM și BYOK: capcana responsabilității partajate

Criptarea în cloud este una dintre cele mai frecvente surse de asigurare falsă. Un furnizor cloud poate cripta implicit spațiile de stocare, dar acest lucru nu înseamnă automat că organizația a guvernat cheia.

Zenith Blueprint, faza de controale în acțiune, pasul 23, explică controlul 5.23 din ISO/IEC 27002:2022 prin accent pe guvernanță cloud, vizibilitate și responsabilitate partajată. Acesta subliniază că furnizorul poate securiza infrastructura, dar clientul rămâne responsabil pentru date, configurații, politici de acces și pregătirea pentru răspuns la incidente.

„Furnizorii cloud securizează infrastructura, dar rămâneți responsabil pentru datele dumneavoastră, configurațiile dumneavoastră, politicile dumneavoastră de acces și pregătirea dumneavoastră pentru răspuns la incidente.”
Atribuire: Zenith Blueprint, faza de controale în acțiune, pasul 23, controale organizaționale 5.19-5.37 Zenith Blueprint

Aici responsabilitatea pentru cheile cloud devine un risc la nivelul consiliului. O companie SaaS poate utiliza criptare gestionată de furnizor pentru jurnale cu risc redus, chei gestionate de client pentru baze de date ale clienților, BYOK pentru chiriași reglementați și chei rădăcină susținute de HSM pentru semnare sau tokenizare. Fiecare opțiune are implicații de conformitate.

Politica de utilizare a serviciilor cloud pentru întreprinderi a Clarysec Politica de utilizare a serviciilor cloud oferă o direcție clară de control:

„Cheile gestionate de client (CMK) sau aducerea propriei chei (BYOK) se utilizează acolo unde sunt acceptate de furnizorul cloud.”
Atribuire: politică pentru întreprinderi, Politica de utilizare a serviciilor cloud, Cerințe de implementare a politicii, clauza 6.4.2 Politica de utilizare a serviciilor cloud

Aceasta nu înseamnă că fiecare serviciu cloud trebuie să utilizeze BYOK. Înseamnă că organizația trebuie să decidă deliberat, pe baza riscului, angajamentelor față de clienți, cerințelor contractuale și recuperabilității.

DORA Article 28 și Article 30 fac acest aspect deosebit de relevant pentru entitățile financiare. Acestea impun gestionarea riscurilor TIC asociate terților, registre ale acordurilor contractuale TIC, due diligence, drepturi de audit și inspecție, asistență în caz de incident, protecția datelor și acces, precum și prevederi privind recuperarea și returnarea. Dacă un furnizor cloud sau SaaS gestionează chei de criptare pentru o funcție critică sau importantă, relația respectivă trebuie să fie vizibilă în registrul terților TIC și în controalele contractuale.

NIS2 impune, de asemenea, securitatea lanțului de aprovizionare, inclusiv vulnerabilități specifice furnizorilor, practici de securitate cibernetică și proceduri de dezvoltare securizată. Dacă un furnizor critic deține cheile, operează KMS-ul, furnizează HSM-ul, gestionează ciclul de viață al certificatelor sau găzduiește backup-uri criptate, furnizorul face parte din mediul dumneavoastră de control criptografic.

Aprobarea algoritmilor și agilitatea criptografică în 2026

O politică de gestionare a cheilor în 2026 nu trebuie doar să enumere „AES-256” și „TLS 1.2 sau versiuni ulterioare”. Trebuie să stabilească un proces de aprobare și revizuire care susține agilitatea criptografică. Agilitatea criptografică înseamnă că organizația poate identifica unde sunt utilizați algoritmii, protocoalele, certificatele și lungimile cheilor, poate evalua expunerea la puncte slabe sau depreciere și poate migra fără panică.

Politica Clarysec pentru IMM-uri prevede:

„Pot fi utilizați doar algoritmii și protocoalele conforme cu bunele practici din industrie, aprobate de furnizorul de suport IT (de exemplu, AES-256, RSA 2048, TLS 1.2 sau versiuni ulterioare)”
Atribuire: politică pentru IMM, Cryptographic Controls Policy-sme, Cerințe de implementare a politicii, clauza 6.2.1 Cryptographic Controls Policy-sme - IMM

Aceasta impune și documentarea:

„Toate metodele de criptare (de exemplu, AES-256, TLS 1.2+) și procesele de gestionare a cheilor trebuie documentate”
Atribuire: politică pentru IMM, Cryptographic Controls Policy-sme, Cerințe de guvernanță, clauza 5.3.1 Cryptographic Controls Policy-sme - IMM

Versiunea capabilă să susțină un audit este un standard criptografic aprobat care include:

• Algoritmi și protocoale permise pentru date în repaus, date în tranzit, semnături, hash-uri de parole, tokenizare și backup-uri.
• Algoritmi, protocoale și biblioteci interzise.
• Lungimi minime ale cheilor și perioade de valabilitate ale certificatelor.
• Platforme KMS, HSM, autoritate de certificare și instrumente de gestionare a secretelor aprobate.
• Cerințe privind generarea securizată a numerelor aleatoare.
• Îndrumări pentru dezvoltatori privind bibliotecile criptografice.
• Proces de solicitare a excepțiilor pentru sisteme moștenite.
• Declanșatori de revizuire pentru vulnerabilități, schimbări de reglementare, schimbări de furnizor și planificarea tranziției post-cuantice.

Planificarea post-cuantică nu impune fiecărei organizații să înlocuiască imediat toată criptografia. Impune însă inventariere. Fără un inventar criptografic, nu puteți ști ce sisteme utilizează criptare cu cheie publică pe termen lung, ce certificate protejează servicii critice, unde se află cheile de semnare sau ce furnizori trebuie să susțină migrarea. Registrul de gestionare a cheilor nu este birocrație. Este fundația agilității criptografice.

Un sprint de 90 de minute pentru dovezile privind gestionarea cheilor

Clarysec utilizează adesea un sprint scurt de colectare a dovezilor împreună cu echipele de conducere, securitate, cloud și conformitate. Scopul este transformarea rapidă a cunoștințelor dispersate despre chei în dovezi de audit.

Pasul 1: Selectați un serviciu critic

Alegeți un sistem relevant pentru NIS2, DORA sau GDPR. Exemplele includ identitatea clienților, procesarea plăților, monitorizarea tranzacțiilor, baza de date de producție a clienților, platforma de backup criptat sau API-ul destinat clienților.

Pasul 2: Deschideți Registrul de gestionare a cheilor

Utilizați cerința din Politica privind controalele criptografice pentru un registru centralizat ca structură. Dacă nu aveți încă unul, creați un registru simplu cu următoarele câmpuri:

Pasul 3: Urmăriți accesul și controlul dual

Pentru operațiuni criptografice cu impact ridicat, aplicați controlul dual și principiul privilegiului minim. Politica privind controalele criptografice pentru întreprinderi prevede:

„Principiile de control dual și privilegiu minim trebuie aplicate operațiunilor criptografice sensibile (de exemplu, importuri de chei rădăcină, administrare HSM).”
Atribuire: politică pentru întreprinderi, Politica privind controalele criptografice, Cerințe de implementare a politicii, clauza 6.6.2 Politica privind controalele criptografice

Întrebați:

• Cine poate dezactiva sau șterge cheia?
• Cine poate modifica politica cheii?
• Cine poate decripta direct datele?
• Rolurile break-glass sunt monitorizate și limitate în timp?
• MFA este impusă pentru operațiunile privilegiate asupra cheilor?
• Acțiunile privilegiate sunt jurnalizate și revizuite?

Pasul 4: Extrageți cinci înregistrări de dovezi

Colectați cinci înregistrări care demonstrează că acest control funcționează:

1. Jurnal de creare sau import al cheii.
2. Politica actuală de acces KMS sau HSM.
3. Ultimul tichet de schimbare pentru rotația cheii.
4. Interogare SIEM care arată utilizarea cheii sau acțiuni administrative.
5. Dovadă de testare a recuperării sau restaurării.

Pasul 5: Mapați la risc și reglementare

Adăugați o scurtă formulare a riscului: „Utilizarea neautorizată sau pierderea acestei chei ar putea expune date cu caracter personal din UE, perturba serviciul pentru clienți și afecta recuperarea sistemelor critice.” Apoi mapați-o la obligațiile relevante.

În 90 de minute, echipa poate identifica de obicei dacă guvernanța cheilor este reală sau doar presupusă.

Raportarea incidentelor: când compromiterea cheilor pornește cronometrul

O suspiciune de compromitere a cheilor nu reprezintă automat o încălcare raportabilă, dar poate porni cronometrul de reglementare.

Conform NIS2, entitățile esențiale și importante trebuie să notifice fără întârzieri nejustificate incidentele semnificative care afectează furnizarea serviciilor. Modelul etapizat include o avertizare timpurie în termen de 24 de ore de la luarea la cunoștință, o notificare a incidentului în termen de 72 de ore, actualizări de stare atunci când sunt solicitate și un raport final cel târziu la o lună după notificarea incidentului.

Conform DORA, entitățile financiare trebuie să detecteze, să gestioneze și să notifice incidentele legate de TIC, să înregistreze incidentele și amenințările cibernetice semnificative, să clasifice incidentele după severitate și criticitatea serviciului afectat, să comunice cu părțile interesate, să raporteze incidentele majore conducerii superioare și autorităților competente, să efectueze analiza cauzei principale și să remedieze. Externalizarea raportării poate fi posibilă, dar responsabilitatea rămâne la entitatea financiară.

Conform GDPR, întrebarea devine dacă a avut loc o încălcare a securității datelor cu caracter personal, adică distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat, accidental ori ilegal, la date cu caracter personal. Criptarea robustă, împreună cu chei necompromise, poate modifica semnificativ analiza riscului de încălcare. Gestionarea deficitară a cheilor poate submina acest argument.

Playbook-urile pentru compromiterea cheilor trebuie să definească:

• Cum este detectată suspiciunea de expunere a cheilor.
• Cine declară un incident criptografic.
• Cum sunt identificate datele, serviciile, clienții și jurisdicțiile afectate.
• Cum sunt revocate sau rotite cheile.
• Cum sunt restaurate sistemele dependente.
• Cum este păstrată integritatea probatorie.
• Cum se iau deciziile privind notificările juridice, de reglementare și către clienți.

Registrul de gestionare a cheilor devine esențial în acest proces. Fără el, responsabilii cu răspunsul pierd timp identificând ce proteja o cheie. Cu el, pot delimita rapid impactul.

Perspectiva de audit: un singur set de controale, mai mulți consumatori de dovezi

Auditorii abordează gestionarea cheilor criptografice din perspective diferite, dar converg asupra acelorași dovezi.

Un pachet solid de audit pentru gestionarea cheilor criptografice conține de regulă:

• Politica privind controalele criptografice aprobată.
• Politica de utilizare a serviciilor cloud aprobată, acolo unde criptarea cloud este relevantă.
• Standard criptografic și listă de algoritmi.
• Registrul de gestionare a cheilor.
• Inventar de certificate și secrete.
• Arhitectură KMS, HSM și seif.
• Dovezi privind revizuirea IAM și a accesului privilegiat.
• Înregistrări de rotație și revocare.
• Dovezi de testare pentru backup, escrow și recuperare.
• Reguli de jurnalizare și monitorizare pentru activitatea cheilor.
• Mapare privind furnizorii și responsabilitatea partajată în cloud.
• Playbook de incident pentru suspiciuni de compromitere a cheilor.
• Excepții și acceptări de risc.
• Înregistrări de revizuire de management și remediere a auditului.

Acest pachet transformă o afirmație de control în dovadă.

Constatări frecvente în auditurile de gestionare a cheilor

Cele mai frecvente constatări pot fi evitate:

1. Nu există un inventar unic al cheilor, certificatelor și instrumentelor criptografice.
2. Criptarea implicită a furnizorului cloud este tratată ca guvernanță completă a cheilor.
3. Nu este desemnat niciun proprietar sau custode pentru cheile de producție.
4. Rotația există pentru certificate, dar nu pentru cheile aplicațiilor sau CMK-urile bazelor de date.
5. Secretele și cheile sunt amestecate în același seif fără clasificare.
6. Dezvoltatorii pot crea chei în afara tiparelor aprobate.
7. Nu există dovezi că administratorii KMS sunt revizuiți.
8. Procedurile de recuperare există, dar nu au fost niciodată testate.
9. Compromiterea cheilor nu este inclusă în playbook-urile de răspuns la incidente.
10. Algoritmii moșteniți rămân în serviciile interne deoarece nimeni nu deține remedierea.
11. Angajamentele BYOK sunt asumate în contractele cu clienții, dar nu sunt reflectate în operațiuni.
12. Criptarea gestionată de furnizor nu este inclusă în revizuirile de risc asociat furnizorilor.

Fiecare constatare se mapează înapoi la guvernanță. De aceea, criptografia nu poate fi tratată ca un proiect exclusiv de inginerie. Ea trebuie conectată la domeniul de aplicare al SMSI, tratarea riscurilor, politică, furnizori, cloud, acces, jurnalizare, incidente și continuitate.

Pregătiți guvernanța cheilor pentru audit înainte de următorul incident

Dacă organizația dumneavoastră se pregătește pentru NIS2, DORA, dovezi pentru GDPR Article 32, certificare ISO/IEC 27001:2022 sau agilitate criptografică post-cuantică, începeți cu o întrebare: puteți produce astăzi un Registru complet de gestionare a cheilor?

Dacă nu, Clarysec vă poate ajuta să construiți sistemul de control în jurul acestuia.

Utilizați Zenith Blueprint Zenith Blueprint pentru a structura activitatea prin faza de gestionare a riscurilor, pasul 14, și faza de controale în acțiune, pasul 20. Utilizați Zenith Controls Zenith Controls pentru a mapa controalele ISO/IEC 27002:2022 8.24, 5.17 și 5.23 cu NIS2, DORA, GDPR, NIST și așteptările de audit. Utilizați Politica privind controalele criptografice a Clarysec Politica privind controalele criptografice, Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - IMM și Politica de utilizare a serviciilor cloud Politica de utilizare a serviciilor cloud pentru a transforma cerințele în reguli operaționale.

Următorul pas practic este simplu: alegeți un serviciu critic, inventariați-i cheile, demonstrați deținerea, verificați accesul, extrageți dovezi de rotație și testați recuperarea. Dacă acest lucru durează mai mult de o zi, guvernanța criptografică necesită atenție înainte ca autoritatea de reglementare, auditorul sau echipa de răspuns la incidente să adreseze aceeași întrebare sub presiune.