dora-compliance-expert

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

DORA Compliance Expert

DORA合规专家

Tools and guidance for Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (Digital Operational Resilience Act — DORA).

针对欧盟《金融部门数字运营韧性条例》（EU 2022/2554，即Digital Operational Resilience Act — DORA）的工具与指南。

DORA Overview

DORA概述

The Digital Operational Resilience Act (Regulation EU 2022/2554) establishes a comprehensive framework for ICT risk management in the EU financial sector. It entered into force on January 16, 2023, and has been applicable since January 17, 2025.

Key objectives:

Ensure financial entities can withstand, respond to, and recover from all types of ICT-related disruptions and threats
Harmonize ICT risk management requirements across the financial sector
Establish an oversight framework for critical ICT third-party service providers
Promote information sharing on cyber threats within the financial sector

Legal nature: Unlike NIS2 (a directive requiring national transposition), DORA is a regulation — directly applicable in all EU Member States without transposition.

Relationship to other frameworks:

Framework	Relationship
NIS2 Directive	DORA is lex specialis (specific law) for financial sector; NIS2 applies residually
GDPR	DORA complements GDPR for security of ICT systems processing personal data
EBA Guidelines on ICT	DORA supersedes prior EBA guidelines on ICT and security risk management
PSD2	DORA enhances and extends PSD2 operational resilience requirements
MiCA	Crypto-asset service providers are in scope of both MiCA and DORA
ISO 27001	DORA requirements map to ISO 27001 controls; certification supports compliance

Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS):

DORA is supplemented by detailed RTS/ITS developed by the European Supervisory Authorities (ESAs: EBA, ESMA, EIOPA). Key RTS/ITS cover:

ICT risk management framework details
Incident classification criteria and reporting formats
Threat-led penetration testing (TLPT) methodology
ICT third-party register format
Oversight framework procedures

**《数字运营韧性条例》（EU 2022/2554）**为欧盟金融部门建立了全面的ICT风险管理框架。该条例于2023年1月16日生效，自2025年1月17日起正式适用。

核心目标：

确保金融实体能够抵御、应对并从各类ICT相关中断与威胁中恢复
统一金融行业ICT风险管理要求
建立针对关键ICT第三方服务提供商的监督框架
推动金融行业内网络威胁信息共享

法律性质： 与需要各国转化实施的NIS2指令不同，DORA是一项条例——无需转化即可直接适用于所有欧盟成员国。

与其他框架的关系：

框架	关系
NIS2指令	DORA是金融领域的特别法；NIS2作为补充适用
GDPR	DORA针对处理个人数据的ICT系统安全，对GDPR形成补充
EBA ICT指南	DORA取代了此前EBA关于ICT与安全风险管理的指南
PSD2	DORA强化并扩展了PSD2的运营韧性要求
MiCA	加密资产服务提供商同时受MiCA与DORA监管
ISO 27001	DORA要求与ISO 27001控制项对应；认证可作为合规证明

监管技术标准（RTS）与实施技术标准（ITS）：

DORA由欧洲监管当局（ESAs：EBA、ESMA、EIOPA）制定的详细RTS/ITS补充。核心RTS/ITS涵盖：

ICT风险管理框架细节
事件分类标准与报告格式
威胁导向渗透测试（TLPT）方法论
ICT第三方登记格式
监督框架流程

Scope

适用范围

DORA applies to 20 types of financial entities and their critical ICT third-party service providers.

DORA适用于20类金融实体及其关键ICT第三方服务提供商。

Financial Entities in Scope

适用的金融实体

#	Entity Type	Examples
1	Credit institutions	Banks, building societies
2	Payment institutions	Payment service providers
3	Account information service providers	Open banking providers
4	Electronic money institutions	E-money issuers
5	Investment firms	Broker-dealers, portfolio managers
6	Crypto-asset service providers	Crypto exchanges, custodians
7	Issuers of asset-referenced tokens	Stablecoin issuers
8	Central securities depositories	CSDs
9	Central counterparties	CCPs
10	Trading venues	Stock exchanges, MTFs, OTFs
11	Trade repositories	Transaction reporting repositories
12	Managers of alternative investment funds	Hedge fund managers, PE managers
13	Management companies (UCITS)	Mutual fund managers
14	Data reporting service providers	ARMs, APAs
15	Insurance and reinsurance undertakings	Insurance companies
16	Insurance intermediaries	Insurance brokers (except SMEs)
17	Institutions for occupational retirement provision	Pension funds
18	Credit rating agencies	S&P, Moody's, Fitch, etc.
19	Administrators of critical benchmarks	LIBOR/EURIBOR administrators
20	Crowdfunding service providers	Investment crowdfunding platforms

#	实体类型	示例
1	信贷机构	银行、建房互助协会
2	支付机构	支付服务提供商
3	账户信息服务提供商	开放银行提供商
4	电子货币机构	电子货币发行商
5	投资公司	经纪交易商、投资组合经理
6	加密资产服务提供商	加密货币交易所、托管商
7	资产参考代币发行商	稳定币发行商
8	中央证券存管机构	CSDs
9	中央对手方	CCPs
10	交易场所	证券交易所、MTFs、OTFs
11	交易存储库	交易报告存储库
12	另类投资基金管理人	对冲基金管理人、私募股权管理人
13	UCITS管理公司	共同基金管理人
14	数据报告服务提供商	ARMs、APAs
15	保险与再保险企业	保险公司
16	保险中介	保险经纪人（中小企业除外）
17	职业退休保障机构	养老基金
18	信用评级机构	标普、穆迪、惠誉等
19	关键基准利率管理人	LIBOR/EURIBOR管理人
20	众筹服务提供商	投资众筹平台

Proportionality Principle

比例原则

DORA applies proportionately based on the entity's:

Size and overall risk profile
Nature, scale, and complexity of services, activities, and operations
Systemic importance

Simplified ICT risk management framework is available for:

Small and non-interconnected investment firms
Payment institutions exempted under PSD2
Institutions exempted under Directive 2013/36/EU
Electronic money institutions exempted under EMD2
Small IORPs

DORA根据实体以下情况按比例适用：

规模与整体风险状况
服务、活动与运营的性质、规模及复杂度
系统性重要性

简化ICT风险管理框架适用于：

小型非互联投资公司
PSD2下豁免的支付机构
指令2013/36/EU下豁免的机构
EMD2下豁免的电子货币机构
小型IORPs

Critical ICT Third-Party Service Providers

关键ICT第三方服务提供商

The ESAs designate critical ICT third-party service providers (CTPPs) based on:

Systemic impact of the services on financial entities
Systemic character or importance of financial entities relying on the provider
Degree of substitutability of the provider
Number of Member States in which the provider operates

CTPPs are subject to the Direct Oversight Framework by the Lead Overseer (one of the ESAs).

ESAs基于以下标准指定关键ICT第三方服务提供商（CTPPs）：

服务对金融实体的系统性影响
依赖该提供商的金融实体的系统性特征或重要性
提供商的可替代性
提供商运营的成员国数量

