SLA-uri pentru remedierea vulnerabilităților în contextul NIS2 și DORA

La ora 08:17, într-o dimineață de marți de la începutul anului 2026, Anna, directorul securității informației al unei companii fintech aflate în creștere rapidă, primește primul mesaj înainte să își termine cafeaua.

Centrul de operațiuni de securitate a semnalat discuții privind exploatarea activă a unei vulnerabilități într-un gateway API destinat clienților. Echipa de inginerie spune că patch-ul este disponibil, dar riscant, deoarece gateway-ul se află în fața fluxurilor de plată. Managerul de conformitate transmite mai departe o solicitare formală din partea unei autorități naționale competente, care cere dovezi privind „gestionarea și divulgarea vulnerabilităților” și dovada că procesul a fost eficace în ultimele 12 luni. Achizițiile adaugă o a treia problemă: gateway-ul este administrat de un MSP, iar contractul spune doar că furnizorul va aplica „actualizări de securitate în timp util”.

Până la ora 09:00, aceasta nu mai este doar o problemă de aplicare a patch-urilor. Este o problemă de dovezi pentru ISO/IEC 27001:2022, o problemă de igienă cibernetică NIS2, o problemă de gestionare a riscurilor TIC DORA, o problemă de guvernanță a furnizorilor și, potențial, o problemă de raportare a incidentelor dacă exploatarea afectează continuitatea serviciilor sau datele cu caracter personal.

Aceasta este lacuna practică de conformitate cu care se vor confrunta multe organizații în 2026. Au scanere, tablouri de bord, tichete și instrumente de patching, dar nu pot răspunde clar la întrebările de audit:

• Cine a aprobat SLA-ul de remediere?
• Cum este SLA-ul bazat pe risc?
• Ce se întâmplă când un patch critic depășește termenul-limită?
• Cum sunt prioritizate activele expuse la internet?
• Cum sunt obligați furnizorii să respecte aceleași termene?
• Unde este înregistrarea de acceptare a riscului pentru un sistem fără patch?
• Ce dovezi demonstrează că un control a funcționat, nu doar că a existat?

Răspunsul nu este încă un tabel cu termene-limită. SLA-urile de remediere a vulnerabilităților trebuie gestionate ca un sistem viu de control, care conectează deținerea activelor, scorarea vulnerabilităților, informațiile despre amenințări, managementul schimbărilor, SLA-urile furnizorilor, gestionarea excepțiilor, monitorizarea, răspunsul la incidente și analiza efectuată de management.

Aici devin utile soluțiile Clarysec pentru organizații mari Politica de management al vulnerabilităților și al patch-urilor (VPMP), pentru IMM-uri Politica de management al vulnerabilităților și al patch-urilor pentru IMM-uri (VPMP-SME), Politica de securitate privind terții și furnizorii pentru IMM-uri (TPSSP-SME), Zenith Blueprint (ZB) și Zenith Controls (ZC). Împreună, acestea transformă „aplicați patch-urile mai repede” într-un proces de guvernanță defensabil, capabil să reziste examinării de audit în stil ISO, NIS2, DORA, GDPR, NIST și ISACA.

De ce SLA-urile de remediere a vulnerabilităților au devenit dovezi la nivelul consiliului de administrație

Remedierea vulnerabilităților era tratată anterior ca o metrică de igienă IT. În 2026, ea este mai apropiată de un angajament reglementat de reziliență operațională.

NIS2 transformă securitatea cibernetică într-o chestiune de responsabilitate a conducerii. Entitățile esențiale și importante trebuie să aibă organisme de conducere care aprobă măsurile de gestionare a riscurilor de securitate cibernetică, supraveghează implementarea și primesc instruire pentru a înțelege riscurile și impactul practicilor de securitate asupra serviciilor. NIS2 Article 21 cere măsuri tehnice, operaționale și organizatorice adecvate și proporționale, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția și mentenanța securizate, gestionarea și divulgarea vulnerabilităților, igienă cibernetică, instruire, controlul accesului, politica de management al activelor și autentificare.

Pentru entitățile financiare, DORA este regimul specializat de reziliență operațională. Acesta cere mecanisme de guvernanță și control pentru riscul TIC, organismul de conducere definind, aprobând, supraveghind și rămânând responsabil pentru gestionarea riscurilor TIC. De asemenea, cere identificarea activelor TIC și a dependențelor, controale de protecție și prevenire precum aplicarea patch-urilor și managementul schimbărilor, gestionarea incidentelor legate de TIC, testarea rezilienței operaționale digitale și managementul riscurilor asociate terților TIC.

