NIS2 със собствени ресурси или с външен консултант? Сравнение на разходите, срока и риска

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

Не избирайте изпълнител, преди да сте определили приложимите задължения

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

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

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

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

След описването на дейността трябва да се извърши правна оценка съгласно актуалните към датата на публикуване секторни критерии, критерии за вида на субекта и неговия размер. Официалното становище следва да бъде одобрено от органа или лицето, което има право да представлява организацията, с участието на правната функция и собствениците на услуги и процеси. ИТ предоставя данните за системите, но не следва самостоятелно да решава въпроса за приложимостта. Темата е разгледана по-подробно в материала „Директива NIS2 – за кого се отнася и кои предприятия трябва да изпълнят новите изисквания?“.

Разходите по внедряването не приключват с фактурата

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

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

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

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

Срокът зависи от готовността за вземане на решения

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

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

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

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

Картирането на процесите трябва да подпомага именно тези решения, а не да увеличава обема на документацията. Сравнението „BPMN или блок-схема – кой инструмент е по-подходящ за картиране на процесите по качество?“ улеснява избора на подходящо ниво на детайлност. За тази цел е подходящ инструментът, който еднозначно показва ролите, точките на предаване на отговорност, информационните зависимости и областите, изискващи защита или заместване.

Рискът произтича преди всичко от неправилни допускания

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

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

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

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

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

Одитът на готовността трябва да оценява способността за действие и представяне на надеждни доказателства, а не само пълнотата на документацията. Подходящи показатели са броят на неизпълнените действия от предходни одити и тестове, резултатите от тестовете за възстановяване, изводите от прегледите на инциденти и прекъсвания и делът на ключовите доставчици, обхванати от оценяване и съгласувани изисквания — винаги въз основа на данните на организацията. Подходът към такава проверка е развит в материала „Одит по NIS2 в производствено предприятие – как да се провери дали организацията е готова за новите задължения“.

Смесеният модел обикновено осигурява най-добър контрол

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

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

В организацията трябва да останат най-малко:

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

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

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

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

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

Основавайте решението на доказателства и способност за поддържане на системата

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

Решението на ръководството трябва да сравнява три варианта: изпълнение със собствени ресурси, смесен модел и по-широка външна подкрепа. За всеки от тях следва да се приложат едни и същи критерии:

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

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

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

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

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