CTPPs需接受牵头监管机构（某一ESA）的直接监督框架监管。

Five Pillars Deep-Dive

五大支柱深度解析

Pillar 1: ICT Risk Management (Chapter II, Articles 5–16)

支柱1：ICT风险管理（第二章，第5-16条）

The cornerstone of DORA. Financial entities must establish a comprehensive ICT risk management framework.

DORA的核心支柱。金融实体必须建立全面的ICT风险管理框架。

Governance and Organization (Article 5)

治理与组织（第5条）

The management body bears ultimate responsibility for ICT risk management:

Define, approve, oversee, and be responsible for the implementation of the ICT risk management framework
Define appropriate risk tolerance level for ICT risk
Approve the digital operational resilience strategy
Allocate adequate budget for ICT risk management
Approve and review the ICT business continuity policy and ICT response and recovery plans
Be informed at least once a year on findings of ICT risk reviews

Organizational requirements:

Designate an ICT risk management function (second line of defense)
Ensure adequate separation of ICT risk management, control, and internal audit functions
Establish clear roles and responsibilities for all ICT-related functions
Implement reporting lines ensuring the management body receives timely information

管理机构对ICT风险管理承担最终责任：

定义、批准、监督并负责ICT风险管理框架的实施
设定ICT风险的适当容忍水平
批准数字运营韧性战略
为ICT风险管理分配充足预算
批准并审查ICT业务连续性政策及ICT响应与恢复计划
每年至少一次了解ICT风险审查结果

组织要求：

指定ICT风险管理职能（第二道防线）
确保ICT风险管理、控制与内部审计职能充分分离
明确所有ICT相关职能的角色与职责
建立确保管理机构及时获取信息的报告线路

ICT Risk Management Framework (Article 6)

ICT风险管理框架（第6条）

Entities must establish, maintain, and implement a sound, comprehensive, and well-documented ICT risk management framework that:

Ensures a high level of digital operational resilience
Is documented and reviewed at least annually (or after major ICT incidents)
Includes a digital operational resilience strategy
Defines how the framework supports the entity's business strategy
Sets clear information security objectives
Defines ICT risk tolerance levels
Commits to a continuous improvement process

Digital Operational Resilience Strategy must include:

Methods for addressing ICT risk
Explanation of how the ICT risk management framework supports the business strategy
ICT risk tolerance level
Key information security objectives
Overview of ICT reference architecture and changes needed
Mechanisms for detecting ICT anomalies
ICT third-party risk strategy
Digital operational resilience testing approach
Communication strategy for incident disclosure

实体必须建立、维护并实施健全、全面且文档化的ICT风险管理框架，该框架需：

确保高水平的数字运营韧性
文档化并至少每年审查一次（或在重大ICT事件后）
包含数字运营韧性战略
明确框架如何支持实体业务战略
设定清晰的信息安全目标
定义ICT风险容忍水平
承诺持续改进流程

数字运营韧性战略必须包含：

应对ICT风险的方法
ICT风险管理框架如何支持业务战略的说明
ICT风险容忍水平
核心信息安全目标
ICT参考架构概述及所需变更
检测ICT异常的机制
ICT第三方风险战略
数字运营韧性测试方法
事件披露沟通战略

ICT Systems, Protocols, and Tools (Article 7)

ICT系统、协议与工具（第7条）

Requirements for ICT systems and infrastructure:

Use and maintain updated ICT systems, protocols, and tools that are adequate to support critical operations
Monitor effectiveness of ICT systems
Identify all sources of ICT risk (including environmental risks and physical threats)
Ensure appropriate network security management
Implement mechanisms for detecting anomalous activities

ICT系统与基础设施要求：

使用并维护足以支持关键运营的更新ICT系统、协议与工具
监控ICT系统的有效性
识别所有ICT风险来源（包括环境风险与物理威胁）
确保适当的网络安全管理
实施检测异常活动的机制

Identification (Article 8)

识别（第8条）

Identify, classify, and adequately document all ICT-supported business functions, information assets, and ICT assets
Identify all sources of ICT risk, particularly cyber threats
Map the interconnections and interdependencies with ICT third-party providers
Perform ICT risk assessments at least annually (and after major changes)
Identify assets and systems critical to business operations

识别、分类并充分记录所有ICT支持的业务职能、信息资产与ICT资产
识别所有ICT风险来源，尤其是网络威胁
绘制与ICT第三方提供商的互联与依赖关系
至少每年进行一次ICT风险评估（重大变更后也需进行）
识别对业务运营至关重要的资产与系统

Protection and Prevention (Article 9)

保护与预防（第9条）

Implement ICT security policies, procedures, protocols, and tools
Continuously monitor and control the security and functioning of ICT systems
Design network connection resilience mechanisms
Deploy strong authentication mechanisms (MFA, Article 9(4))
Implement ICT change management policies
Apply software patching policies
Implement data and system access policies based on least privilege

实施ICT安全政策、流程、协议与工具
持续监控并控制ICT系统的安全与运行
设计网络连接韧性机制
部署强认证机制（MFA，第9(4)条）
实施ICT变更管理政策
应用软件补丁政策
基于最小权限原则实施数据与系统访问政策

Detection (Article 10)

检测（第10条）

Put in place mechanisms to promptly detect anomalous activities
Detect network performance issues and ICT-related incidents
Deploy multiple layers of controls (including automated alerting)
Implement detection mechanisms that enable a fast response
Allocate sufficient resources for monitoring trading activities

建立及时检测异常活动的机制
检测网络性能问题与ICT相关事件
部署多层控制措施（包括自动告警）
实施能够实现快速响应的检测机制
为监控交易活动分配充足资源

Response and Recovery (Article 11)

响应与恢复（第11条）

Implement a comprehensive ICT business continuity policy
Develop ICT response and recovery plans
Activate response plans upon identification of ICT incidents
Estimate preliminary impacts, damages, and losses
Set communication and crisis management actions
Execute ICT response and recovery procedures as appropriate

Specific requirements:

Record all ICT-related incidents and significant cyber threats
Activate containment measures and restoration of operations
Implement backup and restoration policies and procedures
When restoring data from backups, maintain the integrity and confidentiality of data

实施全面的ICT业务连续性政策
制定ICT响应与恢复计划
在识别到ICT事件后启动响应计划
预估初步影响、损害与损失
制定沟通与危机管理行动
酌情执行ICT响应与恢复流程

特定要求：

记录所有ICT相关事件与重大网络威胁
启动遏制措施并恢复运营
实施备份与恢复政策及流程
从备份恢复数据时，保持数据的完整性与保密性

Backup and Restoration (Article 12)

备份与恢复（第12条）

Establish backup policies specifying scope, frequency, and retention
Restore backup data on separate ICT systems (not directly connected to source)
Regularly test backup procedures and restoration capabilities
When restoring data, ensure integrity checks are performed
Maintain redundant ICT capacities equipped with sufficient resources

制定明确范围、频率与保留期限的备份政策
在独立ICT系统（不直接连接源系统）上恢复备份数据
定期测试备份流程与恢复能力
恢复数据时确保执行完整性检查
维护配备充足资源的冗余ICT容量

