Побудова КСЗІ: наказ, технічне завдання і роль розробника

Побудова КСЗІ — це не тільки техніка. Це ще й правильно розподілені ролі та папери, без яких найкраще інженерне рішення не пройде оцінювання. Розберемо, з чого все починається, хто за що відповідає й чому вибір виконавця — критичне рішення. Побудова КСЗІ провалюється не через слабку апаратуру, а через розмиті ролі: коли незрозуміло, хто ухвалює рішення, проєкт стоїть. Повний перелік кроків — у статті як створюється КСЗІ.

Наказ про створення КСЗІ: формальна відправна точка

Формальний старт — наказ керівника установи. Він фіксує рішення й запускає процес. Доти будь-які роботи юридичної ваги позбавлені: витрачені гроші лишаються витраченими, а документи — чернетками.

Що зазвичай визначає такий документ:

• рішення виконувати роботи та підставу для них (вимога законодавства, а не бажання);
• склад і повноваження тих, хто вестиме проєкт;
• строки етапів;
• відповідальних осіб поіменно;
• порядок взаємодії з підрядником.

Типова помилка — видати наказ заднім числом, коли роботи вже йдуть. Оцінювач звіряє дати, і розбіжність між датою наказу та датою акта обстеження помічається одразу.

Служба захисту інформації: хто веде проєкт

Для організації робіт створюють службу захисту інформації (СЗІ). Це може бути підрозділ або призначені відповідальні особи — залежно від масштабу. Типове положення такої служби описано окремим нормативним документом.

Завдання СЗІ:

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

Важливо: СЗІ лишається й після отримання підсумкового документа. Вона супроводжує систему далі — і саме тому її склад варто продумати всерйоз, а не «призначити когось».

Конфлікт ролей. Поширена ситуація: єдиний системний адміністратор одночасно і налаштовує захист, і контролює його. Формально це можливо, практично — самоперевірка рідко буває суворою. Що більша установа, то важливіше розвести того, хто робить, і того, хто перевіряє.

Технічне завдання на створення КСЗІ: приклад, шаблон і чому копіювати не можна

ТЗ — центральний документ проєкту. Саме з ним потім звірятимуть результат, і саме тому до нього ставляться з особливою ретельністю.

Що ТЗ зазвичай містить:

• підстави для робіт й опис самої системи;
• вимоги до захищеності — на основі моделі загроз і класу системи;
• функціональні послуги безпеки, які система має реалізувати;
• вимоги до складу засобів захисту;
• вимоги до документації;
• порядок і етапи виконання робіт;
• порядок випробувань та оцінювання захищеності.

Ключова особливість: ТЗ погоджується з органами Держспецзв'язку. Помилки чи неповнота тут означають переробку — тому саме ТЗ найчастіше стає вузьким місцем проєкту.

Щодо «прикладу ТЗ». Шаблони з мережі допомагають зрозуміти структуру, але для копіювання не годяться. ТЗ пишеться під конкретну систему: її клас, її модель загроз, її склад засобів. Скопійований документ майже гарантовано отримає зауваження — а іноді й гірше: він описуватиме захист від чужих загроз і промовчить щодо ваших.

Скільки коштує невдалий документ. Здається, що переробка ТЗ — це просто «переписати кілька сторінок». Насправді це нове погодження, нова черга й зсув усіх подальших етапів. Проєктні рішення, зроблені під першу редакцію, доводиться переглядати, а закуплене обладнання іноді виявляється зайвим. Тиждень, заощаджений на якості документа, легко обертається кварталом затримки.

Самоперевірка перед подачею — п'ять питань:

• Чи випливає кожна вимога документа з моделі загроз, а не з каталогу постачальника?
• Чи можна кожну вимогу перевірити? Формулювання на кшталт «забезпечити належний рівень» перевірити неможливо.
• Чи описано межу системи однозначно — які вузли всередині, які поза нею?
• Чи є порядок випробувань, чи лише перелік бажаного?
• Чи впізнає вашу систему той, хто її ніколи не бачив, прочитавши цей документ?

Розробник і ліцензія: без цього результат не визнають

Комплексний захист рідко будують власними силами: потрібні спеціальні компетенції та право виконувати роботи.

Ключове правило: надання послуг у галузі технічного захисту інформації є ліцензованим видом господарської діяльності. Звідси наслідки:

• виконавець повинен мати відповідну ліцензію;
• якщо проєкт потребує різних видів ліцензованих послуг, а виконавець має право не на всі, — залучають співвиконавців;
• перевірити наявність ліцензії можна за переліком ліцензіатів, який веде Держспецзв'язку і публікує у відкритих даних.

Докладніше щодо ліцензування галузі — у матеріалі що таке ТЗІ.

Практичний висновок: перш ніж обирати підрядника, переконайтеся, що він має право виконувати саме ті роботи, які вам потрібні. Це радше умова визнання результату, ніж бюрократична формальність: без потрібної ліцензії роботи не зарахують, і платити доведеться двічі.