Impactul practic este semnificativ. Un termen ratat pentru aplicarea unui patch poate indica un eșec al:

• Guvernanței, dacă managementul nu a aprobat SLA-uri bazate pe risc
• Politicii de management al activelor, dacă proprietarul sistemului afectat este necunoscut
• Managementului schimbărilor, dacă aplicarea de urgență a patch-urilor nu este controlată
• Managementului furnizorilor, dacă termenele furnizorului sunt vagi
• Răspunsului la incidente, dacă semnele de exploatare nu sunt triate
• Gestionării dovezilor, dacă tichetele și jurnalele nu pot demonstra închiderea
• Tratării riscului, dacă excepțiile nu sunt aprobate și revizuite

ISO/IEC 27001:2022 oferă coloana vertebrală a sistemului de management. Clauzele 4.1–4.3 cer organizațiilor să înțeleagă aspectele interne și externe, cerințele părților interesate, obligațiile legale și contractuale și interfețele cu alte organizații. Clauzele 6.1.1–6.1.3 cer evaluarea riscurilor, tratarea riscurilor, o Declarație de aplicabilitate și aprobarea riscului rezidual de către proprietarul riscului. Clauzele 9.1, 9.2, 9.3, 10.1 și 10.2 cer monitorizare, audit intern, analiza efectuată de management, îmbunătățire continuă, acțiune corectivă și dovezi păstrate.

Pe scurt, dacă doriți ca SLA-urile de remediere a vulnerabilităților să fie pregătite pentru audit, acestea trebuie să facă parte din SMSI, nu să fie doar o metrică DevOps.

Modelul de SLA pe care auditorii se așteaptă să îl vadă

Un SLA de remediere a vulnerabilităților trebuie să răspundă la trei întrebări:

1. Cât de repede trebuie să acționăm?
2. Cine este responsabil?
3. Ce dovezi demonstrează rezultatul?

Politica de management al vulnerabilităților și al patch-urilor definește un punct de plecare practic pentru termene de remediere bazate pe risc:

Organizația trebuie să clasifice toate vulnerabilitățile detectate utilizând o metodologie standardizată (de exemplu, CVSS v3.x) și să aplice termene de remediere aliniate la criticitatea activității: 5.2.1 Critică (CVSS 9.0-10.0): revizuire imediată; termen maxim de aplicare a patch-ului de 72 de ore. 5.2.2 Ridicată (7.0-8.9): răspuns în 48 de ore; termen de aplicare a patch-ului de 7 zile calendaristice. 5.2.3 Medie (4.0-6.9): răspuns în 5 zile; termen de aplicare a patch-ului de 30 de zile calendaristice. 5.2.4 Scăzută (<4.0): răspuns în 10 zile; termen de aplicare a patch-ului de 60 de zile calendaristice.

Această clauză este solidă deoarece separă timpul de răspuns de termenul de aplicare a patch-ului. O vulnerabilitate cu severitate ridicată nu trebuie să rămână neobservată timp de șase zile și apoi să fie remediată în ziua a șaptea. Ceasul de răspuns confirmă triajul, responsabilitatea, evaluarea impactului riscului și planificarea remedierii. Termenul de aplicare a patch-ului confirmă închiderea tehnică sau existența unei excepții aprobate.

Pentru organizațiile mai mici, Politica de management al vulnerabilităților și al patch-urilor pentru IMM-uri folosește un limbaj mai simplu, dar totuși verificabil:

Patch-urile critice trebuie aplicate în termen de 3 zile de la lansare, în special pentru sistemele expuse la internet

Iar pentru ansamblul mai larg al patch-urilor:

Toate celelalte patch-uri trebuie aplicate în termen de 30 de zile, cu excepția cazului în care este documentată o excepție validă

Ideea nu este că fiecare organizație trebuie să folosească termene identice. ISO/IEC 27001:2022, NIS2 și DORA susțin toate proporționalitatea. Ideea este că SLA-urile de remediere trebuie definite, aprobate, bazate pe risc, monitorizate și documentate prin dovezi.

Aici eșuează multe companii. Definim SLA-ul, dar nu definim dovezile. Din perspectiva auditorului, o politică fără înregistrări operaționale este o promisiune, nu un control.

Deținerea activelor este dependența ascunsă

Un scaner vă poate spune că există un CVE pe un server. Nu vă poate spune dacă serverul susține un proces critic de plată, stochează date cu caracter personal din categorii speciale, se conectează la un furnizor de decontare sau este programat pentru dezafectare.

Acest context vine din politica de management al activelor, clasificarea datelor, inventarul furnizorilor și evaluarea riscurilor.

