SLA за отстраняване на уязвимости за NIS2 и DORA

В 08:17 във вторник сутрин в началото на 2026 г. Анна, CISO на бързо растяща финтех компания, получава първото съобщение още преди да е изпила кафето си.

SOC е маркирал активни обсъждания за експлоатиране на уязвимост в клиентски API шлюз. Инженерният екип казва, че корекцията е налична, но е рискова, защото шлюзът стои пред работни процеси за плащания. Мениджърът по съответствието препраща формално искане от национален компетентен орган за доказателства за „обработване и оповестяване на уязвимости“ и доказателство, че процесът е бил ефективен през последните 12 месеца. Екипът по доставки добавя трети проблем: шлюзът се управлява от доставчик на управлявани услуги (MSP), а договорът казва само, че доставчикът ще прилага „актуализации за сигурност своевременно“.

Към 09:00 това вече не е само въпрос на прилагане на корекции. Това е въпрос на доказателства по ISO/IEC 27001:2022, въпрос на киберхигиена по NIS2, въпрос на управление на ИКТ риска по DORA, въпрос на управление на доставчици и потенциално въпрос на докладване на инциденти, ако експлоатирането засегне непрекъснатостта на услугите или лични данни.

Това е практическият пропуск в съответствието, пред който много организации ще се изправят през 2026 г. Те имат скенери, информационни табла, тикети и инструменти за прилагане на корекции, но не могат ясно да отговорят на одитните въпроси:

• Кой одобри SLA за отстраняване?
• Как SLA е базиран на риска?
• Какво се случва, когато критична корекция пропусне срока?
• Как се приоритизират достъпните от интернет активи?
• Как доставчиците се обвързват със същите срокове?
• Къде е записът за приемане на риска за некоригирана система?
• Кои доказателства показват, че контролът е работил, а не само че е съществувал?

Отговорът не е поредна електронна таблица с крайни срокове. SLA за отстраняване на уязвимости трябва да се управляват като жива система от контроли, която свързва собствеността върху активите, оценката на уязвимостите, разузнаването за заплахи, управлението на промените, SLA с доставчици, управлението на изключения, мониторинга, реагирането при инциденти и прегледа от ръководството.

Тук стават полезни корпоративната Политика за управление на уязвимости и корекции (VPMP) на Clarysec, Политика за управление на уязвимости и корекции за МСП (VPMP-SME), Политика за сигурност на трети страни и доставчици за МСП (TPSSP-SME), Zenith Blueprint (ZB) и Zenith Controls (ZC). Заедно те превръщат „прилагайте корекции по-бързо“ в защитим управленски процес, който може да издържи одитна проверка по ISO, NIS2, DORA, GDPR, NIST и ISACA.

Защо SLA за отстраняване на уязвимости станаха доказателство на ниво управителен орган

Отстраняването на уязвимости преди се разглеждаше като показател за ИТ хигиена. През 2026 г. то е по-близо до ангажимент за регулирана оперативна устойчивост.

NIS2 превръща киберсигурността във въпрос на управленска отчетност. Съществените и важните субекти трябва да имат управителни органи, които одобряват мерките за управление на риска за киберсигурността, упражняват надзор върху внедряването им и получават обучение, за да разбират рисковете и въздействието на практиките за сигурност върху услугите. NIS2 Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъснатост на дейността, сигурност на веригата на доставки, сигурно придобиване и поддръжка, обработване и оповестяване на уязвимости, киберхигиена, обучение, контрол на достъпа, управление на активите и автентикация.

За финансовите субекти DORA е специализираният режим за оперативна устойчивост. Той изисква механизми за управление и контрол на ИКТ риска, при които управителният орган определя, одобрява, надзирава и остава отговорен за управлението на ИКТ риска. DORA изисква също идентифициране на ИКТ активи и зависимости, контроли за защита и превенция, включително прилагане на корекции и управление на промените, управление на инциденти, свързани с ИКТ, тестване на цифровата оперативна устойчивост и управление на ИКТ риска от трети страни.

Практическото въздействие е съществено. Пропуснат срок за корекция може да показва отказ на:

• Управлението, ако ръководството не е одобрило риск-базирани SLA
• Управлението на активите, ако собственикът на засегнатата система е неизвестен
• Управлението на промените, ако аварийното прилагане на корекции не е контролирано
• Управлението на доставчици, ако сроковете на доставчика са неясни
• Реагирането при инциденти, ако признаците за експлоатиране не са преминали триаж
• Управлението на доказателства, ако тикетите и журналите не могат да докажат приключване
• Третирането на риска, ако изключенията не са одобрени и прегледани

ISO/IEC 27001:2022 предоставя гръбнака на системата за управление. Клаузи 4.1 до 4.3 изискват организациите да разбират вътрешния и външния контекст, изискванията на заинтересованите страни, правните и договорните задължения и интерфейсите с други организации. Клаузи 6.1.1 до 6.1.3 изискват оценка на риска, третиране на риска, Декларация за приложимост и одобрение на остатъчния риск от собственика на риска. Клаузи 9.1, 9.2, 9.3, 10.1 и 10.2 изискват мониторинг, вътрешен одит, преглед от ръководството, непрекъснато подобрение, коригиращи действия и съхранявани доказателства.

Казано ясно, ако искате SLA за отстраняване на уязвимости да са готови за одит, те трябва да са част от СУИС, а не само DevOps показател.

Моделът на SLA, който одиторите очакват да видят

SLA за отстраняване на уязвимости трябва да отговаря на три въпроса:

1. Колко бързо трябва да действаме?
2. Кой носи отчетност?
3. Какви доказателства доказват резултата?

Политика за управление на уязвимости и корекции дефинира практическа отправна точка за риск-базирани срокове за отстраняване:

Организацията трябва да класифицира всички открити уязвимости чрез стандартизирана методология (напр. CVSS v3.x) и да прилага срокове за отстраняване, съобразени с критичността за бизнеса: 5.2.1 Critical (CVSS 9.0-10.0): незабавен преглед; срок за прилагане на корекция до максимум 72 часа. 5.2.2 High (7.0-8.9): реакция в рамките на 48 часа; срок за прилагане на корекция до 7 календарни дни. 5.2.3 Medium (4.0-6.9): реакция в рамките на 5 дни; срок за прилагане на корекция до 30 календарни дни. 5.2.4 Low (<4.0): реакция в рамките на 10 дни; срок за прилагане на корекция до 60 календарни дни.

Тази клауза е силна, защото разделя времето за реакция от срока за прилагане на корекция. Уязвимост с висока сериозност не трябва да остава незабелязана шест дни и после да бъде коригирана на седмия. Часовникът за реакция потвърждава триажа, собствеността, оценката на въздействието и планирането на отстраняването. Срокът за прилагане на корекция потвърждава техническото приключване или одобрено изключение.

За по-малки организации Политика за управление на уязвимости и корекции за МСП използва по-опростен, но все още одитируем език:

Критичните корекции трябва да се прилагат в рамките на 3 дни от публикуването им, особено за достъпни от интернет системи

А за по-широкия обхват на корекциите:

Всички останали корекции трябва да се прилагат в рамките на 30 дни, освен ако е документирано валидно изключение

Смисълът не е всяка организация да използва идентични срокове. ISO/IEC 27001:2022, NIS2 и DORA подкрепят пропорционалността. Смисълът е SLA за отстраняване да бъдат дефинирани, одобрени, базирани на риска, наблюдавани и доказвани.

Тук много компании се провалят. Те дефинират SLA, но не дефинират доказателствата. От гледна точка на одитора политика без оперативни записи е обещание, а не контрол.

Собствеността върху активите е скритата зависимост

Скенер може да ви каже, че CVE съществува на сървър. Той не може да ви каже дали сървърът поддържа критичен платежен процес, съхранява специални категории лични данни, свързва се с доставчик за сетълмент или е планиран за извеждане от експлоатация.

Този контекст идва от управление на активите, класификация на данните, инвентар на доставчиците и оценка на риска.

