Як впровадити звітність про інциденти DORA з використанням ШІ

Огляд

Ви дізнаєтесь, як впровадити вимоги DORA щодо звітності про ІКТ-інциденти згідно зі статтями 17-23 з використанням ШІ. Цей посібник охоплює критерії класифікації інцидентів, обов'язкові терміни звітності 4 години/72 години/1 місяць, шаблони повідомлень, процедури аналізу першопричин та інтеграцію з існуючими процесами управління інцидентами, з конкретними запитами ISMS Copilot для генерації кожного компонента.

Для кого цей посібник

Цей посібник призначений для:

• Менеджерів реагування на інциденти та керівників SOC, відповідальних за виявлення та класифікацію ІКТ-інцидентів
• Спеціалістів з комплаєнсу, які керують регуляторними повідомленнями про інциденти
• CISO, які контролюють програми управління інцидентами у фінансових установах
• Менеджерів з ризиків, які оцінюють вплив інцидентів та відстежують усунення наслідків
• Консультантів, які впроваджують звітність про інциденти DORA для клієнтів фінансових установ

Перш ніж розпочати

Вам знадобиться:

• Обліковий запис ISMS Copilot (доступна безкоштовна пробна версія)
• Ваша структура управління ІКТ-ризиками, створена згідно з How to build a DORA ICT risk management framework using AI
• Ваш реєстр ІКТ-активів з класифікацією за критичністю (необхідний для оцінки впливу інцидентів)
• Ваші існуючі процедури реагування на інциденти та будь-які поточні процеси регуляторної звітності
• Розуміння каналів та форматів звітності вашого компетентного органу
• Доступ до вашої команди реагування на інциденти, SOC та функції комплаєнсу

Розуміння вимог DORA щодо звітності про інциденти

Розбір статей

Розділ III DORA (статті 17-23) встановлює всебічний режим управління та звітності про інциденти. Кожна стаття охоплює певний аспект процесу:

Article

Title

Key requirements

Key deliverables

Art 17

Процес управління ІКТ-інцидентами

Розробка процесу управління інцидентами з ранніми індикаторами, процедурами та ролями

Документ процесу управління інцидентами, матриця ролей

Art 18

Класифікація ІКТ-інцидентів та кіберзагроз

Класифікація інцидентів за встановленими критеріями (серйозні та несерйозні)

Матриця класифікації, критерії серйозності, блок-схема прийняття рішень

Art 19

Звітність про серйозні ІКТ-інциденти

Триетапна звітність: початкова (4 год), проміжна (72 год), остаточна (1 міс)

Шаблони звітів, процедури ескалації, робочі процеси подання

Art 20

Гармонізація змісту та шаблонів звітності

Стандартизовані формати звітів згідно з RTS

Заповнені шаблони звітів, узгоджені з форматами RTS

Art 21

Централізація звітності

Звітність через єдиний європейський хаб (майбутня вимога)

Процедури каналів звітності

Art 22

Наглядовий зворотний зв'язок

Отримання та врахування наглядового зворотного зв'язку

Процес інтеграції зворотного зв'язку

Art 23

Повідомлення про значні кіберзагрози

Добровільне повідомлення про значні кіберзагрози

Процедури повідомлення про загрози

Триетапний графік звітності

Розуміння графіка звітності DORA є критично важливим для розробки ваших процедур:

Report stage

Deadline

Trigger

Content required

Key challenge

Початкове повідомлення

Протягом 4 годин після класифікації як серйозного

Інцидент класифіковано як серйозний

Резюме інциденту, обґрунтування класифікації, початкова оцінка впливу, уражені послуги

Швидкість класифікації та подання

Проміжний звіт

Протягом 72 годин після початкового повідомлення

Триває розслідування

Оновлена оцінка впливу, аналіз першопричини (попередній), заходи стримування, статус відновлення

Надання змістовного аналізу, поки інцидент може тривати

Остаточний звіт

Протягом 1 місяця після початкового повідомлення

Вирішення інциденту

