TL;DR

DORA（デジタル・オペレーショナル・レジリエンス法）は、金融セクターのデジタル・レジリエンスを対象としている。あなたが銀行、保険会社、フィンテック、あるいは金融機関にサービスを提供する技術ベンダーであれば、この法律はあなたに影響します。

ICTリスク管理、（TLPTのような）強制的な脅威テスト、第三者によるリスク監視、厳格なインシデント報告などをカバーしている。

2025年1月17日から実施され、油断した場合には厳しい罰則が科される。

DORAスコアカードの概要：

• 開発者の労力：中程度から高程度（セキュアで弾力性のあるコーディングプラクティスの実施、強固な ICT リスク管理の支援、詳細なインシデントログ/報告の有効化、高度な弾力性テストへの参加が必要）。
• ツールコスト：高い（ICTリスクマネジメントツール、高度なセキュリティテストツール（ペンテス ト、TLPT）、堅牢なモニタリング／SIEM、サードパーティリスクマネジメントプラットフォーム、事 業継続／災害復旧ソリューションへの投資が必要）。
• 市場への影響：クリティカル（事実上すべての EU の金融機関とその重要な ICT プロバイダーに対する義務付け。）
• 柔軟性：中程度（規制は主要な柱にわたって要件を定めているが、規模、リスクプロファイル、サービスの性質／複雑性に基づく比例性を認めている）。
• 監査の強度：高い（各国所轄庁および欧州監督当局（ESAs）による監督を受けるコンプライアンス、強固なフレームワーク、テスト結果、インシデント管理能力の実証を伴う）。

DORAとは？

デジタル・オペレーショナル・レジリエンス法（規則（EU）2022/2554）（DORA）は、金融機関のビジネスプロセスを支えるネットワークと情報システムのセキュリティに関する統一的な要件を定めるEUの重要な法律である。DORAは、EU金融セクターのITセキュリティとオペレーショナル・レジリエンスを強化するために特別に設計された、拘束力のある包括的な枠組みを構築するものである。

広範に適用されるNIS2とは異なり、DORAは金融機関（銀行、保険会社、投資会社、決済機関、暗号資産プロバイダーなど）と、それらにサービスを提供する重要なICTサードパーティプロバイダー（クラウドプラットフォーム、ソフトウェアベンダー、データ分析プロバイダーなど）に特化している。

DORAは5つの柱を柱としている：

1. ICTリスク管理：ICTリスクを特定し、保護し、検知し、対応し、回復するための戦略、方針、手順、プロトコル、ツールを含む、包括的で文書化されたICTリスクマネジメントの枠組みを持つことを要求する。管理機関が最終責任を負う。
2. ICT関連インシデント管理と報告：標準化されたテンプレートとタイムラインを用いて、主要なICT関連インシデントを検出、管理、記録、分類し、管轄当局に報告するプロセスを義務付ける。
3. デジタル運用回復力テスト：事業体に対して、脆弱性評価、ネットワーク・セキュリティ評価、シナリオ・ベースのテスト、および重要な事業体については、少なくとも3年ごとに高度な脅威主導型侵入テスト（TLPT）を含む、比例的かつリスクベースのデジタル運用回復力テスト・プログラムを確立することを求める。
4. ICTサードパーティのリスク管理：ICTサードパーティ・サービス・プロバイダーへの依存に関連するリスクを管理するための厳格なルールを課す。これには、契約前のデューデリジェンス、具体的な契約条項（アクセス、監査、セキュリ ティ、出口戦略を含む）、集中リスク評価、および継続的なモニタリングが含まれる。
5. 情報の共有：金融機関間のサイバー脅威情報およびインテリジェンスの自発的な共有を奨励し、全体的な認識とレジリエンスを強化する。

DORAは、ICT問題やサイバー攻撃による深刻な業務中断が発生しても、金融システムが回復力を維持できるようにすることを目的としている。DORAは2023年1月に発効し、金融機関は2025年1月17日までにこれを遵守しなければならない。

なぜ重要なのか？

DORAはEUの金融セクターとそのエコシステムにとって極めて重要である：