Learning and Evolving (Article 13)

学习与演进（第13条）

Gather information on vulnerabilities, cyber threats, and ICT-related incidents
Review ICT-related incidents after recovery (post-incident reviews)
Implement findings of post-incident reviews and digital operational resilience testing
Monitor effectiveness of the ICT risk management framework
Deliver mandatory annual ICT security awareness training for all staff
Develop ICT security awareness programs for non-ICT staff

收集漏洞、网络威胁与ICT相关事件的信息
恢复后审查ICT相关事件（事后审查）
落实事后审查与数字运营韧性测试的结果
监控ICT风险管理框架的有效性
为所有员工提供强制性年度ICT安全意识培训
为非ICT员工制定ICT安全意识计划

Communication (Article 14)

沟通（第14条）

Develop crisis communication plans for internal and external stakeholders
Designate at least one spokesperson to communicate externally during incidents
Define communication policies for responsible disclosure of ICT-related incidents
Inform relevant clients and the public when appropriate

制定针对内外部利益相关者的危机沟通计划
指定至少一名发言人在事件期间进行外部沟通
定义ICT相关事件负责任披露的沟通政策
在适当情况下通知相关客户与公众

Pillar 2: ICT-Related Incident Management (Chapter III, Articles 17–23)

支柱2：ICT相关事件管理（第三章，第17-23条）

Incident Management Process (Article 17)

事件管理流程（第17条）

Financial entities must:

Define, establish, and implement an ICT-related incident management process
Put in place early warning indicators to trigger detection
Establish procedures to identify, track, log, categorize, and classify ICT-related incidents
Assign roles and responsibilities for different incident types/scenarios
Define plans for communication to staff, external stakeholders, media, and competent authorities

金融实体必须：

定义、建立并实施ICT相关事件管理流程
设定触发检测的预警指标
建立识别、跟踪、记录、分类ICT相关事件的流程
为不同事件类型/场景分配角色与职责
制定向员工、外部利益相关者、媒体及主管机构沟通的计划

Classification of ICT-Related Incidents (Article 18)

ICT相关事件分类（第18条）

Entities must classify incidents based on these criteria:

Criterion	Description
Number of clients/counterparts affected	Scale of impact on external parties
Duration	Length of the incident
Geographic spread	Jurisdictions and Member States affected
Data losses	Availability, authenticity, integrity, or confidentiality of data
Criticality of services affected	Impact on critical or important functions
Economic impact	Direct and indirect financial costs

Major incident determination: An incident is classified as major if it meets the thresholds defined in the RTS on incident classification.

实体必须基于以下标准对事件进行分类：

标准	描述
受影响客户/交易对手数量	对外部各方的影响范围
持续时间	事件时长
地理范围	受影响的司法管辖区与成员国
数据损失	数据的可用性、真实性、完整性或保密性受损情况
受影响服务的关键性	对关键或重要职能的影响
经济影响	直接与间接财务成本

重大事件判定： 若事件达到事件分类RTS中定义的阈值，则被归类为重大事件。

Reporting Obligations (Article 19)

报告义务（第19条）

Stage	Deadline	Content
Initial notification	Within 4 hours of classifying as major (or 24 hours from detection)	Basic facts, initial classification, estimated impact
Intermediate report	Within 72 hours of initial notification	Updated information, severity, root cause assessment, recovery status
Final report	Within 1 month of intermediate report	Root cause analysis, complete impact assessment, mitigation measures, lessons learned

Additional requirements:

Entities must inform their clients without undue delay about major ICT-related incidents that affect their financial interests
Entities must report to the competent authority using specified templates
Competent authorities may request additional information at any time

阶段	截止期限	内容
初始通知	归类为重大事件后4小时内（或检测后24小时内）	基本事实、初始分类、预估影响
中期报告	初始通知后72小时内	更新信息、严重程度、根本原因评估、恢复状态
最终报告	中期报告后1个月内	根本原因分析、完整影响评估、缓解措施、经验教训

附加要求：

若重大ICT相关事件影响客户财务利益，实体必须及时通知客户
实体必须使用指定模板向主管机构报告
主管机构可随时要求提供额外信息

Voluntary Reporting (Article 19(2))

自愿报告（第19(2)条）

Entities may voluntarily report:

Significant cyber threats (even if they have not resulted in an incident)
Near-misses that could have caused a major incident

实体可自愿报告：

重大网络威胁（即使未引发事件）
可能导致重大事件的未遂事件

Centralized Reporting (Article 20)

集中报告（第20条）

The ESAs develop common templates and procedures for incident reporting to reduce burden and ensure consistency.

ESAs制定通用报告模板与流程，以减轻负担并确保一致性。

Pillar 3: Digital Operational Resilience Testing (Chapter IV, Articles 24–27)

支柱3：数字运营韧性测试（第四章，第24-27条）

General Requirements (Article 24)

一般要求（第24条）

All financial entities must establish, maintain, and review a digital operational resilience testing program as an integral part of their ICT risk management framework.

所有金融实体必须建立、维护并审查数字运营韧性测试计划，将其作为ICT风险管理框架的组成部分。

Basic Testing (Article 25)

基础测试（第25条）

All entities must perform, at a minimum:

Test Type	Frequency	Description
Vulnerability assessments and scans	Regular (at least annually)	Automated and manual vulnerability identification
Open-source analyses	Regular	Assessment of open-source software risks
Network security assessments	Annual minimum	Network architecture, configuration, traffic analysis
Gap analyses	Annual minimum	Comparison of current controls vs requirements
Physical security reviews	Periodic	Data center, office, and facility security
Questionnaires and scanning software	Regular	Compliance checking and configuration verification
Source code reviews	Where applicable	Security-focused code review for in-house applications
Scenario-based tests	Annual	Tabletop exercises, simulations
Compatibility testing	As needed	Testing for system updates and changes
Performance testing	Regular	Load and stress testing for critical systems
End-to-end testing	Regular	Testing of complete business process chains
Penetration testing	Annual minimum	Simulated attack testing

所有实体必须至少执行以下测试：

测试类型	频率	描述
漏洞评估与扫描	定期（至少每年一次）	自动与手动漏洞识别
开源软件分析	定期	评估开源软件风险
网络安全评估	至少每年一次	网络架构、配置、流量分析
差距分析	至少每年一次	对比当前控制措施与要求
物理安全审查	定期	数据中心、办公场所与设施安全检查
问卷与扫描软件	定期	合规检查与配置验证
源代码审查	适用时	针对内部应用的安全导向代码审查
场景化测试	每年一次	桌面演练、模拟
兼容性测试	按需	系统更新与变更测试
性能测试	定期	关键系统负载与压力测试
端到端测试	定期	完整业务流程链测试
渗透测试	至少每年一次	模拟攻击测试

Advanced Testing — Threat-Led Penetration Testing (Article 26)

高级测试——威胁导向渗透测试（TLPT，第26条）