Повний аналіз першопричини, загальний вплив (фінансовий, операційний, репутаційний), заходи з усунення, уроки

Всебічний аналіз та докази усунення наслідків

Крок 1: Розробка процесу управління інцидентами (Стаття 17)

Основний процес управління інцидентами

Стаття 17 вимагає наявності всебічного процесу управління ІКТ-інцидентами. Цей процес має бути інтегрований з вашими можливостями виявлення (Стаття 10) та ширшою структурою управління ІКТ-ризиками.

1. Відкрийте ваш робочий простір DORA у ISMS Copilot

2. Згенеруйте процес управління інцидентами:

   "Create a comprehensive ICT-related incident management process for a [entity type] satisfying DORA Article 17. Include: purpose, scope, and process objectives, incident lifecycle phases (detection, triage, classification, containment, eradication, recovery, post-incident review), roles and responsibilities (incident commander, technical lead, communications lead, compliance/regulatory reporting, management body liaison), early warning indicators and detection triggers (linking to Article 10 monitoring), escalation matrix by incident severity, communication protocols (internal teams, management body, clients, competent authority), integration with existing IT service management (ITSM) processes, documentation and evidence preservation requirements, process activation criteria and decision trees, and process performance metrics. Provide the process in flowchart-ready format with clear decision points."

3. Визначте структуру команди реагування на інциденти:

   "Define the ICT incident response team (IRT) structure for a [entity type] with [number] employees. Include: team composition (core team, extended team, on-call roster), team leader selection criteria and authority levels, activation procedures (business hours and after hours), communication channels and tools, team member contact directory template, training and exercise requirements, and integration with external parties (regulators, law enforcement, forensic providers, third-party ICT providers). Address 24/7 coverage requirements for meeting the 4-hour notification deadline."

Крок 2: Створення матриці класифікації інцидентів (Стаття 18)

Критерії класифікації серйозних інцидентів

Стаття 18 встановлює критерії для класифікації ІКТ-інцидентів як серйозних. Регламентні технічні стандарти (RTS) містять детальні порогові значення суттєвості. Ваша матриця класифікації має операціоналізувати ці критерії для швидкого прийняття рішень під час інциденту.

1. Згенеруйте матрицю класифікації:

   "Create an ICT-related incident classification matrix for a [entity type] that satisfies DORA Article 18. Include the following classification criteria from the regulation and RTS: number of clients/financial counterparties affected (provide specific thresholds for our entity type), duration of the incident, geographical spread of the incident, data losses (confidentiality, integrity, availability), criticality of services affected (mapped to our ICT asset classification), economic impact (direct and indirect financial losses), reputational impact assessment. For each criterion, define: specific quantitative thresholds that trigger 'major' classification, measurement methodology, data sources for rapid assessment, and examples. Create a scoring matrix that allows classification within 1-2 hours of incident detection. Include a decision flowchart: if any single criterion meets the major threshold, the incident is classified as major."

2. Створіть блок-схему прийняття рішень щодо класифікації:

   "Design a step-by-step incident classification decision flowchart for DORA Article 18. The flowchart should be usable by on-call incident managers at 3 AM with limited information. Start with: initial incident details (what happened, when, what is affected). Then assess each major incident criterion sequentially: clients affected (threshold: [X]), duration (threshold: [X] hours), data impact (any confirmed data breach), critical services affected (any service on our critical list), economic impact (estimated above [X] EUR). If any criterion is met, classify as MAJOR and trigger 4-hour reporting. If borderline, escalate to [role] for classification decision. If no criteria met, classify as non-major and follow standard incident process. Provide guidance for situations with incomplete information."

Відстеження несерйозних інцидентів

Хоча лише серйозні інциденти вимагають регуляторного повідомлення, DORA вимагає відстежувати та аналізувати всі ІКТ-інциденти:

"Create a non-major ICT incident tracking and analysis procedure for DORA compliance. Include: recording requirements for all ICT incidents (incident register template), trend analysis methodology (identify patterns that could indicate systemic issues), escalation criteria (when accumulation of non-major incidents suggests a major issue), periodic reporting to management (frequency, format, content), and integration with the continuous improvement process under Article 13. Provide a quarterly incident trend report template."

