情報管理技術士 学習ノート
← 一覧へ
セキュリティ・個人情報
#DORA#디지털 운영 복원력#ICT 위험관리#금융 보안#제3자 위험#CTPP#Regulation (EU) 2022/2554
最終更新 · 2026-09-29

EU DORAに基づく金融デジタル運用レジリエンス管理

1. 概要

A. 定義と背景

デジタル運用レジリエンス法（Digital Operational Resilience Act、DORA）は、金融機関がICTリスクを統合的に管理し、障害やサイバー攻撃下でもサービスを継続・復旧し、ICT第三者への依存を統制するよう求める欧州連合の金融分野規則（Regulation (EU) 2022/2554）である。

金融サービスは相互に接続されているため、決済、取引、信用、保険金支払い、市場インフラにおける一事業者のICT障害が、多数の機関や顧客へ波及する可能性がある。 クラウド、データセンター、重要ソフトウェア事業者への依存が高まると、個々の金融機関のセキュリティ統制だけでは、エコシステム全体の集中リスクや連鎖障害を十分に管理できない。 DORAはこの課題に対し、セキュリティ事故対応をデジタル運用レジリエンスのライフサイクル管理へ拡張する。

DORAは2022年にRegulation (EU) 2022/2554として制定され、2025年1月17日から適用されている。 ICTリスク管理、重大なICT関連事故の報告、デジタル運用レジリエンステスト、ICT第三者リスク管理、情報共有を相互に補完する領域として統合する。 技術士は法務チェックリストだけで捉えず、業務サービス・資産・供給者・復旧目標・証跡を結ぶ運用アーキテクチャとして理解すべきである。

B. 目的と適用の考え方

DORAにおけるレジリエンスは、障害が一切発生しない状態を意味しない。 予防が失敗しても検知・対応・復旧でき、顧客への影響を許容範囲に抑え、事後の教訓から統制を改善できる能力を意味する。 情報セキュリティ、事業継続、ITサービス管理、調達・委託管理は、同じ重要業務サービスを基準に整合させる必要がある。

適用範囲には銀行、決済機関・電子マネー機関、投資会社、保険会社、市場インフラなど幅広い金融機関が含まれる。 事業体の種類と例外は規則第2条を基準に判定する。 金融機関にサービスを提供するICT事業者がすべて同一の直接義務を負うわけではない。 金融機関は供給者リスクを管理し、欧州監督機関（ESA）が別途指定した重要ICT第三者サービス提供者（CTPP）は、EUレベルの監督フレームワークの対象となる。

欧州域外の組織も、EU金融機関やそのICTサプライチェーンにサービスを提供する場合、契約、リスク管理、監査証跡、事故通知、復旧要件の影響を受け得る。 韓国企業は直接適用の有無にかかわらず、顧客からのセキュリティ要件、事故通知、復旧証拠の提示に備える必要がある。 域外事業者の法的地位と具体的義務は契約当事者や適用条件に左右されるため、法律専門家と管轄監督当局の案内を確認する。

2. DORA参照構造とレジリエンス管理

DORA対応は、条文を部門へ割り当てるだけでなく、重要業務サービスから技術資産・供給者までの依存関係を可視化することから始める。 業務影響分析により、許容停止時間、許容データ損失、顧客・市場への影響、復旧優先順位を定める。 これらをICT資産台帳、リスクシナリオ、統制、テスト、事故報告、復旧計画へ結び付けると、各統制がどの業務成果を保護するか説明できる。

flowchart TB
  A["重要業務サービス・業務影響分析"] --> B["ICT資産・データ・供給者の依存関係"]
  B --> C["ICTリスク管理フレームワーク"]
  C --> D["保護・検知・対応・復旧の統制"]
  D --> E["事故分類・報告・顧客連絡"]
  D --> F["レジリエンステスト・改善"]
  B --> G["第三者リスク・契約・再委託管理"]
  E --> H["経営層レビュー・是正措置"]
  F --> H
  G --> H
  H --> C