Applicable to: Entities identified by competent authorities based on systemic importance, ICT risk profile, and criticality of services.

TLPT requirements:

Based on the TIBER-EU framework
Covers critical or important functions mapped to services, business processes, and ICT
Conducted at least every 3 years
Scope is determined by the financial entity, validated by the competent authority
Must include live production systems
The management body must approve the scope

TLPT methodology:

Scoping phase: Identify critical functions and supporting ICT infrastructure
Threat intelligence phase: Gather threat intelligence specific to the entity's sector and geography
Red team phase: Execute realistic attack scenarios against production systems
Closure phase: Report findings, remediation planning
Purple team phase: Collaborative exercises between red team (attackers) and blue team (defenders)

Key rules:

Conducted by external testers with appropriate qualifications and independence
Internal testers may participate under specific conditions
Test results must be validated by competent authority
Remediation plans must be produced and implemented
Summary results must be shared with the competent authority

适用对象： 主管机构基于系统性重要性、ICT风险状况与服务关键性认定的实体。

TLPT要求：

基于TIBER-EU框架
覆盖映射到服务、业务流程与ICT的关键或重要职能
至少每3年执行一次
范围由金融实体确定，经主管机构验证
必须涵盖实时生产系统
管理机构必须批准测试范围

TLPT方法论：

范围界定阶段： 识别关键职能及支撑ICT基础设施
威胁情报阶段： 收集针对实体所在行业与地域的威胁情报
红队阶段： 针对生产系统执行真实攻击场景
收尾阶段： 报告发现、制定 remediation 计划
紫队阶段： 红队（攻击者）与蓝队（防御者）协作演练

核心规则：

由具备适当资质与独立性的外部测试人员执行
内部测试人员可在特定条件下参与
测试结果必须经主管机构验证
必须制定并实施整改计划
摘要结果必须与主管机构共享

Purple Teaming

紫队协作

DORA introduces purple teaming as a key element:

Collaborative exercise between red team and blue team
Red team shares tactics, techniques, and procedures (TTPs) used
Blue team reviews detection and response capabilities
Joint identification of gaps and improvement areas
Mandatory as part of the TLPT closure phase

DORA引入紫队协作作为核心要素：

红队与蓝队的协作演练
红队分享所用战术、技术与流程（TTPs）
蓝队审查检测与响应能力
共同识别差距与改进领域
作为TLPT收尾阶段的强制性环节

Pillar 4: ICT Third-Party Risk Management (Chapter V, Articles 28–44)

支柱4：ICT第三方风险管理（第五章，第28-44条）

General Principles (Article 28)

一般原则（第28条）

Financial entities must:

Manage ICT third-party risk as an integral component of ICT risk management
Be responsible at all times for compliance, regardless of outsourcing
Define strategy on ICT third-party risk (part of the digital resilience strategy)
Maintain and update a register of information relating to all contractual arrangements on ICT services

金融实体必须：

将ICT第三方风险管理作为ICT风险管理的组成部分
无论是否外包，始终对合规负责
制定ICT第三方风险战略（作为数字韧性战略的一部分）
维护并更新所有ICT服务合同安排的信息登记册

Preliminary Assessment (Article 28(4))

初步评估（第28(4)条）

Before entering into a contractual arrangement, entities must:

Identify and assess all relevant risks (including concentration risk)
Assess whether the arrangement covers critical or important functions
Conduct appropriate due diligence on prospective ICT third-party providers
Identify and assess conflicts of interest
Verify the ICT third-party provider's ability to comply with applicable regulations

签订合同安排前，实体必须：

识别并评估所有相关风险（包括集中度风险）
评估安排是否涵盖关键或重要职能
对潜在ICT第三方提供商进行适当尽职调查
识别并评估利益冲突
验证ICT第三方提供商遵守适用法规的能力

Key Contractual Provisions (Article 30)

关键合同条款（第30条）

Contracts with ICT third-party service providers must include:

Provision	Description
Clear service descriptions	Complete description of all services, including SLAs
Location requirements	Where data will be processed and stored, including sub-processing
Data protection provisions	Measures ensuring availability, authenticity, integrity, and confidentiality
Service level commitments	Quantitative and qualitative performance targets
Assistance obligations	ICT provider must assist with ICT incidents affecting the entity
Cooperation with authorities	Provider must cooperate with competent authorities and resolution authorities
Termination rights	Clear termination rights, including for performance failures and regulatory changes
Transition and exit provisions	Adequate transition periods and assistance for orderly transfer of services
Participation in TLPT	ICT provider must participate in entity's threat-led penetration testing
Audit rights	Full access and audit rights, including on-site inspections of the ICT provider
Unrestricted right to monitor	Right to continuously monitor provider's performance
Exit strategies	Mandatory exit strategies for critical or important function outsourcing

For critical or important functions, additional contractual requirements apply:

More detailed service level descriptions
Notice periods and reporting obligations for material developments
Full access to performance and security data
ICT provider must implement and test business continuity plans
Provider must provide staff training on ICT security awareness

与ICT第三方服务提供商的合同必须包含：

条款	描述
清晰的服务描述	所有服务的完整描述，包括SLA
位置要求	数据处理与存储地点，包括分包处理
数据保护条款	确保可用性、真实性、完整性与保密性的措施
服务水平承诺	定量与定性绩效目标
协助义务	ICT提供商必须协助处理影响实体的ICT事件
与机构合作	提供商必须配合主管机构与处置机构
终止权利	明确的终止权利，包括因绩效不佳与法规变更终止
过渡与退出条款	有序转移服务的充足过渡期限与协助
参与TLPT	ICT提供商必须参与实体的威胁导向渗透测试
审计权利	全面访问与审计权利，包括对ICT提供商的现场检查
无限制监控权	持续监控提供商绩效的权利
退出策略	针对关键或重要职能外包的强制性退出策略

针对关键或重要职能，需附加合同要求：

更详细的服务水平描述
重大事项的通知期限与报告义务
全面访问绩效与安全数据
ICT提供商必须实施并测试业务连续性计划
提供商必须为员工提供ICT安全意识培训

Register of ICT Third-Party Arrangements (Article 28(3))

ICT第三方安排登记册（第28(3)条）

Entities must maintain a register containing:

All contractual arrangements with ICT third-party providers
Distinction between critical/important and non-critical functions
Entity identification details (LEI, type, group structure)
Service details (type, start date, end date, governing law, data processing locations)
Sub-contractor chain information
Exit strategy information

The register must be reported to competent authorities upon request.

实体必须维护包含以下内容的登记册：

与ICT第三方提供商的所有合同安排
区分关键/重要职能与非关键职能
实体识别信息（LEI、类型、集团结构）
服务详情（类型、开始日期、结束日期、管辖法律、数据处理地点）
分包商链信息
退出策略信息

主管机构要求时，必须提交该登记册。

Exit Strategies (Article 28(8))

退出策略（第28(8)条）

For critical or important functions, entities must:

Develop exit strategies that are comprehensive, documented, and tested
Ensure sufficient transition arrangements that avoid disruption or degradation of services
Consider alternative solutions and transition plans
Enable recovery of data and applications