Крок 3: Створення шаблонів регуляторних повідомлень (Статті 19-20)

Шаблон початкового повідомлення (4 години)

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

1. Згенеруйте шаблон початкового повідомлення:

   "Create an initial incident notification template for DORA Article 19 (4-hour deadline). Pre-populate with standing organizational data. Include fields for: reporting entity identification (name, LEI, entity type, competent authority), incident identifier and classification date/time, incident description (what happened, initial timeline), classification rationale (which major criteria are met, with evidence), services affected and initial impact assessment, number of clients potentially affected (estimate if exact not known), geographical scope, initial containment actions taken, estimated duration if known, contact details for follow-up, and cross-border impact indicator. Design the template so it can be completed in under 60 minutes with the information available at classification time. Include guidance notes for each field."

2. Згенеруйте шаблон проміжного звіту (72 години):

   "Create an intermediate incident report template for DORA Article 19 (72-hour deadline). Include fields for: reference to initial notification, updated incident timeline, updated impact assessment (clients affected, financial impact, data impact), root cause analysis (preliminary findings), containment and mitigation measures implemented, recovery status and estimated timeline, any changes to incident classification, communication actions taken (clients, counterparties, public), involvement of external parties (law enforcement, forensic providers), updated risk assessment, and any supervisory actions requested. Include guidance on providing meaningful root cause analysis even when investigation is ongoing."

3. Згенеруйте шаблон остаточного звіту (1 місяць):

   "Create a final incident report template for DORA Article 19 (1-month deadline). Include comprehensive sections for: complete incident timeline (detection through resolution), confirmed root cause analysis (technical and organizational), total impact assessment (financial losses quantified, clients affected, services disrupted, data compromised), full description of containment, eradication, and recovery actions, effectiveness assessment of existing controls, remediation plan (actions, owners, deadlines, status), lessons learned and framework improvements, management body notification and decisions, regulatory reporting timeline compliance, and cross-references to any related incidents. This report should be suitable for supervisory review and serve as input to the post-incident review process under Article 13."

Процедури подання

Розробіть чіткі процедури подання звітів вашому компетентному органу:

"Create an incident report submission procedure for DORA regulatory notifications. Include: identification of our competent authority and their reporting channel (portal, email, API), submission authorization (who can authorize submission and at what time of day), quality review checklist before submission (completeness, accuracy, consistency with previous reports), submission confirmation and tracking, procedures for submitting outside business hours (for the 4-hour deadline), backup submission methods if primary channel is unavailable, record-keeping requirements (copies of all submissions with timestamps), and procedures for handling supervisory feedback under Article 22. Address the scenario where the incident itself affects our ability to submit reports."

Крок 4: Розробка процедур ескалації та комунікації

Внутрішня матриця ескалації

Ефективна ескалація є критично важливою для дотримання жорстких термінів DORA. Визначте чіткі шляхи ескалації для кожного сценарію:

1. Згенеруйте матрицю ескалації:

   "Create an ICT incident escalation matrix for a [entity type] covering DORA reporting requirements. Define escalation levels: Level 1 (SOC/IT Operations): initial detection and triage, Level 2 (Incident Response Team): investigation and containment, Level 3 (CISO/CRO): major incident classification decision, Level 4 (Management Body): notification of major incidents, regulatory communication approval. For each level, specify: escalation criteria (what triggers escalation to next level), escalation timeline (maximum time at each level before escalation), notification method and contact details, information to provide when escalating, and decision authority at each level. Include after-hours escalation procedures and backup contacts. Design to ensure classification can occur within 2 hours of detection."

2. Створіть процедури повідомлення клієнтів:

   "Develop client notification procedures for major ICT incidents under DORA. Include: criteria for when clients must be notified, notification timing relative to regulatory reporting, notification content (what to disclose, what to withhold during investigation), communication channels (email, portal, phone for critical clients), template client notifications for common incident types (service outage, data breach, system degradation), follow-up communication cadence, and record-keeping requirements. Address scenarios where the incident affects our ability to communicate with clients."