ISO/IEC 27001:2022 Annex A контрол 8.8, Management of technical vulnerabilities, е централен, но не работи самостоятелно. Той зависи силно от управление на конфигурацията, управление на промените, мониторинг на доставчици, управление на облачни услуги, регистриране, мониторинг и третиране на риска.

NIST CSF 2.0 изразява същия проблем чрез езика на резултатите. Функцията GOVERN очаква правните, регулаторните и договорните изисквания за киберсигурност да бъдат разбрани и управлявани, апетитът към риск и толерансът към риск да бъдат документирани, ролите и ресурсите да бъдат назначени, а политиките за киберсигурност да бъдат установени, прилагани, преглеждани и актуализирани. Резултатите по IDENTIFY включват инвентари на хардуер, софтуер, услуги, системи, данни и жизнен цикъл, заедно с идентифициране на уязвимости, анализ на риска, управление на изключенията и процеси за оповестяване на уязвимости.

В сценария с Анна във вторник сутрин първият технически въпрос е „къде е уязвимият компонент?“ Първият управленски въпрос е „коя услуга и кой риск засяга?“

Zenith Blueprint, фаза Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability, адресира това чрез свързване на рисковете с контроли, собственици и срокове:

Също така задайте Собственик и Срок за всяко действие (може в отделна колона или в коментарите). Напр. „Собственик: ИТ мениджър, срок: до Q3 2025.“ Това го превръща в истински план.

Точно това изисква отстраняването на уязвимости. Констатация без собственик се превръща в шум в backlog. Констатация със собственик, срок, решение за третиране на риска и одитна следа от доказателства се превръща в одитируем контрол.

Как Zenith Controls картографира връзките между контролите

Zenith Controls разглежда ISO/IEC 27002:2022 контрол 8.8, Management of technical vulnerabilities, като превантивен контрол, поддържащ поверителност, цялостност и наличност. Той го свързва с концепциите за киберсигурност Identify и Protect, оперативната способност за управление на заплахи и уязвимости и областите на контролите за сигурност: управление, екосистема, защита и отбрана.

Това е важно, защото SLA за отстраняване не са само защитен механизъм. Те са и управленски механизъм, и механизъм за екосистемата. Вашата експозиция се формира от доставчици, облачни платформи, управлявани услуги, open-source компоненти и достъпни от интернет зависимости.

Zenith Controls картографира 8.8 към няколко поддържащи контроли:

Zenith Controls също свързва управлението на уязвимости с ISO/IEC 27005:2024, особено идентифицирането на уязвимости и рискови сценарии, включващи некоригирани системи. Това засилва аргумента, че сроковете за прилагане на корекции трябва да са базирани на риска, а не произволни. То също свързва мониторинга на доставчици с ISO/IEC 27036-4:2016 за нива на сигурност в споразуменията за облачни услуги и ISO/IEC 20000-1:2018 за планиране на предоставянето на услуги и управление на промените.

Тази междусекторна структура е важна по време на одит. Ако организацията каже „критичните уязвимости се коригират в рамките на 72 часа“, одиторът ще провери дали това твърдение е подкрепено от оценка на риска, класификация на активите, задължения на доставчици, записи за промени и доказателства от мониторинг.

Киберхигиена по NIS2: от обработване на уязвимости към коригиращо действие

NIS2 Article 21 изисква подход към мрежовите и информационните системи, обхващащ всички опасности. За SLA за отстраняване на уязвимости няколко елемента от Article 21 са пряко релевантни:

• Анализ на риска и политики за сигурност на информационните системи
• Обработване на инциденти
• Непрекъснатост на дейността и кризисно управление
• Сигурност на веригата на доставки
• Сигурно придобиване, разработване и поддръжка, включително обработване и оповестяване на уязвимости
• Процедури за оценка на ефективността на киберсигурността
• Базова киберхигиена и обучение
• Контрол на достъпа и управление на активите
• Многофакторно удостоверяване или непрекъсната автентикация, когато е подходящо

NIS2 Article 20 възлага отчетност на управителните органи за одобряване и надзор върху мерките за управление на риска за киберсигурността. Това означава, че показателите за отстраняване на уязвимости не могат да живеят само в инженерно информационно табло. Те трябва да присъстват в управленските отчети, материалите за комитет по риска или записите от преглед от ръководството на СУИС.

