ISO 27001 Anexa A: cum faceți operaționale cele 93 de controale

Anexa A oferă echipelor de securitate un set de referință util. Valoarea sa operațională vine din a arăta de ce se aplică un control, cum este implementat și ce dovezi îl susțin în mediul dumneavoastră. Un registru cu 93 de indicatori de stare verzi nu este suficient dacă nimeni nu poate explica ce sisteme acoperă acești indicatori.

Pentru un CTO, provocarea practică este transpunerea intenției controalelor în activități de inginerie și operaționale, fără a transforma sistemul de management al securității informației într-o birocrație paralelă. Revizuirile accesului ar trebui să folosească date reale despre permisiuni. Planurile de recuperare ar trebui să reflecte dependențele serviciilor. Evaluările furnizorilor ar trebui să vizeze serviciile pe care compania le utilizează efectiv.

Acest ghid explică modul de selectare a controalelor, de distribuire a responsabilităților, de definire a implementărilor și de testare a afirmațiilor rezultate. Frecvențele de revizuire și exemplele de implementare de mai jos sunt recomandări practice, nu intervale universale prescrise de standard.

Înțelegeți ce face Anexa A și ce nu face

ISO/IEC 27001:2022 conține 93 de controale în Anexa A, grupate în patru teme. Clauzele 4–10 conțin cerințele sistemului de management: contextul organizației, leadershipul, planificarea, suportul, operarea, evaluarea performanței și îmbunătățirea. Anexa A sprijină selectarea controalelor; nu înlocuiește aceste cerințe sau evaluarea riscurilor dumneavoastră.

Distincția contează în timpul implementării. O configurație de backup poate susține un control selectat, dar nu demonstrează că ați definit domeniul de aplicare al SMSI, ați evaluat riscurile, ați efectuat un audit intern sau ați finalizat analiza efectuată de management. Acestea sunt activități separate, cu dovezi separate.

Selectarea controalelor se bazează pe risc. Stabiliți controalele necesare pentru tratarea riscurilor dumneavoastră, apoi comparați-le cu Anexa A pentru a verifica dacă nu ați omis controale necesare. Pot fi necesare și controale suplimentare din afara Anexei A. Invers, o excludere justificată este posibilă; nu există nicio regulă potrivit căreia fiecare organizație trebuie să excludă ceva sau să implementeze exact aceeași selecție.

ISO/IEC 27002:2022 oferă îndrumări de implementare pentru controale. Atributele sale ajută la organizarea acestora după tipul de control, proprietatea de securitate a informației, conceptul de securitate cibernetică, capacitatea operațională și domeniul de securitate. Acestea sunt instrumente utile de filtrare, nu liste de verificare suplimentare pentru certificare. Consultați standardele licențiate pentru formularea cu autoritate.

Folosiți cele patru teme pentru a găsi responsabilii potriviți

Temele oferă o structură de navigare, nu patru fluxuri de lucru independente. Un proces de plecare a unui angajat, de exemplu, leagă responsabilitățile de angajare, administrarea identităților, returnarea echipamentelor și accesul la aplicații.

Controale organizaționale: legați guvernanța de deciziile operaționale

Aceste controale acoperă politicile, responsabilitățile, separarea sarcinilor, activele, clasificarea și manipularea informațiilor, guvernanța accesului, furnizorii, incidentele, continuitatea, obligațiile legale și activitățile de revizuire.

Începeți prin a identifica unde se iau deciziile. Cine aprobă un nou serviciu cloud? Cine atribuie o clasificare a informațiilor? Cine decide dacă un eveniment raportat este un incident? O politică ar trebui să facă aceste decizii repetabile și să atribuie autoritatea, nu doar să exprime sprijin pentru securitate.

Securitatea furnizorilor are nevoie de un lanț de dovezi specific serviciului: scopul de business al serviciului, informațiile pe care le gestionează, riscurile evaluate, responsabilitățile contractuale și revizuirea continuă. Raportul de asigurare al unui furnizor poate sprijini această evaluare, dar domeniul de aplicare, perioada și responsabilitățile clientului din acesta trebuie să corespundă utilizării dumneavoastră.