ISO/IEC 27001:2022 Anexa A controlul 8.8, managementul vulnerabilităților tehnice, este central, dar nu funcționează izolat. Depinde în mare măsură de managementul configurației, managementul schimbărilor, monitorizarea furnizorilor, guvernanța cloud, jurnalizare, monitorizare și tratarea riscurilor.

NIST CSF 2.0 exprimă aceeași problemă în limbaj de rezultate. Funcția GOVERN așteaptă ca cerințele de securitate cibernetică legale, de reglementare și contractuale să fie înțelese și gestionate, ca apetitul la risc și toleranța la risc să fie documentate, rolurile și resursele să fie alocate, iar politicile de securitate cibernetică să fie stabilite, aplicate, revizuite și actualizate. Rezultatele IDENTIFY includ inventare de hardware, software, servicii, sisteme, date și cicluri de viață, împreună cu identificarea riscurilor privind vulnerabilitățile, analiza riscurilor, gestionarea excepțiilor și procese de divulgare a vulnerabilităților.

În scenariul Annei din dimineața de marți, prima întrebare tehnică este „unde este componenta vulnerabilă?”. Prima întrebare de guvernanță este „ce serviciu și ce risc afectează?”.

Zenith Blueprint, faza de management al riscurilor, Pasul 13: planificarea tratării riscurilor și Declarația de aplicabilitate, abordează acest lucru prin conectarea riscurilor cu controale, proprietari și termene:

De asemenea, atribuiți un proprietar și un termen pentru fiecare acțiune (eventual într-o coloană separată sau în comentarii). De exemplu: „Proprietar: Manager IT, termen: până în T3 2025.” Astfel, documentul devine un plan real.

Exact acest lucru necesită remedierea vulnerabilităților. O constatare fără proprietar devine zgomot de backlog. O constatare cu proprietar, termen, decizie de tratare a riscului și pistă de audit devine un control verificabil.

Cum mapează Zenith Controls relațiile dintre controale

Zenith Controls tratează controlul ISO/IEC 27002:2022 8.8, managementul vulnerabilităților tehnice, ca pe un control preventiv care susține confidențialitatea, integritatea și disponibilitatea. Îl conectează la conceptele de securitate cibernetică Identify și Protect, la capabilitatea operațională de management al amenințărilor și vulnerabilităților și la domeniile de securitate privind guvernanța, ecosistemul, protecția și apărarea.

Acest lucru contează deoarece SLA-urile de remediere nu sunt doar un mecanism de protecție. Ele sunt și un mecanism de guvernanță și un mecanism de ecosistem. Expunerea este modelată de furnizori, platforme cloud, servicii administrate, componente open-source și dependențe expuse la internet.

Zenith Controls mapează 8.8 la mai multe controale-suport:

Zenith Controls conectează, de asemenea, managementul vulnerabilităților la ISO/IEC 27005:2024, în special la identificarea vulnerabilităților și la scenariile de risc care implică sisteme fără patch. Aceasta consolidează argumentul că termenele de aplicare a patch-urilor trebuie să fie bazate pe risc, nu arbitrare. De asemenea, conectează monitorizarea furnizorilor la ISO/IEC 27036-4:2016 pentru nivelurile de securitate din acordurile de servicii cloud și la ISO/IEC 20000-1:2018 pentru planificarea livrării serviciilor și managementul schimbărilor.

Această structură trans-standard contează în timpul auditului. Dacă o organizație afirmă că „vulnerabilitățile critice sunt patch-uite în 72 de ore”, auditorul va testa dacă acea afirmație este susținută de evaluarea riscurilor, clasificarea activelor, obligațiile furnizorilor, înregistrările schimbărilor și dovezile de monitorizare.

Igiena cibernetică NIS2: de la gestionarea vulnerabilităților la acțiune corectivă

NIS2 Article 21 cere o abordare all-hazards pentru rețelele și sistemele informatice. Pentru SLA-urile de remediere a vulnerabilităților, mai multe elemente din Article 21 sunt direct relevante:

• Analiza riscurilor și politici de securitate a sistemelor informatice
• Gestionarea incidentelor
• Continuitatea activității și managementul crizelor
• Securitatea lanțului de aprovizionare
• Achiziție, dezvoltare și mentenanță securizate, inclusiv gestionarea și divulgarea vulnerabilităților
• Proceduri pentru evaluarea eficacității securității cibernetice
• Igienă cibernetică de bază și instruire
• Controlul accesului și politica de management al activelor
• Autentificare multifactor sau autentificare continuă, după caz