Article 21 също очаква субектите, които установят несъответствие с изискваните мерки, да предприемат коригиращо действие без неоправдано забавяне. Тази фраза е важна. Ако вашето табло показва просрочени критични уязвимости, доказателствата за съответствие не трябва да спират до „знаем“. Те трябва да показват ескалация, преглед на риска, видимост за ръководството, коригиращо действие и повторна оценка.

NIS2 Article 23 добавя още едно измерение. Ако експлоатирането на некоригирана уязвимост причини или може да причини сериозно оперативно прекъсване, финансови загуби или вреди за други лица, то може да стане значим инцидент. Жизненият цикъл на докладването включва ранно предупреждение в рамките на 24 часа от узнаването за значимия инцидент, уведомление за инцидент в рамките на 72 часа, междинни доклади при поискване и окончателен доклад в рамките на един месец след уведомлението за инцидент. Окончателният доклад трябва да включва степен на сериозност, въздействие, вероятна първопричина, мерки за смекчаване и трансгранично въздействие, когато е приложимо.

Затова процесът по SLA трябва да се свърже с реагирането при инциденти. Критична уязвимост с доказателства за активно експлоатиране трябва да задейства триаж по сигурността, мониторинг, запазване на доказателства и оценка за докладване, а не само рутинен тикет за корекция.

ИКТ риск по DORA: сроковете за отстраняване като доказателства за устойчивост

За финансовите субекти DORA се прилага от 17 януари 2025 г. и създава единни изисквания в областта на управлението на ИКТ риска, докладването на сериозни инциденти, свързани с ИКТ, тестването на цифровата оперативна устойчивост, споделянето на информация и управлението на ИКТ риска от трети страни. Той се третира като секторно специфичният правен акт на ЕС за обхванатите финансови субекти, идентифицирани по националните правила за NIS2.

Оперативният модел на DORA е близък до интегрирана СУИС. Articles 5 и 6 изискват управление, политики, процедури, инструменти, годишен или периодичен преглед, одит, отстраняване на критични одитни констатации и стратегия за цифрова оперативна устойчивост. Article 8 изисква идентифициране и инвентаризиране на бизнес функции, поддържани от ИКТ, информационни активи, ИКТ активи, зависимости, процеси на трети страни и рискове от наследени ИКТ. Article 9 изисква контроли за защита и превенция, включително прилагане на корекции и управление на промените. Articles 11 и 12 изискват непрекъснатост, реакция, възстановяване, резервни копия и цели за възстановяване.

DORA Articles 17 до 19 изискват процес за управление на инциденти, свързани с ИКТ, който открива, управлява, записва, класифицира, ескалира, докладва, комуникира, анализира първопричина и възстановява сигурни операции. Articles 24 до 26 изискват тестване на цифровата оперативна устойчивост, включително подходящо тестване на ИКТ инструменти и системи, анализ на уязвимости, оценки на мрежовата сигурност, анализи на пропуски, прегледи на изходния код, когато е възможно, тестове за проникване и тестове за проникване, водени от заплахи, за определени финансови субекти. Articles 28 и 30 изискват управление на ИКТ риска от трети страни, регистри на договорите за ИКТ услуги, надлежна проверка, права на одит и инспекция, нива на услугите, съдействие от доставчика по време на инциденти, права за прекратяване и договорености за изход.

За SLA за отстраняване DORA променя очакванията за доказателства по три начина.

Първо, констатациите за уязвимости от тестване трябва да се подават към приоритизиран процес за отстраняване. Доклад от сканиране не е достатъчен.

Второ, отстраняването на критични констатации трябва да се проследява чрез управление и одит. DORA очаква формално отстраняване на критични одитни констатации за субекти, които не са микропредприятия.

Трето, външните доставчици на ИКТ трябва да бъдат обвързани с измерими задължения. Ако вашият доставчик на облачни услуги, SaaS или MSP контролира прозореца за прилагане на корекции, договорът и регистърът трябва да показват как неговите срокове за отстраняване подкрепят вашите задължения за устойчивост.