针对关键或重要职能，实体必须：

制定全面、文档化并经过测试的退出策略
确保充足的过渡安排，避免服务中断或降级
考虑替代方案与过渡计划
实现数据与应用的恢复

Oversight Framework for Critical ICT Third-Party Providers (Articles 31–44)

关键ICT第三方提供商监督框架（第31-44条）

The ESAs designate CTPPs and assign a Lead Overseer. The oversight framework includes:

Direct supervision powers over CTPPs
On-site inspections of CTPPs
Power to request information and issue recommendations
Annual oversight plans
CTPPs must cooperate with the Lead Overseer
Non-compliance may result in periodic penalty payments

ESAs指定CTPPs并分配牵头监管机构。监督框架包括：

对CTPPs的直接监管权力
对CTPPs的现场检查
要求提供信息与发布建议的权力
年度监督计划
CTPPs必须配合牵头监管机构
不合规可能导致定期罚款

Concentration Risk (Article 29)

集中度风险（第29条）

Entities must:

Identify and assess risks arising from concentrating ICT service arrangements on a single provider
Assess whether planned ICT outsourcing leads to material concentration risk
Consider the substitutability of the ICT third-party provider
Develop multi-vendor strategies where appropriate

实体必须：

识别并评估将ICT服务安排集中于单一提供商的风险
评估计划中的ICT外包是否导致重大集中度风险
考虑ICT第三方提供商的可替代性
酌情制定多供应商策略

Pillar 5: Information Sharing (Chapter VI, Article 45)

支柱5：信息共享（第六章，第45条）

Voluntary Cyber Threat Intelligence Sharing

自愿网络威胁情报共享

Financial entities may exchange amongst themselves cyber threat intelligence information including:

Indicators of compromise (IoCs)
Tactics, techniques, and procedures (TTPs)
Cybersecurity alerts and configuration tools
Tools and methods for detecting cyberattacks

金融实体可相互交换网络威胁情报信息，包括：

入侵指标（IoCs）
战术、技术与流程（TTPs）
网络安全告警与配置工具
检测网络攻击的工具与方法

Requirements for Sharing Arrangements

共享安排要求

Sharing must aim to enhance digital operational resilience
Must be within trusted communities of financial entities
Arrangements must respect business confidentiality and data protection
Must protect personal data in accordance with GDPR
Sharing may be enabled through information sharing and analysis centers (ISACs)

共享旨在提升数字运营韧性
必须在金融实体可信社区内进行
安排必须尊重商业机密与数据保护
必须按照GDPR保护个人数据
可通过信息共享与分析中心（ISACs）实现共享

Notification Requirements

通知要求

Entities must notify competent authorities of their participation in information-sharing arrangements.

实体必须将其参与信息共享安排的情况通知主管机构。

Penalties and Enforcement

处罚与执行

Administrative Penalties

行政罚款

DORA delegates penalty-setting to Member States and competent authorities. The regulation empowers authorities to impose:

Administrative penalties and remedial measures proportionate to the infringement
Periodic penalty payments to compel compliance
Public statements identifying the entity and the nature of the infringement
Orders to cease conduct and to desist from repetition
Temporary or permanent prohibition of certain activities

DORA授权成员国与主管机构设定罚款。条例赋予机构以下权力：

与违规行为相称的行政罚款与补救措施
定期罚款以强制合规
公开声明，指明实体与违规性质
责令停止违规行为并防止重复
临时或永久禁止某些活动

Enforcement Powers

执行权力

Competent authorities have powers to:

Require access to any document, data, or information
Conduct on-site inspections
Require remediation within a specified timeframe
Suspend or restrict activities
Impose administrative penalties

主管机构拥有以下权力：

要求访问任何文件、数据或信息
进行现场检查
要求在指定时间内整改
暂停或限制活动
处以行政罚款

CTPP Oversight Penalties

CTPP监督处罚

For critical ICT third-party service providers:

The Lead Overseer may issue recommendations
Non-compliance with recommendations may lead to periodic penalty payments
Maximum penalty: 1% of average daily worldwide turnover per day, for up to 6 months

针对关键ICT第三方服务提供商：

牵头监管机构可发布建议
不遵守建议可能导致定期罚款
最高罚款：每日全球平均营业额的1%，最长可达6个月

DORA Implementation Roadmap

DORA实施路线图

9-Month Plan

9个月计划

Month	Phase	Key Activities
1	Assessment	Map ICT risk landscape, identify applicable DORA requirements, gap analysis against 5 pillars
2	Framework Design	Design ICT risk management framework, define governance structure, establish policies
3	ICT Risk Management	Implement risk identification, protection, detection, and response procedures
4	Incident Management	Deploy incident classification, establish reporting procedures, prepare templates
5	Third-Party Risk	Build ICT third-party register, assess critical providers, update contracts
6	Third-Party Risk (cont.)	Complete contractual updates, develop exit strategies, assess concentration risk
7	Resilience Testing	Design testing program, execute basic tests (vulnerability scanning, gap analysis)
8	Advanced Testing	Conduct penetration testing, scenario-based exercises, TLPT preparation (if applicable)
9	Validation	Internal audit, remediation, management body reporting, continuous improvement setup

月份	阶段	核心活动
1	评估	绘制ICT风险图景，识别适用的DORA要求，针对5大支柱进行差距分析
2	框架设计	设计ICT风险管理框架，定义治理结构，制定政策
3	ICT风险管理	实施风险识别、保护、检测与响应流程
4	事件管理	部署事件分类，建立报告流程，准备模板
5	第三方风险	建立ICT第三方登记册，评估关键提供商，更新合同
6	第三方风险（续）	完成合同更新，制定退出策略，评估集中度风险
7	韧性测试	设计测试计划，执行基础测试（漏洞扫描、差距分析）
8	高级测试	进行渗透测试、场景化演练，准备TLPT（如适用）
9	验证	内部审计、整改、向管理机构报告，建立持续改进机制

Quick Wins (Month 1–2)

快速成果（第1-2个月）

Establish ICT risk management governance (management body accountability)
Begin building the ICT third-party register
Review and update incident response procedures for DORA timelines (4h/72h/1mo)
Ensure management body receives regular ICT risk reporting
Verify MFA deployment for critical systems
Document existing BCP/DRP for ICT systems

建立ICT风险管理治理（管理机构问责）
开始构建ICT第三方登记册
针对DORA时间线（4小时/72小时/1个月）审查并更新事件响应流程
确保管理机构定期收到ICT风险报告
验证关键系统的MFA部署
记录现有ICT系统的BCP/DRP

Infrastructure Checks

基础设施检查

ICT Asset Inventory

ICT资产清单

Maintain a comprehensive register of all ICT assets (hardware, software, network, cloud)
Classify assets by criticality and map to business functions
Include dependencies on ICT third-party providers
Update inventory upon any changes to ICT infrastructure