Gestionarea incidentelor are nevoie, la fel, de mai mult decât o listă de contacte de urgență. Definiți căile de raportare, criteriile de evaluare, autoritatea de răspuns, gestionarea dovezilor și activitățile de învățare. Consemnați exercițiile sau răspunsurile efective, inclusiv acțiunile ulterioare și responsabilii acestora.

Controale referitoare la persoane: transformați evenimentele de angajare în declanșatori fiabili

Cele opt controale referitoare la persoane vizează verificarea, condițiile de angajare, conștientizarea și instruirea, procesele disciplinare, responsabilitățile după modificarea raportului de muncă, confidențialitatea, munca la distanță și raportarea evenimentelor.

Integrați-le în fluxurile de lucru existente privind angajarea. Un angajat nou are nevoie de obligații, acces și instruire adecvate. Un angajat care își schimbă rolul are nevoie de reevaluarea permisiunilor, nu doar de adăugarea altora noi. Un angajat care pleacă are nevoie de eliminarea accesului, returnarea activelor și claritate privind responsabilitățile de confidențialitate care continuă.

Responsabilitatea se întinde adesea pe mai multe echipe. HR poate iniția o plecare, administratorii de identități dezactivează contul central, responsabilii de aplicații elimină accesul gestionat local, iar un manager confirmă finalizarea. Atribuirea întregului proces echipei de securitate ascunde aceste dependențe.

Dovezile utile includ evidențe aprobate ale fluxurilor de lucru, finalizarea instruirilor și urmărirea celor restante, condiții confirmate și eșantioane de modificări ale raporturilor de muncă. Restricționați accesul la dovezile HR sensibile; un evaluator al controalelor nu are automat nevoie de dosarele de personal complete.

Controale fizice: documentați perimetrul dumneavoastră și perimetrul furnizorului

Controalele fizice vizează sediile, accesul, monitorizarea, amenințările de mediu, zonele securizate, birourile și ecranele, echipamentele, suporturile de stocare, utilitățile, cablarea, mentenanța și eliminarea.

O organizație care se bazează în primul rând pe cloud trebuie totuși să ia în considerare securitatea fizică. O parte din implementare poate fi asigurată de un furnizor de cloud, în timp ce accesul la birou și dispozitivele angajaților rămân în responsabilitatea proprie. Consemnați această împărțire, în loc să excludeți automat întreaga temă.

Pentru locațiile proprii, identificați cine poate intra, cum se modifică accesul, unde se află echipamentele sensibile și cum sunt gestionați vizitatorii. Pentru dispozitivele utilizate la distanță, definiți aranjamentele de depozitare, transport, reparare și eliminare adecvate riscurilor acestora.

Dovezile pot include evidențe privind autorizarea accesului, proceduri pentru vizitatori, inventare de echipamente și evidențe privind eliminarea. Dovezile furnizorului ar trebui să explice ce facilități și servicii acoperă; ele nu ar trebui tratate ca dovadă a controalelor pentru biroul sau laptopurile dumneavoastră.

Controale tehnologice: definiți acoperirea înainte de a alege instrumentele

Tema tehnologică acoperă dispozitivele finale, accesul privilegiat, autentificarea, accesul la codul sursă, capacitatea, malware-ul, vulnerabilitățile, configurațiile, gestionarea datelor, backup-urile, reziliența, jurnalizarea, monitorizarea, rețelele, criptografia, dezvoltarea și gestionarea modificărilor.

Începeți cu acoperirea sistemelor. O politică de identitate este incompletă dacă accesul la producție, conturile de serviciu sau o aplicație gestionată separat rămân în afara implementării sale. O platformă de jurnalizare este incompletă dacă evenimentele critice nu ajung niciodată la ea sau dacă nimeni nu reacționează la alerte.

Pentru dezvoltarea de software, legați cerințele și deciziile de proiectare de revizuirea codului, testarea de securitate, separarea mediilor, gestionarea datelor de test și aprobarea lansărilor. Modelarea amenințărilor poate ajuta la identificarea cerințelor de securitate înainte de implementare. Profunzimea testării ar trebui să urmeze riscul și obligațiile; ISO 27001 nu impune un calendar universal pentru testele de penetrare.