• 調和：断片的な各国のアプローチに代わって、EU加盟国全体でデジタル運用の回復力に関する単一で一貫した規則を策定する。
• 金融の安定：ICT事故が個々の金融会社やより広範な金融システムを不安定化させることを防ぐことを目的とする。
• システミック・リスクへの対応：ICTへの依存の高まりと、特に重要な第三者プロバイダーに関する障害によってもたらされる潜在的なシステミック・リスクを認識する。
• 重要なプロバイダーに対する直接監督：欧州監督当局（ESA：EBA、ESMA、EIOPAなど）に対し、指定された重要なICTサードパーティプロバイダー（CTPP）に対する直接的な監督権限を付与する。
• コンプライアンスの義務化：いくつかのフレームワークとは異なり、DORAは規制であり、対象範囲内のすべての事業体に直接適用され、法的拘束力を持つ。
• 強化されたレジリエンス要件：基本的なサイバーセキュリティを超え、強固なテスト（TLPT を含む）、詳細なインシデント管理、厳格な第三者リスク管理を要求する。
• 経営の説明責任：NIS2と同様、ICTリスクを監督する明確な責任を経営組織に課す。

金融機関とその主要な技術サプライヤーにとって、DORAへの準拠は、EUにおける規制当局の承認、市場参入、業務の安定性維持のために不可欠である。

何をどのように実施するか（技術・政策）

DORAの実施には、技術的・政策的措置を含む5つの柱にわたって多大な努力が必要である：

1. ICTリスクマネジメントフレームワーク（第5条-第16条）：
   
   • 方針／戦略経営陣によって承認された、健全かつ包括的なICTリスクマネジメントの枠組みを構築し、維持する。
   • 技術的統制：特定、保護（安全な設定、パッチ適用、ネットワークセキュリティ、物理セキュリティ）、検知（監視システム、異常検知）、対応、復旧（バックアップ、災害復旧計画）といったリスク評価に基づくセキュリティ対策を実施する。これには、ファイアウォール、SIEM、EDR、脆弱性管理、IAMなどのツールが含まれる。
   • 文書化：フレームワーク、リスクアセスメント、コントロールの実施、有効性テストに関する広範な文書を維持する。
2. インシデント管理と報告（第17条-第23条）：
   
   • プロセス主要なICTインシデントの監視、検出、分類（規制技術基準（RTS）に定義された基準に基づく）、管理、記録、報告のプロセスを確立する。
   • テクニカルサポートインシデントを検出し、報告に必要なデータを収集できるロギングおよび監視ツール（SIEM）を導入する。レポートのワークフローを開発する。
3. デジタル・オペレーショナル・レジリエンス・テスト（第24条～第27条）：
   
   • テストプログラム脆弱性評価、オープンソース分析、ネットワークセキュリティ評価、物理セキュリティレビュー、シナリオベースのテスト、互換性テストを含むリスクベースのプログラムを確立する。
   • ツール：脆弱性スキャナー、コンフィギュレーション・スキャナー、DAST、SAST、SCAツールを活用する。
   • 脅威主導型ペネトレーションテスト（TLPT）：重要な事業体に対しては、特定の RTS に基づき、実際の攻撃者をシミュレートした外部の認定テス ターが参加する高度な TLPT を実施する（TIBER-EU のような）。効果的な実施には、成熟した検知・対応能力が必要。
4. ICT第三者リスク管理（第28条-第44条）：
   
   • 戦略と方針：ICTサードパーティプロバイダーに関連するリスクを管理するための戦略と方針を策定する。
   • 情報の登録：すべてのICT第三者サービス契約の詳細な登録簿を維持する。
   • デューデリジェンス：ICT プロバイダーと契約する前に、厳格なセキュリティおよび回復力評価を実施する。
   • 契約要件（第30条）：契約には、セキュリティ基準、監査権、インシデント報告協力、明確なサービス内容、データ処理の場所、出口戦略などを網羅する必須条項を含めるようにする。
   • 重要プロバイダー（CTPP）の監督：指定されたCTPPの直接監督活動において、ESAと協力する。
   • 集中リスク：単一または少数のプロバイダーに過度に依存することに伴うリスクを評価し、管理する。
