ISO 27001 & SOC 2:
ce dovadă tehnică cere auditorul
Un ghid practic pentru companiile care intră în certificare: ce controale cer testare, cât de des, și cum arată dovada pe care o acceptă auditorul.
ISO 27001 și SOC 2 sunt cadre de management, nu liste de vulnerabilități. Niciunul nu spune „faceți un test de penetrare în fiecare an". Amândouă cer însă ceva ce nu se poate demonstra din documente: dovada că măsurile tehnice chiar funcționează. Aici intră pentestul — și de aceea îl cere, în practică, aproape orice auditor.
Ce controale ISO 27001 ating testarea tehnică
Revizia din 2022 a Anexei A a restructurat controalele, iar trei dintre ele se sprijină direct pe testare: A.8.8 — gestionarea vulnerabilităților tehnice, A.8.29 — testarea securității în dezvoltare și acceptanță și A.8.9 — gestionarea configurațiilor. La acestea se adaugă clauza 9.1 din corpul standardului: monitorizarea, măsurarea și evaluarea performanței SMSI.
Diferența practică e simplă: un scaner automat răspunde la A.8.8 („știm ce vulnerabilități avem"), dar nu la A.8.29 și nici la clauza 9.1 („am verificat că apărarea rezistă"). Un scaner nu încearcă să încatenezi două constatări medii într-o compromitere reală; un tester da.
Unde apare pentestul în SOC 2
SOC 2 se construiește pe Trust Services Criteria. Criteriul CC4.1 cere evaluări periodice ale controalelor, iar CC7.1 cere detectarea și monitorizarea vulnerabilităților și a configurațiilor noi. Într-un audit Type II, auditorul nu se uită la un moment, ci la o perioadă de 3–12 luni: contează că testarea s-a întâmplat în perioadă și că remedierile au fost urmărite până la capăt.
De aici vine greșeala cea mai scumpă: un raport de pentest datat înainte de începutul perioadei de observare nu contează ca dovadă pentru acea perioadă. Testarea se planifică odată cu fereastra de audit, nu după.
Ce cere fiecare cadru — și ce livrează pentestul
| Control / criteriu | Cerința relevantă | Dovada din pentest |
|---|---|---|
| ISO 27001 — A.8.8 | Vulnerabilitățile tehnice sunt identificate și tratate | Listă de constatări cu severitate, dovadă și plan de remediere |
| ISO 27001 — A.8.29 | Testarea securității în dezvoltare și acceptanță | Test pe mediul de preproducție înainte de lansare, cu criterii de acceptanță |
| ISO 27001 — clauza 9.1 | Evaluarea performanței măsurilor de securitate | Comparație între două cicluri de testare: ce s-a închis, ce a reapărut |
| SOC 2 — CC4.1 | Evaluări periodice ale eficacității controalelor | Raport datat în perioada de observare, cu perimetru documentat |
| SOC 2 — CC7.1 | Detectarea vulnerabilităților și a schimbărilor de configurație | Constatări de configurare, plus re-test care dovedește închiderea |
Când se face testul, în ciclul de certificare
- Înainte de auditul de etapa 2 (ISO) — ca să nu descoperi constatări majore în fața auditorului.
- În primele săptămâni ale perioadei de observare SOC 2 Type II — rămâne timp pentru remediere și re-test în aceeași fereastră.
- Anual, pentru auditurile de supraveghere.
- După orice schimbare majoră de arhitectură, migrare în cloud sau lansare de produs nou.
Ce trebuie să conțină raportul ca să treacă de auditor
- Perimetru explicit: ce adrese, aplicații și conturi au fost în test — și ce a rămas în afara lui.
- Metodologie declarată (OWASP, PTES) și date de start/final ale testării.
- Severitate motivată, nu doar un scor CVSS copiat din scaner.
- Rezumat executiv pe care îl poate citi comitetul de management fără traducere tehnică.
- Re-test documentat, cu starea finală a fiecărei constatări.
Întrebări frecvente
ISO 27001 obligă la test de penetrare?
Standardul nu folosește cuvântul „pentest" ca obligație explicită. Însă controalele A.8.8, A.8.29 și clauza 9.1 cer identificarea vulnerabilităților tehnice, testarea securității și evaluarea eficacității măsurilor. În practică, auditorii acceptă un test de penetrare drept dovada cea mai directă pentru aceste cerințe, iar o organizație care a declarat A.8.29 aplicabil fără să poată arăta testare riscă o neconformitate.
Un scan de vulnerabilități este suficient pentru SOC 2?
Scanarea acoperă partea de monitorizare continuă din CC7.1, dar rareori satisface singură CC4.1, care cere evaluarea eficacității controalelor. Un scaner raportează ce ar putea fi vulnerabil; un test de penetrare arată ce se poate exploata efectiv și până unde ajunge un atacator. Majoritatea auditorilor așteaptă ambele: scanare recurentă plus cel puțin un test manual în perioada de observare.
Cât de vechi poate fi raportul de pentest la audit?
Regula uzuală este maximum 12 luni, dar pentru SOC 2 Type II contează altceva: raportul trebuie datat în interiorul perioadei de observare. Un test excelent făcut cu o lună înainte de începutul ferestrei nu produce dovadă pentru acea fereastră. Pentru ISO, testul se recomandă înaintea auditului de certificare și apoi anual, la supraveghere.
Ce perimetru trebuie testat pentru certificare?
Perimetrul testului trebuie să acopere sistemele din domeniul de aplicare al SMSI, respectiv sistemele care susțin criteriile SOC 2 alese: aplicațiile expuse clienților, infrastructura care le găzduiește, mecanismele de autentificare și, tot mai des, configurația de cloud. Un perimetru mai îngust decât domeniul declarat este chiar lucrul pe care auditorul îl observă primul.
Cine poate face testul — o echipă internă?
Se poate, dar independența contează. ISO 27001 cere ca evaluarea să fie obiectivă, iar SOC 2 privește cu mai multă încredere o parte externă. Dacă echipa care a construit sistemul este și cea care îl testează, auditorul va cere dovezi suplimentare de separare a responsabilităților. Cea mai simplă cale este un furnizor extern, cu metodologie declarată și raport independent.
Ghiduri conexe
- Cât costă un pentest — ce determină prețul, cum se estimează efortul și ce face o ofertă comparabilă cu alta.
- DORA & TLPT — reziliența operațională digitală în sectorul financiar și testarea bazată pe amenințări.
- Legea 48/2023 (Moldova) — cadrul național de securitate cibernetică: cui i se aplică și ce obligații aduce.
- OWASP Top 10 — cele zece categorii de riscuri web, explicate cu exemple și cu ce se testează la fiecare.
- PCI DSS 4.0 — cerințele 11.3 și 11.4, testarea segmentării și ce înseamnă pentru procesatorii de plăți.
- Pentest vs scanare de vulnerabilități — ce găsește fiecare, ce ratează și ce acceptă auditorii ca dovadă.
- Cum te pregătești de pentest — perimetru, acces, reguli de angajament și tot ce se stabilește înainte de prima zi.
Acest material are caracter informativ și nu constituie consultanță de certificare. Cerințele exacte depind de domeniul de aplicare declarat și de organismul de certificare sau firma de audit aleasă.
Intri în certificare anul acesta?
Programează o consultație gratuită și primești un plan de testare aliniat la domeniul tău de aplicare și la calendarul auditului.