Политика за управление на уязвимости и корекции адресира това директно:

Прилагане на корекции от трети страни и надзор върху риска при SaaS 6.6.1 Всички системи на трети страни (SaaS, PaaS, управлявани от MSP) трябва да демонстрират адекватни контроли за управление на уязвимости и корекции. 6.6.2 SLA на доставчиците трябва да включват срокове за отстраняване, еквивалентни на вътрешно дефинираните прагове, базирани на критичността.

Тази клауза често е липсващият мост между вътрешните доказателства по ISO и надзора върху доставчиците по DORA.

GDPR: когато забавянето на корекции става отказ на отчетността за лични данни

GDPR не е стандарт за управление на уязвимости, но променя последиците от отказ при прилагане на корекции.

GDPR Article 5 изисква личните данни да се обработват сигурно и изисква администраторът да може да демонстрира съответствие. Article 32 изисква подходящи технически и организационни мерки за гарантиране на ниво на сигурност, съответстващо на риска. Когато некоригирани системи обработват лични данни, особено данни за самоличност, финансови данни, биометрични данни, здравни данни, данни за заетост или KYC информация, SLA за отстраняване стават част от отчетността за сигурността на обработването.

Забавена корекция може да бъде защитима, ако рискът е оценен, приложени са компенсиращи контроли и остатъчният риск е приет от правилното лице. Много по-трудно е да се защити, ако уязвимостта е била просрочена, достъпна от интернет и без собственик.

Zenith Controls картографира управлението на уязвимости към GDPR Articles 32 и 5(1)(f), защото своевременното прилагане на корекции намалява рисковете за поверителността и целостта на личните данни. То също картографира управлението на промените към GDPR Article 24 и Article 32, защото промените в системи, обработващи лични данни, трябва да бъдат оценени спрямо риска, одобрени, документирани и прегледани.

Урокът за съответствие е ясен: ако са засегнати лични данни, доказателствата за корекция трябва да включват контекста на данните. Одиторите и регулаторите ще питат не само „коригирано ли е?“, а „кои данни са били изложени на риск, за колко време и кои контроли са намалили този риск?“

Практически работен процес на Clarysec за готови за одит доказателства по SLA

Зрял процес за отстраняване на уязвимости не започва, когато одиторът поиска записи. Той е проектиран така, че да създава записи всеки месец.

Стъпка 1: Одобрете политиката за SLA

Започнете с Политика за управление на уязвимости и корекции или Политика за управление на уязвимости и корекции за МСП, в зависимост от вашия оперативен модел. Адаптирайте праговете на SLA към вашия апетит към риск, регулаторен обхват, критичност на услугите, чувствителност на данните и технически ограничения. Осигурете одобрение от CISO, комитет по риска или управителен орган.

За корпоративни среди използвайте CVSS, критичност на активите, експлоатируемост, експониране към интернет, чувствителност на данните и въздействие върху бизнеса. За МСП запазете модела прост, но изричен: критични корекции в рамките на три дни, други корекции в рамките на 30 дни, освен ако не съществува валидно изключение.

Стъпка 2: Картографирайте активите към собственици и критични услуги

Всяка констатация за уязвимост трябва да се свързва с:

• Име на актива и уникален идентификатор
• Бизнес услуга или приложение
• Собственик на система
• Технически собственик
• Класификация на данните
• Експониране към интернет
• Зависимост от доставчик, ако е приложимо
• Критичност на поддържаната функция

Това подкрепя собствеността върху риска по ISO/IEC 27001:2022, управлението на активите по NIS2, инвентара на ИКТ активи и зависимости по DORA и резултатите IDENTIFY по NIST CSF.

Стъпка 3: Извършете триаж на уязвимостта

Създайте тикет за всяка констатация или групиран набор от констатации. Включете CVSS оценка, източник скенер, засегнат актив, статус на експлойт, разузнаване за заплахи, бизнес критичност и изискван SLA. Ако има подозрение за експлоатиране, свържете тикета с оценка на инцидент.

Стъпка 4: Изпълнете чрез управление на промените