NIS2 Article 20 face organismele de conducere responsabile pentru aprobarea și supravegherea măsurilor de gestionare a riscurilor de securitate cibernetică. Aceasta înseamnă că metricile de remediere a vulnerabilităților nu pot exista doar într-un tablou de bord al ingineriei. Ele trebuie să apară în raportarea către management, în materialele comitetului de risc sau în înregistrările analizei efectuate de management în cadrul SMSI.

Article 21 se așteaptă, de asemenea, ca entitățile care identifică neconformități cu măsurile cerute să ia acțiuni corective fără întârzieri nejustificate. Această formulare contează. Dacă tabloul de bord arată vulnerabilități critice restante, dovezile de conformitate nu trebuie să se oprească la „știm”. Ele trebuie să arate escaladare, revizuirea riscului, vizibilitate pentru management, acțiune corectivă și reevaluare.

NIS2 Article 23 adaugă o altă dimensiune. Dacă exploatarea unei vulnerabilități fără patch cauzează sau poate cauza perturbări operaționale severe, pierderi financiare sau prejudicii altor persoane, aceasta poate deveni un incident semnificativ. Ciclul de raportare include avertizare timpurie în termen de 24 de ore de la luarea la cunoștință a incidentului semnificativ, notificarea incidentului în termen de 72 de ore, rapoarte intermediare la cerere și un raport final în termen de o lună după notificarea incidentului. Raportul final trebuie să includă severitatea, impactul, cauza principală probabilă, măsurile de atenuare și impactul transfrontalier, după caz.

Prin urmare, procesul SLA trebuie să se conecteze la răspunsul la incidente. O vulnerabilitate critică pentru care există dovezi de exploatare activă trebuie să declanșeze triaj de securitate, monitorizare, păstrarea dovezilor și o evaluare a obligațiilor de raportare, nu doar un tichet obișnuit de patch.

Riscul TIC DORA: termenele de remediere ca dovezi de reziliență

Pentru entitățile financiare, DORA se aplică de la 17 ianuarie 2025 și creează cerințe uniforme privind gestionarea riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale digitale, schimbul de informații și managementul riscurilor asociate terților TIC. Este tratată ca actul juridic sectorial specific al UE pentru entitățile financiare acoperite identificate în temeiul normelor naționale NIS2.

Modelul operațional DORA este apropiat de un SMSI integrat. Articles 5 și 6 cer guvernanță, politici, proceduri, instrumente, revizuire anuală sau periodică, audit, remedierea constatărilor critice de audit și o strategie de reziliență operațională digitală. Article 8 cere identificarea și inventarierea funcțiilor de afaceri susținute de TIC, a activelor informaționale, activelor TIC, dependențelor, proceselor terților și riscurilor TIC moștenite. Article 9 cere controale de protecție și prevenire, inclusiv aplicarea patch-urilor și managementul schimbărilor. Articles 11 și 12 cer continuitate, răspuns, recuperare, backup, restaurare și obiective de recuperare.

DORA Articles 17–19 cer un proces de gestionare a incidentelor legate de TIC care detectează, gestionează, înregistrează, clasifică, escaladează, raportează, comunică, analizează cauza principală și restaurează operațiunile securizate. Articles 24–26 cer testarea rezilienței operaționale digitale, inclusiv testarea adecvată a instrumentelor și sistemelor TIC, evaluări de vulnerabilitate, evaluări de securitate a rețelei, analize ale lacunelor, revizuirea codului sursă acolo unde este fezabil, testare de penetrare și testare de penetrare bazată pe amenințări pentru anumite entități financiare. Articles 28 și 30 cer managementul riscului asociat terților TIC, registre ale contractelor de servicii TIC, verificare prealabilă, drepturi de audit și inspecție, niveluri de servicii, asistență din partea furnizorilor în timpul incidentelor, drepturi de încetare și aranjamente de ieșire.

Pentru SLA-urile de remediere, DORA schimbă așteptările privind dovezile în trei moduri.

În primul rând, constatările privind vulnerabilitățile rezultate din testare trebuie să alimenteze un proces de remediere prioritizat. Un raport de scanare nu este suficient.

În al doilea rând, remedierea constatărilor critice trebuie urmărită prin guvernanță și audit. DORA se așteaptă la remedierea formală a constatărilor critice de audit pentru entitățile care nu sunt microîntreprinderi.

În al treilea rând, furnizorii terți de servicii TIC trebuie obligați să respecte obligații măsurabile. Dacă furnizorul cloud, SaaS sau MSP controlează fereastra de aplicare a patch-urilor, contractul și registrul dumneavoastră trebuie să arate cum termenele lor de remediere susțin obligațiile dumneavoastră de reziliență.

