ISO 27001 și SOC 2: ce dovadă tehnică cere, de fapt, auditorul

Ai dosarul de politici complet, proceduri semnate, registre de risc actualizate și un SMSI care arată impecabil pe hârtie. Apoi auditorul se așază la masă, deschide laptopul și întreabă un singur lucru: „Arătați-mi că apărarea rezistă." Și aici se termină zona confortabilă a documentelor. ISO 27001 și SOC 2 nu sunt liste de vulnerabilități și niciunul nu scrie negru pe alb „faceți un test de penetrare în fiecare an". Amândouă cer însă ceva ce nu se poate demonstra din Word: dovada că măsurile tehnice chiar funcționează. De aici începe povestea pentestului în certificare.

De ce nu ajunge dosarul de politici

Un cadru de management al securității descrie intenția și procesul: cum identifici riscuri, cum decizi ce măsuri aplici, cum monitorizezi. Problema e că o politică aprobată spune doar că ai planificat să te aperi. Nu spune dacă firewall-ul chiar filtrează, dacă aplicația expusă clienților chiar validează ce primește sau dacă un atacator care a obținut un cont de utilizator obișnuit poate ajunge la baza de date.

Auditorul știe asta. De aceea, în practică, aproape orice auditor cere un test de penetrare: este cea mai directă dovadă că un control tehnic face ce pretinde că face. Diferența dintre o scanare automată și un test manual este exact diferența dintre „știm ce vulnerabilități avem" și „am verificat că apărarea rezistă". Un scaner nu încearcă să încateneze două constatări medii într-o compromitere reală. Un tester da — și asta se vede în raport.

Ce controale ISO 27001 ating testarea

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, care cere 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 răspunde la A.8.29 și nici la clauza 9.1, care întreabă altceva: am verificat că apărarea rezistă, și o putem demonstra comparând cicluri de testare? A.8.29 cere testare înainte de lansare, pe mediul de preproducție, cu criterii de acceptanță clare. Clauza 9.1 cere o evaluare a performanței măsurilor — adică nu doar „am testat", ci „ce s-a închis de la ultimul test și ce a reapărut".

Atenție: dacă ai marcat A.8.29 ca aplicabil în Declarația de aplicabilitate și nu ai nicio dovadă de testare, ți-ai creat singur o neconformitate. Auditorii verifică exact potrivirea dintre ce ai declarat aplicabil și ce poți arăta.

Unde apare pentestul în SOC 2

SOC 2 se construiește pe Trust Services Criteria, iar două criterii privesc direct testarea. CC4.1 cere evaluări periodice ale controalelor — adică dovezi că eficacitatea lor a fost verificată, nu doar presupusă. CC7.1 cere detectarea și monitorizarea vulnerabilităților și a configurațiilor noi, ceea ce acoperă atât scanarea recurentă, cât și constatările de configurare.

Aici intervine particularitatea care prinde multe companii nepregătite: î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. Un raport de pentest datat înainte de începutul perioadei de observare nu contează ca dovadă pentru acea perioadă, oricât de bun ar fi tehnic.

Important: testarea se planifică împreună cu fereastra de audit, nu după ea. Un test excelent făcut cu o lună înainte de începutul perioadei de observare nu produce dovadă pentru acea fereastră.

Ce cere fiecare cadru, punct cu punct

Cel mai clar mod de a înțelege legătura dintre cerință și livrabil este să le pui față în față. Tabelul de mai jos arată ce anume urmărește auditorul la fiecare control și ce trebuie să conțină raportul ca să răspundă.

Observă firul comun: niciun rând din tabel nu se rezolvă cu un PDF de politici. Toate cer dovezi tehnice, datate, cu perimetru clar și cu urmărirea remedierii.

Când se face testul, în ciclul de certificare

Momentul ales contează aproape la fel de mult ca testul în sine. Un pentest făcut la momentul greșit poate însemna bani cheltuiți fără ca auditorul să îl accepte ca dovadă pentru perioada relevantă.

• Înainte de auditul de etapa 2 (ISO) — ca să nu descoperi constatări majore chiar în fața auditorului, când nu mai ai timp de remediere.
• În primele săptămâni ale perioadei de observare SOC 2 Type II — rămâne timp suficient pentru remediere și re-test în aceeași fereastră.
• Anual, pentru auditurile de supraveghere, astfel încât clauza 9.1 să aibă două cicluri comparabile.
• După orice schimbare majoră de arhitectură, migrare în cloud sau lansare de produs nou — pentru că perimetrul se schimbă, iar dovada veche nu mai acoperă ce e nou.