Хто є хто в проєкті

Таблиця виглядає простою, але кожен рядок ховає підводний камінь. Керівник має виділити не лише гроші, а й час людей. Служба має мати повноваження, а не лише обов'язки. Персонал має пройти навчання, а не розписатися у відомості.

Найчастіший провал розподілу ролей — коли замовник фактично самоусувається: «ми найняли підрядника, хай робить». Підрядник не знає ваших процесів, позбавлений доступу до всіх людей і не може ухвалювати рішення за вас. Проєкт без активної СЗІ з боку замовника розтягується вдвічі.

Коли виконавця обрано, а довіри немає

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

• Поетапна оплата. Гроші йдуть за прийнятими документами, а не за календарем. Немає акта обстеження — немає траншу.
• Проміжні прийомки. Замовник читає й погоджує кожен ключовий документ, а не лише підсумковий пакет.
• Право залучити третю сторону. Пункт договору, який дозволяє вам показати документи незалежному фахівцю, дисциплінує краще за будь-які штрафи.
• Фіксація доопрацювань. Хто платить, якщо оцінювач дав зауваження, — має бути написано до початку робіт, а не з'ясовуватися після.

Жоден із цих важелів не є виявом недовіри. Вони просто роблять відповідальність вимірюваною.

Що змінилося у 2025–2026 роках

Головне, чого немає у більшості матеріалів мережі: ролі перерозподілилися.

Постанова Кабінету Міністрів № 712 від 18.06.2025 запровадила профілі безпеки та авторизацію з безпеки; перехідний період від класичної моделі завершився 18 червня 2026 року. Що це змінює для учасників:

• Замовник розробляє й затверджує цільовий профіль безпеки — власними силами або із залученням виконавця. Це вже не «підрядник напише, ми підпишемо».
• Оцінювач перевіряє, як реалізовано кожен пункт профілю, і результат оформлюють авторизаційним листом.
• Держспецзв'язку затверджує базові профілі та веде перелік авторизованих систем.

А що з технічним завданням? Воно лишається інженерним документом: підряднику треба знати, що будувати. Але роль головного мірила поступово переходить до цільового профілю: тепер доводять не відповідність власному ТЗ, а реалізацію затвердженого набору вимог.

Практичний маркер для перевірки підрядника: спитайте, чим завершиться проєкт. Відповідь «атестатом» для нової системи означає, що виконавець живе у вчорашньому дні.

П'ять питань, які варто поставити виконавцю

• Чи є у вас чинна ліцензія саме на ті види послуг, які нам потрібні?
• Які роботи виконуватимуть співвиконавці й хто вони?
• Хто у вас пише ТЗ і скільки таких документів ви погоджували торік?
• Ви ведете нас до авторизаційного листа чи до атестата? Чому саме туди?
• Що ми отримаємо, якщо оцінювач дасть зауваження, — доопрацювання коштом виконавця чи новий договір?

Останнє питання найкорисніше: воно одразу показує, чи готовий підрядник відповідати за результат.

І ще одна порада: усі відповіді просіть письмово. Усна обіцянка «звісно, у нас усе є» коштує рівно стільки, скільки коштує усна обіцянка. Лист із реквізитами ліцензії та переліком співвиконавців — це вже документ, яким можна оперувати, якщо щось піде інакше.

Чотири помилки, які повторюють роками

• Починати роботи до наказу. Формальної підстави немає, дати не збігаються, зауваження гарантовані.
• Копіювати ТЗ із сусідньої установи. Інший клас, інше середовище, інша модель загроз.
• Призначати СЗІ формально. Люди, яких забули повідомити щодо призначення, координувати нічого не будуть.
• Перевіряти ліцензію після підписання договору. Або взагалі не перевіряти, повіривши логотипу на сайті.

Скільки людей потрібно з боку замовника

Питання, яке ставлять рідко, а варто б. Мінімум — двоє: керівник, який ухвалює рішення й підписує, та людина, яка щодня веде проєкт і має доступ до всіх підрозділів.

Друга роль — найважча. Вона потребує часу, а не ентузіазму: обстеження вимагає інтерв'ю з людьми, збирання схем, звірки списків доступу. Якщо цю роль дали співробітникові «додатково до основних обов'язків», побудова КСЗІ розтягнеться рівно настільки, наскільки він зайнятий іншим.

Коротко про головне

Комплексний захист будують люди, а не пристрої. Спочатку рішення керівника, потім служба, потім документ, за яким усе перевірятимуть, і лише потім — обладнання. Кожен, хто пропонує зворотний порядок, економить свій час коштом вашого бюджету. Послідовність тут важить більше за кошторис: правильна економить місяці, хибна їх з'їдає. Базове пояснення самого поняття — у статті КСЗІ простими словами.