Pentru criptografie, distingeți datele în repaus de datele în tranzit și documentați responsabilitatea pentru chei, accesul, recuperarea, rotația și revocarea. „Criptare activată” lasă fără răspuns întrebări importante de implementare.

Ce s-a schimbat în 2022 și unde să căutați lacune

Ediția din 2013 avea 114 controale în 14 domenii. Ediția din 2022 le-a reorganizat în 93 de controale în patru teme, inclusiv 11 controale noi. Un număr mai mic nu înseamnă mai puțină muncă de securitate: consolidarea poate plasa mai multe responsabilități operaționale sub o singură referință.

Când actualizați un registru mai vechi, păstrați implementările și dovezile de bază, în loc să înlocuiți doar identificatorii. Verificați dacă noua grupare schimbă acoperirea, responsabilitățile sau testele necesare pentru a vă susține statutul.

Termenul de tranziție pentru certificarea acreditată conform ISO/IEC 27001:2013 a fost 31 octombrie 2025. Aceste certificate nu mai sunt valabile; simpla actualizare a unui registru al controalelor nu stabilește certificarea conform ediției din 2022.

Cele ce urmează sunt puncte de plecare practice pentru cele 11 controale noi, nu reproduceri ale textului lor oficial.

Evitați să le tratați ca pe unsprezece achiziții automate de produse. De exemplu, informațiile despre amenințări necesită analiză și acțiune, nu doar un abonament la un flux de date. Ștergerea datelor presupune înțelegerea copiilor, a backup-urilor și a obligațiilor de păstrare, nu doar un buton de ștergere. Monitorizarea are nevoie de o cale de răspuns operațională.

Consemnați separat aplicabilitatea și implementarea

Declarația de aplicabilitate (SoA) ar trebui să identifice controalele necesare, să explice includerea lor, să consemneze dacă sunt implementate și să justifice excluderile controalelor din Anexa A. Aceste cerințe se regăsesc în dispozițiile privind tratarea riscurilor din ISO/IEC 27001.

Utilizarea tuturor celor 93 de referințe ca index de revizuire este o modalitate practică de a face comparația verificabilă. Includeți și orice controale suplimentare necesare. SoA nu este registrul riscurilor, planul de tratare sau depozitul de dovezi, deși ar trebui să fie legată de fiecare dintre acestea acolo unde este relevant.

Pentru fiecare control aplicabil, consemnați:

• Riscurile sau obligațiile care susțin includerea.
• Sistemele, locațiile, informațiile și procesele relevante.
• Implementarea efectivă și responsabilul.
• Dovezile justificative și perioada lor de revizuire.
• Dependențele, excepțiile și activitățile nefinalizate.
• Următoarea dată de revizuire sau evenimentul declanșator.

Mențineți aplicabilitatea independentă de stadiul implementării. „Aplicabil, implementat parțial” este o evidență onestă și utilă. „Neaplicabil pentru că nu am cumpărat un instrument” nu este o justificare a aplicabilității.

O excludere ar trebui să descrie faptele privind domeniul de aplicare care fac controlul inutil și să rămână consecventă cu evaluarea riscurilor. „Nu dezvoltăm software” trebuie examinat cu atenție dacă un contractor dezvoltă portalul dumneavoastră pentru clienți. Externalizarea schimbă calea de implementare și de dovezi; nu elimină automat riscul.

Pentru implementările distribuite, consemnați împărțirea. Un control de protecție fizică poate depinde de facilitățile de găzduire operate de furnizor, de accesul în birou gestionat de companie și de modul în care angajații manipulează dispozitivele. Un singur responsabil poate rămâne răspunzător pentru afirmația combinată, în timp ce echipe diferite desfășoară activitățile.

O declarație de implementare utilă este suficient de specifică pentru a putea fi testată: „Administratorii de producție primesc acces nominal și aprobat prin serviciul de identitate; accesul de urgență este jurnalizat și revizuit separat.” „Accesul este gestionat în mod securizat” nu poate ghida un inginer sau un evaluator.

Testați afirmația din spatele stării

