Договор с ИТ доставчик след NIS2: клаузи за сигурност, SLA и докладване на инциденти

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

Договорът като механизъм за управление на риска

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

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

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

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

Позоваването на NIS2 или на приложимите изисквания на KSC трябва да бъде резултат от анализа на риска и отговорностите, а не заместител на оперативното съдържание на договора. По-широкият управленски контекст е представен в материала NIS2 за производствени предприятия: за кого се прилага, какви задължения въвежда и как организацията да се подготви, без темата да се свежда само до ИТ. Обхватът на договорните промени трябва всеки път да бъде съобразен с ролята на организацията, критичността на услугата и реалното разпределение на контрола между страните.

Обхват на услугата и разпределение на отговорностите

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

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

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

Доставчикът трябва да поддържа актуален списък на подизпълнителите, които влияят върху услугата, с описание на техните роли и местата на обработване, и да им налага изисквания, не по-слаби от договорените с клиента. Договорът трябва да разграничава промените, изискващи предварително съгласие, от тези, за които е достатъчно уведомяване и повторна оценка на риска. Сертификатът за система за управление може да подпомогне тази оценка, но не замества отговорността за конкретната услуга. Връзката е разгледана по-подробно в материала NIS2 и BDS EN ISO 27001: какво дава сертификатът и какво все още не достига за съответствие с KSC.

Проверими клаузи за сигурност

Клаузата за сигурност става измерима и проследима едва когато определя очаквания резултат, приложното поле, честотата на изпълнение, начина за потвърждаване и реда за управление на отклоненията. Формулировки като „съгласно добрите практики“ или „с дължимата грижа“ могат да допълват изискванията, но не позволяват да се оцени дали доставчикът е изпълнил задължението си. За всяка контрола трябва да бъдат посочени собственикът на изискването, срокът за съхранение на доказателствата и страната, която има право да одобри изключение.

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

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

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

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

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

SLA за устойчивост, а не само за достъпност

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

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

При система за управление на производствен процес критичният инцидент може да изисква незабавна ескалация и непрекъсната комуникация до задействането на аварийния режим. Същият технически проблем в учебна среда може да получи по-нисък приоритет. Затова класификацията трябва да се основава на въздействието върху дейността, а не само на техническото описание на грешката. Ако организацията разполага с надеждни исторически данни, при определянето на праговете трябва да отчете реалните времена за реакция и възстановяване, постигнатата достъпност и броя на повтарящите се аварии.

Механизмът за измерване трябва да посочва източника на данните, часовата зона, момента на стартиране и спиране на отчитането, договорените часове за предоставяне на услугата, прозорците за поддръжка и правилата за промяна на класа на инцидента. Изключенията от измерването трябва да бъдат включени в затворен и проверим списък. Те не могат да обхващат събития, попадащи в отговорността на доставчика. Съответствието между тези договорености и реалната оперативна готовност може да се оцени чрез Одит по NIS2 в производствено предприятие – как да се провери готовността на организацията за новите задължения.

Кредитите за услуга и символичните обезщетения не възстановяват процеса и не ограничават последствията от престоя. По-съществени са задължението за представяне на план за коригиращи действия, управленската ескалация, допълнителните изпитвания на устойчивостта и правото за прекратяване при трайно или повтарящо се неизпълнение на договорените нива. Финансовата санкция може да засили отговорността, но не замества механизма за възстановяване на услугата, отстраняване на причините и предотвратяване на повторни откази.

Инциденти и задължения за уведомяване

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

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

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

Клаузите трябва също да определят правилата за запазване и предоставяне на доказателства, защита на тяхната цялост, документиране на решенията и подготовка на данните за уведомяванията и последващия анализ на първопричината. Сроковете, адресатите и обхватът на външните уведомявания трябва всеки път да се проверяват според актуалната правна рамка, статута на организацията и вида на събитието. Регистрите на уведомяванията, решенията, ескалациите и действията следва да се свържат с разработката „Документация по NIS2 и KSC преди проверка: какви политики, регистри и доказателства действително са необходими“, а графикът за адаптиране — с материала Внедряване на NIS2 след вписване в регистъра по KSC – план за действие до 3 април 2027 г..

Внедряване, наблюдение и сигурен изход

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

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

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

Актуализирането на договорния портфейл трябва да започне от услугите с най-голямо въздействие върху дейността, а пропуските да бъдат приоритизирани според последствията и спешността. Ефективността на приетите механизми е добре да се провери чрез учение за реакция при инцидент и одит на извадка от доказателства. Резултатите от прегледите на SLA, инцидентите, отклоненията, коригиращите действия и тестовете на плана за изход ще покажат дали изискванията работят на практика, или остават само договорни формулировки.

Обхватът на оценката може да се свърже с материала „Одит по NIS2 в производствено предприятие – как да се провери готовността на организацията за новите задължения“. Задълженията на организацията трябва да се определят и спрямо нейния статут, разгледан в Директивата NIS2 – за кого се прилага и кои предприятия трябва да изпълняват новите изисквания?