Evidențele pentru audit ISO 27001 sunt artefactele verificabile prin care organizația poate demonstra că un control este implementat și funcționează în practică. Politicile și procedurile descriu ce ar trebui să se întâmple; logurile, rapoartele, aprobările, access reviews, testele de restaurare, tichetele și înregistrările operaționale demonstrează ce s-a întâmplat efectiv.
01. Evidențe audit ISO 27001: ce trebuie să poată demonstra organizația
O evidență este un artefact verificabil care susține o afirmație de control.
Dacă organizația spune că revizuiește accesurile privilegiate trimestrial, auditorul va căuta mai mult decât politica de access management. Trebuie să existe o urmă a execuției: lista conturilor analizate, criteriile de revizuire, persoana responsabilă, deciziile luate, aprobările și dovada că accesurile nejustificate au fost eliminate.
Evidența bună trebuie să permită unui evaluator să înțeleagă ce control a fost executat, când, asupra cărui sistem sau proces, de către cine, cu ce rezultat și ce s-a întâmplat atunci când au fost identificate deviații.
Dacă lipsește legătura dintre control, responsabil și rezultat, dovada poate fi insuficientă chiar dacă documentul arată formal corect.
ISO/IEC 27001 nu impune un dosar universal de dovezi identic pentru toate organizațiile. Evidențele necesare depind de context, riscurile asumate, controalele stabilite și Statement of Applicability.
Principiul rămâne însă același: dovezile trebuie să fie relevante, actuale, trasabile și suficient de fiabile pentru a permite verificarea controlului.
02. De la risc la control și de la control la evidență
Pregătirea eficientă pentru audit începe cu o legătură explicită între risc, control și evidență.
Fără această legătură, organizația poate ajunge să colecteze sute de documente fără să poată demonstra clar ce expunere materială este redusă de fiecare control.
Modelul practic este:
Risk → Control → Owner → Execution → Evidence → Result → Remediation.
Exemplu: conturile administrative Microsoft 365
Un exemplu frecvent este riscul asociat conturilor administrative în Microsoft 365 sau în infrastructura cloud.
Riscul material nu este simpla existență a unui cont administrativ. Scenariul relevant este compromiterea identității privilegiate și posibilitatea atacatorului de a modifica configurații, accesa date sau extinde compromiterea.
Controalele pot include MFA rezistent la phishing, PIM/JIT, conturi administrative separate, Conditional Access și revizuiri periodice ale rolurilor.
Evidența nu este doar un screenshot din portal. Ea poate include exporturi ale rolurilor, rapoarte de activare PIM, rezultate ale access review-urilor, aprobări, loguri, excepții și tichete care demonstrează remedierea accesurilor nejustificate.
Exemplu: backup și recuperare
Același model se aplică backup-urilor. Afirmația „avem backup” nu demonstrează recuperabilitatea.
Pentru un sistem critic trebuie să existe o legătură între cerințele de business, RTO/RPO, politica de retenție, configurația tehnică și testarea efectivă a restaurării.
Un test de restore care păstrează data, sistemul restaurat, timpul efectiv de recuperare, deviațiile identificate și acțiunile corective reprezintă o evidență mult mai puternică decât un screenshot cu un job marcat „successful”.
03. Documente, înregistrări și probe tehnice
Politicile și procedurile explică intenția și regulile organizației. Înregistrările demonstrează execuția. Probele tehnice confirmă configurația sau comportamentul efectiv al sistemelor.
Un audit matur folosește toate aceste categorii fără să le confunde.
| Tip | Rol | Exemple |
|---|---|---|
| Documentație | Definește regula și modul de operare | Politici, proceduri, standarde, planuri, matrice de responsabilități |
| Înregistrări | Demonstrează că procesul a fost executat | Aprobări, access reviews, tichete, minute, rapoarte de exercițiu |
| Probe tehnice | Demonstrează configurația sau comportamentul | Loguri, exporturi, rapoarte native, configurații, alerte, rezultate EDR/SIEM |
| Evidence of effectiveness | Demonstrează că mecanismul produce rezultatul dorit | Restore tests, rescan după patching, incident exercises, remediation validation |
De exemplu, procedura de management al incidentelor trebuie să definească rolurile, criteriile de severitate, escaladarea și comunicarea.
Pentru a demonstra aplicarea ei, organizația trebuie să poată prezenta tichete de incident, cronologia deciziilor, notificări, rapoarte post-incident și rezultate ale exercițiilor.
Pentru organizațiile aflate sub incidența NIS2, aceste evidențe trebuie să susțină și capacitatea de raportare în termenele aplicabile , nu doar existența unei proceduri generale.
04. Evidențe pentru controalele cu risc ridicat
Auditurile scot frecvent la suprafață aceeași problemă: controlul este declarat, dar execuția nu este repetabilă sau organizația nu o poate demonstra.
Identitatea, vulnerabilitățile, backup-ul, incidentele și furnizorii merită o atenție specială deoarece combină expunerea operațională cu cerințe ridicate de trasabilitate.
| Control area | Afirmația | Evidență puternică | Evidență slabă |
|---|---|---|---|
| Privileged Access | Accesul privilegiat este controlat | PIM logs + access review + approvals + remediation | Screenshot MFA |
| Backup | Sistemele critice sunt recuperabile | Restore test + rezultat RTO/RPO + acțiuni corective | Backup job successful |
| Vulnerability Management | Vulnerabilitățile sunt tratate | Scan → ticket → remediation → rescan | Scan report |
| Incident Response | Procesul funcționează | Incident timeline + decisions + PIR + remediation | Incident response policy |
| Supplier Risk | Furnizorii critici sunt controlați | Assessment + contract + review + exceptions | Vendor questionnaire |
Identitate, acces și privilegii
Organizația trebuie să poată demonstra ciclul complet: acordarea accesului, aprobarea, modificarea la schimbarea rolului, revocarea la plecare și revizuirea periodică.
Dovezile relevante includ cereri aprobate, fluxuri HR-IT, rapoarte de conturi inactive, rezultate ale access review-urilor, justificări pentru conturi generice și rapoarte pentru acces privilegiat.
Un punct sensibil îl reprezintă excepțiile. Dacă un furnizor extern primește acces administrativ permanent „pentru urgențe”, simpla mențiune într-un e-mail nu controlează riscul.
Sunt necesare justificare de business, aprobare, termen de expirare, restricții de acces, monitorizare și o revizuire documentată.
Vulnerabilități, patching și configurații
Un raport de scanare nu demonstrează că vulnerabilitățile sunt gestionate. Demonstrează doar că anumite probleme au fost identificate la un moment dat.
Pentru assurance trebuie urmărit traseul complet: identificare, prioritizare, owner, termen, remediere, excepție dacă este cazul și verificarea ulterioară a remedierii.
Același principiu se aplică logging-ului. Dacă organizația afirmă că serverele, endpoint-urile, firewall-urile și serviciile cloud critice sunt monitorizate, trebuie să poată demonstra sursele conectate, acoperirea, retenția, alertele și modul în care acestea sunt revizuite.
Logging fără retenție adecvată sau fără ownership pentru analiză produce volum, nu assurance.
Furnizori, cloud și responsabilitate
Utilizarea unui furnizor cloud nu transferă integral responsabilitatea pentru control.
Modelul de responsabilitate partajată trebuie reflectat în evaluarea de risc, contracte, cerințele de securitate, drepturile de audit și monitorizarea serviciului.
Evidențele pot include evaluări înainte de contractare, clasificarea furnizorului după criticitate, clauze privind incidentele și datele, rapoarte de assurance analizate, rezultate ale revizuirilor periodice și decizii privind riscurile reziduale.
Este important ca organizația să poată demonstra ce a verificat ea însăși, nu doar ce declară furnizorul în documentația comercială.
Continuitate și răspuns la incidente
Planurile de continuitate devin credibile atunci când sunt testate. O simulare de indisponibilitate pentru un serviciu critic trebuie să lase o urmă: scenariu, participanți, obiective, timpi obținuți, blocaje, lecții învățate și plan de acțiune.
Dacă RTO sau RPO nu sunt atinse, rezultatul trebuie analizat și tratat. Valoarea testului este tocmai capacitatea de a identifica diferența dintre ceea ce organizația presupunea și ceea ce infrastructura poate livra în realitate.
05. Evidence Register: organizați dovezile fără să creați un depozit inutil
O abordare eficientă este menținerea unui registru de evidențe corelat cu riscurile și controalele aplicabile.
Scopul nu este crearea unui nou strat birocratic, ci posibilitatea de a identifica rapid cine deține controlul, cât de des trebuie executat, de unde provine dovada și dacă rezultatul este acceptabil.
Evidence register
Ce ar trebui urmărit pentru fiecare control.
Riscul sau cerința pe care controlul o tratează.
Controlul și obiectivul său operațional.
Owner-ul responsabil pentru execuție și rezultat.
Frecvența cu care controlul trebuie executat.
Sursa exactă din care este obținută evidența.
Perioada acoperită și data ultimei verificări.
Criteriul prin care rezultatul este considerat acceptabil.
Excepțiile, deviațiile și riscurile reziduale identificate.
Acțiunile corective, owner-ul și termenul de remediere.
Dovada că remedierea a fost verificată și închisă.
Cu un astfel de model, pregătirea auditului nu mai depinde de memoria echipei IT sau de căutarea grăbită prin e-mailuri, foldere și portaluri.
Nu toate dovezile trebuie colectate manual. Pentru controalele recurente, automatizarea poate reduce erorile și crește consistența: rapoarte periodice de access review, alerte privind expirarea excepțiilor, rapoarte de conformitate pentru endpoint-uri sau rezultate ale joburilor de backup.
Automatizarea nu elimină însă ownership-ul. Dacă un raport este generat automat, trebuie să existe în continuare cineva care analizează deviațiile, validează rezultatul și urmărește remedierea.
06. Testați dovezile înainte să le ceară auditorul
Un pre-audit intern sau independent nu ar trebui să verifice doar dacă fișierele există.
Testul mai valoros este dacă un evaluator care nu cunoaște organizația poate reconstrui povestea controlului din informațiile disponibile.
Pentru un eșantion de controale cu risc ridicat, traseul trebuie parcurs de la început până la sfârșit:
risc identificat → decizie de tratament → control implementat → owner → execuție → evidență → excepție → remediere → verificarea rezultatului.
Dacă povestea se rupe la unul dintre acești pași, există o problemă de control sau de assurance care trebuie analizată.
07. Audit readiness trebuie să existe înainte de audit
Una dintre diferențele importante este cea dintre evidența de proiect și evidența de operare.
Implementarea MFA, de exemplu, produce documentație de proiect, configurații, aprobări și rezultate ale implementării.
Operațiunea ulterioară trebuie însă să producă dovezi recurente: nivelul de acoperire, conturile exceptate, revizuirea excepțiilor, alertele relevante și acțiunile corective.
Același lucru este valabil pentru patching, backup, acces, furnizori, logging și incident response.
Auditorul va observa rapid diferența dintre un control care a fost implementat o dată și unul care este operat, măsurat și menținut.
| Întrebare de readiness | Ce trebuie să puteți demonstra |
|---|---|
| Cine deține controlul? | Owner clar și responsabilitate operațională. |
| Cât de des este executat? | Frecvență definită și istoric verificabil. |
| Cum știm că funcționează? | Criteriu de eficacitate și rezultat măsurabil. |
| Ce se întâmplă când eșuează? | Excepție, risk decision, remediere și termen. |
| Putem demonstra? | Evidență trasabilă și suficientă pentru verificare. |
Această abordare este relevantă și pentru NIS2 și ISO/IEC 27001, unde guvernanța, managementul riscului, ownership-ul și capacitatea de a demonstra aplicarea măsurilor sunt elemente centrale ale unui model de control matur.
08. De la conformitate declarată la control demonstrabil
Un audit ISO 27001 bine pregătit nu începe cu câteva săptămâni înainte de audit.
Începe atunci când fiecare control relevant are un owner, o frecvență, un criteriu de eficacitate și o urmă verificabilă.
Obiectivul nu ar trebui să fie construirea unui folder care arată bine pentru auditor. Obiectivul este ca operarea normală a organizației să producă dovezi suficiente pentru a demonstra că riscurile sunt cunoscute, controalele sunt executate, deviațiile sunt observate și acțiunile corective sunt urmărite.
Modelul practic rămâne:
Risk → Control → Owner → Evidence → Verify → Remediate.
Aceasta este diferența dintre existența unei documentații de compliance și existența unui sistem de management care poate fi verificat.