Politica de management al vulnerabilităților și al patch-urilor tratează direct acest aspect:

Supravegherea aplicării patch-urilor de către terți și a riscurilor SaaS 6.6.1 Toate sistemele terților (SaaS, PaaS, gestionate de MSP) trebuie să demonstreze controale adecvate de management al vulnerabilităților și al patch-urilor. 6.6.2 SLA-urile furnizorilor trebuie să includă termene de remediere echivalente cu pragurile definite intern, bazate pe criticitate.

Această clauză este adesea puntea lipsă dintre dovezile ISO interne și supravegherea furnizorilor impusă de DORA.

GDPR: când întârzierile la patch-uri devin eșecuri de responsabilizare privind datele cu caracter personal

GDPR nu este un standard de management al vulnerabilităților, dar schimbă consecințele eșecului de patching.

GDPR Article 5 cere ca datele cu caracter personal să fie prelucrate în siguranță și cere operatorului de date să poată demonstra conformitatea. Article 32 cere măsuri tehnice și organizatorice adecvate pentru a asigura un nivel de securitate corespunzător riscului. Atunci când sistemele fără patch prelucrează date cu caracter personal, în special date de identitate, date financiare, date biometrice, date de sănătate, date privind angajații sau informații KYC, SLA-urile de remediere devin parte a responsabilizării privind securitatea prelucrării.

O întârziere la aplicarea unui patch poate fi susținută dacă riscul a fost evaluat, controalele compensatorii au fost aplicate și riscul rezidual a fost acceptat de persoana potrivită. Este mult mai greu de susținut dacă vulnerabilitatea era restantă, expusă la internet și fără proprietar.

Zenith Controls mapează managementul vulnerabilităților la GDPR Articles 32 și 5(1)(f), deoarece aplicarea la timp a patch-urilor reduce riscurile pentru confidențialitatea și integritatea datelor cu caracter personal. De asemenea, mapează managementul schimbărilor la GDPR Article 24 și Article 32, deoarece schimbările aduse sistemelor care prelucrează date cu caracter personal trebuie evaluate din perspectiva riscului, aprobate, documentate și revizuite.

Lecția de conformitate este simplă: dacă sunt implicate date cu caracter personal, dovezile privind patch-urile trebuie să includă contextul datelor. Auditorii și autoritățile de reglementare vor întreba nu doar „a fost aplicat patch-ul?”, ci și „ce date au fost expuse riscului, pentru cât timp și ce controale au redus acel risc?”.

Un flux de lucru Clarysec practic pentru dovezi SLA pregătite pentru audit

Un proces matur de remediere a vulnerabilităților nu începe atunci când un auditor cere înregistrări. El este proiectat să producă înregistrări în fiecare lună.

Pasul 1: Aprobați politica SLA

Începeți cu Politica de management al vulnerabilităților și al patch-urilor sau cu Politica de management al vulnerabilităților și al patch-urilor pentru IMM-uri, în funcție de modelul operațional. Adaptați pragurile SLA la apetitul la risc, domeniul de reglementare, criticitatea serviciilor, sensibilitatea datelor și constrângerile tehnice. Asigurați aprobarea de către directorul securității informației, comitetul de risc sau organismul de conducere.

Pentru medii enterprise, utilizați CVSS, criticitatea activelor, exploatabilitatea, expunerea la internet, sensibilitatea datelor și impactul asupra activității. Pentru IMM-uri, păstrați modelul simplu, dar explicit: patch-uri critice în termen de trei zile, celelalte patch-uri în termen de 30 de zile, cu excepția cazului în care există o excepție validă.

Pasul 2: Mapați activele la proprietari și servicii critice

Fiecare constatare de vulnerabilitate trebuie să poată fi legată de:

• Denumirea activului și identificator unic
• Serviciul de business sau aplicația
• Proprietar de sistem
• Proprietar tehnic
• Clasificarea datelor
• Expunere la internet
• Dependență de furnizor, dacă este cazul
• Criticitatea funcției susținute

Aceasta susține deținerea riscurilor în ISO/IEC 27001:2022, politica de management al activelor NIS2, inventarul activelor și dependențelor TIC DORA și rezultatele NIST CSF IDENTIFY.

Pasul 3: Triați vulnerabilitatea

Creați un tichet pentru fiecare constatare sau set grupat de constatări. Includeți scorul CVSS, scanerul sursă, activul afectat, statutul de exploatare, informațiile despre amenințări, criticitatea activității și SLA-ul necesar. Dacă se suspectează exploatarea, conectați tichetul la o evaluare de incident.