Повідомлення органу управління

Стаття 5 вимагає інформувати орган управління про ІКТ-інциденти. Визначте, як це відбуватиметься під час інцидентів:

"Create a management body incident notification procedure for DORA Article 5 compliance. Include: notification triggers (all major incidents, significant non-major incidents), notification timeline (within [X] hours of classification), notification format (structured briefing template), content (incident summary, impact assessment, response actions, regulatory reporting status, client impact, media risk), decision points requiring management body input (public communications, client compensation, regulatory engagement), follow-up reporting cadence during ongoing incidents, and post-incident briefing and lessons learned presentation. Provide the management body incident briefing template."

Крок 5: Інтеграція з існуючим управлінням інцидентами

Відображення вимог DORA на ваші поточні процеси

Більшість фінансових установ вже мають процеси управління інцидентами. Використовуйте ISMS Copilot для інтеграції вимог DORA у вашу існуючу структуру, а не створюйте паралельні процеси:

"We currently use [ITIL/NIST/custom] incident management processes with [describe current tools: ServiceNow, Jira, PagerDuty, etc.]. Map DORA Article 17-23 requirements to our existing process. Identify: where our current process already satisfies DORA (detection, triage, containment, recovery), where we need to add DORA-specific steps (major incident classification, regulatory reporting, client notification), process modifications needed (timeline compression, escalation enhancements), tooling changes required (classification automation, report generation, submission tracking), and documentation updates needed. Provide a gap analysis with specific remediation actions."

Автоматизація класифікації та звітності

Враховуючи 4-годинний термін, розгляньте можливості автоматизації:

"Identify opportunities to automate DORA incident classification and reporting for a [entity type]. Consider: automated collection of classification data points (number of affected clients from monitoring systems, service availability metrics, transaction volume impacts), automated pre-population of report templates from incident management tools, automated calculation of major incident criteria thresholds, workflow automation for escalation and notifications, integration between SIEM/incident platform and reporting workflow, automated deadline tracking and reminder alerts, and automated compilation of incident metrics for trend analysis. Provide implementation recommendations prioritized by impact on the 4-hour deadline."

Крок 6: Процедури аналізу першопричин

Структурована методологія аналізу першопричин

DORA вимагає аналізу першопричин як частини проміжного (72 години) та остаточного (1 місяць) звітів. Розробіть стандартизовану методологію:

1. Згенеруйте методологію RCA:

   "Create a root cause analysis (RCA) methodology for DORA ICT incident reporting. Include: RCA initiation criteria and timing (start within 24 hours of major incident classification), investigation methods (5 Whys, fishbone/Ishikawa, fault tree analysis, timeline analysis), evidence collection and preservation procedures, technical investigation steps (log analysis, forensics, system examination), organizational investigation steps (process review, policy compliance, training adequacy), root cause categories (technical failure, human error, process gap, third-party failure, external attack, design flaw), preliminary RCA process for the 72-hour intermediate report (structured even with incomplete information), comprehensive RCA process for the 1-month final report, quality review of RCA findings before submission, and linkage between root causes and remediation actions. Provide an RCA report template with examples."

2. Створіть процедури відстеження усунення наслідків:

   "Develop a post-incident remediation tracking procedure for DORA compliance. Include: how remediation actions are identified from RCA findings, action prioritization methodology (critical, high, medium based on risk), action assignment (owner, deadline, resources), progress tracking and reporting, management body oversight of remediation progress, verification of remediation effectiveness, closure criteria for remediation actions, and integration with the ICT risk register (updating risk assessments based on incident findings). Provide a remediation tracking register template."

Крок 7: Повідомлення про кіберзагрози (Стаття 23)

Добровільна звітність про загрози

Стаття 23 заохочує фінансові установи повідомляти компетентні органи про значні кіберзагрози, навіть якщо вони ще не призвели до інцидентів. Розробіть процедури для цієї добровільної звітності:

"Create a significant cyber threat notification procedure for DORA Article 23. Include: criteria for what constitutes a 'significant cyber threat' warranting voluntary notification (targeted attacks detected but contained, intelligence on imminent threats, zero-day vulnerabilities affecting critical systems, threat patterns across the sector), internal assessment and decision process (who decides whether to notify), notification template for cyber threats (different from incident reports), timing expectations (not mandated but should be prompt), confidentiality considerations and information sharing limitations, and benefits of voluntary reporting (supervisory goodwill, sector-wide protection, intelligence sharing). Provide decision criteria and a notification template."

Крок 8: Тестування вашої здатності до звітності про інциденти

Навчальні вправи та симуляції

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

1. Розробіть сценарії навчальних вправ:

   "Design three tabletop exercise scenarios for testing our DORA incident classification and reporting procedures. Each scenario should: be realistic for a [entity type], unfold over multiple phases (initial detection, escalation, containment, reporting), test the major incident classification decision, test the 4-hour initial notification process end-to-end, include complications (incomplete information, after-hours detection, multiple simultaneous issues), test client communication triggers, and require management body notification. Scenarios should cover: (1) ransomware attack affecting critical banking/payment systems, (2) cloud provider outage affecting multiple services, (3) data breach discovered through external notification. For each scenario, provide an exercise facilitator guide with inject timeline, expected participant actions, and evaluation criteria."

2. Створіть систему оцінки вправ:

   "Create an evaluation framework for DORA incident reporting tabletop exercises. Evaluate: time from detection to classification (target under 2 hours), time from classification to initial notification submission (target under 4 hours), accuracy of classification decision, completeness of initial notification, quality of escalation and communication, management body notification effectiveness, client communication appropriateness, documentation quality, and team coordination. Provide a scoring rubric and post-exercise report template."

Наступні кроки

Тепер у вас є всебічний механізм звітності про інциденти DORA:

• Процес управління інцидентами, інтегрований з можливостями виявлення
• Матриця класифікації з кількісними порогами для серйозних інцидентів
• Триетапні шаблони регуляторних повідомлень (4 години, 72 години, 1 місяць)
• Матриця ескалації з чіткими повноваженнями прийняття рішень та термінами
• Методологія аналізу першопричин з відстеженням усунення наслідків
• Процедури повідомлення про кіберзагрози
• Протестовані процедури за допомогою навчальних вправ

Продовжуйте з наступними посібниками цієї серії DORA:

• How to plan DORA resilience testing using AI -- Розробіть вашу програму тестування, включаючи сценарії, які перевіряють ваші можливості реагування на інциденти та звітності
• How to manage DORA third-party ICT risk using AI -- Забезпечте, щоб ваші сторонні постачальники ІКТ могли підтримувати ваші зобов'язання щодо звітності про інциденти з відповідними пунктами повідомлень та SLA

Для базової настройки див. How to get started with DORA implementation using AI. Для структури управління ІКТ-ризиками, яка лежить в основі управління інцидентами, див. How to build a DORA ICT risk management framework using AI.

Для готових до використання запитів див. DORA Compliance Prompt Library. Для повного огляду регуляторних вимог зверніться до DORA Compliance Guide for Financial Entities.

Отримання допомоги

Для додаткової підтримки у впровадженні звітності про інциденти DORA:

• Запитайте ISMS Copilot: Використовуйте свій робочий простір DORA для генерації специфічних для сценарію рекомендацій щодо класифікації та налаштування шаблонів звітів для вашого типу установи
• Завантажте існуючі процедури: Отримайте цільовий аналіз прогалин, завантаживши ваш поточний план реагування на інциденти для порівняння зі статтями 17-23 DORA
• Симулюйте звітність: Використовуйте ISMS Copilot для проходження навчальних сценаріїв інцидентів та практики заповнення шаблонів повідомлень у стислі терміни
• Валідуйте результати: Перевірте всі критерії класифікації та шаблони звітів на відповідність тексту регуляторного акта DORA та відповідним Регламентним технічним стандартам перед офіційним прийняттям