Управління кіберризиками людського фактору: чому одних тренінгів недостатньо

Більшість зломів досі починаються з людини, а не з файрвола. Саме цей факт породив цілу індустрію навчальних модулів, фішинг-симуляцій і дашбордів, що обіцяють це виправити, — і все ж показник рік у рік майже не змінюється. Управління кіберризиками людського фактору — це спроба поставитися до цього розриву як до управлінської задачі, а не тренінгової. Нижче — що це насправді означає, і місце, де оцінку ризику варто перевіряти доказами, а не приймати на віру.

Ключові висновки

• Кіберризик людського фактору не вирішується більшою кількістю тренінгів. Він потребує постійного вимірювання, крос-функціональної відповідальності і — принципово — перевірки того, що це вимірювання насправді показує.
• 62% зломів нині включають людський фактор, за даними Verizon Data Breach Investigations Report 2026; фішинг залишається найпоширенішим початковим вектором атак, за даними IBM Cost of a Data Breach Report 2025.
• "Оцінка людського ризику" — це поведінкова проксі-метрика, побудована на самозвітності й симуляціях. Це корисний сигнал і ненадійний вирок — це не одне й те саме.
• Регуляторні рамки (NIS2, DORA, оновлений ISO 27001) дедалі частіше трактують управління ризиком людського фактору як задокументовану, аудитовану програму, а не як щорічний тренінг для галочки.
• Ми перевіряємо те, що вже стверджує оцінка ризику, звіт про підозрілу поведінку чи заявлені дані кандидата, — через OSINT-дослідження та роботу з публічними реєстрами, а не через другий шар автоматизованого скорингу.

Що таке управління кіберризиками людського фактору насправді