A. ICTリスク管理とガバナンス

金融機関はICTリスクを全社的リスク管理の一部として扱い、責任、方針、役割、報告経路を明確にする。 取締役会・経営陣の責任は技術部門への委任によって消えるものではなく、重要業務サービスのレジリエンス目標を承認し、実行状況を監督する。 実務ではサービスオーナー、セキュリティ、ICT運用、リスク管理、事業継続、調達、内部監査が共通の用語と証跡を用いる必要がある。

リスク管理フレームワークは、業務機能とそれを支える情報・ICT資産を特定し、脅威・脆弱性・影響を評価したうえで、保護・検知・対応・復旧の統制を選定する反復プロセスである。 資産台帳はサーバーやネットワークだけでなく、データフロー、ID・認証、ソフトウェア構成要素、クラウドリージョン、外部委託運用、バックアップ復旧経路を含める。 重要な構成変更、企業統合・買収、供給者の変更後には、依存関係とリスク評価を再確認する。

統制は機密性・完全性・可用性に加えて、復旧可能性と意思決定速度も扱う。 マルチリージョン構成は地域障害に有効だが、同じ認証情報、制御プレーン、データ破損の影響を受けるなら独立した復旧手段ではない。 各リスクシナリオについて、予防、検知信号、隔離、代替運用、復旧確認が連携しているか検証する。

B. 事故管理と報告

事故対応は技術アラートと業務影響を結び付けることから始まる。 同じサーバー障害でも、社内開発環境の短時間の遅延と、決済・取引機能の長時間停止では、重大度、報告経路、顧客影響が異なる。 金融機関は分類基準と責任者を定め、閾値を超えた事象を迅速に上位対応組織と経営陣へエスカレーションする。

DORAは重大なICT関連事故と重大なサイバー脅威の処理・報告を標準化する。 分類には、影響を受けた顧客・取引・サービス、継続時間、地理的範囲、データ完全性、経済的影響を、規則および技術基準に沿って反映する。 初報、中間報、最終報に向けて事実・時系列・根本原因・対応措置・復旧状況を記録するが、初期の不確かな情報を確定事実として報告してはならない。

対応にはセキュリティ監視、サービス管理、業務責任者、法務・コンプライアンス、プライバシー担当、供給者、監督当局への連絡窓口が関わる。 供給者契約には事故通知期限、ログ・証跡保全、調査協力、下位供給者への通知、復旧支援を含め、報告義務を実行可能にする。 事故終結後は根本原因への対策責任者と期限を定め、類似サービスや供給者にも教訓を適用する。

C. デジタル運用レジリエンステスト

テストは方針の存在ではなく、実際の業務条件で統制が機能するかを検証する。 テスト強度はサービスの重要度とリスクに比例させ、基本点検・脆弱性評価からシナリオテスト、復旧訓練、独立レビューまで設計する。 本番サービスを無用に損なわずに、主要な依存関係、権限、データ経路を反映したテスト環境を用いる。

テスト範囲には、重要資産を支えるICTシステム・アプリケーション、インフラ、データセンター、ネットワーク、人員、第三者サービスが含まれ得る。 復旧訓練ではバックアップ作成の確認にとどまらず、クリーン環境への復元、データ整合性、業務責任者による実際の切替承認を確認する。 発見事項は重大度、業務影響、是正責任者、再テスト条件とともに記録する。

脅威主導型侵入テスト（TLPT）は、最新の脅威情報に基づき重要機能への高度な攻撃を模擬する高強度のテストである。 日常的な脆弱性スキャンとは異なり、すべての金融機関が一律の周期で実施するものではなく、指定された金融機関が管轄当局の監督下で行う。 範囲、リスク管理、試験者の独立性、供給者の参加、結果共有は、関連規則・技術基準・監督当局の指針に従う。

D. ICT第三者リスクとCTPP監督