Pasul 4: Executați prin managementul schimbărilor

Aplicarea patch-urilor este o schimbare. Utilizați schimbare standard pentru actualizări de rutină și schimbare de urgență pentru vulnerabilități critice exploatate. Includeți dovezi de testare, aprobare, marcaj temporal al implementării, plan de revenire și validare post-schimbare.

Aceasta corespunde relației din Zenith Controls dintre 8.8 și 8.32, unde aplicarea patch-urilor este guvernată prin managementul schimbărilor pentru a echilibra urgența și stabilitatea operațională.

Pasul 5: Validați închiderea

Nu închideți tichetele doar pe baza afirmației „patch instalat”. Solicitați validarea prin rescanare, confirmarea versiunii, verificarea configurației sau confirmarea controalelor compensatorii. Dacă patch-ul nu poate fi aplicat, deschideți o excepție.

Pasul 6: Înregistrați excepțiile și riscul rezidual

Politica de management al vulnerabilităților și al patch-urilor definește conținutul necesar pentru excepții:

Solicitările de excepție trebuie să includă: 7.2.1 Justificarea de business pentru întârziere sau neremediere 7.2.2 evaluarea riscurilor (pe baza CVSS, criticității activului, informațiilor despre amenințări) 7.2.3 controale compensatorii propuse 7.2.4 termen pentru remediere sau reevaluare

De asemenea, definește aprobarea și revizuirea:

Excepțiile trebuie aprobate de directorul securității informației sau de comitetul de risc delegat și înregistrate în registrul de excepții al SMSI, cu un interval de revizuire care nu depășește 90 de zile.

Acest registru al excepțiilor devine o dovadă esențială pentru ISO/IEC 27001:2022 Clause 6.1.3 privind tratarea riscurilor și acceptarea riscului rezidual, precum și pentru analiza efectuată de management.

Această înregistrare demonstrează că organizația nu a ignorat vulnerabilitatea. A evaluat riscul, a aplicat controale compensatorii, a aprobat riscul rezidual și a stabilit o dată de revizuire.

Pasul 7: Construiți pachetul lunar de dovezi

Pachetul lunar de dovezi privind remedierea vulnerabilităților trebuie să includă:

Pentru IMM-uri, dovezile pot fi mai ușoare, dar trebuie să rămână consecvente. Politica de management al vulnerabilităților și al patch-urilor pentru IMM-uri cere jurnale ale patch-urilor cu trasabilitate:

Jurnalele trebuie să includă numele dispozitivului, actualizarea aplicată, data aplicării patch-ului și motivul oricărei întârzieri

Această singură clauză este extrem de valoroasă pentru audit. Transformă patchingul dintr-o afirmație într-o înregistrare.

Patchingul furnizorilor: contractul trebuie să corespundă SLA-ului dumneavoastră

Dacă un MSP, furnizor SaaS, furnizor PaaS sau furnizor de servicii cloud controlează implementarea patch-urilor, SLA-urile interne sunt inutile dacă obligațiile furnizorului nu le corespund.

Politica de securitate privind terții și furnizorii pentru IMM-uri include obligații de securitate a informației ca cerință de guvernanță. Pentru remedierea vulnerabilităților, aceste obligații trebuie transformate în limbaj contractual măsurabil:

• Ferestre de notificare pentru vulnerabilități critice
• Termene de remediere pentru vulnerabilități critice, ridicate, medii și scăzute
• Proces de schimbare de urgență
• Cerințe de aprobare din partea clientului pentru indisponibilitate
• Formatul dovezilor pentru finalizarea patch-ului
• Proces de divulgare a vulnerabilităților
• Obligații de asistență în cazul incidentelor
• Dreptul de audit sau de primire a rapoartelor de asigurare
• Obligații de patching pentru persoane împuternicite secundare sau subcontractori
• Suport pentru ieșire și tranziție pentru servicii critice

Zenith Blueprint, faza Controls in Action, Pasul 20, Controlul 8.21 Securitatea serviciilor de rețea, exprimă clar principiul:

Atunci când serviciile sunt furnizate extern, inclusiv de ISP-uri, furnizori SD-WAN sau furnizori de cloud privat, cerințele de securitate trebuie incluse în contracte și SLA-uri. Aceasta include garanții de disponibilitate, timpi de răspuns la incidente, obligații de aplicare a patch-urilor sau de atenuare a vulnerabilităților și limite clare privind gestionarea datelor. Nu trebuie să presupuneți niciodată că un furnizor vă îndeplinește așteptările dacă acestea nu sunt scrise, măsurabile și verificabile.