Управління кіберризиками людського фактору — це дисципліна, що трактує людей — співробітників, підрядників, керівників — як окрему, вимірювану категорію ризику, відмінну від (але пов'язану з) ризиком технічної інфраструктури. Це відрізняється від традиційного навчання з обізнаності трьома конкретними речами: навчання з обізнаності — загальне і періодичне; управління кіберризиками людського фактору — персоналізоване, безперервне і прив'язане до вимірюваних результатів, а не до показника завершення курсу.

<table>  <thead>    <tr><th></th><th>Навчання з обізнаності</th><th>Фішинг-симуляції</th><th>Верифікована оцінка людського ризику</th></tr>  </thead>  <tbody>    <tr>      <td><strong>Головна мета</strong></td>      <td>Звітність і комплаєнс</td>      <td>Виміряти конкретну вразливість</td>      <td>Знизити ризик так, щоб це можна було незалежно підтвердити</td>    </tr>    <tr>      <td><strong>Підхід</strong></td>      <td>Загальний, разовий</td>      <td>Реактивний, ізольовані тести</td>      <td>Структурний, безперервний, перевірений доказами</td>    </tr>    <tr>      <td><strong>Ключова метрика</strong></td>      <td>Показник завершення курсу</td>      <td>Показник кліків на симуляцію</td>      <td>Підтверджена зміна поведінки, підкріплені дані про інциденти</td>    </tr>    <tr>      <td><strong>Що це насправді показує</strong></td>      <td>Хто пройшов модуль</td>      <td>Хто клікнув на симульоване посилання</td>      <td>Чи витримує перевірку саме твердження &mdash; про вразливість ролі, історію кандидата, задекларований інцидент</td>    </tr>  </tbody></table>

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

Реальна ціна помилки

Аргумент на користь того, щоб ставитися до людського ризику так само серйозно, як і до технічного, спирається на цифри, що рухаються не в той бік. Шістдесят два відсотки зломів нині включають людський фактор, за даними Verizon Data Breach Investigations Report 2026, — прийнятий дзвінок, клік на лист, відвідана сторінка, передані облікові дані. Фішинг залишається найпоширенішим способом проникнення: за даними IBM Cost of a Data Breach Report 2025, це 16% інцидентів, провідний початковий вектор, із середньою вартістю $4,8 млн і в середньому 254 днями на виявлення й локалізацію.

В Україні ця динаміка накладається на цілеспрямовану кампанію проти конкретних організацій, а не абстрактну галузеву тенденцію. За даними CERT-UA, лише за перше півріччя 2025 року в країні зафіксовано понад 3 000 кіберінцидентів, і команда команди відзначає зсув повʼязаних із рф атакуючих груп у бік соціальної інженерії та інструментів на основі ШІ — замість суто технічного зламу. Навесні 2026 року CERT-UA зафіксувала кампанію, що добре ілюструє цю логіку: зловмисники розсилали електронні листи з PDF-вкладеннями, замаскованими під сертифікати про проходження курсів на освітній платформі Prometheus, із посиланнями на завантаження ZIP-архівів зі шкідливим JavaScript-кодом, що встановлював інструменти на кшталт Cobalt Strike для віддаленого контролю над системою. Листи розсилали, зокрема, через уже скомпрометовані облікові записи українських установ — тобто сама довіра до знайомого відправника й знайомого сервісу і була вектором атаки. Жоден технічний периметр цього не зупинить: співробітник, що відкриває лист від "колеги" про курс, який він справді проходив, не порушує жодної технічної політики.

Прямі витрати — легша половина цієї суми для пояснення: реагування на інцидент, регуляторні штрафи, усунення наслідків і — дедалі частіше, під NIS2 і DORA, — обов'язкове повідомлення про злом у фіксований термін, до якого більшість організацій структурно не готові. Складніша половина — те, що взагалі не потрапляє у звіт про інцидент: клієнт, що тихо переносить свій рахунок в іншу компанію після зламу, який зачепив його дані; партнер, що додає ще один рівень перевірки перед продовженням контракту; внутрішня культура, де співробітники не повідомляють про майже-інциденти, бо останню людину, яка це зробила, звинуватили, а не підтримали.

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

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

Кіберризик людського фактору — це не лише проблема CISO

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

Ефективна відповідальність розподілена між чотирма групами, кожна з яких дає те, чого структурно не можуть дати інші:

• CEO та керівна команда. Спонсорство на цьому рівні визначає, чи отримає програма ресурси як справжній інструмент управління ризиком, чи стане пунктом для галочки, який дістають з шухляди після аудиту. Бюджет і пріоритет ідуть за тим, хто просуває програму всередині компанії, а програма без підтримки на цьому рівні зазвичай втрачає і те, і інше, щойно конкурує за бюджет із проєктом, що генерує дохід.
• CISO. Володіє фреймворком ризику, методологією вимірювання і — принципово — чесністю щодо того, що ці метрики насправді означають. Це також роль, яку найчастіше спокушає надто довіряти дашборду просто тому, що він уже під рукою.
• HR / керівник напряму людей. Контролює три з найризикованіших перехідних точок у житті співробітника в компанії: онбординг (який доступ надається і наскільки ретельно перевірено людину за заявкою), зміну ролі (чи коригується доступ під нові обов'язки, чи просто накопичується) і звільнення (чи відкликається доступ справді в останній день, чи через три тижні).
• Лінійні керівники. Бачать щоденну поведінку і майже-інциденти задовго до того, як їх зафіксує будь-який дашборд, — співробітник під стресом, що зрізає кути, підрядник, що просить доступ ширший за заявлений обсяг, патерн активності в неробочий час, що не відповідає ролі. Ніщо з цього не потрапляє у звіт про показник завершення курсу.

Те, що CISO дедалі частіше підпорядковується напряму CEO, а не ховається всередині IT-функції, саме й сигналізує, яка з цих чотирьох груп реально веде програму, а яка лише її толерує.

Програма, а не тренінг: чотири фази

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

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

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

Фаза 4 — розвиток. Людський ризик не статичний — нові ролі, нові техніки атак і організаційні зміни (злиття, нові відносини з постачальником, швидкий найм) щоразу зсувають, де саме зосереджений ризик. Ця фаза — безперервний цикл перегляду, а не щорічне оновлення: оцінку з Фази 1 варто переглядати щоразу, коли структура організації чи характер загроз змінюються суттєво, а не за фіксованим календарем незалежно від того, що насправді відбулося. Компанія, що щойно завершила поглинання іншої, наприклад, за одну ніч успадкувала чужі патерни доступу, відносини з постачальниками й історії співробітників — жодного з яких початкова оцінка на Фазі 1 не охоплювала.

Вимірювання прогресу без надмірної довіри до одного числа

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

Сам по собі це не висновок. Оцінка ризику значною мірою побудована на даних, які контролює або на які впливає сам суб'єкт оцінки, — як він реагує на відому симуляцію, що сам про себе повідомляє, наскільки швидко проходить обов'язковий модуль. Люди, що розуміють, що їх оцінюють, коригують поведінку саме навколо механізму оцінки — добре задокументоване викривлення будь-якої метрики, заснованої на самозвітності чи тестуванні. Низька оцінка може означати справді низький ризик, а може означати людину, що навчилась добре проходити саме ці конкретні тести.

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

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

Автоматизований скоринг vs. верифікована оцінка людського ризику

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

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

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

Де тут місце для перевірки: ми ставимось до оцінки ризику, анонімного повідомлення чи самозаявленої кваліфікації так само, як до будь-якого іншого неперевіреного твердження в розслідуванні, — як до гіпотези для перевірки, а не висновку для дії. Для ролей та інцидентів, що дійсно несуть наслідки, — позначена як високоризикова посада, співробітник, що звільняється й має привілейований доступ, інсайдерське повідомлення, здатне зламати кар'єру, якщо воно хибне, — наші аналітики перевіряють базове твердження за відкритими джерелами, публічними реєстрами і прямим підтвердженням із першоджерел — так само, як ми перевіряли б твердження про постачальника чи контрагента в рамках due diligence. Та сама дисципліна, що застосовується до перевірки постачальника перед його підключенням, застосовується і до перевірки сигналу людського ризику перед тим, як за ним діяти.

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

FAQ

Управління кіберризиками людського фактору — це те саме, що навчання з обізнаності?

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

Хто має володіти програмою управління кіберризиками людського фактору?

Відповідальність має бути розподіленою, а не зосередженою виключно в команді безпеки. CISO зазвичай володіє фреймворком і вимірюванням; HR контролює найризикованіші перехідні точки (найм, зміну ролі, звільнення); керівники бачать щоденну поведінку першими; а підтримка на рівні керівництва компанії визначає, чи ресурсується програма як управління ризиком, чи трактується як формальність для комплаєнсу.

Чим це відрізняється від програми фішинг-симуляцій?

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

NIS2 і DORA справді цього вимагають, чи це просто найкраща практика?

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

Чи можна "обхитрити" оцінку людського ризику?

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

Що саме додає перевірка, чого не додає скоринг?

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

‍