Прилагането на корекции е промяна. Използвайте стандартна промяна за рутинни актуализации и аварийна промяна за критични експлоатирани уязвимости. Включете доказателства от тестване, одобрение, времеви маркер на внедряване, план за връщане към предишно състояние и валидиране след промяната.

Това съответства на връзката в Zenith Controls между 8.8 и 8.32, където прилагането на корекции се управлява чрез управление на промените, за да се балансират спешността и оперативната стабилност.

Стъпка 5: Валидирайте приключването

Не затваряйте тикети само въз основа на „корекцията е инсталирана“. Изисквайте валидиране чрез повторно сканиране, потвърждение на версията, проверка на конфигурацията или потвърждение на компенсиращ контрол. Когато корекцията не може да бъде приложена, открийте изключение.

Стъпка 6: Записвайте изключенията и остатъчния риск

Политика за управление на уязвимости и корекции дефинира изискваното съдържание на изключението:

Исканията за изключение трябва да включват: 7.2.1 Бизнес обосновка за забавянето или неотстраняването 7.2.2 Оценка на риска (въз основа на CVSS, критичност на актива, разузнаване за заплахи) 7.2.3 Предложени компенсиращи контроли 7.2.4 Срок за отстраняване или повторна оценка

Тя също дефинира одобрение и преглед:

Изключенията трябва да бъдат одобрени от CISO или делегиран Комитет по риска и записани в Регистъра на изключенията в СУИС, с интервал за преглед, който не надвишава 90 дни.

Този регистър на изключенията става съществено доказателство за ISO/IEC 27001:2022 Clause 6.1.3 третиране на риска и приемане на остатъчния риск, както и за преглед от ръководството.

Този запис демонстрира, че организацията не е игнорирала уязвимостта. Тя е оценила риска, приложила е компенсиращи контроли, одобрила е остатъчния риск и е определила дата за преглед.

Стъпка 7: Изградете месечния пакет с доказателства

Вашият месечен пакет с доказателства за отстраняване на уязвимости трябва да включва:

За МСП доказателствата могат да бъдат по-леки, но трябва да останат последователни. Политика за управление на уязвимости и корекции за МСП изисква журнали на корекциите с проследимост:

Журналите трябва да включват името на устройството, приложената актуализация, датата на прилагане на корекцията и причината за всяко забавяне

Тази единична клауза е изключително ценна за одит. Тя превръща прилагането на корекции от твърдение в запис.

Прилагане на корекции от доставчици: договорът трябва да съответства на вашия SLA

Ако MSP, доставчик на SaaS, доставчик на PaaS или доставчик на облачни услуги контролира внедряването на корекции, вътрешните SLA са безполезни, освен ако задълженията на доставчика не им съответстват.

Политика за сигурност на трети страни и доставчици за МСП включва задължения за информационна сигурност като управленско изискване. За отстраняване на уязвимости тези задължения трябва да се превърнат в измерим договорен език:

• Прозорци за уведомяване при критична уязвимост
• Срокове за отстраняване за критични, високи, средни и ниски уязвимости
• Процес за аварийни промени
• Изисквания за одобрение от клиента при прекъсване
• Формат на доказателствата за завършено прилагане на корекция
• Процес за оповестяване на уязвимости
• Задължения за съдействие при инциденти
• Право на одит или получаване на доклади за уверение
• Задължения за прилагане на корекции от подизпълнители и подпроцесори
• Подкрепа при изход и преход за критични услуги

Zenith Blueprint, фаза Controls in Action, Step 20, Control 8.21 Security of network services, формулира принципа ясно:

Когато услугите се предоставят външно, включително от ISP, доставчици на SD-WAN или частни облачни доставчици, изискванията за сигурност трябва да бъдат заложени в договорите и SLA. Това включва гаранции за наличност, времена за реакция при инциденти, задължения за прилагане на корекции или смекчаване на уязвимости и ясни граници за обработване на данни. Никога не трябва да приемате, че доставчикът изпълнява вашите очаквания, освен ако това не е записано, измеримо и одитируемо.