Există și o capcană de calendar care costă scump: dacă planifici perioada de observare SOC 2 fără să tai câteva zile pentru testare la începutul ei, ajungi să testezi la final, când remedierea nu mai încape în fereastră. Ordinea corectă este test, remediere, re-test — toate în interiorul perioadei.

Cum arată raportul care trece de auditor

Un raport de pentest scris pentru echipa tehnică și unul scris pentru audit nu sunt identice. Auditorul nu vrea să citească payload-uri, vrea să verifice că testarea a fost reală, cuprinzătoare și urmărită. Iată elementele care fac diferența dintre un raport acceptat și unul respins.

• Perimetru explicit: ce adrese, aplicații și conturi au fost în test — și, la fel de important, ce a rămas în afara lui. Un perimetru mai îngust decât domeniul declarat este primul lucru pe care îl observă auditorul.
• Metodologie declarată (OWASP, PTES) și date de start/final ale testării, ca să se poată verifica încadrarea în perioada de observare.
• Severitate motivată, nu doar un scor CVSS copiat din scaner. Auditorul vrea să vadă de ce o constatare contează în contextul tău, nu doar cât de roșu e un număr.
• Rezumat executiv pe care comitetul de management îl poate citi fără traducere tehnică — pentru că semnătura de aprobare vine de acolo.
• Re-test documentat, cu starea finală a fiecărei constatări: închisă, acceptată ca risc sau în curs. Fără acest pas, CC4.1 și clauza 9.1 rămân fără răspuns.

Un detaliu care merită subliniat: raportul trebuie să spună și ce nu s-a testat. Onestitatea despre limitele testului nu slăbește dovada, o întărește. Auditorul preferă un perimetru clar delimitat unui document care sugerează o acoperire totală pe care nimeni nu o poate susține.

Scanare sau pentest? Ambele, de fapt

Întrebarea „ne trebuie scanare sau pentest?" primește aproape mereu același răspuns: ambele, pentru că răspund la întrebări diferite. Scanarea acoperă partea de monitorizare continuă din CC7.1 și susține A.8.8 prin detectarea recurentă a vulnerabilităților cunoscute. 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. De aceea, majoritatea auditorilor așteaptă ambele: scanare recurentă pe tot parcursul anului, plus cel puțin un test manual în perioada de observare. Combinația spune o poveste completă — monitorizezi constant și verifici periodic că apărarea rezistă în profunzime.

Cine poate face testul

Se poate și cu o echipă internă, 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 — ceea ce, într-o companie mică, e greu de demonstrat convingător. Cea mai simplă cale rămâne un furnizor extern, cu metodologie declarată și raport independent.

Cât de vechi poate fi raportul

Regula uzuală este maximum 12 luni, dar pentru SOC 2 Type II contează altceva: raportul trebuie datat în interiorul perioadei de observare. Pentru ISO, testul se recomandă înaintea auditului de certificare și apoi anual, la supraveghere. Dacă perioada de observare se întinde pe 12 luni, un singur test la început poate să nu fie suficient pentru unii auditori — de aceea multe companii planifică două cicluri.

Ce rămâne după ce închizi dosarul

Certificarea nu este un examen care se termină o dată și se uită. Fiecare ciclu de testare lasă în urmă o hartă a ceea ce s-a închis și a ceea ce reapare, iar acea hartă devine, în timp, cel mai valoros document de securitate pe care îl ai. Ea arată tendințe, nu doar instantanee: aceleași două tipuri de constatări care revin an după an îți spun mai mult despre procesul tău de dezvoltare decât orice politică.

Din perspectiva noastră, după testări făcute pentru companii care intră în certificare, greșeala cea mai frecventă nu este tehnică. Este de planificare: testul făcut prea devreme, prea târziu sau pe un perimetru mai mic decât domeniul declarat. Toate trei se rezolvă înainte de prima zi de testare, printr-o discuție despre domeniul de aplicare și calendarul auditului. Dacă reușești să aliniezi aceste două lucruri, pentestul nu mai este o cheltuială de conformitate — devine exact ce ar trebui să fie: dovada că sistemele tale rezistă, scrisă într-un limbaj pe care auditorul îl acceptă fără să pună întrebări.