DORA face acest lucru deosebit de important pentru entitățile financiare. Aranjamentele cu terții TIC trebuie să includă niveluri de servicii, asistență din partea furnizorului în timpul incidentelor TIC, acces la date și recuperarea acestora, cooperare cu autoritățile, drepturi de încetare și prevederi mai stricte pentru funcții critice sau importante, inclusiv monitorizare, drepturi de audit, planuri de continuitate și măsuri de securitate.

NIST CSF 2.0 spune același lucru prin rezultatele privind riscul lanțului de aprovizionare: furnizorii trebuie cunoscuți, prioritizați după criticitate, evaluați înainte de angajament, guvernați prin cerințe contractuale, monitorizați pe durata relației, incluși în planificarea incidentelor și gestionați la încetare.

Ce vor întreba efectiv auditorii

Discuția de audit se schimbă în funcție de profilul auditorului.

Un auditor ISO/IEC 27001:2022 va începe cu SMSI. Va verifica dacă managementul vulnerabilităților este inclus în Declarația de aplicabilitate, dacă evaluarea riscurilor identifică sistemele fără patch ca risc, dacă planurile de tratare a riscurilor au proprietari și termene, dacă controlul 8.8 din Anexa A este implementat, dacă dovezile sunt păstrate și dacă auditul intern și analiza efectuată de management evaluează performanța.

Zenith Blueprint, faza Controls in Action, Pasul 19, explicitează așteptarea de audit:

Acesta este un control cu prioritate ridicată pentru auditori, iar aceștia vor analiza de obicei în profunzime. Așteptați-vă să fiți întrebați cât de des sunt patch-uite sistemele, ce proces urmați când este anunțat un zero-day și ce sisteme sunt cel mai greu de patch-uit.

Continuă cu așteptări practice privind dovezile:

Auditorii vor solicita probabil rezultate ale scanărilor de vulnerabilitate. Dacă utilizați instrumente precum Nessus, OpenVAS sau Qualys, exportați un raport care arată vulnerabilitățile recente detectate și modul în care au fost tratate. Ideal, acesta trebuie să includă ratinguri de risc (CVSS) și termene de remediere.

Un auditor sau o autoritate competentă concentrată pe NIS2 va căuta aprobarea consiliului de administrație, proporționalitate, igienă cibernetică, gestionarea vulnerabilităților, securitatea furnizorilor, gestionarea incidentelor, evaluarea eficacității, acțiune corectivă fără întârzieri nejustificate și înregistrări ale deciziilor de raportare dacă exploatarea a cauzat impact semnificativ.

Un supraveghetor DORA va testa dacă constatările privind vulnerabilitățile sunt integrate în gestionarea riscurilor TIC, testarea rezilienței operaționale digitale, clasificarea incidentelor, analiza cauzei principale, registrele terților, obligațiile contractuale, drepturile de audit și remedierea constatărilor critice.

Un evaluator NIST CSF va organiza probabil revizuirea în jurul funcțiilor GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER. Va întreba dacă cerințele legale și contractuale sunt înțelese, dacă toleranța la risc este documentată, dacă vulnerabilitățile sunt identificate și prioritizate, dacă excepțiile sunt gestionate, dacă monitorizarea detectează exploatarea și dacă acțiunile de răspuns și recuperare sunt coordonate.

Un auditor COBIT 2019 sau în stil ISACA se va concentra pe obiective de guvernanță, capabilitatea proceselor, practici de management, metrici, deținere, proiectarea controalelor, funcționarea controalelor și suficiența dovezilor. Va întreba dacă remedierea vulnerabilităților este repetabilă, măsurată, escaladată, îmbunătățită și aliniată la obiectivele organizației și apetitul la risc.

Escaladare și metrici: cum demonstrați că SLA-ul este gestionat

Un SLA fără escaladare este doar o țintă. Un program defensabil de remediere a vulnerabilităților are nevoie de escaladare înainte de încălcare, la încălcare și după eșecuri repetate.

Clarysec recomandă un model de escaladare pe patru niveluri:

1. Escaladare operațională, proprietarul tichetului și responsabilul tehnic sunt notificați înainte de încălcare.
2. Escaladarea riscului, proprietarul activului și proprietarul riscului revizuiesc impactul atunci când încălcarea este probabilă.
3. Escaladarea guvernanței securității, directorul securității informației sau comitetul de risc aprobă excepția sau acțiunea de urgență.
4. Escaladare către management, încălcările SLA repetate sau critice sunt raportate în analiza efectuată de management împreună cu acțiuni corective.