维护所有ICT资产（硬件、软件、网络、云）的全面登记册
按关键性对资产分类并映射到业务职能
包含对ICT第三方提供商的依赖关系
ICT基础设施变更时更新清单

Network Resilience Testing

网络韧性测试

Annual network security assessments
Network architecture review and segmentation validation
DDoS resilience testing for public-facing services
Redundant network path verification
Network monitoring and anomaly detection validation

年度网络安全评估
网络架构审查与分段验证
面向公众服务的DDoS韧性测试
冗余网络路径验证
网络监控与异常检测验证

Data Center Redundancy

数据中心冗余

Active-active or active-passive redundancy for critical systems
Geographic separation of primary and secondary data centers
Automated failover mechanisms tested regularly
Power and cooling redundancy verification
Physical security assessment of data centers

关键系统的主备或双活冗余
主备数据中心的地理隔离
定期测试自动故障转移机制
电源与冷却冗余验证
数据中心物理安全评估

Business Continuity Testing

业务连续性测试

Annual BCP exercise for all critical business functions
ICT disaster recovery testing covering failover and restoration
Scenario-based testing (cyber incident, natural disaster, provider failure)
Recovery time and recovery point validation against targets
Post-exercise improvement tracking

所有关键业务职能的年度BCP演练
涵盖故障转移与恢复的ICT灾难恢复测试
场景化测试（网络事件、自然灾害、提供商故障）
验证恢复时间与恢复点目标
跟踪演练后改进措施

Disaster Recovery Capabilities

灾难恢复能力

Documented DRP for all critical ICT systems
Backup restoration tested on separate environments
Immutable backup storage for ransomware resilience
Communication plans for disaster scenarios
Coordination procedures with ICT third-party providers

所有关键ICT系统的文档化DRP
在独立环境测试备份恢复
用于勒索软件韧性的不可变备份存储
灾难场景沟通计划
与ICT第三方提供商的协调流程

Third-Party Dependency Mapping

第三方依赖映射

Map all ICT third-party providers to business functions
Identify critical dependencies and single points of failure
Assess concentration risk across providers
Document sub-contractor chains for critical services
Verify provider business continuity capabilities

将所有ICT第三方提供商映射到业务职能
识别关键依赖与单点故障
评估跨提供商的集中度风险
记录关键服务的分包商链
验证提供商业务连续性能力

Tools

工具

DORA Readiness Checker

DORA就绪度检查器

Assesses organizational readiness against all 5 DORA pillars with per-pillar scoring.

bash

undefined

针对所有5大DORA支柱评估组织就绪度，并按支柱打分。

bash

undefined

Generate assessment template

生成评估模板

python scripts/dora_readiness_checker.py --template > assessment.json

Run full readiness assessment

运行完整就绪度评估

python scripts/dora_readiness_checker.py --config assessment.json

Assess specific pillars only

仅评估特定支柱

python scripts/dora_readiness_checker.py --config assessment.json --pillars 1 3 4 --json

Generate report with JSON output

生成JSON格式报告

python scripts/dora_readiness_checker.py --config assessment.json --output readiness_report.json --json


**Features:**
- Assessment against all 5 DORA pillars
- Per-pillar readiness scoring (0–100)
- Overall readiness score
- ICT risk management framework validation
- Incident management readiness check
- Third-party risk management assessment
- Resilience testing program evaluation
- Gap analysis with prioritized remediation recommendations

---

python scripts/dora_readiness_checker.py --config assessment.json --output readiness_report.json --json


**功能：**
- 针对所有5大DORA支柱的评估
- 按支柱的就绪度评分（0–100）
- 整体就绪度评分
- ICT风险管理框架验证
- 事件管理就绪度检查
- 第三方风险管理评估
- 韧性测试计划评估
- 差距分析与优先级整改建议

---

DORA Incident Classifier

DORA事件分类器

Classifies ICT incidents per DORA criteria and determines reporting obligations.

bash

undefined

根据DORA标准对ICT事件进行分类，并确定报告义务。

bash

undefined

Classify an incident interactively

交互式分类事件

python scripts/dora_incident_classifier.py --clients-affected 5000 --duration-hours 4 --data-loss yes --services-critical yes --economic-impact 500000

Classify from JSON input

从JSON输入分类

python scripts/dora_incident_classifier.py --config incident.json --json

Generate incident notification template

生成事件通知模板

python scripts/dora_incident_classifier.py --config incident.json --generate-template --output notification.json


**Features:**
- Incident classification per Article 18 criteria
- Major incident determination
- Reporting deadline calculation (4h initial, 72h intermediate, 1 month final)
- Incident notification template generation
- Severity scoring and impact assessment

---

python scripts/dora_incident_classifier.py --config incident.json --generate-template --output notification.json


**功能：**
- 根据第18条标准进行事件分类
- 重大事件判定
- 报告截止期限计算（初始4小时、中期72小时、最终1个月）
- 事件通知模板生成
- 严重程度评分与影响评估

---

Reference Guides

参考指南

DORA Five Pillars Guide

DORA五大支柱指南

Complete implementation guidance for all 5 DORA pillars with ISO 27001 control mapping, financial-sector-specific requirements, and RTS/ITS references.

针对所有5大DORA支柱的完整实施指南，包含ISO 27001控制项映射、金融行业特定要求及RTS/ITS参考。

DORA Third-Party Management Guide

DORA第三方管理指南

ICT third-party register template, contractual requirements checklist, exit strategy framework, concentration risk assessment methodology, and critical provider oversight.

ICT第三方登记册模板、合同要求清单、退出策略框架、集中度风险评估方法论及关键提供商监督内容。

Troubleshooting

故障排除

Problem	Possible Cause	Resolution
Readiness score unexpectedly low on Pillar 1 (ICT Risk Management)	Management body has not formally approved the ICT risk management framework	Ensure the management body signs off on the framework, digital resilience strategy, and ICT risk tolerance level per Article 5; document board meeting minutes
Incident classification tool returns "major" for minor service interruptions	Threshold parameters set too conservatively or default values used	Review classification criteria against actual RTS thresholds; adjust `--clients-affected` , `--duration-hours` , and `--economic-impact` inputs to match your entity's context
Third-party register incomplete despite significant outsourcing	ICT service arrangements not systematically tracked or sub-contractor chains undocumented	Inventory all contractual ICT arrangements; use the register template from `references/dora-third-party-management.md` ; include sub-processing chains and data processing locations
Resilience testing program scored as non-compliant	Only basic vulnerability scanning performed; no scenario-based or penetration testing	Design a comprehensive testing program per Article 25 covering all 12 test types; schedule annual penetration testing and scenario-based exercises; plan for TLPT if designated by competent authority
Pillar 5 (Information Sharing) shows zero compliance	Organization has not joined any cyber threat intelligence sharing arrangement	Evaluate participation in an ISAC (Information Sharing and Analysis Center) relevant to your financial sub-sector; notify competent authority of participation per Article 45
Exit strategies missing for critical ICT third-party providers	Contracts lack termination, transition, and data recovery provisions	Update all contracts for critical functions to include comprehensive exit strategies per Article 28(8); test transition plans and document alternative provider options
Proportionality assessment unclear	Organization unsure whether simplified framework applies	Assess entity size, risk profile, and systemic importance per DORA proportionality principle; small and non-interconnected firms may qualify for simplified requirements

