dora-compliance-expert by borghei/claude-skills
npx skills add https://github.com/borghei/claude-skills --skill dora-compliance-expert适用于金融领域数字运营韧性法规(欧盟)2022/2554(数字运营韧性法案 — DORA)的工具和指南。
数字运营韧性法案(法规 EU 2022/2554) 为欧盟金融领域的 ICT 风险管理建立了一个全面的框架。该法案于 2023 年 1 月 16 日生效,并自 2025 年 1 月 17 日起适用。
主要目标:
法律性质: 与 NIS2(一项需要成员国转化的指令)不同,DORA 是一项法规 — 无需转化,直接适用于所有欧盟成员国。
与其他框架的关系:
| 框架 | 关系 |
|---|---|
| NIS2 指令 | DORA 是金融领域的特别法;NIS2 作为补充适用 |
| GDPR | 在处理个人数据的 ICT 系统安全方面,DORA 是对 GDPR 的补充 |
| EBA ICT 指南 |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| DORA 取代了之前 EBA 关于 ICT 和安全风险管理的指南 |
| PSD2 | DORA 增强并扩展了 PSD2 的运营韧性要求 |
| MiCA | 加密资产服务提供商同时适用于 MiCA 和 DORA |
| ISO 27001 | DORA 要求可映射到 ISO 27001 控制项;认证有助于合规 |
监管技术标准与实施技术标准:
DORA 由欧洲监管机构(ESAs:EBA、ESMA、EIOPA)制定的详细 RTS/ITS 补充。关键的 RTS/ITS 涵盖:
DORA 适用于 20 种类型的金融实体 及其 关键的 ICT 第三方服务提供商。
---|---|---
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 | 众筹服务提供商 | 投资众筹平台
DORA 根据实体的以下情况按比例适用:
简化的 ICT 风险管理框架 适用于:
ESAs 根据以下标准指定关键的 ICT 第三方服务提供商:
CTPPs 需接受直接监督框架的监管,由主导监督机构(ESAs 之一)负责。
DORA 的基石。金融实体必须建立全面的 ICT 风险管理框架。
管理主体对 ICT 风险管理承担最终责任:
组织要求:
实体必须建立、维护和实施一个健全、全面且有据可查的 ICT 风险管理框架,该框架应:
数字运营韧性战略必须包括:
对 ICT 系统和基础设施的要求:
具体要求:
金融实体必须:
实体必须根据以下标准对事件进行分类:
| 标准 | 描述 |
|---|---|
| 受影响的客户/对手方数量 | 对外部各方的影响规模 |
| 持续时间 | 事件的持续时间 |
| 地理分布 | 受影响的司法管辖区和成员国 |
| 数据丢失 | 数据的可用性、真实性、完整性或机密性 |
| 受影响服务的关键性 | 对关键或重要功能的影响 |
| 经济影响 | 直接和间接的财务成本 |
重大事件 的判定:如果事件达到 RTS 中关于事件分类定义的阈值,则被分类为重大事件。
| 阶段 | 截止时间 | 内容 |
|---|---|---|
| 初次通知 | 分类为重大事件后 4 小时内(或检测后 24 小时内) | 基本事实、初步分类、估计影响 |
| 中期报告 | 初次通知后 72 小时内 | 更新信息、严重程度、根本原因评估、恢复状态 |
| 最终报告 | 中期报告后 1 个月内 | 根本原因分析、完整影响评估、缓解措施、经验教训 |
附加要求:
实体可以自愿报告:
ESAs 制定了事件报告的通用模板和程序,以减少负担并确保一致性。
所有金融实体必须建立、维护和审查一个数字运营韧性测试计划,作为其 ICT 风险管理框架的组成部分。
所有实体必须至少执行:
| 测试类型 | 频率 | 描述 |
|---|---|---|
| 漏洞评估和扫描 | 定期(至少每年一次) | 自动和手动漏洞识别 |
| 开源分析 | 定期 | 开源软件风险评估 |
| 网络安全评估 | 至少每年一次 | 网络架构、配置、流量分析 |
| 差距分析 | 至少每年一次 | 当前控制措施与要求的对比 |
| 物理安全审查 | 定期 | 数据中心、办公室和设施安全 |
| 问卷和扫描软件 | 定期 | 合规检查和配置验证 |
| 源代码审查 | 如适用 | 对内部应用程序进行安全导向的代码审查 |
| 基于场景的测试 | 每年 | 桌面演练、模拟 |
| 兼容性测试 | 根据需要 | 系统更新和变更的测试 |
| 性能测试 | 定期 | 关键系统的负载和压力测试 |
| 端到端测试 | 定期 | 完整业务流程链的测试 |
| 渗透测试 | 至少每年一次 | 模拟攻击测试 |
适用于: 主管当局根据系统重要性、ICT 风险状况和服务关键性确定的实体。
TLPT 要求:
TLPT 方法:
关键规则:
DORA 引入了紫队演练作为一个关键要素:
金融实体必须:
在签订合同安排之前,实体必须:
与 ICT 第三方服务提供商的合同必须包括:
| 条款 | 描述 |
|---|---|
| 明确的服务描述 | 所有服务的完整描述,包括 SLA |
| 位置要求 | 数据处理和存储的位置,包括子处理 |
| 数据保护条款 | 确保可用性、真实性、完整性和机密性的措施 |
| 服务水平承诺 | 定量和定性绩效目标 |
| 协助义务 | ICT 提供商必须协助处理影响实体的事件 |
| 与当局合作 | 提供商必须与主管当局和处置当局合作 |
| 终止权 | 明确的终止权,包括因绩效失败和法规变更 |
| 过渡和退出条款 | 充分的过渡期和有序转移服务的协助 |
| 参与 TLPT | ICT 提供商必须参与实体的威胁导向渗透测试 |
| 审计权 | 完全的访问和审计权,包括对 ICT 提供商的现场检查 |
| 不受限制的监控权 | 持续监控提供商绩效的权利 |
| 退出策略 | 针对关键或重要功能外包的强制性退出策略 |
对于关键或重要功能,适用额外的合同要求:
实体必须维护一个包含以下内容的登记册:
登记册必须在主管当局要求时向其报告。
对于关键或重要功能,实体必须:
ESAs 指定 CTPPs 并指派主导监督机构。监督框架包括:
实体必须:
金融实体可以在彼此之间交换网络威胁情报信息,包括:
实体必须将其参与信息共享安排的情况通知主管当局。
DORA 将处罚设定权授予成员国和主管当局。该法规授权当局实施:
主管当局拥有以下权力:
对于关键的 ICT 第三方服务提供商:
| 月份 | 阶段 | 关键活动 |
|---|---|---|
| 1 | 评估 | 映射 ICT 风险格局,识别适用的 DORA 要求,针对五大支柱进行差距分析 |
| 2 | 框架设计 | 设计 ICT 风险管理框架,定义治理结构,建立策略 |
| 3 | ICT 风险管理 | 实施风险识别、保护、检测和响应程序 |
| 4 | 事件管理 | 部署事件分类,建立报告程序,准备模板 |
| 5 | 第三方风险 | 构建 ICT 第三方登记册,评估关键提供商,更新合同 |
| 6 | 第三方风险(续) | 完成合同更新,制定退出策略,评估集中度风险 |
| 7 | 韧性测试 | 设计测试计划,执行基本测试(漏洞扫描、差距分析) |
| 8 | 高级测试 | 进行渗透测试、基于场景的演练、TLPT 准备(如适用) |
| 9 | 验证 | 内部审计、补救、管理主体报告、持续改进设置 |
根据所有 5 个 DORA 支柱评估组织就绪度,并提供每个支柱的评分。
# 生成评估模板
python scripts/dora_readiness_checker.py --template > assessment.json
# 运行全面就绪度评估
python scripts/dora_readiness_checker.py --config assessment.json
# 仅评估特定支柱
python scripts/dora_readiness_checker.py --config assessment.json --pillars 1 3 4 --json
# 生成 JSON 输出报告
python scripts/dora_readiness_checker.py --config assessment.json --output readiness_report.json --json
功能:
根据 DORA 标准对 ICT 事件进行分类并确定报告义务。
# 交互式分类事件
python scripts/dora_incident_classifier.py --clients-affected 5000 --duration-hours 4 --data-loss yes --services-critical yes --economic-impact 500000
# 从 JSON 输入分类
python scripts/dora_incident_classifier.py --config incident.json --json
# 生成事件通知模板
python scripts/dora_incident_classifier.py --config incident.json --generate-template --output notification.json
功能:
所有 5 个 DORA 支柱的完整实施指南,包含 ISO 27001 控制项映射、金融领域特定要求以及 RTS/ITS 参考。
ICT 第三方登记册模板、合同要求清单、退出策略框架、集中度风险评估方法以及关键提供商监督。
最后更新:2026年3月 法规参考:EU 2022/2554 适用起始日期:2025年1月17日
每周安装次数
1
代码库
GitHub 星标数
29
首次出现
今天
安全审计
安装于
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
Tools and guidance for Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (Digital Operational Resilience Act — 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:
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:
DORA applies to 20 types of financial entities and their critical ICT third-party service providers.
---|---|---
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
DORA applies proportionately based on the entity's:
Simplified ICT risk management framework is available for:
The ESAs designate critical ICT third-party service providers (CTPPs) based on:
CTPPs are subject to the Direct Oversight Framework by the Lead Overseer (one of the ESAs).
The cornerstone of DORA. Financial entities must establish a comprehensive ICT risk management framework.
The management body bears ultimate responsibility for ICT risk management:
Organizational requirements:
Entities must establish, maintain, and implement a sound, comprehensive, and well-documented ICT risk management framework that:
Digital Operational Resilience Strategy must include:
Requirements for ICT systems and infrastructure:
Specific requirements:
Financial entities must:
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.
| 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 may voluntarily report:
The ESAs develop common templates and procedures for incident reporting to reduce burden and ensure consistency.
All financial entities must establish, maintain, and review a digital operational resilience testing program as an integral part of their ICT risk management framework.
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 |
Applicable to: Entities identified by competent authorities based on systemic importance, ICT risk profile, and criticality of services.
TLPT requirements:
TLPT methodology:
Key rules:
DORA introduces purple teaming as a key element:
Financial entities must:
Before entering into a contractual arrangement, entities must:
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 |
For critical or important functions , additional contractual requirements apply:
Entities must maintain a register containing:
The register must be reported to competent authorities upon request.
For critical or important functions, entities must:
The ESAs designate CTPPs and assign a Lead Overseer. The oversight framework includes:
Entities must:
Financial entities may exchange amongst themselves cyber threat intelligence information including:
Entities must notify competent authorities of their participation in information-sharing arrangements.
DORA delegates penalty-setting to Member States and competent authorities. The regulation empowers authorities to impose:
Competent authorities have powers to:
For critical ICT third-party service providers:
| 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 |
Assesses organizational readiness against all 5 DORA pillars with per-pillar scoring.
# 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
python scripts/dora_readiness_checker.py --config assessment.json --output readiness_report.json --json
Features:
Classifies ICT incidents per DORA criteria and determines reporting obligations.
# 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
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:
Complete implementation guidance for all 5 DORA pillars with ISO 27001 control mapping, financial-sector-specific requirements, and RTS/ITS references.
ICT third-party register template, contractual requirements checklist, exit strategy framework, concentration risk assessment methodology, and critical provider oversight.
Last Updated: March 2026 Regulation Reference: EU 2022/2554 Applicable From: January 17, 2025
Weekly Installs
1
Repository
GitHub Stars
29
First Seen
Today
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
xdrop 文件传输脚本:Bun 环境下安全上传下载工具,支持加密分享
28,800 周安装
| 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 |
| 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 |
| 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 |