Politica de management al vulnerabilităților și al patch-urilor consolidează această așteptare de audit:

Auditurile periodice trebuie efectuate de auditul intern sau de o parte terță independentă pentru a verifica: 5.6.1 Respectarea SLA-urilor 5.6.2 Dovezi privind prioritizarea bazată pe risc 5.6.3 Eficacitatea patch-urilor implementate 5.6.4 Controale asupra sistemelor fără patch

Metricile trebuie să susțină deciziile, nu să decoreze tablouri de bord. Cele mai puternice metrici pentru 2026 includ:

• Procentul de respectare a SLA-ului critic
• Procentul de respectare a SLA-ului ridicat
• Timpul mediu până la triaj
• Timpul mediu de remediere pe clasă de active
• Numărul vulnerabilităților critice restante
• Numărul excepțiilor acceptate, pe vechime
• Excepții care depășesc 90 de zile
• Numărul expunerilor critice la internet
• Încălcări ale SLA-urilor furnizorilor
• Vulnerabilități redeschise după validare
• Schimbări de urgență cauzate de vulnerabilități exploatate
• Eșecuri de patch pe platformă sau unitate de business

Conectați aceste metrici la ISO/IEC 27001:2022 Clause 9.3 analiza efectuată de management, raportarea de guvernanță DORA și supravegherea managementului NIS2. Pentru NIST CSF 2.0, utilizați-le pentru a actualiza profilurile curente și țintă, analiza lacunelor și planurile de acțiune.

Lista de verificare Clarysec pentru SLA-urile de remediere

Utilizați această listă de verificare pentru a evalua programul curent:

• Există o politică aprobată de management al vulnerabilităților și al patch-urilor?
• SLA-urile de remediere sunt definite în funcție de severitate și criticitatea activității?
• Vulnerabilitățile expuse la internet și exploatate sunt accelerate?
• Activele sunt mapate la proprietari, servicii, date și furnizori?
• Constatările scanerelor sunt transformate în tichete atribuite?
• Patch-urile sunt executate prin managementul schimbărilor?
• Schimbările de urgență sunt documentate și revizuite?
• Rezultatele remedierii sunt validate prin rescanări sau verificări de versiune?
• Excepțiile sunt evaluate din perspectiva riscului, aprobate și revizuite cel puțin o dată la 90 de zile?
• Controalele compensatorii sunt documentate pentru sistemele care nu pot fi patch-uite?
• Contractele cu furnizorii sunt aliniate la pragurile interne de remediere?
• Jurnalele de patch-uri sunt suficient de complete pentru a demonstra ce s-a întâmplat și când?
• Încălcările SLA sunt escaladate și corectate?
• Metricile sunt revizuite de management?
• Incidentele și evaluările privind încălcările sunt declanșate atunci când se suspectează exploatarea?

Dacă mai multe răspunsuri sunt „nu”, problema nu este instrumentarul. Este proiectarea controalelor.

Pașii următori: transformați termenele de patching în reziliență pregătită pentru audit

În 2026, SLA-urile de remediere a vulnerabilităților trebuie să facă mai mult decât să satisfacă un tablou de bord al scanerului. Ele trebuie să demonstreze că organizația poate identifica expunerea, prioritiza riscul, acționa în termene aprobate, controla excepțiile, guverna furnizorii și documenta deciziile prin dovezi în raport cu așteptările de audit ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 și COBIT 2019.

Clarysec vă poate ajuta să treceți de la tichete fragmentate de patching la un program integrat de remediere a vulnerabilităților, bazat pe dovezi, utilizând:

• Politica de management al vulnerabilităților și al patch-urilor
• Politica de management al vulnerabilităților și al patch-urilor pentru IMM-uri
• Politica de securitate privind terții și furnizorii pentru IMM-uri
• Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori
• Zenith Controls: ghidul de conformitate transversală

Începeți cu un serviciu cu risc ridicat. Mapați-i activele, furnizorii, vulnerabilitățile, tichetele, schimbările, excepțiile și dovezile. Apoi aplicați întrebările de audit asupra acestuia. Dacă nu puteți demonstra SLA-ul de la detecție până la închidere, acela este primul proiect de remediere.

Scopul nu este patchingul perfect. Scopul este remedierea guvernată, bazată pe risc, măsurabilă și verificabilă. Descărcați șabloanele de politici Clarysec, efectuați o evaluare țintită a lacunelor sau programați o demonstrație Clarysec pentru a transforma remedierea vulnerabilităților din presiune de audit în reziliență operațională.