O politică descrie comportamentul urmărit. Ea poate demonstra proiectarea și aprobarea, dar nu poate demonstra singură funcționarea. Construiți un lanț de dovezi de la cerință la mecanismul implementat și apoi la un rezultat observat.

Pentru gestionarea accesului, comparați regulile aprobate cu permisiunile efective ale utilizatorilor și cu evidențele privind plecările. Includeți, acolo unde este relevant, identitățile privilegiate, conturile neumane și aplicațiile din afara gestionării centrale a identităților. Consemnați populația, eșantionul și excepțiile, în loc să prezentați o singură captură de ecran convenabilă.

Pentru backup-uri, examinați configurația și un rezultat de restaurare. Un job de backup reușit dovedește mai puțin decât recuperarea reușită a unor informații utilizabile. Verificați permisiunile, dependențele și obiectivele de recuperare; o bază de date restaurată fără cheile sale de criptare poate să nu restabilească serviciul.

Pentru securitatea furnizorilor, legați evaluarea de serviciul respectiv și de responsabilitățile contractuale. Verificați dacă dovezile acoperă serviciul pe care îl utilizați și dacă responsabilitățile identificate de partea clientului sunt implementate.

O evidență practică a testării ar trebui să conțină rezultatul așteptat, metoda, domeniul, data dovezilor, evaluatorul, rezultatul și decizia ulterioară. Distingeți între:

• Proiectare: mecanismul propus abordează riscul identificat.
• Implementare: mecanismul există în întregul domeniu declarat.
• Funcționare: evidențele arată că funcționează în perioada relevantă.
• Eficacitate: testarea indică faptul că atinge rezultatul urmărit.

Dovezile pot include configurații, exporturi, tichete, contracte, interviuri și observații fizice. Selectați dovezile care susțin afirmația efectivă. Un export al configurației poate arăta setările actuale; tichetele istorice pot arăta dacă excepțiile au fost gestionate în timp.

Păstrați proveniența: sistemul sursă, data colectării, perioada acoperită și orice filtrare. Protejați dovezile care conțin secrete sau informații personale prin restricții de acces și redactare adecvată. Colectarea dovezilor nu ar trebui să creeze un nou depozit necontrolat de date sensibile.

Exemplu practic: un proces de plecare care poate fi verificat

Să luăm ca exemplu ilustrativ o companie SaaS cu 45 de angajați, un birou, găzduire în cloud, identitate gestionată central și două aplicații cu conturi locale. Acestea sunt ipoteze ale exemplului, nu rezultate ale clienților Secani.

Riscul este accesul continuu la informațiile clienților sau ale companiei după plecare. Controalele relevante includ responsabilitățile la modificarea raportului de muncă, gestionarea identităților, drepturile de acces și returnarea activelor. Autentificarea tehnică și restricțiile de acces sprijină, de asemenea, implementarea.

Compania consemnează controlul ca fiind aplicabil. HR răspunde de declanșarea plecării; IT răspunde de acțiunile privind identitatea și dispozitivele; fiecare responsabil de aplicație răspunde de eliminarea conturilor locale. Managerul angajatului confirmă momentul necesar al plecării. Responsabilul de securitate revizuiește procesul și excepțiile nerezolvate.

Implementarea include un tichet de plecare autorizat, dezactivarea programată a contului central, revocarea sesiunilor acolo unde este posibil, eliminarea conturilor locale, returnarea activelor și verificarea datelor de autentificare controlate de persoana respectivă. Secretele partajate sunt schimbate acolo unde este necesar; conturile personale nu sunt reatribuite fără discernământ unui succesor.

Pachetul de dovezi leagă procedura aprobată, tichetul de plecare, evidențele acțiunilor asupra conturilor, confirmările pentru aplicațiile locale și evidența echipamentelor. Fiecare element susține o parte definită a afirmației.

În cadrul unei revizuiri ilustrative, echipa examinează patru plecări. Conturile centrale au fost dezactivate conform programului, dar o aplicație locală a păstrat accesul timp de două zile. Controlul nu este declarat pe deplin eficace doar pe baza dovezilor privind identitatea centrală.

