93 de controale din Anexa A a ISO 27001 trebuie evaluate una cate una. Pentru fiecare, decizi daca se aplica sau nu in firma ta si scrii motivul. Documentul care contine toate aceste decizii se numeste Declaratie de Aplicabilitate (Statement of Applicability, prescurtat SoA).
Clauza 6.1.3 din ISO 27001 cere explicit sa produci acest document. Alaturi de politica de securitate a informatiei (clauza 5.2), SoA este unul dintre documentele obligatorii pe care auditorul le solicita. Fara el, nu poti obtine certificarea. Auditorul il primeste inainte de vizita si il foloseste ca referinta pentru tot ce verifica in firma ta.
Ce contine o Declaratie de Aplicabilitate?
SoA este, in esenta, un tabel. Fiecare rand corespunde unui control din Anexa A. Coloanele minime pe care le cere standardul sunt:
| Coloana | Ce completezi |
|---|---|
| ID control | Codul din Anexa A (ex: A.5.1, A.8.12) |
| Denumire control | Numele controlului din standard |
| Aplicabil (Da/Nu) | Daca ai decis sa il implementezi |
| Justificare | De ce l-ai inclus sau de ce l-ai exclus |
| Stare implementare | Implementat complet, partial sau planificat |
| Responsabil | Cine raspunde de controlul respectiv |
In practica, multe organizatii adauga si alte coloane: data implementarii, legatura cu riscul identificat, referinta la procedura interna. Dar cele de mai sus sunt suficiente pentru audit.
De unde pornesti cand construiesti SoA?
Nu incepi de la Anexa A. Incepi de la evaluarea de risc. Parcurgi trei pasi:
- Identifici riscurile de securitate a informatiei din firma ta (clauza 6.1.2)
- Stabilesti tratamentul pentru fiecare risc (accepti, reduci, transferi sau eviti)
- Compari tratamentele cu controalele din Anexa A si selectezi ce se aplica
Dupa acest exercitiu, deschizi lista celor 93 de controale si completezi SoA pe baza deciziilor luate. Controalele pe care nu le selectezi din Anexa A nu inseamna ca le ignori. Standardul cere sa justifici explicit fiecare excludere.
Cum arata justificarile in practica?
Aici se blocheaza multe organizatii. Justificarea trebuie sa fie concreta, nu generica. Iata doua exemple reale dintr-o firma de dezvoltare software cu 35 de angajati din Cluj:
Controlul A.7.4 (Monitorizare securitate fizica) este marcat ca aplicabil. Firma are un birou propriu cu server room, iar camerele de supraveghere acopera intrarea si sala serverelor. Justificarea: riscul de acces fizic neautorizat la echipamente a fost evaluat ca mediu.
Controlul A.7.3 (Securizarea birourilor si incaperilor) este exclus. Toti angajatii lucreaza remote de la domiciliu. Firma nu are spatii fizice unde se stocheaza documente confidentiale pe hartie. Justificarea: riscul nu exista in contextul operational al organizatiei.
Auditorul citeste aceste justificari si le compara cu ce gaseste in teren. Daca ai scris ca A.7.4 este implementat dar camerele nu functioneaza, ai o neconformitate.
Ce verifica auditorul in SoA?
SoA este primul document pe care il solicita auditorul de certificare. Trei lucruri il intereseaza:
Versiunea si data documentului trebuie sa corespunda cu cele inscrise pe certificat. Daca ai modificat SoA dupa audit fara sa anunti organismul de certificare, certificatul poate fi suspendat.
Justificarile de excludere trebuie sa fie coerente cu evaluarea de risc. Daca ai exclus un control de criptare (A.8.24) dar prelucrezi date personale ale clientilor, auditorul va intreba de ce.
Starea reala a implementarii trebuie sa corespunda cu ce ai declarat. „Implementat complet” inseamna ca exista procedura, ca angajatii o cunosc si ca exista dovezi (loguri, inregistrari, rapoarte).
Cum influenteaza NIS2 si GDPR selectia controalelor?
Daca firma ta intra sub incidenta OUG 155/2024 (transpunerea NIS2), unele controale devin practic imposibil de exclus. Controalele de gestionare a incidentelor (A.5.24, A.5.25, A.5.26) sunt obligatorii prin NIS2, care cere raportarea incidentelor catre DNSC. Nu le poti exclude din SoA daca esti entitate esentiala sau importanta.
La fel, daca prelucrezi date personale, controalele de criptare (A.8.24), clasificarea informatiilor (A.5.12) si stergerea datelor (A.8.10) sunt greu de justificat ca „neaplicabile” fara sa intri in conflict cu cerintele GDPR. ANSPDCP verifica exact aceste masuri tehnice.
Concret: o firma de IT cu 50 de angajati care opereaza o platforma SaaS in Romania si intra sub NIS2 va selecta probabil 80+ controale din cele 93. Spatiul real de excludere este mic.
Ce greseli apar frecvent in SoA?
Cea mai comuna eroare: justificari copy-paste. „Controlul este aplicabil deoarece organizatia a identificat riscuri asociate.” Auditorul va cere detalii imediat. Fiecare justificare trebuie sa faca referire la un risc specific sau la un context concret.
A doua eroare: SoA facut o data si uitat. Documentul trebuie revizuit cel putin anual si dupa orice schimbare in organizatie (angajari, sisteme noi, sediu nou, contracte noi cu clienti). La auditul de supraveghere, auditorul compara SoA actual cu cel din anul precedent.
A treia eroare: excluderea controalelor doar pentru ca par „prea complicate” de implementat. Costul sau complexitatea nu sunt justificari acceptate de standard. Poti exclude un control doar daca riscul asociat nu exista in contextul tau operational.
Daca esti la inceput cu implementarea ISO 27001, SoA se construieste in faza 3 (dupa evaluarea de risc si inainte de implementarea controalelor). Nu lasa acest document la final.