Як створити рамкову систему управління ІКТ-ризиками відповідно до DORA з використанням ШІ
Ви дізнаєтесь, як створити комплексну рамкову систему управління ІКТ-ризиками, яка відповідає статтям 6-16 DORA з використанням ШІ. Цей посібник охоплює повну структуру рамкової системи, від управління та ідентифікації ризиків до захисту, виявлення, реагування, відновлення та безперервного вдосконалення, з конкретними запитами ISMS Copilot для генерації кожного компонента.
Огляд
Ви дізнаєтесь, як створити комплексну рамкову систему управління ІКТ-ризиками, яка відповідає статтям 6-16 DORA з використанням ШІ. Цей посібник охоплює повну структуру рамкової системи, від управління та ідентифікації ризиків до захисту, виявлення, реагування, відновлення та безперервного вдосконалення, з конкретними запитами ISMS Copilot для генерації кожного компонента.
Для кого цей посібник
Цей посібник призначений для:
- CISO та менеджерів з ІТ-ризиків, які створюють або вдосконалюють рамкові системи управління ІКТ-ризиками для відповідності DORA
- Співробітників з комплаєнсу, відповідальних за документування політик і процедур управління ІКТ-ризиками
- Консультантів, які розробляють рамкові системи, що відповідають DORA, для клієнтів-фінансових установ
- Членів комітетів з ризиків та членів органів управління, які здійснюють нагляд за управлінням ІКТ-ризиками
- Внутрішніх аудиторів, які оцінюють адекватність заходів з управління ІКТ-ризиками
Перш ніж розпочати
Вам знадобиться:
- Обліковий запис ISMS Copilot (доступна безкоштовна пробна версія)
- Завершення базових кроків у посібнику Як розпочати впровадження DORA з використанням ШІ, включаючи оцінку сфери застосування та аналіз прогалин
- Наявна документація з управління ІКТ-ризиками (політики, реєстри ризиків, інвентаризація активів) для порівняння прогалин
- Розуміння вашого ІКТ-ландшафту (додатки, інфраструктура, хмарні сервіси, топологія мережі)
- Доступ до ключових зацікавлених сторін: CISO, CRO, ІТ-операції, менеджера з безперервності бізнесу
Вимоги DORA до управління ІКТ-ризиками в статтях 6-16 становлять основу всього регулювання. Рамкова система, яку ви створите тут, лежить в основі звітності про інциденти, тестування стійкості та управління ризиками третіх сторін. Приділіть достатньо часу, щоб правильно вибудувати цей стовп.
Розуміння вимог DORA до управління ІКТ-ризиками
Розбір статей
Розділ II DORA (статті 5-16) встановлює найдетальніші вимоги до управління ІКТ-ризиками в регулюванні фінансових послуг ЄС. Розуміння конкретних вимог кожної статті є необхідним перед створенням вашої рамкової системи:
Article
Title
Key requirements
Key deliverables
Art 5
Governance and organisation
Management body defines, approves, oversees ICT risk framework
Board mandate, governance charter, training program
Art 6
ICT risk management framework
Comprehensive, documented framework with strategies, policies, procedures
Framework document, ICT risk strategy, annual review process
Art 7
ICT systems, protocols, tools
Reliable and resilient ICT systems maintained and updated
System standards, update policies, capacity management
Art 8
Identification
Identify, classify, document all ICT assets, risks, and dependencies
ICT asset register, risk register, dependency maps
Art 9
Protection and prevention
ICT security policies, access controls, encryption, patch management
Security policy suite, access control procedures, encryption standards
Art 10
Detection
Mechanisms to detect anomalous activities and ICT incidents
Monitoring strategy, SIEM configuration, alert procedures
Art 11
Response and recovery
ICT business continuity policy, disaster recovery plans, communication plans
BCP, DRP, crisis communication plan, backup strategy
Art 12
Backup policies and procedures
Backup and restoration policies, testing of backups, separate recovery sites
Backup policy, restoration procedures, test records
Art 13
Learning and evolving
Post-incident reviews, mandatory training, vulnerability disclosures
Post-incident review process, training program, lessons learned register
Art 14
Communication
Crisis communication plans, responsible disclosure policies
Communication policy, disclosure procedures, public notification templates
Art 15
Further harmonisation of ICT risk management tools
Regulatory Technical Standards specifying details of the framework
RTS compliance mapping, technical implementation
Art 16
Simplified ICT risk management framework
Proportionate requirements for qualifying small entities
Simplified framework document (if applicable)
Відповідальність органу управління: Стаття 5 покладає остаточну відповідальність за рамкову систему управління ІКТ-ризиками на орган управління. Кожна політика та процедура, яку ви створюєте відповідно до статей 6-16, має бути схвалена на рівні ради директорів і переглядатися щонайменше раз на рік. Це постійний пункт уваги під час аудиту.
Структура рамкової системи
DORA вимагає, щоб ваша рамкова система управління ІКТ-ризиками дотримувалася певного життєвого циклу: Ідентифікація, Захист, Виявлення, Реагування, Відновлення, Навчання. Це відображає усталені рамкові системи кібербезпеки (наприклад, NIST CSF), але додає специфічні вимоги DORA щодо управління, пропорційності та звітності перед регуляторами.
Використовуйте ISMS Copilot, щоб зрозуміти, як ваша наявна рамкова система співвідноситься з цим життєвим циклом:
"Порівняйте життєвий цикл управління ІКТ-ризиками DORA (Ідентифікація, Захист, Виявлення, Реагування, Відновлення, Навчання) зі статей 6-16 з нашою наявною рамковою системою [ISO 27001 / NIST CSF / EBA Guidelines]. Для кожної фази життєвого циклу визначте: які наявні засоби контролю вже відповідають DORA, де DORA додає специфічні вимоги понад нашу поточну рамкову систему, та які нові документи або процеси нам потрібно створити."
Крок 1: Створення документа рамкової системи управління ІКТ-ризиками
Структура та управління рамковою системою
Стаття 6 вимагає комплексної, документованої рамкової системи управління ІКТ-ризиками. Це основний документ, який об'єднує всі політики, процедури та процеси протягом життєвого циклу.
-
Відкрийте ваш робочий простір DORA у ISMS Copilot
-
Створіть документ рамкової системи:
"Створіть комплексну рамкову систему управління ІКТ-ризиками для [типу організації], яка відповідає статті 6 DORA. Включіть: мету та сферу застосування, структуру управління (з посиланням на обов'язки органу управління відповідно до статті 5), стратегію та цілі управління ІКТ-ризиками, рівні апетиту до ризику та толерантності, компоненти рамкової системи (ідентифікація, захист, виявлення, реагування, відновлення, навчання), інтеграцію з загальним управлінням ризиками підприємства, ролі та обов'язки (CISO, CRO, функція управління ІКТ-ризиками, перша/друга/третя лінії захисту), процедури перегляду та оновлення (щонайменше щорічні та після серйозних інцидентів відповідно до статті 6(5)), та метрики ефективності рамкової системи. Посилайтеся на конкретні статті DORA для кожного розділу."
-
Визначте стратегію управління ІКТ-ризиками:
"Розробіть стратегію управління ІКТ-ризиками для нашої [типу організації], як того вимагає стаття 6(8) DORA. Включіть: стратегічні цілі управління ІКТ-ризиками, узгоджені з бізнес-стратегією, порогові значення толерантності до ризиків, схвалені органом управління, підхід до методології оцінки ІКТ-ризиків, стратегію розподілу ресурсів для ІКТ-безпеки, ключові індикатори ризиків (KRI) та частоту звітності, та інтеграцію з ініціативами цифрової трансформації. Зробіть її придатною для схвалення органом управління."
Порада: Ваш документ рамкової системи управління ІКТ-ризиками має слугувати "парасолькою", яка посилається на всі підпорядковані політики та процедури. Зберігайте його стратегічним та орієнтованим на управління, а детальні операційні процедури виносьте в окремі документи. Така структура полегшує щорічні перегляди та схвалення органом управління.
Функція внутрішнього ІКТ-аудиту
Стаття 6(6) вимагає, щоб рамкова система управління ІКТ-ризиками регулярно перевірялася ІКТ-аудиторами. Використовуйте ISMS Copilot для створення цієї функції:
"Визначте вимоги до функції внутрішнього ІКТ-аудиту для статті 6(6) DORA. Включіть: статут ІКТ-аудиту, вимоги до незалежності та об'єктивності, аудиторський всесвіт, що охоплює всі компоненти рамкової системи управління ІКТ-ризиками, методологію ризик-орієнтованого планування аудиту, частоту аудиту (щонайменше щорічно для ключових областей), звітність перед органом управління та аудиторським комітетом, та процедури подальшого відстеження результатів аудиту. Надайте зразок річного плану ІКТ-аудиту."
Крок 2: Ідентифікація та класифікація ІКТ-активів (Стаття 8)
Створення інвентаризації ІКТ-активів
Стаття 8 вимагає ідентифікувати, класифікувати та документувати всі ІКТ-активи, ресурси та їх взаємозв'язки. Ця інвентаризація є основою для оцінки ризиків, класифікації інцидентів та управління ризиками третіх сторін.
-
Створіть структуру інвентаризації активів:
"Створіть шаблон інвентаризації ІКТ-активів, який відповідає вимогам статті 8 DORA. Включіть стовпці для: ідентифікатора активу, назви та опису активу, категорії активу (апаратне забезпечення, програмне забезпечення, дані, мережа, хмарний сервіс, послуга третьої сторони), власника активу, підтримуваної бізнес-функції, класифікації критичності (критичний, важливий, стандартний), вимог до конфіденційності/цілісності/доступності, фізичного та логічного розташування, взаємозв'язків та залежностей від інших активів, постачальників ІКТ-послуг третьої сторони, цільового часу відновлення (RTO) та цільової точки відновлення (RPO), дати останнього перегляду. Надайте критерії класифікації для кожного поля та зразки записів для [типу організації]."
-
Картування залежностей ІКТ-активів:
"Створіть методологію картування залежностей ІКТ для статті 8(1) DORA. Наші критичні бізнес-функції включають [перелік функцій]. Для кожної функції допоможіть нам ідентифікувати: ІКТ-системи та додатки, які її підтримують, компоненти інфраструктури (сервери, мережі, сховища), потоки даних та сховища даних, ІКТ-послуги та постачальників третьої сторони, єдині точки відмови та ризики концентрації. Надайте шаблон для документування цих залежностей у візуальному та табличному форматі."
-
Класифікуйте ІКТ-активи за критичністю:
"Визначте критерії класифікації ІКТ-активів для відповідності DORA. Створіть схему класифікації з рівнями (Критичний, Важливий, Стандартний) на основі: впливу на надання фінансових послуг у разі збою, зобов'язань щодо звітності перед регуляторами, кількості клієнтів/контрагентів, яких це стосується, чутливості даних, вимог до часу відновлення та взаємозв'язку з іншими критичними активами. Надайте дерева рішень та приклади для [типу організації]."
Стаття 8(4) вимагає від фінансових установ ідентифікувати всі ІКТ-активи, які підтримують критичні або важливі функції, та їх залежності, включаючи ті, що розміщені у постачальників третьої сторони. Ця інвентаризація безпосередньо впливає на класифікацію інцидентів (що вважається серйозним), обсяг тестування стійкості (що тестувати) та реєстр ризиків третіх сторін (які постачальники є критичними).
Ідентифікація та оцінка ІКТ-ризиків
Маючи повну інвентаризацію активів, проведіть систематичну оцінку ризиків щодо ідентифікованих ІКТ-активів:
"Створіть методологію та шаблон оцінки ІКТ-ризиків, узгоджені зі статтею 8 DORA. Для кожного критичного та важливого ІКТ-активу оцініть: сценарії загроз (кібератаки, збої систем, природні катастрофи, людські помилки, збої третіх сторін), вразливості (технічні, процедурні, організаційні), наявні засоби контролю та їх ефективність, ймовірність виникнення (шкала 1-5 з критеріями), вплив на бізнес-функції, клієнтів та відповідність регуляторним вимогам (шкала 1-5 з критеріями), залишковий рівень ризику та рівень ризику, власника ризику та рішення щодо обробки (зниження, прийняття, передача, уникнення), дії щодо обробки та терміни. Включіть точки інтеграції з нашим корпоративним реєстром ризиків."
Очікування аудиту: Регулятори очікують, що ваша оцінка ІКТ-ризиків буде всеосяжною, охоплюючи всі критичні активи, а не вибірковою. Переконайтеся, що кожен актив, класифікований як критичний або важливий у вашій інвентаризації, має відповідну оцінку ризиків. Прогалини тут є поширеною знахідкою під час аудиту.
Крок 3: Заходи захисту та запобігання (Стаття 9)
Розробка політик ІКТ-безпеки
Стаття 9 зобов'язує фінансові установи розробляти та документувати політики ІКТ-безпеки, що охоплюють управління доступом, шифрування, мережеву безпеку та управління змінами. Ці політики мають бути пропорційними вашому профілю ризиків.
-
Створіть пакет політик ІКТ-безпеки:
"Створіть комплексну політику ІКТ-безпеки для [типу організації], яка відповідає статті 9 DORA. Структуруйте політику так, щоб вона охоплювала: управління інформаційною безпекою та цілі, контроль доступу та управління ідентифікацією (включаючи привілейований доступ, багатофакторну автентифікацію та принцип найменших привілеїв), мережеву безпеку (сегментація, захист периметра, запобігання вторгненням), шифрування та криптографічні засоби контролю (дані в стані спокою, під час передачі, управління ключами), управління змінами в ІКТ (тестування, затвердження, процедури відкату), терміни усунення вразливостей та управління патчами, фізичну та екологічну безпеку для ІКТ-активів, вимоги до безпечного життєвого циклу розробки, захист кінцевих точок та управління мобільними пристроями, та заходи запобігання витоку даних. Для кожної області посилайтеся на конкретну статтю DORA та надайте рекомендації щодо впровадження, пропорційні для організації [розміру організації]."
-
Створіть процедури контролю доступу:
"Розробіть детальні процедури контролю доступу для статті 9(4) DORA. Включіть: робочі процеси надання та скасування доступу користувачів, проектування ролей на основі доступу (RBAC), вимоги до управління привілейованим доступом (PAM), процедури перегляду доступу (частота, обсяг, документування), стандарти автентифікації (вимоги до MFA, політики паролів), засоби контролю безпеки віддаленого доступу, управління обліковими записами служб та вимоги до ведення журналів доступу та моніторингу. Надайте шаблони процедур з покроковими інструкціями."
-
Встановіть процедури управління патчами:
"Створіть політику та процедури управління патчами для відповідності DORA. Включіть: частоту сканування на вразливості, класифікацію патчів (критичні, високі, середні, низькі) з відповідними термінами усунення, процедури тестування перед розгортанням, процес екстреного патчування для вразливостей нульового дня, відстеження патчів та звітність про відповідність, управління винятками для систем, які не можуть бути пропатчені, та інтеграцію з процесом управління змінами. Надайте KPI для звітності про відповідність патчам перед органом управління."
Порада: Якщо у вас вже впроваджені засоби контролю з додатку A ISO 27001, використовуйте ISMS Copilot, щоб визначити, які засоби контролю відповідають вимогам статті 9 DORA. Запитайте: "Зіставте наші засоби контролю з додатку A ISO 27001:2022 з вимогами статті 9 DORA. Визначте, де наші наявні засоби контролю повністю відповідають DORA, де вони частково відповідають, та де DORA вимагає додаткових заходів понад ISO 27001." Це допоможе уникнути дублювання зусиль.
Стандарти та стійкість ІКТ-систем (Стаття 7)
Стаття 7 вимагає, щоб ІКТ-системи були стійкими, надійними та мали достатню потужність. Використовуйте ISMS Copilot для розробки відповідних стандартів:
"Створіть стандарти та вимоги до ІКТ-систем для статті 7 DORA. Включіть: цілі надійності та доступності систем для критичних функцій, процедури управління потужностями (моніторинг, планування, масштабування), політики оновлення та обслуговування систем, управління застарілими технологіями, стандарти управління конфігураціями, розділення середовищ (продуктивне, тестове, розробницьке) та вимоги до систем, що підтримують критичні або важливі функції. Надайте у форматі контрольного списку відповідності."
Крок 4: Можливості виявлення (Стаття 10)
Створення стратегії виявлення та моніторингу
Стаття 10 вимагає механізмів для швидкого виявлення аномальних дій, включаючи проблеми з продуктивністю ІКТ-мереж та ІКТ-інциденти. Ваші можливості виявлення мають бути пропорційними важливості ІКТ-активів, що моніторяться.
-
Розробіть стратегію виявлення:
"Створіть комплексну стратегію виявлення та моніторингу ІКТ для [типу організації], яка відповідає статті 10 DORA. Включіть: архітектуру моніторингу (компоненти SIEM, EDR, NDR, UEBA), джерела даних для моніторингу (мережевий трафік, системні журнали, журнали додатків, події автентифікації, активність баз даних, журнали хмарних сервісів), сценарії виявлення, пріоритезовані за ризиком (несанкціонований доступ, витік даних, шкідливе ПЗ, DDoS, загрози зсередини, аномалії третіх сторін), класифікацію та рівні серйозності сповіщень, правила кореляції та базові поведінкові показники, вимоги до цілодобового моніторингу та інтеграцію з класифікацією інцидентів відповідно до статті 17 DORA. Надайте пріоритети впровадження для організації [розміру]."
-
Визначте процедури виявлення аномалій:
"Розробіть операційні процедури виявлення ІКТ-аномалій відповідно до статті 10 DORA. Включіть: як ідентифікуються аномалії (автоматизовані сповіщення, ручний огляд, канали розвідки загроз), процес первинної тріажу (хто переглядає, цільові терміни реагування, критерії ескалації), управління хибнопозитивними спрацьовуваннями, вимоги до документування виявлених аномалій, процедури передачі команді реагування на інциденти та безперервне налаштування правил виявлення на основі змін у ландшафті загроз. Надайте шаблон процедури з ролями та обов'язками."
Сильні можливості виявлення безпосередньо впливають на вашу здатність дотримуватися 4-годинного терміну повідомлення про інциденти згідно зі статтею 19 DORA. Якщо ви не можете швидко виявляти та класифікувати інциденти, ви не зможете вчасно їх повідомляти. Дивіться посібник Як впровадити звітність про інциденти DORA з використанням ШІ для повного керівництва щодо звітності про інциденти.
Крок 5: Процедури реагування та відновлення (Статті 11-12)
Управління безперервністю ІКТ-бізнесу
Статті 11 та 12 встановлюють детальні вимоги до безперервності бізнесу, аварійного відновлення та управління резервними копіями. Вони мають охоплювати сценарії, включаючи серйозні збої в ІКТ, кібератаки та збої постачальників третіх сторін.
-
Створіть політику безперервності ІКТ-бізнесу:
"Розробіть політику безперервності ІКТ-бізнесу для [типу організації], яка відповідає статті 11 DORA. Включіть: цілі та сферу застосування політики, управління (вимога схвалення органом управління), методологію аналізу впливу на бізнес (BIA) для ІКТ-послуг, стратегії безперервності для кожної критичної бізнес-функції, цільові терміни відновлення (RTO) та цільові точки відновлення (RPO) за функціями, плани безперервності для сценаріїв: кібератака, збій системи, вимкнення дата-центру, збій критичного постачальника третьої сторони, стихійне лихо, пандемія, плани комунікацій (внутрішні, клієнти, компетентні органи, громадськість), ролі та обов'язки під час події безперервності, критерії активації плану та процедури ескалації, вимоги до тестування (частота, обсяг, типи тестів), цикл обслуговування та перегляду плану (щонайменше щорічно). Посилайтеся на вимоги статті 11 DORA протягом усього документа."
-
Розробіть процедури аварійного відновлення:
"Створіть плани аварійного відновлення ІКТ для нашої [типу організації], що охоплюють [перелік критичних систем]. Для кожної критичної системи задокументуйте: опис системи та підтримувані бізнес-функції, команду відновлення та контактні дані, процедури відновлення (покроково), механізми перемикання на резервні потужності та альтернативні місця обробки, процедури відновлення даних з резервних копій, перевірку цілісності після відновлення, вимоги до комунікацій під час відновлення, критерії завершення відновлення та процедури пост-відновного огляду. Узгодьте RTO та RPO з нашою політикою безперервності бізнесу."
-
Встановіть політику та процедури резервного копіювання (Стаття 12):
"Створіть комплексну політику та процедури резервного копіювання та відновлення для статті 12 DORA. Включіть: обсяг резервного копіювання (усі дані, конфігурації, програмне забезпечення, необхідні для відновлення роботи), частоту резервного копіювання за класифікацією даних та RPO, методи резервного копіювання (повне, інкрементальне, диференціальне), вимоги до безпечного зберігання (географічно відокремлене вторинне місце розташування відповідно до статті 12(1)), шифрування резервних даних, процедури та частоту перевірки цілісності резервних копій, процедури тестування відновлення (щонайменше щорічно відповідно до статті 12(2)), моніторинг резервного копіювання та сповіщення, вимоги до документування та ведення журналів, та процедури резервного копіювання систем, розміщених у постачальників третіх сторін. Вкажіть вимоги до фізично та логічно відокремленого місця розташування резервних копій."
Критична вимога: Стаття 12 DORA конкретно вимагає, щоб системи резервного копіювання були розміщені на майданчику, який є географічно віддаленим та фізично і логічно відокремленим від основного майданчика. Це більш деталізована вимога, ніж у багатьох існуючих стандартах. Переконайтеся, що ваша поточна архітектура резервного копіювання відповідає цій конкретній вимозі.
Комунікація під час кризи (Стаття 14)
Стаття 14 вимагає наявності спеціальних планів комунікації під час кризи. Створіть їх за допомогою ISMS Copilot:
"Розробіть план комунікації під час ІКТ-кризи для статті 14 DORA. Включіть: управління комунікацією (хто санкціонує зовнішні повідомлення), матрицю комунікації зі зацікавленими сторонами (орган управління, співробітники, клієнти, контрагенти, компетентні органи, ЗМІ, громадськість), шаблони повідомлень для різних рівнів серйозності інцидентів, політику відповідального розкриття інформації про ІКТ-вразливості, процедури координації з компетентними органами під час інцидентів, протоколи для соціальних мереж та зв'язків з громадськістю, призначеного речника та дублера, та ведення журналів комунікацій та ведення записів. Надайте шаблонні повідомлення для сценаріїв серйозних ІКТ-інцидентів."
Крок 6: Навчання та розвиток (Стаття 13)
Процес пост-інцидентного огляду
Стаття 13 вимагає від фінансових установ вчитися на ІКТ-інцидентах, результатах тестування та вразливостях. Це створює цикл безперервного вдосконалення, який з часом зміцнює вашу рамкову систему.
-
Встановіть процес пост-інцидентного огляду:
"Створіть процедуру пост-інцидентного огляду для статті 13 DORA. Включіть: критерії запуску (які інциденти потребують формального огляду), терміни огляду (протягом [X] тижнів після закриття інциденту), учасників огляду (учасники реагування на інцидент, управління ризиками, уражені бізнес-підрозділи, керівництво), шаблон огляду, що охоплює: хронологію інциденту, аналіз першопричин (технічних та організаційних), оцінку ефективності засобів контролю, прогалини у виявленні або реагуванні, вплив на клієнтів та бізнес-функції, точність звітності перед регуляторами, отримані уроки та заходи з покращення, відстеження дій (відповідальний, термін, пріоритет), вимоги до звітності перед органом управління та інтеграцію уроків у оновлення рамкової системи управління ІКТ-ризиками. Надайте шаблон звіту про пост-інцидентний огляд."
-
Створіть програму безперервного вдосконалення:
"Розробіть програму безперервного вдосконалення рамкової системи управління ІКТ-ризиками відповідно до статті 13 DORA. Включіть: джерела для циклу вдосконалення (пост-інцидентні огляди, результати тестування, висновки аудиту, регуляторні рекомендації, розвідка загроз, технологічні зміни), управління заходами з вдосконалення (як дії пріоритезуються, схвалюються, відстежуються), метрики ефективності рамкової системи (тенденції інцидентів, час виявлення, час відновлення, зрілість засобів контролю), процес щорічного перегляду рамкової системи для органу управління та інтеграцію з програмами навчання та підвищення обізнаності відповідно до статті 13(6). Надайте шаблон для звіту про щорічний перегляд рамкової системи."
Обізнаність та навчання з ІКТ-безпеки
Стаття 13(6) вимагає обов'язкових програм обізнаності з ІКТ-безпеки та навчання з цифрової операційної стійкості. Розробіть їх за допомогою ISMS Copilot:
"Створіть програму обізнаності з ІКТ-безпеки та навчання для статті 13(6) DORA. Включіть: аналіз потреб у навчанні за ролями (орган управління, ІКТ-персонал, всі співробітники, підрядники третьої сторони), теми навчання (обізнаність з ІКТ-ризиками, зобов'язання щодо звітності про інциденти, політики безпеки, соціальна інженерія, специфічні вимоги DORA), методи та частоту проведення навчання, навчальну програму з ІКТ-ризиків для органу управління (відповідно до статті 5(4)), оцінку ефективності навчання, ведення записів та відстеження відповідності, та річний план навчання. Розрізняйте загальну обізнаність та технічне навчання, специфічне для ролей."
Порада: Створіть спеціальний навчальний модуль з DORA для вашого органу управління, який охоплює їхні особисті зобов'язання відповідно до статті 5, ландшафт ІКТ-ризиків, що стосується вашої установи, та як інтерпретувати звіти про ІКТ-ризики. Це важливий пункт для аудиту та демонструє справжню залученість управління.
Крок 7: Інтеграція та валідація повної рамкової системи
Перехресне посилання компонентів рамкової системи
Після розробки всіх компонентів рамкової системи використовуйте ISMS Copilot для перевірки повноти та узгодженості:
"Перегляньте наступні компоненти рамкової системи управління ІКТ-ризиками на предмет повноти відповідності DORA: [перелік або завантажте ваш документ рамкової системи, політики, процедури, шаблони]. Для кожної статті DORA 5-16 підтвердіть: чи розглянуто вимогу, який документ її розглядає, чи є підхід адекватним для [типу організації] нашого розміру, будь-які прогалини або неузгодженості між документами, та будь-які вимоги з Регуляторних технічних стандартів (RTS) відповідно до статті 15, які ще не розглянуто. Надайте матрицю відповідності."
Підготовка до регуляторної перевірки
Компетентні органи перевірятимуть вашу рамкову систему управління ІКТ-ризиками як основний об'єкт уваги. Підготуйте пакет доказів:
"Створіть контрольний список підготовки до перевірки управління ІКТ-ризиками DORA для [типу організації]. Для кожної статті 5-16 перелічіть: очікувані регуляторні питання, документи-докази, які слід підготувати, ключові метрики та KPI для представлення, поширені недоліки та як їх уникнути, та вимоги до демонстрації органом управління (записи про навчання, протоколи засідань, докази схвалення). Пріоритезуйте за ймовірністю фокусу перевірки."
Вашу рамкову систему управління ІКТ-ризиками необхідно переглядати щонайменше раз на рік та після серйозних ІКТ-інцидентів (стаття 6(5)). Включіть цей цикл перегляду до свого календаря управління з самого початку та використовуйте ISMS Copilot для створення шаблону звіту про щорічний перегляд.
Наступні кроки
Тепер у вас є комплексна рамкова система управління ІКТ-ризиками, що охоплює всі вимоги статей 6-16 DORA:
- Документ рамкової системи зі структурою управління та стратегією управління ІКТ-ризиками
- Інвентаризація ІКТ-активів з класифікацією та картуванням залежностей
- Заходи захисту та запобігання з пакетом політик безпеки
- Можливості виявлення зі стратегією та процедурами моніторингу
- Процедури реагування та відновлення з планами безперервності бізнесу (BCP), аварійного відновлення (DRP) та політиками резервного копіювання
- Програма навчання та розвитку з процесом пост-інцидентного огляду та навчанням
Продовжуйте з наступними посібниками цієї серії DORA:
- Як впровадити звітність про інциденти DORA з використанням ШІ -- Розвивайте свої можливості виявлення та реагування з урахуванням специфічних вимог DORA до класифікації та звітності про інциденти
- Як спланувати тестування стійкості DORA з використанням ШІ -- Розробіть програму тестування для перевірки засобів контролю та процедур, які ви встановили в цій рамковій системі
- Як управляти ІКТ-ризиками третіх сторін відповідно до DORA з використанням ШІ -- Розширте свою рамкову систему управління ризиками, щоб охопити постачальників ІКТ-послуг третьої сторони, ідентифікованих у вашій інвентаризації активів
Для готових до використання запитів, що охоплюють усі аспекти управління ІКТ-ризиками, дивіться Бібліотеку запитів для відповідності DORA. Для повного огляду регулювання зверніться до Посібника з відповідності DORA для фінансових установ.
Отримання допомоги
Для додаткової підтримки у створенні вашої рамкової системи управління ІКТ-ризиками:
- Запитайте ISMS Copilot: Використовуйте свій робочий простір DORA для ітеративної розробки та перегляду політик
- Завантажте наявні політики: Отримайте цілеспрямований аналіз прогалин, завантаживши поточну документацію з ІКТ-ризиків для порівняння з вимогами DORA
- Перехресне посилання на рамкові системи: Зіставте наявні засоби контролю ISO 27001 або EBA Guidelines зі статтями 6-16 DORA, щоб використати попередню роботу
- Валідуйте результати: Перегляньте згенеровані ШІ документи рамкової системи на відповідність тексту регулювання DORA та відповідним Регуляторним технічним стандартам перед схваленням органом управління
Створюйте свою рамкову систему управління ІКТ-ризиками вже сьогодні. Відкрийте свій робочий простір DORA за посиланням chat.ismscopilot.com та почніть зі створення документа рамкової системи. Знання ISMS Copilot статті за статтею DORA гарантує, що кожна політика та процедура, яку ви генеруєте, відповідає очікуванням регуляторів та готова до наглядової перевірки.