5. 情報共有（第45条）：
   
   • サイバー脅威のインテリジェンスと情報を共有するための取り決めに（自発的に）参加し、GDPRの遵守を確保する。

実施には、強力なガバナンス、専任のリソース、部門横断的な協力体制（IT、セキュリティ、リスク、法務、調達）が必要であり、多くの場合、テクノロジーや専門知識への多額の投資が必要となる。

避けるべき一般的な間違い

DORAを導入する企業は、このようなよくある誤りを避けるべきである：

1. 実施の遅れ：2025年1月の期限までに、ギャップ分析、フレームワークの開発、テストの実施、第三者契約の是正に必要な大がかりな作業を始めるには時間がかかりすぎる。
2. 範囲と労力の過小評価： DORAの5つの柱にまたがる要求事項の広さを把握できず、コンプライアンスへの取り組みを過小評価した。
3. 単なるIT/セキュリティとして扱う：特にICTリスクフレームワークと第三者リスクマネジメントに関して、リスク、法務、調達、上級管理職が十分に関与していない。
4. 不十分な第三者リスク管理：適切なデューデリジェンスの実施、必須条項付き契約の更新、ICTプロバイダーに関する集中リスクの管理を怠った。
5. 不十分なレジリエンス・テスト： DORA が義務付けている包括的なリスクベースのテスト（必要な場合は TLPT を含む）を実施せず、基本的な脆弱性スキャンのみを実施している。
6. インシデント報告態勢の不備：重大なインシデントを正確に分類し、必要な期限内に報告するための技術的なモニタリングや内部プロセスが欠如している。
7. 他のフレームワークで十分だと思い込むこと： DORAの詳細な要件、特にサードパーティによるリスクと回復力のテストに関する具体的なギャップ分析を実施せずに、既存のISO 27001やその他のコンプライアンスのみに依存すること。

監査役／規制当局が質問するかもしれないこと（デベロッパー・フォーカス）

DORAのコンプライアンスをチェックする監督当局は、広範な権限を持つことになる。開発チームに影響を与える質問は、回復力、設計によるセキュリティ、テスト、インシデント対応に集中する可能性がある：