问题	可能原因	解决方案
支柱1（ICT风险管理）就绪度评分意外偏低	管理机构未正式批准ICT风险管理框架	确保管理机构根据第5条签署框架、数字韧性战略与ICT风险容忍水平；记录董事会会议纪要
事件分类工具将轻微服务中断判定为"重大"	阈值参数设置过于保守或使用默认值	根据实际RTS阈值审查分类标准；调整 `--clients-affected` 、 `--duration-hours` 与 `--economic-impact` 输入以匹配实体实际情况
尽管存在大量外包，第三方登记册仍不完整	ICT服务安排未系统跟踪或分包商链未记录	盘点所有ICT合同安排；使用 `references/dora-third-party-management.md` 中的登记册模板；包含分包链与数据处理地点
韧性测试计划被判定为不合规	仅执行了基础漏洞扫描；未进行场景化或渗透测试	根据第25条设计涵盖所有12种测试类型的全面测试计划；安排年度渗透测试与场景化演练；若被主管机构指定，准备TLPT
支柱5（信息共享）合规性为零	组织未加入任何网络威胁情报共享安排	评估参与金融细分领域相关的ISAC（信息共享与分析中心）；根据第45条通知主管机构参与情况
关键ICT第三方提供商缺少退出策略	合同缺少终止、过渡与数据恢复条款	更新所有关键职能合同，根据第28(8)条加入全面退出策略；测试过渡计划并记录替代提供商选项
比例原则评估不清晰	组织不确定是否适用简化框架	根据DORA比例原则评估实体规模、风险状况与系统性重要性；小型非互联企业可能符合简化要求

Success Criteria

成功标准

Overall readiness score of 75+ across all 5 pillars -- indicating the organization can demonstrate compliance with core DORA requirements to competent authorities
ICT risk management framework formally approved by the management body -- with documented digital operational resilience strategy, risk tolerance levels, and annual review cycle
Incident classification and reporting procedures operational -- with capability to submit initial notification within 4 hours of major incident classification and intermediate report within 72 hours
Complete ICT third-party register maintained -- covering all contractual arrangements, distinguishing critical/important functions, with entity identification, service details, and sub-contractor chains
Resilience testing program covers all 12 required test types -- with annual penetration testing, scenario-based exercises, and TLPT preparation (if applicable) per Articles 24-27
Exit strategies documented and tested for all critical ICT providers -- with comprehensive transition arrangements, alternative provider identification, and data recovery procedures
Annual ICT security awareness training delivered to all staff -- with records maintained and specialized training for ICT and security personnel per Article 13

所有5大支柱整体就绪度评分达75分以上——表明组织可向主管机构证明符合DORA核心要求
ICT风险管理框架经管理机构正式批准——包含文档化的数字运营韧性战略、风险容忍水平及年度审查周期
事件分类与报告流程已投入使用——能够在重大事件分类后4小时内提交初始通知，72小时内提交中期报告
维护完整的ICT第三方登记册——涵盖所有合同安排，区分关键/重要职能，包含实体识别信息、服务详情与分包商链
韧性测试计划涵盖所有12种要求的测试类型——包含年度渗透测试、场景化演练及TLPT准备（如适用），符合第24-27条要求
所有关键ICT提供商的退出策略已文档化并测试——包含全面过渡安排、替代提供商识别与数据恢复流程
向所有员工提供年度ICT安全意识培训——保留记录，并为ICT与安全人员提供专项培训，符合第13条要求

Scope & Limitations

范围与局限性

In Scope:

Readiness assessment against all 5 DORA pillars with per-pillar scoring
ICT incident classification per Article 18 criteria with major incident determination
Reporting deadline calculation (4-hour initial, 72-hour intermediate, 1-month final)
Incident notification template generation for competent authority submissions
Third-party risk management guidance including register template and contractual requirements
Resilience testing program design covering basic and advanced (TLPT) testing
Gap analysis with prioritized remediation recommendations

Out of Scope:

Actual penetration testing execution or vulnerability scanning -- this skill provides planning and assessment frameworks, not testing tools
Direct interaction with competent authorities or ESAs (EBA, ESMA, EIOPA)
Legal determination of entity scope (whether your organization falls under DORA's 20 entity types) -- consult regulatory counsel
CTPP (Critical Third-Party Provider) oversight framework compliance -- applicable only to ESA-designated providers
Real-time ICT monitoring or SIEM implementation -- use
```
infrastructure-compliance-auditor
```
for technical security controls

Important Notes:

DORA became applicable January 17, 2025; regulators are treating 2025 as a transition year but enforcement is expected to intensify in 2026
Non-compliance penalties can reach up to 2% of total annual worldwide turnover or 1% of average daily global turnover for up to 6 months (for CTPPs)

适用范围：

针对所有5大DORA支柱的就绪度评估，含按支柱打分
根据第18条标准进行ICT事件分类与重大事件判定
报告截止期限计算（初始4小时、中期72小时、最终1个月）
生成提交给主管机构的事件通知模板
第三方风险管理指南，含登记册模板与合同要求
涵盖基础与高级（TLPT）测试的韧性测试计划设计
差距分析与优先级整改建议

不适用范围：

实际渗透测试执行或漏洞扫描——本工具提供规划与评估框架，而非测试工具
与主管机构或ESAs（EBA、ESMA、EIOPA）直接交互
实体范围的法律判定（组织是否属于DORA的20类实体）——咨询监管法律顾问
CTPP（关键第三方提供商）监督框架合规——仅适用于ESA指定的提供商
实时ICT监控或SIEM实施——使用
```
infrastructure-compliance-auditor
```
评估技术安全控制

重要提示：

DORA自2025年1月17日起适用；监管机构将2025年视为过渡年，但2026年执法力度预计会加强
不合规罚款最高可达年度全球总营业额的2%，或CTPP每日全球平均营业额的1%，最长可达6个月

Integration Points

集成点

Skill	Integration	When to Use
`information-security-manager-iso27001`	ISO 27001 controls map directly to DORA Pillar 1 requirements; ISO 27001 certification supports DORA compliance evidence	When building ICT risk management framework aligned with both ISO 27001 and DORA
`nis2-directive-specialist`	DORA is lex specialis for financial sector; NIS2 applies residually; coordinate incident reporting timelines	When financial entity also falls under NIS2 scope for non-financial ICT services
`infrastructure-compliance-auditor`	Technical infrastructure checks validate DORA Pillar 1 (protection, detection) and Pillar 3 (resilience testing) controls	When assessing actual infrastructure security posture against DORA requirements
`nist-csf-specialist`	NIST CSF 2.0 functions map to DORA pillars; useful for organizations with US operations	When building a unified resilience framework across US and EU requirements

工具	集成方式	使用场景
`information-security-manager-iso27001`	ISO 27001控制项直接映射到DORA支柱1要求；ISO 27001认证可作为DORA合规证明	构建同时符合ISO 27001与DORA要求的ICT风险管理框架时
`nis2-directive-specialist`	DORA是金融领域的特别法；NIS2作为补充适用；协调事件报告时间线	金融实体同时属于NIS2非金融ICT服务适用范围时
`infrastructure-compliance-auditor`	技术基础设施检查验证DORA支柱1（保护、检测）与支柱3（韧性测试）控制项	评估实际基础设施安全状况是否符合DORA要求时
`nist-csf-specialist`	NIST CSF 2.0职能与DORA支柱对应；适用于有美国业务的组织	构建跨美国与欧盟要求的统一韧性框架时

Tool Reference

工具参考

dora_readiness_checker.py

Assesses organizational readiness against all 5 DORA pillars with per-pillar scoring and gap analysis.

Flag	Required	Description
`--config <file>`	Yes (unless `--template` )	Path to JSON assessment configuration file
`--template`	No	Generate blank assessment template to stdout
`--pillars <nums>`	No	Assess specific pillars only (e.g., `--pillars 1 3 4` )
`--json`	No	Output results in JSON format for automation
`--output <file>`	No	Export report to specified file path

Output: Overall readiness score (0-100), per-pillar readiness scores, ICT risk management framework validation, incident management readiness, third-party risk assessment, resilience testing evaluation, and prioritized remediation recommendations.

针对所有5大DORA支柱评估组织就绪度，提供按支柱打分与差距分析。

参数	必填	描述
`--config <file>`	是（除非使用 `--template` ）	JSON评估配置文件路径
`--template`	否	生成空白评估模板到标准输出
`--pillars <nums>`	否	仅评估特定支柱（例如： `--pillars 1 3 4` ）
`--json`	否	以JSON格式输出结果用于自动化
`--output <file>`	否	将报告导出到指定文件路径

输出： 整体就绪度评分（0-100）、按支柱就绪度评分、ICT风险管理框架验证、事件管理就绪度、第三方风险评估、韧性测试评估及优先级整改建议。

dora_incident_classifier.py

Classifies ICT incidents per DORA Article 18 criteria and determines reporting obligations.

Flag	Required	Description
`--config <file>`	No	Path to JSON incident description file
`--template`	No	Generate blank incident input template to stdout
`--clients-affected <num>`	No	Number of clients/financial counterparts affected
`--duration-hours <num>`	No	Duration of the incident in hours
`--data-loss <yes/no>`	No	Whether data loss occurred (availability, integrity, or confidentiality)
`--services-critical <yes/no>`	No	Whether critical or important functions were affected
`--economic-impact <num>`	No	Estimated economic impact in EUR
`--json`	No	Output results in JSON format
`--generate-template`	No	Generate incident notification template for competent authority
`--output <file>`	No	Export report or template to specified file path

Output: Incident severity scoring per Article 18 criteria, major incident determination, reporting deadline calculation (initial 4h, intermediate 72h, final 1 month), and notification template generation.

Last Updated: March 2026 Regulation Reference: EU 2022/2554 Applicable From: January 17, 2025

根据DORA第18条标准对ICT事件进行分类，并确定报告义务。

参数	必填	描述
`--config <file>`	否	JSON事件描述文件路径
`--template`	否	生成空白事件输入模板到标准输出
`--clients-affected <num>`	否	受影响客户/金融交易对手数量
`--duration-hours <num>`	否	事件持续时长（小时）
`--data-loss <yes/no>`	否	是否发生数据损失（可用性、完整性或保密性）
`--services-critical <yes/no>`	否	是否影响关键或重要职能
`--economic-impact <num>`	否	预估经济影响（欧元）
`--json`	否	以JSON格式输出结果
`--generate-template`	否	生成提交给主管机构的事件通知模板
`--output <file>`	否	将报告或模板导出到指定文件路径

输出： 根据第18条标准的事件严重程度评分、重大事件判定、报告截止期限计算（初始4小时、中期72小时、最终1个月）及通知模板生成。

最后更新：2026年3月 法规参考：EU 2022/2554 适用日期：2025年1月17日

dora-compliance-expert

Original

Translation

DORA Compliance Expert

DORA合规专家

Table of Contents

目录

DORA Overview

DORA概述

Scope

适用范围

Financial Entities in Scope

适用的金融实体

Proportionality Principle

比例原则

Critical ICT Third-Party Service Providers

关键ICT第三方服务提供商

Five Pillars Deep-Dive

五大支柱深度解析

Pillar 1: ICT Risk Management (Chapter II, Articles 5–16)

支柱1：ICT风险管理（第二章，第5-16条）

Governance and Organization (Article 5)

治理与组织（第5条）

ICT Risk Management Framework (Article 6)

ICT风险管理框架（第6条）

ICT Systems, Protocols, and Tools (Article 7)

ICT系统、协议与工具（第7条）

Identification (Article 8)

识别（第8条）

Protection and Prevention (Article 9)

保护与预防（第9条）

Detection (Article 10)

检测（第10条）

Response and Recovery (Article 11)

响应与恢复（第11条）

Backup and Restoration (Article 12)

备份与恢复（第12条）

Learning and Evolving (Article 13)

学习与演进（第13条）

Communication (Article 14)

沟通（第14条）

Pillar 2: ICT-Related Incident Management (Chapter III, Articles 17–23)

支柱2：ICT相关事件管理（第三章，第17-23条）

Incident Management Process (Article 17)

事件管理流程（第17条）

Classification of ICT-Related Incidents (Article 18)

ICT相关事件分类（第18条）

Reporting Obligations (Article 19)

报告义务（第19条）

Voluntary Reporting (Article 19(2))

自愿报告（第19(2)条）

Centralized Reporting (Article 20)

集中报告（第20条）

Pillar 3: Digital Operational Resilience Testing (Chapter IV, Articles 24–27)

支柱3：数字运营韧性测试（第四章，第24-27条）

General Requirements (Article 24)

一般要求（第24条）

Basic Testing (Article 25)

基础测试（第25条）

Advanced Testing — Threat-Led Penetration Testing (Article 26)

高级测试——威胁导向渗透测试（TLPT，第26条）

Purple Teaming

紫队协作

Pillar 4: ICT Third-Party Risk Management (Chapter V, Articles 28–44)

支柱4：ICT第三方风险管理（第五章，第28-44条）

General Principles (Article 28)

一般原则（第28条）

Preliminary Assessment (Article 28(4))

初步评估（第28(4)条）

Key Contractual Provisions (Article 30)

关键合同条款（第30条）

Register of ICT Third-Party Arrangements (Article 28(3))

ICT第三方安排登记册（第28(3)条）

Exit Strategies (Article 28(8))

退出策略（第28(8)条）

Oversight Framework for Critical ICT Third-Party Providers (Articles 31–44)

关键ICT第三方提供商监督框架（第31-44条）

Concentration Risk (Article 29)

集中度风险（第29条）

Pillar 5: Information Sharing (Chapter VI, Article 45)