外部委託はリスクの移転ではなく、リスク曝露の拡大である。 金融機関は事前調査、重要度・集中度評価、契約、継続監視、終了・移行まで、ICTサービスの全ライフサイクルを管理する。 重要業務機能を支えるサービスについては、供給者の代替可能性、データ移行性、再委託、管轄、監査権、復旧依存を事前に評価する。

金融機関はICT第三者との契約関係を登録簿（register of information）に体系的に記録し、機関・グループの各レベルでサービス・供給者・再委託関係を追跡する。 登録簿は単なる調達一覧ではなく、集中リスク、重要機能への依存、代替可能性、監督報告を分析するデータ基盤である。 一貫したサービス識別子と供給者マスターデータにより、記録の分断が報告や影響分析を遅らせることを防ぐ。

CTPPの指定と監督は、各金融機関の供給者リスク管理とは別のEUレベルの監督機能である。 ESAは規則と指定基準に基づいて金融部門全体への重要性や相互接続性を評価し、指定された供給者への監督活動を主監督者（Lead Overseer）が調整する。 ただし金融機関自身の供給者管理責任が監督当局に移るわけではなく、各機関は自らのリスク評価、契約、統制、復旧責任を引き続き負う。

3. 実装アーキテクチャと運用手順

実行可能な対応モデルでは、ガバナンスと技術データフローを一体で設計する。 サービスカタログ、CMDB、データリネージ、契約リポジトリ、リスク管理ツール、ITSM、SIEM、復旧基盤が異なる識別子を使うと、事故やテスト結果を重要業務サービスに結び付けにくい。 共通のサービスID、供給者ID、資産ID、責任者情報が自動化の前提である。

sequenceDiagram
  participant BUS as 業務サービスオーナー
  participant GRC as リスク・規制管理
  participant IT as ICT運用・セキュリティ
  participant V as 供給者管理
  participant TEST as テスト・復旧組織
  BUS->>GRC: 重要サービス・影響許容度を登録
  GRC->>IT: 統制・リスクシナリオを割り当て
  GRC->>V: 供給者・契約・登録簿データを依頼
  IT->>TEST: 復旧シナリオ・範囲を連携
  TEST-->>GRC: 結果・不備・再試験証跡を返却
  IT-->>BUS: サービス状況・復旧影響を報告
  V-->>GRC: 供給者変更・事故・再委託を通知
  GRC-->>BUS: 残余リスク・是正措置の判断を依頼

A. 業務サービス中心のデータモデル

技術資産台帳だけでは、規制遵守やレジリエンス水準を判断できない。 サービス・業務機能・データ・アプリケーション・インフラ・供給者を結ぶ依存関係グラフを構築し、クラウドリージョンや認証サービスの障害がどの顧客業務に影響するか分析する。 各要素に責任者、重要度、復旧目標、データ分類、供給者、契約、テスト結果、最終確認日を関連付ける。

例えば海外送金サービスが顧客チャネル、認証、不正検知、決済ネットワーク接続、クラウドデータベース、外部メッセージングに依存する場合、各コンポーネントの技術復旧だけではサービス全体の復旧を保証できない。 依存関係の順序、手作業による迂回、規制上の制約、顧客連絡を考慮し、業務単位の復旧シナリオを設計する。 業務影響が変われば、技術復旧の優先度と供給者関係の重要度も更新する。

B. 証跡自動化と変更管理

方針、リスク評価、資産台帳、事故記録、テスト結果、供給者契約を証跡カタログで連携すると、監督照会への回答と監査の再現性が向上する。 構成変更、脆弱性状況、バックアップ成功、テスト完了、供給者状況など観測可能な事実は自動収集に向く。 ただし自動スコアだけで残余リスクを承認せず、責任者が業務影響と例外を検討する。

変更管理には業務サービスへの影響、セキュリティ・復旧統制、供給者通知、文書更新、テスト、承認を含める。 例えばデータベースを別リージョン・供給者へ移行する場合、接続設定だけでなく、データ移行、鍵管理、バックアップ復元、遅延、契約上の越境移転条件を再評価する。 重要変更をリリース承認時のレジリエンステストやリスクレビューに結び付けると、規制文書と実運用の乖離を縮小できる。