Responsabilul aplicației elimină contul, evaluează dacă a avut loc vreun acces și consemnează rezultatul. Echipa adaugă aplicația pe lista de verificare pentru plecări și atribuie un pas de reconciliere. Acțiunea de tratare primește un responsabil și un termen; un test ulterior verifică dacă fluxul de lucru revizuit funcționează.

Acest exemplu arată de ce dovezile trebuie să urmeze dependențele. Patru sisteme care indică „finalizat” nu demonstrează finalizarea dacă un al cincilea sistem nu a fost inclus niciodată.

Mențineți controalele operaționale între revizuiri

Controalele se schimbă atunci când se schimbă sistemele, furnizorii, oamenii și cerințele de business. Stabiliți declanșatori de revizuire pentru lansări semnificative, servicii noi, schimbări de birou, incidente și obligații revizuite, alături de revizuirile programate.

Utilizați o frecvență adecvată volatilității și riscului. Excepțiile privind accesul privilegiat pot necesita o revizuire promptă, în timp ce o politică stabilă poate folosi un ciclu mai lung, completat de declanșatori legați de modificări. Acestea sunt alegeri ale conducerii, nu frecvențe universale ale Anexei A.

Urmăriți un număr mic de indicatori utili: remedieri restante, sisteme neacoperite, excepții nerezolvate privind dovezile și teste de control eșuate. Separați-i de numărul de documente. O bibliotecă mare de dovezi poate lăsa totuși netestat un mediu de producție critic.

Auditul intern oferă o evaluare separată a SMSI; revizuirile de rutină ale responsabililor de controale nu îl înlocuiesc. Analiza efectuată de management are nevoie, la fel, de decizii ale conducerii privind performanța, modificările, resursele și îmbunătățirea, nu doar de o foaie de calcul a controalelor completată. Certificarea este realizată de un organism de certificare independent, nu de ISO sau de un furnizor de software.

Greșelile frecvente includ atribuirea tuturor sarcinilor echipei de securitate, copierea excluderilor altei organizații, bazarea pe certificatele furnizorilor fără verificarea domeniului de aplicare și închiderea constatărilor atunci când se modifică o politică, în loc de momentul în care procesul revizuit a fost testat.

Începeți cu un serviciu și un lanț complet de dovezi

Alegeți un serviciu reprezentativ și urmăriți sistemele, furnizorii, informațiile și responsabilii operaționali ai acestuia. Selectați un set mic de controale conexe, cum ar fi accesul, gestionarea modificărilor, jurnalizarea și recuperarea, și faceți fiecare implementare verificabilă înainte de a extinde registrul.

Secani sprijină acest flux de lucru prin modelarea sistemelor și a dependențelor, legarea dovezilor de cerințe, controale și decizii și urmărirea lacunelor ca sarcini. Desemnați un responsabil și un evaluator, atașați evidențele existente și păstrați comentariile și aprobările din revizuire. Tratați corelările sau rezumatele asistate de IA ca pe niște ciorne: validați sursele și mențineți explicită aprobarea umană. Pregătirea structurată pentru audit explică modelul de dovezi pe care se sprijină acest flux.

Primul rezultat ar trebui să fie un lanț coerent de la risc la control, implementare, dovezi, rezultatul testului și decizia ulterioară. Acest lanț poate fi apoi repetat în restul domeniului de aplicare, fără a inventa un proces nou pentru fiecare referință din Anexa A.

Întrebări practice

Poate o singură evidență să susțină mai multe controale?

Da. Un tichet de plecare poate susține mai multe controale conexe. Explicați ce afirmație susține pentru fiecare; partajarea dovezilor nu face controalele identice.

Trebuie ca fiecare control să aibă propria politică?

Nu. Organizați politicile și procedurile în jurul unor procese operaționale ușor de înțeles. Un singur document poate aborda mai multe controale, cu condiția ca responsabilitățile și implementarea să rămână clare.

De unde ar trebui să provină lista oficială a controalelor?

Utilizați standardul licențiat ISO/IEC 27001 pentru formularea Anexei A și ISO/IEC 27002 pentru îndrumările de implementare. Rezumatele operaționale sunt instrumente utile de navigare, nu substitute ale standardelor.