• (ICT Risk Mgmt）「セキュリティと回復力の要件は、ソフトウェア開発ライフサイクルにどのように組み込まれているか？
• (ICT Risk Mgmt）"開発におけるセキュアコーディングの実践と脆弱性管理の証拠を示す。"
• (インシデント管理）"アプリケーションのロギングは、ICT関連インシデントの検出、分析、報告をどのように促進するか？"
• (アプリケーションに対して、どのようなセキュリティテスト（静的テスト、動的テスト、 コンポーネントテスト）が実施されていますか？最近の結果を提示してください。
• (レジリエンス・テスト）「アプリケーションは、障害や高負荷に耐えられるようにどのように設計されているか（冗長性、スケーラビリティ、フェイルオーバーの仕組みなど）？
• (レジリエンス・テスト）「バックアップからアプリケーションとそのデータを復元するプロセスを実演できますか？
• (サードパーティリスク）「アプリケーションに統合されたサードパーティのソフトウエアコンポーネントやAPIに関連するセキュリティリスクをどのように管理していますか？

規制当局は、文書化されたフレームワーク、ポリシー、手順、テスト結果、インシデントログ、およびレジリエンスがシステムとプロセスに組み込まれていることの証拠を期待するだろう。

開発チームのクイックウィン

DORAへの完全準拠は複雑だが、開発チームは基礎的な実践を通じて貢献できる：

1. アプリケーションログの改善アプリケーションログを強化して、インシデント分析に役立つセ キュリティ関連のイベントやエラーを記録する。ログの一元化を確実に行う。
2. SAST/SCA の統合：CI/CD パイプラインの早い段階で、コードと依存関係の自動セキュリ ティスキャンを組み込む。
3. レジリエンス・パターンの重視：レジリエンスを向上させるコーディング手法を重視する（適切なエラー処理、タイムアウト、再試行、可能であればステートレス化など）。
4. 依存関係を文書化する：アプリケーションの正確なソフトウェア部品表（SBOM）を維持する。
5. 失敗シナリオのテスト：障害条件下（依存関係が利用できない、高負荷など）でアプリケーションがどのように動作するかのテストを含める。
6. 安全な構成：アプリケーションのデフォルト設定が安全であることを確認し、構成設定を適切に外部化する。

これを無視すれば...（コンプライアンス違反の結果）

DORAは管轄当局に重要な監督・執行権限を与えている。コンプライアンス違反は以下のような結果を招く：

• 行政罰／罰金：DORA自体は、具体的な罰金額を全面的に定めてはいないが（加盟国にその実施の一部を委ねている）、DORAが強化する基本的な指令／規制への不遵守や、所轄官庁の命令に従わない場合、多額の罰金（各国の実施状況や具体的な違反行為に応じて、世界売上高の1～2％、または1000万ユーロなどの具体的な金額に達する可能性がある）につながる可能性がある。訂正いくつかの情報源は、ESAが直接監督する重要なサードパーティプロバイダーに対して、1日平均の世界売上高の1％を上限とする定期的な罰金支払いに言及している。金融機関自体に対する罰則は国によって異なるが、相当な額になることが予想される。
• 是正措置：当局は、事業体に対し、行為の停止、特定の是正措置の実施、または特定の情報の提供を命じることができる。
• 公告：当局は、非準拠企業と侵害の性質を特定する公告を発行することができる。
• 認可の撤回：厳しい場合には、金融機関の承認が撤回される可能性がある。
• 管理上の制裁：違反の責任を負う管理組織メンバーに対する行政処分または一時的な出入り禁止処分の可能性。
• 風評被害：コンプライアンス違反やそれに起因する事件の公表は、金融セクターに対する信頼を著しく損なう。
• 操業制限：コンプライアンスが回復するまで、当局は業務に制限を課すことができる。

よくあるご質問

誰がDORAに準拠する必要があるのか？

DORAは、銀行、信用機関、決済機関、投資会社、保険・再保険会社、暗号資産サービス・プロバイダー、クラウドファンディング・プラットフォーム、中央取引所（CCP）、取引保管機関、代替投資ファンドの運用会社（AIFM）、UCITS運用会社、さらに欧州監督当局が指定する重要なICT第三者サービス・プロバイダーなど、幅広いEUの金融機関に適用される。

DORAの遵守期限は？

金融機関は2025年1月17日までにDORAに完全準拠しなければならない。

DORAとNIS2の関係は？

DORAは金融セクターにとって特別なレックスである。つまり、DORAとNIS2の両方が適用される金融機関は、主にICTリスク管理、インシデント報告、レジリエンス・テスト、第三者リスクに関して、DORAのより具体的な要件に従う。NIS2は、DORAでカバーされない側面については、依然として適用される。

DORAにおける脅威主導型侵入テスト（TLPT）とは？

TLPTは、DORA（第26条）に基づき、重要な金融機関に義務付けられているレジリエンス・テストの高度な形態である。これは、事業体の重要な機能や基盤となるシステムを標的とする現実世界の脅威行為者の戦術、技術、手順（TTP）をシミュレートするものである。これはTIBER-EUのようなフレームワークに基づいており、認定された外部テスターを必要とする。

DORAはクラウド・プロバイダーに適用されるのか？

はい、かなり。クラウドサービスプロバイダーはDORAの下ではICT第三者サービスプロバイダーとみなされる。クラウドサービスを利用する金融機関は、厳格な第三者リスク管理要件を適用しなければならない（第28～30条）。さらに、欧州監督当局によって「重要」とみなされたクラウドプロバイダーは、直接的な監督と潜在的な罰則の対象となる（第31～44条）。

DORAの主な柱は何ですか？

核となる5つの柱とは

1. ICTリスク管理
2. ICT関連のインシデント管理と報告
3. デジタル・オペレーショナル・レジリエンス・テスト
4. ICTサードパーティリスク管理
5. 情報共有の取り決め

DORAの資格はありますか？

いいえ、DORA自体は認証スキームを確立していません。コンプライアンスは、各国の管轄当局および欧州監督当局（重要なICTサードパーティプロバイダの場合）によって監督・実施される。事業者は、実施されたフレームワーク、ポリシー、テスト結果、インシデント報告、監督当局との協力を通じてコンプライアンスを実証する。