C. サービス復旧と危機時の意思決定

復旧目標はサーバー単位で任意に決めず、業務影響とリスク許容度から導く。 目標復旧時間（RTO）と目標復旧時点（RPO）は、サービス依存、データ再処理、顧客・市場損失、運用コストを反映する。 業務データ整合性、取引再処理、顧客連絡、照合が完了して初めて技術復旧をサービス復旧と判断する。

危機時には権限を持つ指揮者が、隔離、代替運用、供給者へのエスカレーション、データ復旧、顧客通知の優先順位を決める。 自動化は検知や反復作業を迅速化できるが、取引停止やデータロールバックのような不可逆操作には承認と安全策を設ける。 訓練では意思決定の遅延と承認競合も測定し、技術復旧時間だけを短縮する最適化にとどめない。

4. 関連フレームワークとの比較

DORAはサイバーセキュリティ、事業継続、外部委託統制と重なるが、金融分野のデジタルレジリエンスを直接適用される規則として整合させる点に独自性がある。 国際規格や一般的なセキュリティフレームワークを導入しても、DORAの義務が自動的に満たされるわけではない。 一方、既存統制と証跡をDORA要件に対応付ければ、重複を減らし、規制専用の分断された運用組織を避けられる。

比較軸 DORA ISO/IEC 27001 従来のBCP・DR
主目的 金融分野のICT運用レジリエンス ISMSの継続的改善 障害時の業務継続・復旧
規範の性質 EU法規と関連技術基準 任意の国際規格・認証制度 方針・規格・契約に依存
主な範囲 リスク、事故報告、テスト、第三者、情報共有 情報セキュリティリスクと統制 業務影響、代替手段、復旧
責任の焦点 金融機関の経営陣と機関固有の義務 組織の管理システムと統制責任者 業務・IT復旧責任者
実務上の関係 共通証跡に規制義務を追加 セキュリティ統制の基盤として再利用可能 復旧能力と訓練を結び付ける

この違いは、いずれかのフレームワークが常に優れているという意味ではない。 ISO/IEC 27001は情報セキュリティ管理の体系的運用に強く、BCP・DRは業務中断時の継続計画に重点を置く。 DORAは事故報告、レジリエンステスト、金融機関とICT供給者の関係を監督対象の義務として結び付けるため、既存統制を対応付けて不足を把握するのが現実的である。

A. 業界適用シナリオ

仮想の欧州銀行で大規模なクラウドリージョン障害が発生し、モバイル決済と送金を処理できない状況を考える。 サービス依存関係グラフにより、認証、取引台帳、不正検知、通知の代替経路を把握し、影響許容度に基づき切替・制限運用・復旧の順序を選ぶ。 事故チームは時間別の影響、取引件数、データ整合性、顧客連絡を記録し、供給者は契約に基づき調査、ログ、復旧を支援する。

第二のシナリオは、重要なSaaS供給者の再委託構造が変更される場合である。 銀行は供給者登録簿と重要サービスの依存関係から影響機能を特定し、データ所在、再委託先、監査権、移行支援を再評価する。 直ちに代替できない場合は代償統制と退出戦略を定め、残余リスクを受容する責任者を指定する。

第三のシナリオでは、バックアップは毎日成功するものの、復旧試験で鍵管理サービスが同じ障害ドメインにあり、バックアップを復号できないことが判明する。 バックアップ成功の指標だけではレジリエンスを証明できず、独立した認証情報、鍵の復旧、データ完全性の確認を含む訓練が必要となる。 発見事項を調達条件とアーキテクチャ標準に反映すれば、他のサービスで同じ弱点が繰り返されるリスクを抑えられる。

5. 発展: DORA適用後の監督と運用成熟度