DORA прави това особено важно за финансовите субекти. Договореностите с ИКТ трети страни трябва да включват нива на услугите, съдействие от доставчика по време на ИКТ инциденти, достъп и възстановяване на данни, сътрудничество с органите, права за прекратяване и по-силни разпоредби за критични или важни функции, включително мониторинг, права на одит, планове при извънредни ситуации и мерки за сигурност.

NIST CSF 2.0 казва същото чрез резултатите за риска във веригата на доставки: доставчиците трябва да са известни, приоритизирани по критичност, оценени преди ангажиране, управлявани чрез договорни изисквания, наблюдавани през целия период на взаимоотношението, включени в планирането при инциденти и управлявани при прекратяване.

Какво реално ще попитат одиторите

Одитният разговор се променя според профила на одитора.

Одитор по ISO/IEC 27001:2022 ще започне от СУИС. Той ще провери дали управлението на уязвимости е включено в Декларацията за приложимост, дали оценката на риска идентифицира некоригирани системи като риск, дали плановете за третиране на риска имат собственици и срокове, дали Annex A контрол 8.8 е внедрен, дали доказателствата се съхраняват и дали вътрешният одит и прегледът от ръководството оценяват резултатността.

Zenith Blueprint, фаза Controls in Action, Step 19, прави одитното очакване изрично:

Това е контрол с висок приоритет за одиторите и те обикновено навлизат в дълбочина. Очаквайте да ви попитат колко често се прилагат корекции на системите, какъв процес следвате при обявяване на zero-day и кои системи са най-трудни за коригиране.

Продължава с практически очаквания за доказателства:

Одиторите вероятно ще поискат резултати от сканирания за уязвимости. Ако използвате инструменти като Nessus, OpenVAS или Qualys, експортирайте доклад, който показва последно откритите уязвимости и как са били обработени. В идеалния случай това трябва да включва оценки на риска (CVSS) и срокове за отстраняване.

Одитор или компетентен орган, фокусиран върху NIS2, ще търси одобрение от управителния орган, пропорционалност, киберхигиена, обработване на уязвимости, сигурност на доставчиците, обработване на инциденти, оценка на ефективността, коригиращо действие без неоправдано забавяне и записи за решение относно докладване, ако експлоатирането е причинило значително въздействие.

Надзорен орган по DORA ще тества дали констатациите за уязвимости са интегрирани в управлението на ИКТ риска, тестването на цифровата оперативна устойчивост, класификацията на инциденти, анализа на първопричините, регистрите на трети страни, договорните задължения, правата на одит и отстраняването на критични констатации.

Оценител по NIST CSF вероятно ще организира прегледа около GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND и RECOVER. Той ще попита дали правните и договорните изисквания са разбрани, дали толерансът към риск е документиран, дали уязвимостите са идентифицирани и приоритизирани, дали изключенията се управляват, дали мониторингът открива експлоатиране и дали действията за реакция и възстановяване са координирани.

Одитор по COBIT 2019 или в стил ISACA ще се фокусира върху управленски цели, способност на процеса, управленски практики, показатели, собственост, дизайн на контролите, функциониране на контролите и достатъчност на доказателствата. Той ще попита дали отстраняването на уязвимости е повторяемо, измервано, ескалирано, подобрявано и съгласувано с корпоративните цели и апетита към риск.

Ескалация и показатели: как да докажете, че SLA се управлява

SLA без ескалация е само цел. Защитима програма за отстраняване на уязвимости се нуждае от ескалация преди нарушение, при нарушение и след повтарящ се отказ.

Clarysec препоръчва четиристепенен модел за ескалация:

1. Оперативна ескалация, собственикът на тикета и техническият ръководител се уведомяват преди нарушение.
2. Ескалация на риска, собственикът на актива и собственикът на риска преглеждат въздействието, когато нарушение е вероятно.
3. Ескалация към управлението на сигурността, CISO или комитетът по риска одобрява изключение или аварийно действие.
4. Управленска ескалация, повтарящи се или критични нарушения на SLA се докладват в преглед от ръководството с коригиращи действия.

Политика за управление на уязвимости и корекции подсилва това одитно очакване:

Периодични одити трябва да се извършват от вътрешен одит или независима трета страна, за да се провери: 5.6.1 Съответствие със SLA 5.6.2 Доказателства за риск-базирано приоритизиране 5.6.3 Ефективност на внедрените корекции 5.6.4 Контроли върху некоригирани системи

Показателите трябва да подкрепят решенията, а не да украсяват таблата. Най-силните показатели за 2026 г. включват:

• Процент на съответствие със SLA за критични уязвимости
• Процент на съответствие със SLA за високи уязвимости
• Средно време до триаж
• Средно време до отстраняване по клас активи
• Брой просрочени критични уязвимости
• Брой приети изключения по възраст
• Изключения над 90 дни
• Брой критични експозиции, достъпни от интернет
• Нарушения на SLA от доставчици
• Уязвимости, отворени отново след валидиране
• Аварийни промени, причинени от експлоатирани уязвимости
• Откази при прилагане на корекции по платформа или бизнес единица

Свържете тези показатели с ISO/IEC 27001:2022 Clause 9.3 преглед от ръководството, управленско докладване по DORA и управленски надзор по NIS2. За NIST CSF 2.0 ги използвайте за актуализиране на Current и Target Profiles, анализ на пропуски и планове за действие.

Контролният списък на Clarysec за SLA за отстраняване

Използвайте този контролен списък, за да оцените текущата си програма:

• Има ли одобрена политика за управление на уязвимости и корекции?
• Дефинирани ли са SLA за отстраняване по степен на сериозност и критичност за бизнеса?
• Ускоряват ли се достъпните от интернет и експлоатираните уязвимости?
• Картографирани ли са активите към собственици, услуги, данни и доставчици?
• Преобразуват ли се констатациите от скенери във възложени тикети?
• Изпълняват ли се корекциите чрез управление на промените?
• Документират и преглеждат ли се аварийните промени?
• Валидират ли се резултатите от отстраняването чрез повторни сканирания или проверки на версии?
• Оценени ли са изключенията спрямо риска, одобрени ли са и преглеждат ли се поне на всеки 90 дни?
• Документирани ли са компенсиращи контроли за некоригируеми системи?
• Съгласувани ли са договорите с доставчици с вътрешните прагове за отстраняване?
• Достатъчно пълни ли са журналите на корекциите, за да докажат какво се е случило и кога?
• Ескалират и коригират ли се нарушенията на SLA?
• Преглеждат ли се показателите от ръководството?
• Задействат ли се оценки на инциденти и нарушения, когато има подозрение за експлоатиране?

Ако няколко отговора са „не“, проблемът не е в инструментите. Проблемът е в дизайна на контролите.

Следващи стъпки: превърнете сроковете за корекции в готова за одит устойчивост

SLA за отстраняване на уязвимости през 2026 г. трябва да правят повече от това да удовлетворяват табло на скенер. Те трябва да доказват, че организацията ви може да идентифицира експозиция, да приоритизира риск, да действа в одобрени срокове, да контролира изключения, да управлява доставчици и да доказва решения спрямо одитните очаквания по ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019.

Clarysec може да ви помогне да преминете от фрагментирани тикети за корекции към интегрирана, основана на доказателства програма за отстраняване на уязвимости чрез:

• Политика за управление на уязвимости и корекции
• Политика за управление на уязвимости и корекции за МСП
• Политика за сигурност на трети страни и доставчици за МСП
• Zenith Blueprint: 30-стъпкова пътна карта за одитори
• Zenith Controls: ръководство за междурегулаторно съответствие

Започнете с една високорискова услуга. Картографирайте нейните активи, доставчици, уязвимости, тикети, промени, изключения и доказателства. След това приложете одитните въпроси към нея. Ако не можете да докажете SLA от откриване до приключване, това е първият ви проект за отстраняване.

Целта не е перфектно прилагане на корекции. Целта е управлявано, базирано на риска, измеримо и одитируемо отстраняване. Изтеглете шаблоните за политики на Clarysec, извършете целева оценка на пропуските или резервирайте демонстрация на Clarysec, за да превърнете отстраняването на уязвимости от одитен натиск в оперативна устойчивост.