DORAは2025年1月17日から適用されているが、すべての金融機関が同じ規模の統制とテストを実施するという意味ではない。 重要サービス、規模、リスクプロファイル、サービス複雑性に応じて統制強度を説明可能な形で調整し、比例性を考慮する。 小規模機関にも重要サービスの資産、供給者、事故、復旧の責任と統制が必要であり、簡素化は重要リスクを無視する免除ではない。

金融機関自身の契約上のリスク管理と、ESAによるCTPPの直接監督を区別することが重要である。 重要供給者への監督は金融エコシステム全体の集中リスクに対応する一方、各金融機関は自らの供給者評価、選定、契約、業務継続、退出計画に責任を持ち続ける。 2026年現在、ESMAのDORA監督案内は指定手続、主監督者の役割、監督フレームワークの公式情報を提供しているため、最新の指定・監督状況は当該案内と管轄当局の通知で確認する。

監督対応は監査直前の文書収集から、統制が機能している証跡の継続的な収集へ成熟させるべきである。 変更承認、復旧訓練、事故時系列、供給者登録簿の更新が共通のサービス識別子で連携すれば、規制報告と経営判断の両方を支援する。 あらゆるデータを保管することが目的ではなく、証跡設計にもデータ最小化、保存期間、アクセス制御を適用する。

6. 考慮事項と示唆

A. 規制遵守とサービス復旧の統合

文書や方針の整備だけでは運用レジリエンスは高まらない。 実際の重要業務サービスの障害シナリオに基づいて統制と復旧訓練を検証し、弱点を予算・人員・アーキテクチャの改善へつなげる。

B. 比例性と一貫性

規模と複雑性に応じた比例性は必要だが、重要サービスの定義やリスク許容度が組織ごとに大きく異なると、グループ監督と比較が難しくなる。 共通の最小分類体系と統制原則を設け、各機関固有のリスクは拡張管理する階層モデルが望ましい。

C. 供給者集中と退出戦略

複数供給者を導入すれば常にリスクが下がるわけではない。 認証、DNS、ネットワーク接続、管理コンソール、再委託先を共有していれば、複数供給者でも共通障害点に依存し得る。 データ移行、業務再構築、契約終了、人員移行まで代替可能性をテストし、非現実的な退出計画を定期的に見直す。

D. テストの安全性と独立性

侵入テストや復旧訓練では、稼働停止や顧客データの漏えいを避けるため、範囲、権限、中止条件、証跡保護を設計する。 重要システムや供給者が参加する場合は、事前調整、独立性、利益相反の統制が重要であり、発見事項は再テストまで完了させる。

E. 経営責任と現場の権限

経営陣はレジリエンス目標とリスクを承認するとともに、対応者が危機時にサービスを隔離し復旧を開始する実権を持てるようにする。 連絡網、代行者、承認限度、顧客・監督当局への通知責任を訓練し、組織構造上のボトルネックを減らす。

F. データ品質と自動化

資産台帳、供給者登録簿、事故分類、テスト記録が不正確であれば、自動化は誤った報告を速く作るだけである。 データオーナー、更新時期、検証規則を定め、記録システムと証跡保管先の間のリネージを管理する。 自動判断が、責任ある人間の承認や説明可能な例外手続きを置き換えないようにする。

G. 韓国の金融機関・技術企業への対応

EU金融市場と取引する韓国の機関は、法的適用性に加え、顧客の委託・セキュリティ・事故通知要件を契約ごとに把握する必要がある。 技術供給者はセキュリティ証跡、サービス依存、再委託、事故通知、復旧支援能力を製品運用の一部として管理する。 技術士は短期的な文書化で終わらせず、顧客サービス水準、技術負債、運用コストのバランスを反映する段階的ロードマップを提案すべきである。

参考資料

一言まとめ: DORAは金融機関のICTリスク・事故・テスト・第三者依存を業務サービス中心に統合し、障害時にも重要機能を継続・復旧し、エコシステムのレジリエンスを立証できるようにするEU規則である。