1 デジタル金融パッケージ（欧州委員会）

EUの金融分野におけるデジタル化を包括的に規律することを目的とした2020年9月24日に欧州委員会が採択した政策パッケージがデジタル金融パッケージになります。これについてのリンクばこちらになります。

このパッケージには、デジタル金融戦略や、暗号資産およびデジタルレジリエンスに関する立法案が含まれており、消費者保護と金融の安定を確保しつつ、消費者が革新的な金融商品にアクセスできる競争力のあるEU金融セクターの実現を目指すものである。このパッケージは、デジタル移行を取り入れた回復を目指すEUの目標を後押しするものである。デジタル金融サービスは、あらゆるセクターにわたって欧州経済の近代化を促進し、欧州を世界的なデジタル分野の主要プレイヤーへと変貌させる一助となる。

欧州委員会は、規制をよりデジタルに親和的で消費者にとって安全なものとすることで、金融セクターにおける革新性の高いスタートアップ企業と既存企業との相乗効果を最大限に活用しつつ、関連するリスクに対処することを目指している。

デジタルファイナンス戦略(Digital Finance Strategy)
パッケージの上位に位置する戦略文書です。(リンクはこちら)。構成としては

1. 背景
2. デジタルイノベーションの動向
3. 私たちの戦略的目標：消費者と企業の利益のためにデジタル金融を受け入れること
4. EU金融セクターのデジタル変革に向けた4つの優先事項
   1. 金融サービスにおけるデジタル単一市場の分断化に対処し、それによって欧州の消費者が国境を越えたサービスにアクセスできるようにするとともに、欧州の金融企業がデジタル事業を拡大できるよう支援することである（4.1）
   2. 消費者の利益と市場の効率性を考慮し、EUの規制枠組みがデジタルイノベーションを促進するよう確保することである（4.2）
   3. データ主導のイノベーションを促進するための「欧州金融データ空間」を構築することであり、これには金融セクター内でのデータへのアクセス強化やデータ共有の促進が含まれる（4.3）
   4. デジタルトランスフォーメーションに伴う新たな課題とリスクに対処することである（4.4）

となっています。これらの項目ごとの行動を抜き出して表にすると以下のようになります。

優先課題	Key Actions（重要行動）	時期
4.1 デジタル単一市場の分断化の解消	マネーロンダリング対策・テロ資金供与対策（AML/CFT）に関する広範なイニシアティブの一環として、顧客のオンボーディングに関する規則の調和を提案する。あわせて、e-IDAS規則の見直しを踏まえ、デジタルIDの相互運用可能な越境的枠組みを実施する。	2021年
	認可・パスポーティング制度のさらなる調和の必要性を検討する。ESAsと協働して欧州イノベーション・ファシリテーター・フォーラム（EFIF）を強化し、官民の協力を促進するEUデジタルファイナンス・プラットフォームを創設する。	—
4.2 デジタルイノベーションを 促進する規制枠組み	資産参照型トークン（いわゆるステーブルコイン）およびユーティリティ・トークンを含む、暗号資産に関する新たなEU法的枠組みを提案する。	戦略と同時 （2020年）
	定期的な見直しを通じ、金融サービス法制に由来するイノベーションへの重大な規制上の障害を除去する。また、既存の金融サービス法制を新技術にどう適用すべきかについて、解釈指針を定期的に提供する。	継続的 （初回2021年）
4.3 欧州金融データ空間の 構築	公開が義務づけられる情報を標準化された機械可読形式で利用可能とするようEU法制を改正し、あわせて公開情報のためのEU出資のインフラを整備する。	—
	監督データに関する戦略を提示する（報告要件の明確化・調和、国際標準および識別子の活用、機械可読形式による報告）。	2021年
	より広範なデータアクセス施策と完全に整合する形で、新たなオープン・ファイナンスの枠組みに関する立法提案を行う。	2022年半ばまで
4.4 デジタル化に伴う 課題とリスクへの対応	デジタルファイナンスのエンドユーザーの保護、金融安定性の確保、EU金融セクターの健全性の保護、および公平な競争条件の確保のため、消費者保護規制および健全性規制について既存の金融サービス法制に必要な調整を提案する。	2022年半ばまで
	デジタル・オペレーショナル・レジリエンスの強化のための新たなEU枠組みに関する提案を行う（＝後のDORA、規則(EU) 2022/2554）。	戦略と同時 （2020年）

このなかで、特にサイバーセキュリティの見地から重要になるのが、4.4 デジタル化に伴う課題とリスクへの対応の中の「デジタル・オペレーショナル・レジリエンスの強化のための新たなEU枠組みに関する提案を行う」ということで、これが、DORA(規則(EU) 2022/2554)ということになります。

2 DORA(規則(EU) 2022/2554)とはなにか

2.0 序

DORA(Digital Operation Resilience Act,デジタル業務レジリエンス法)本体(規則(EU) 2022/2554)というのは、銀行、保険会社、投資会社などの金融機関のネットワークおよび情報システムのセキュリティに関する統一的な規則であって、情報通信技術（ICT）に関連するあらゆる障害や脅威に対して、耐性を持ち、適切に対応し、復旧することを義務付けるものです。

官報のリンクは、こちら。EIOPA(欧州保険・職業年金機構)のDORAページは、こちら。

EIOPAのページは、DORAが規則2022/2554、附随する指令(EU) 2022/2556、そして各種ガイドラインという三層で実施される構造を整理しており、RTS/ITS(技術標準)へのリンク集として最も使いやすい当局ページです。EBA・ESMAにも同種のページがあり、三機関(ESAs)共同でRTS/ITSを策定しています。ESAはEuropean Supervisory Authorities(欧州監督機構)の略です。日本語では「欧州監督当局」とも訳されます。

2008年の金融危機を受けたド・ラロジエール報告書の提言に基づき、2011年1月1日に発足した以下の三機関の総称です。

三機関は、欧州システミックリスク理事会(ESRB)および各国所管当局とともに、欧州金融監督制度(ESFS: European System of Financial Supervision)を構成します。

DORAは、2025年1月17日より適用されています。

構造としては、

第I章 総則

• 第1条 対象事項
• 第2条 適用範囲
• 第3条 定義
• 第4条 比例性の原則

第II章 ICTリスク管理

• 第I節(表題なし)
  • 第5条 ガバナンス及び組織
• 第II節(表題なし)
  • 第6条 ICTリスク管理フレームワーク
  • 第7条 ICTシステム、プロトコルおよびツール
  • 第8条 特定
  • 第9条 保護および予防
  • 第10条 検知
  • 第11条 対応および復旧
  • 第12条 バックアップ方針および手順、復元および復旧の手順および方法
  • 第13条 学習と進化
  • 第14条 情報伝達
  • 第15条 ICTリスク管理ツール、手法、プロセスおよび方針のさらなる調和
  • 第16条 簡素化されたICTリスク管理枠組み

第III章 ICT関連インシデントの管理、分類および報告

• 第17条 ICT関連インシデントの管理プロセス
• 第18条 ICT関連インシデントおよびサイバー脅威の分類
• 第19条 ICT関連の重大なインシデントの報告および重大なサイバー脅威の自主的な通報
• 第20条 報告内容および書式の調和
• 第21条 重大なICT関連インシデントの報告の一元化
• 第22条 監督当局からのフィードバック
• 第23条 信用機関、決済機関、口座情報サービス提供者、および電子マネー機関に関する業務上または決済のセキュリティに関連するインシデント

第IV章 デジタル業務レジリエンス・テスト

• 第24条 デジタル業務レジリエンス・テストの実施に関する一般要件
• 第25条 ICTツールおよびシステムのテスト
• 第26条 TLPTに基づくICTツール、システムおよびプロセスの高度なテスト
• 第27条 TLPTの実施におけるテスターに対する要件

第5章 ICT第三者リスクの管理 ※ここのみアラビア数字。「第V章」への統一を推奨

• 第I節 ICT第三者リスクの適切な管理に関する基本原則
  • 第28条 一般原則
  • 第29条 事業体レベルにおけるICT集中リスクの予備的評価
  • 第30条 主要な契約条項
• 第II節 重要ICT第三者サービス提供者の監督枠組み
  • 第31条 重要ICT第三者サービス提供者の指定
  • 第32条 監督枠組みの構造
  • 第33条 主監督者の任務
  • 第34条 主監督官間の業務上の調整
  • 第35条 主監督官の権限
  • 第36条 連合域外における主監督官の権限の行使
  • 第37条 情報の提供要請
  • 第38条 一般的な調査
  • 第39条 検査
  • 第40条 継続的監督
  • 第41条 監督活動の実施を可能とする条件の調和
  • 第42条 所管当局によるフォローアップ
  • 第43条 監督手数料
  • 第44条 国際協力

第VI章 情報共有の取決め

• 第45条 サイバー脅威情報およびインテリジェンスに関する情報共有の取決め

第VII章 所管当局

• 第46条 所管当局
• 第47条 指令(EU)2022/2555により設立された組織および当局との協力
• 第48条 当局間の協力
• 第49条 金融セクター横断的な演習、情報共有および協力
• 第50条 行政処分および是正措置
• 第51条 行政制裁及び是正措置を課す権限の行使 ※50条と51条で「行政処分」「行政制裁」と訳語が揺れています
• 第52条 刑事罰
• 第53条 通知義務
• 第54条 行政処分の公表
• 第55条 職務上の秘密
• 第56条 データ保護

第VIII章 委任行為

• 第57条 委任の行使

第IX章 経過措置及び最終規定

• 第I節(表題なし)
  • 第58条 見直し条項
• 第II節 改正
  • 第59条 規則(EC)第1060/2009の改正
  • 第60条 規則(EU)第648/2012号の改正 ※訳文では見出しが独立行になっておらず、第59条の本文段落の中に埋没しています
  • 第61条 規則(EU)第909/2014号の改正
  • 第62条 規則(EU)第600/2014号の改正
  • 第63条 規則(EU)2016/1011 ※「の改正」が脱落
  • 第64条 発効および適用

となります。

背景

2008年の金融危機を受けて実施された改革は、主に同セクターの金融安定性を強化するものであった。ICTリスクについては、一部の分野で間接的にしか対処されておらず、EU金融システムの業務レジリエンス、パフォーマンス、および安定性にとって引き続き課題となっていた。

「DORA」として知られる本規則は、技術開発を促進し、金融の安定性と消費者保護を確保することを目的とした、より広範なデジタル金融パッケージの一部である。そのその他の要素には、デジタル金融戦略、暗号資産市場、および分散型台帳技術が含まれる。

詳細については、以下章ごとのポイントをみていきます。

2.1  一般規定

第1条は、対象事項(subject matter)として、法の目的を定めています。具体的には、

　高い水準の共通のデジタル業務レジリエンスを実現するため、本規則は、金融機関の業務プロセスを支えるネットワークおよび情報システムのセキュリティに関する統一的な要件を定める

としています。具体的なものは、

• 情報通信技術（ICT）リスク管理；
•  重大なICT関連インシデントの報告、および重要なサイバー脅威の管轄当局への任意の通報；
• 重大な業務上または決済のセキュリティに関連するインシデントの所管当局への報告；
• デジタル業務レジリエンスのテスト；
•  サイバー脅威および脆弱性に関する情報およびインテリジェンスの共有；
•  ICT第三者リスクの健全な管理のための措置；

となっていて、また、 ICT第三者 サービス提供者と金融機関との間で締結される契約上の取り決めに関する要件、 重要なICT第三者サービス提供者が金融機関にサービスを提供する際の、監督枠組みの確立および運用に関する規則も対象となることが述べられています。

第2条は、適用範囲を示していて 金融機関と呼ばれる事業体(なお、2条2項)として

• 信用機関、決済機関、電子マネー機関、および職業年金機関；
• 口座情報、暗号資産、データ報告、クラウドファンディング、およびICT関連の第三者サービス提供者；
• 投資会社、オルタナティブ投資ファンド、運用会社、信用格付け機関、および重要ベンチマークの管理者；
• 取引・証券化リポジトリ、中央証券保管機関、中央清算機関、および取引所；
• 保険会社、保険媒介者、および再保険事業者。

があげられています。

第3条は、定義規定です。上で述べた「デジタル業務レジリエンス」について

金融事業体が、直接的に、またはICT第三者サービス提供者が提供するサービスの利用を通じて間接的に、当該金融事業体が利用し、かつ金融サービスの継続的な提供とその品質（障害発生時を含む）を支えるネットワークおよび情報システムのセキュリティに対処するために必要な、ICT関連のあらゆる能力を確保することにより、その業務の完全性および信頼性を構築、確保、および検証する能力をいう。

とされています。

あと、興味深い定義としては、

• 「ネットワークおよび情報システムのセキュリティ」(4)-指令（EU） 2022／2555(いわゆるNIS2指令です)の第6条第2項に定義されるネットワークおよび情報システムのセキュリティをいう；
•  「ICTリスク」(5)-ネットワークおよび情報システムの利用に関連して合理的に特定可能なあらゆる状況を指し、それが現実化した場合、デジタル環境または物理的環境において悪影響を及ぼすことにより、ネットワークおよび情報システム、技術に依存するツールまたはプロセス、業務およびプロセス、あるいはサービスの提供のセキュリティを損なうおそれがあるものをいうとなります。
• 「サイバー脅威」(12)-規則（EU）2019／ 881（サイバーセキュリティ法）第2条第(8)項に定義される「サイバー脅威」をいうとなっていて、ネットワーク・情報システム、当該システムの利用者、およびその他の者に対して、損害を与え、機能を妨げ、またはその他悪影響を及ぼしうる、あらゆる潜在的な状況・事象・行為をいうことるなりぇす
• 「サイバー攻撃」(14)とはいかなる脅威アクターによる、資産の破壊、暴露、改ざん、無効化、窃取、または不正アクセス、もしくは不正使用を企図する行為によって引き起こされた悪意のあるICT 関連インシデントをいう。
• 「脅威インテリジェンス」(15)-意思決定に必要な文脈を提供し、ICT 関連インシデントまたはサイバー脅威の影響を軽減するために、関連性があり十分な理解を可能にするよう、集約、変換、分析、解釈、または充実化された情報をいう。これには、サイバー攻撃の技術的詳細、攻撃の責任者、その手口および動機が含まれる。
• 「脆弱性」(16) -資産、システム、 プロセス、または統制における弱点、脆弱性、または欠陥であって、悪用される可能性のあるものをいう
• 「脅威主導型侵入テスト（TLPT）」(17) -真のサイバー脅威をもたらすと見なされる実在の脅威アクターの戦術、技術、手順を模倣し、金融事業者の重要な稼働中の本番システムに対して、管理された、カスタマイズされた、インテリジェンス主導の （レッドチーム）テストを実施する枠組みをいう
• 「ICT第三者リスク」(18)-アウトソーシング契約などを通じて、ICT第三者サービスプロバイダーまたはその下請業者から提供されるICTサービスの利用に関連して、金融機関に生じ得るICTリスクをいう
• 「ICT第三者サービス提供者」(19)-ICTサービスを提供する事業体をいう。
  などがあります。

2.2 第Ⅱ章　ICTリスク管理

零細企業を除く金融機関は、以下を遵守しなければならないとされています。

• ICTリスクの効果的かつ慎重な管理を確保するための内部ガバナンスおよび統制措置を整備すること（5条）
• 経営陣が、関連するすべての取り決めを定義、承認、監督し、その責任を負うことを確保すること（5条）
• 迅速かつ効率的に対応するために必要な戦略、方針、手順、プロトコル、およびツールを備えた、健全かつ包括的で、十分に文書化されたICTリスク管理フレームワークを整備すること（６条）
• 適切かつ信頼性が高く、技術的に強靭で、十分な容量を備えたICTシステム、プロトコル、ツールを使用し、最新の状態に維持すること（7条）
• ICTによって支えられているすべての業務機能、役割、責任を特定・分類し、適切に文書化するとともに、リスクシナリオを見直すこと（8条）
• ICTリスクの影響を最小限に抑えるため、ICTシステムおよびツールのセキュリティと運用を継続的に監視すること（9条）
• 異常を速やかに検知し、潜在的な障害箇所を特定すること（10条）
• 適切な計画、手順、および仕組みを備えた包括的なICT事業継続方針を策定すること（11条）
• バックアップ方針および復旧・回復手順を策定し、文書化すること（12条）
• リソースおよびスタッフを配置し、脆弱性、サイバー脅威、およびICT関連のインシデント（特にサイバー攻撃）を評価し、それらが当該組織のデジタル運用レジリエンスに及ぼす潜在的な影響を分析すること（13条）
• 少なくとも重大なICT関連のインシデントや脆弱性について、顧客、取引相手、および一般市民に開示するための危機コミュニケーション計画を策定すること（14条）

興味深い規定について

上記の規定は、金融機関において、サイバーセキュリティにおけるリスク管理としていわれている事項として一般的に見えます。ですが、具体的にみていくと、興味深い事項も指摘できます。

2.2.1　経営機関の「最終責任」——第5条

５条１項は、

金融機関は、第6条第4項に従い、ICTリスクの効果的かつ慎重な管理を確保し、高水準のデジタル 業務レジリエンスを実現するため、第6条(4)に従い、ICTリスクの効果的かつ慎重な管理を保証する内部ガバナンスおよび統制の枠組みを整備しなければならない。

とされており、さらに第2項(a)号で経営陣がICTリスク管理枠組みに関するすべての措置を定義・承認・監督し、その実施について責任を負うとされると明記します。(b)〜(i)号で予算配分、ICT監査計画の承認、第三者委託方針の承認、報告経路の整備まで列挙されています。これは、日本の取締役の善管注意義務・内部統制構築義務の議論とも同様かと思います。さらに注目すべきは第4項で、

金融機関の経営機関の構成員は、管理されているICTリスクに見合った定期的な特定研修の受講などを通じて、ICTリスクおよびそれが金融機関の業務に与える影響を理解・評価するための十分な知識と技能を積極的に最新の状態に維持しなければならない。

として、経営機関の構成員個人に対し、定期的な研修受講等を通じてICTリスクを理解・評価するための知識・技能を「積極的に最新の状態に維持」する義務を課しています。取締役の個人的な能力維持義務を明文化する例は珍しいとされます。

2.2.2　 ICTリスク管理フレームワーク（6条）と三線モデル

第6条第1項から第3項は、ICTリスク管理枠組みの基本形を定めます。すなわち金融機関は、全体的なリスク管理システムの一環として、健全かつ包括的で適切に文書化されたICTリスク管理枠組みを整備し、ICTリスクに迅速・効率的・包括的に対処しなければなりません(第1項)。枠組みには少なくとも戦略、方針、手順、ICTプロトコルおよびツールを含める必要があり、その保護対象は、ソフトウェア・ハードウェア・サーバーを含むすべての情報資産・ICT資産にとどまらず、施設、データセンター、指定された機密区域といった物理的構成要素・インフラにも及びます(第2項)。ICTリスク管理が論理的セキュリティに限られず物理的セキュリティを包含することを明示した点は、CER指令(Critical Entities Resilience Directive、2022年12月14日))との適用関係(前文および第2条)と対応する重要な立法判断です。そして金融機関は、これらの手段を通じてICTリスクの影響を最小限に抑えるとともに、所管当局の要請に応じ、ICTリスクおよび自社の枠組みに関する完全かつ最新の情報を提供しなければなりません(第3項)。

6条４項では、利益相反を回避するため、ICTリスクの管理・監督責任を統制機能に割り当て、その独立性を確保せよとし、

融事業者は、利益相反を回避するため、ICTリスクの管理および監督の責任を統制機能に割り当て、当該統制機能の適切な独立性を確保しなければならない。金融機関は、「三つの防衛線」モデル、または内部リスク管理・統制モデルに基づき、ICTリスク管理機能、統制機能、および内部監査機能の適切な分離と独立性を確保しなければならない。

明示的に「三線」モデルに言及します。「三線」モデル（three lines of defence）というのは、もともとは第1線は事業運営部門(営業、開発等)でリスクを保有・管理する主体、第2線はリスク管理・コンプライアンス等の中央集権的な統制機能で第1線の実践を促進・監視する主体、第3線は内部監査で経営陣および統治機関に対し独立した保証を提供する主体、という機能・組織単位ベースの整理でした。なお、現在は、IIA(内部監査人協会)は2020年7月に旧モデルを改訂し、名称自体を「The IIA’s Three Lines Model(三つのラインモデル)」(ⅠⅠＡの３ラインモデル ３つのディフェンスラインの改訂 )に変更しています。

また、上記以外にも第6条第8項(b)号において、デジタル業務レジリエンス戦略において、リスク許容水準の設定に加え「ICT障害の影響許容度を分析する」ことを求めていたり、第6条第10項は、ICTリスク管理要件への適合性検証業務をグループ内または外部に委託できるとしつつ、金融機関は「引き続き全面的な責任を負う」と定めていたりすることが注目されます。

2.2.3　　ICT変更管理(9条)

9条は、興味深い規定を含んでいます。特に、9条第4項においては、ICTリスク管理フレームワークの一環として 、金融機関は以下を行うものとするとする項目 のうち、興味深いものとしては、以下があります。

同項(b)号は、適切な技術、手法およびプロトコルを用いて、堅固なネットワークおよびインフラ管理体制を確立することとしたうえで、これに、

サイバー攻撃発生時に影響を受けた情報資産を隔離するための自動化されたメカニズムの導入が含まれる場合がある

としています。

9条第4項(e)号は、ICT変更管理について文書化された方針・手続・統制の実施を求め、すべての変更が「記録、テスト、評価、承認、実施および検証」されることを確保せよとし、末尾で変更管理プロセスは適切な管理ラインによる承認を受けなければならないと定めます。

第9条第4項(f)号は、「パッチおよび更新に関する適切かつ包括的な文書化された方針」の策定義務があるとしています。フロンティアAIのブログにおいてtime-to-patchの短縮(行動計画)、自律的パッチ適用(ENISA)についてふれましたが、金融セクターにおいて、これが文書化されたものとして求められているのが特徴です。

2.2.4 情報伝達

14条1項は、

第6条第1項に規定するICTリスク管理枠組みの一環として、 金融機関は、少なくとも重大なICT関連のインシデントや脆弱性について、顧客や取引相手、ならびに必要に応じて一般市民に対し、責任ある形で開示することを可能とする危機コミュニケーション計画を策定しなければならない。

としており、特に、脆弱性について、顧客や取引相手、ならびに必要に応じて一般市民に対し、責任ある形で開示することが、明らかにされているのは、興味深いです。

2.2.5 その他

第12条 バックアップ方針および手順、復元および復旧の手順および方法 

第12条第3項はバックアップデータの復元には元のICTシステムから物理的および論理的に分離されたシステムを用いよとしています。これは、ランサムウェア対策として実質的な意味を持ものと考えられます。また、第4項の冗長ICT能力の維持義務、第5項の中央証券保管機関に対する二次処理拠点(主拠点と地理的に離れ、異なるリスクプロファイルを有すること)の要求も、規制の具体性の水準を示す例として挙げられます。

第13条 学習と進化

事後検証(post-incident review)の実施と、その結果に基づく変更内容の当局への報告(第2項)、ICT担当上級職員による経営陣への年1回以上の報告(第5項)、上級管理職を含む全従業員への必須研修モジュール(第6項)、そして新技術の導入がICTセキュリティ要件に及ぼす影響の継続的監視(第7項)があります。フロンティアAIが問題となる時代においては、第7項は、生成AIの業務導入がDORA上の既存義務の射程に入ることを示す条文として読むことも可能になります。

2.3 第Ⅲ章 ICT関連インシデントの管理、 分類および報告

第Ⅲ章は、「 ICT関連インシデントの管理、 分類および報告」になります。

「ICT関連インシデント」とは、金融機関によって予期されなかった単一の事象または一連の関連する事象であり、ネットワークおよび情報システムのセキュリティを損ない、データの可用性、真正性、完全性または機密性、あるいは金融機関が提供するサービスに悪影響を及ぼすものをいう；

とされていますが、これに関して金融機関は、以下を行わなければならないとされています。

•  ICT関連インシデントを検知・管理・記録・通知するための措置の定義・確立・実施 → 17条（ICT関連インシデント管理プロセス）。
•  影響を受けた顧客・取引相手の数、継続期間、地理的範囲、データ損失などの基準によるインシデントの分類と影響判定 → 18条（ICT関連インシデントおよびサイバー脅威の分類）。18条1項が分類基準を列挙し、18条3項が重大性の閾値をRTSに委任しています。
• 重大なICT関連インシデントの所管当局への報告と、当局から上位機関への転送 → 19条（重大なICT関連インシデントの報告および重大なサイバー脅威の任意通知）。当局からECB、EBA等への情報提供は19条6項・7項に基づきます。
• 報告様式の調和は20条、単一EUハブの検討は21条、監督当局からのフィードバックは22条が定めます。

2.3.1  管理プロセス(17条)

根本原因の特定・是正義務——第17条第2項

すべてのICT関連インシデントおよび重大なサイバー脅威の記録義務に加え、一貫した監視・処理・フォローアップにより根本原因が特定・文書化され、是正されることを確保する手順の確立を求めます。単発の復旧では足らず、再発防止のための原因分析を組織的プロセスとして制度化する趣旨です。

 経営陣への報告義務——第17条第3項(e)号

重大なICT関連インシデントについては、上級管理職に加えて経営機関(management body)に対し、その影響、対応、および当該インシデントを契機として確立すべき追加的統制措置を説明して報告することを確保しなければなりません。第5条の経営陣の最終責任と対応する規定で、インシデント情報が取締役会に到達することを制度的に担保しています。報告懈怠が取締役の責任論に接続しうる条文です。

2.3.2 分類基準の法定

重要性判断の基準が6項目で法定されています（第18条第1項）。影響を受けた顧客・取引相手の数と重要度、取引金額・件数、評判への影響の有無((a)号)、継続期間とサービス停止時間((b)号)、地理的広がり(特に2以上の加盟国に及ぶ場合)((c)号)、データ損失(可用性・真正性・完全性・機密性)((d)号)、影響を受けたサービスの重要度((e)号)、そして直接的・間接的な費用と損失を絶対的および相対的な観点から評価する経済的影響((f)号)。評判リスクと間接損失を明文の基準に取り込んだ点、そして絶対額と相対比の双方を求める点が特徴です。

第2項は、サイバー脅威を「重大」と分類する基準を別に定めており、現に発生したインシデントと将来の脅威を分けて扱う構造になっています。重大なインシデントとされた場合には、19条の通知義務の対象になります。

2.3.3　報告（19条など）

権限ある当局への通知－NIS2との接続——第19条第1項・第20条

金融機関は、19条第4項に従い、第46条で言及される関連する所管当局に対し、ICT関連の重大なインシデントを報告しなければならないとされています（19条1項）。また、脅威について任意の通知を定めています（19条2項）。

さらに注目すべきは第20条第1項(a)号(ii)の末尾です。報告期限の設定について、DORAとNIS2に基づくインシデント報告の一貫したアプローチを損なわない範囲で異なる期限を反映しうるとし、ESAsがNIS2の文脈で採用されたアプローチから逸脱する場合にはその根拠を示す義務を負うとしています。二つの法制の整合を、立法段階ではなく技術基準の策定段階で、しかも「逸脱には理由づけを要する」という説明責任の形で確保する手法であり、規制設計の技法として興味を引く条文です。

 顧客への通知義務——第19条第3項

重大なICT関連インシデントが顧客の経済的利益に影響を及ぼす場合、認識後不当な遅滞なく、インシデントと軽減措置を顧客に通知しなければなりません。重大なサイバー脅威については、影響を受ける可能性のある顧客に、当該顧客が講じうる保護措置を通知します。当局報告とは別建ての、顧客に対する直接の通知義務です。

なお、ここでGDPR第34条の本人通知との関係(要件・時期・宛先の相違)は、実務では併行検討を要する論点になります。

三段階報告——第19条第4項

DORAのインシデント報告の骨格です。(a)初期通知、(b)当初の状況に著しい変化が生じた場合または対応が変更された場合の中間報告(その後も更新情報が得られるたび、および当局の個別要請があるたびに更新通知)、(c)根本原因分析が完了し、推定値に代わる実際の影響数値が入手可能となった時点での最終報告。具体的な期限は第20条第1項(a)号(ii)に基づくRTSに委ねられています。

実務上重要なのは(c)号の要件で、最終報告は「是正措置が既に実施されているか否かを問わず」提出時期が定まる一方、根本原因分析の完了と実測値の入手を要件とします。当局への説明責任が推定値では完結しないという設計です。

2.3.4　その他

単一EUハブ構想——第21条　インシデント関連報告の一元化

ESAsがECBおよびENISAと協議し、金融機関による重大なICT関連インシデント報告のための単一のEUハブ設立の実現可能性を評価する共同報告書を作成する義務です。検討事項として、利点だけでなく「機密情報の高濃度化に伴うリスク」(第2項(b)号)を明示する点が重要でしょう。報告の一元化は効率的である反面、集約された情報自体が攻撃対象・単一障害点となる——CRAの単一報告プラットフォームやEUVDをめぐる議論と同じ緊張が、DORAでは既に明文化されているわけです。

この報告書ですが、プレスリリース(概要把握用)は、こちら（EBA: https://www.eba.europa.eu/publications-and-media/press-releases/esas-publish-study-feasibility-further-centralisation-major-ict-related-incident-reporting-financial　ESMA: https://www.esma.europa.eu/node/215613 — 2025年1月17日付、）Joint Committee名義。「次のステップ」として、報告書が欧州議会・欧州理事会・欧州委員会に提出され、金融セクターにおける重大ICT関連インシデント報告のさらなる一元化に関する将来の展開のためにその知見が検討されると記されています。

 当局フィードバックと責任の切断——第22条第1項

所管当局は、初期通知・各報告の受領を確認し、実行可能な場合には比例的なフィードバックや大枠の指針(類似の脅威に関する匿名化された情報・インテリジェンスを含む)を提供することができます。もっとも同項末文は、当局のフィードバックを受けたことは金融機関の責任を減じないとして、インシデントの対応と結果について引き続き全面的な責任を負うと定めます。当局の関与が事業者の免責事由に転化することを防ぐ規定で、監督と責任の関係を考える際の重要な手掛かりです。第2項ではESAsが匿名化・集計された年次報告を行い、警告と概要統計を作成する義務が定められています。

適用範囲の拡張——第23条

本章の要件は、信用機関・決済機関・口座情報サービス提供者・電子マネー機関に係る業務上または決済のセキュリティに関連するインシデントにも適用されます。PSD2(第96条)の報告体制をDORAに統合する趣旨の規定で、決済関連の報告義務がDORA体系に吸収されたことを意味します。

2.4 第Ⅳ章 デジタル業務レジリエンスのテスト

2.4.1　これまでの経緯

第Ⅳ章 デジタル業務レジリエンスのテストを定めています。この点について、前文（56）は、

高いレベルのデジタル業務レジリエンスを実現するため、また、関連する国際基準（例：G7の「脅威主導型侵入テストの基本要素」）およびTIBER-EUなどのEU内で適用されている枠組みに沿って、金融機関は、予防、検知、 対応および復旧能力の有効性について、定期的にテストを行い、潜在的なICTの脆弱性を発見・是正すべきである。金融機関のサイバーセキュリティ準備態勢の水準に関して、様々な金融サブセクター間およびセクター内に存在する差異を反映させるため、テストには、基本要件の評価（例：脆弱性評価およびスキャン、オープンソース分析、ネットワークセキュリティ評価、ギャップ分析、物理的セキュリティレビュー、 アンケートやスキャン用ソフトウェアソリューション、実行可能な場合のソースコードレビュー、シナリオベースのテスト、互換性テスト、性能テスト、あるいはエンドツーエンドテスト）から、TLPTを用いたより高度なテストに至るまで、多岐にわたるツールや措置を含めるべきである。（以下略）

とされています。これを具体的に見ていくと、

G7「脅威主導型侵入テストの基本要素」(G7FE-TLPT)

これはG7サイバー専門家グループ(G7 Cyber Expert Group、CEG)が策定し、2018年10月11日、カナダ議長国下でバリにおいて開催されたG7財務大臣・中央銀行総裁会議で採択されたものです。同時に「第三者サイバーリスク管理の基本要素」も採択されています。脅威主導型侵入テストというのは、 Threat-Led Penetration Testingになります。

日本銀行と金融庁も公表に関与しており、日本語版が存在します(公表のについてのｱﾅｳﾝｽﾒﾝﾄはこちら。これは、2016年の「金融セクターのサイバーセキュリティの基本要素」に始まるG7 CEGの「基本要素」シリーズの一つです(他に2017年の実効的評価、2018年の第三者サイバーリスク管理、2020年のサイバー演習プログラム、2025年のReconnection Best Practice等)。英国政府がシリーズを一括して公開しています: https://www.gov.uk/government/collections/g7-cyber-expert-group-fundamental-elements-series

これは事業体に対しては、シミュレーションを通じて悪意あるサイバーインシデントへのレジリエンスを評価するための指針を、当局に対しては、自らの管轄区域でTLPTの活用を検討する際の指針を提供するものです。想定される名宛人は、当局、TLPTを実施する事業体、脅威インテリジェンス提供者、侵入テスト提供者、そして認定・認証提供者の5類型とされ、その適用は法的拘束力を持たない(non-binding)ものと明記されています。もっとも、当局が事業体のサイバーレジリエンス評価にTLPTを組み込むことは想定されており、越境評価に関与する事業体は、TLPT実施前に参加当局のリストを定めるべきだとされます。これは多国籍事業体のTLPT結果の管轄区域を越えた相互承認に関する議論を促し、成果物の共有プロトコルを整備することを目的としています。

脅威インテリジェンスはTLPTプロセス全体の中核的フェーズと位置づけられ、提供者は事業体に焦点を当てたインテリジェンスと偵察を用いて、実在の脅威アクターを模倣した信頼性のある脅威プロファイルを作成します。このプロファイルにはサイバー脅威シナリオが含まれ、レッドチームがテスト計画を策定する基礎となります。

DORA第26条・第27条の基本要素として「相互承認」「脅威インテリジェンス主導」「外部の脅威インテリジェンス提供者」「認定・認証」が上げられていますが、これらは、いずれもこのG7文書に淵源を持ちます。

TIBER-EU

成立と性格——Threat Intelligence-based Ethical Red Teaming(脅威インテリジェンスに基づく倫理的レッドチーミング)の略で、ECBとEU各国中央銀行が共同で策定し、ECB政策理事会の承認を経て2018年5月に公表されました (発音的には、ˈtaɪ.bərです(Introduction to the TIBER BE Framework))。事業体の重要機能または主要機能(CIF)と、それを支える人・プロセス・技術という基盤システムに対し、管理された、個別設計の、インテリジェンス主導のレッドチームテストを実施し、実在の脅威アクターの戦術・技術・手順(TTP)を模倣するものです。ECBの説明のページはこちら。 英国のCBEST、オランダのTIBER-NLを範としています。

欧州および各国の当局が金融機関等と協働し、高度なサイバー攻撃へのレジリエンスをテスト・改善するプログラムを構築できるようにします。当局、事業体、脅威インテリジェンス提供者、レッドチーム・テスターがどう協働すべきかについての包括的な指針を示し、必須要件に加えて各法域の事情に応じて調整可能な任意要件も含んでいます。

オーストリア、ベルギー、チェコ、デンマーク、フィンランド、フランス、ドイツ、アイスランド、アイルランド、イタリア、リヒテンシュタイン、ルクセンブルク、マルタ、オランダ、ノルウェー、ポルトガル、ルーマニア、スロバキア、スペイン、スウェーデンで採用され、ECB自身およびECB銀行監督でも実施されています。各国のTIBERサイバーチームが自国の事業体とテストを実施し、複数法域で活動する事業体は複数のTIBERサイバーチームによる共同テストに参加できます。

2025年2月11日、ユーロシステムはTIBER-EUフレームワークを、DORAのTLPTに関する規制技術基準(RTS)と整合させるために改訂しました。改訂版は、DORAのTLPTを質的に高く、統制された安全な方法で、EU全域で統一的なアプローチにより実施する方法についての詳細な指針を含んでいます。用語も改められ、テストを調整する内部グループの名称が「ホワイトチーム」から「コントロールチーム」に変更されるなど、DORAとの語彙の統一が図られました。

さらに2025年11月21日、ECBはDORAに基づきTLPT対象として特定された重要機関(significant institutions)についてTIBER-EUをどのように採用・実施するかを定めるガイドを公表しました。DORA第26条・第46条により、ECBは重要機関にとっての所管当局かつTLPT当局(TLPTA)であり、TLPTの運用化について最終的な責任を負うためです。

注目すべきは、TIBER-EUがもともと任意の枠組みであった点です。金融機関は参加するか否かを選択できました。DORAの適用開始(2025年1月17日)により、対象となる金融機関にはTLPTが法的義務となり、TIBER-EUは事実上、その法的要件を満たすための公式な方法論となりました。DORA前文第58項が、TIBER-EUの実施を通じて所管当局が蓄積した専門知識の活用を語り、加盟国が単一の公的機関をTLPT責任機関として指定できるとしているのは、この移行を制度的に受け止めるための規定です。

2.4.2 概要

零細企業を除く金融機関は、以下を遵守しなければならないとされています。

• 必要な評価・テスト・方法論・実務・ツールを備えた、健全かつ包括的なテストプログラムの策定・維持・見直し → 24条（一般的要件）。個別のテスト手法とその頻度（重要機能を支えるICTシステムは少なくとも年1回）は25条が規定します。
•  少なくとも3年ごとの脅威主導型ペネトレーションテスト（TLPT）の実施 → 26条1項。リスクプロファイルと業務状況を踏まえた対象範囲の設定は26条2項・3項によります。
• 認定を受け、必要な専門知識と適性を有し、職業賠償責任保険に加入したテスターの使用 → 27条1項。内部テスターの使用条件は27条2項が別途規律しています。

2.4.3 第24条——テストプログラムの一般要件

零細企業を除くすべての金融機関に、デジタル業務レジリエンス試験プログラム(digital operational resilience testing programme )の策定・維持・見直しを義務付けます(24条1項)。目的は、ICT関連インシデントへの対応準備態勢の評価、レジリエンス上の弱点・不備・ギャップの特定、そして是正措置の速やかな実施です。プログラムはICTリスク管理枠組みの一部と位置づけられます。

実施上の要件として、①第4条第2項の比例性基準を考慮したリスクベース・アプローチ(ICTリスク環境の変化、現に晒され又は晒されうる特定のリスク、情報資産・提供サービスの重要度等を勘案)、②内部・外部を問わず独立した当事者によるテストの実施(内部テスターの場合は十分なリソース配分と、設計・実施の全段階における利益相反の回避)、③発見された問題の優先順位付け・分類・是正の手順および完全な是正を確認する内部検証手法の確立、④重要または主要な機能を支えるすべてのICTシステム・アプリケーションについて、少なくとも年1回の適切なテストが定められています。

2.4.4 第25条——ICTツール・システムのテスト(基本テスト)

第24条のデジタル業務レジリエンス試験プログラムに含めるべきテスト手法として以下の手法が列挙されています(25条1項)。前文(56)が「基本要件の評価」と呼ぶ層に対応します。

• 脆弱性評価およびスキャン、
• オープンソース分析
• ネットワークセキュリティ評価
• ギャップ分析
• 物理的セキュリティレビュー
• アンケートおよびスキャン用ソフトウェアソリューション
• 実行可能な場合のソースコードレビュー
• シナリオベースのテスト
• 互換性テスト
• 性能テスト
• エンドツーエンドテスト
• および侵入テスト

です。

加えて第2項は、中央証券保管機関および中央清算機関に対し、重要・主要機能を支える新規・既存のアプリケーションおよびインフラ構成要素、ならびに当該機能を支えるICTサービスについて脆弱性評価の実施を義務付けます。

第3項は零細企業について、リスクベース・アプローチと戦略的計画を組み合わせ、リソースの規模・所要時間と、緊急性・リスクの種類・重要度等とのバランスを図ることを求める緩和規定です。

2.4.5 第26条——脅威主導型侵入テスト(TLPT)による高度テスト

頻度と対象(第1項・第8項)——第16条第1項の簡素化枠組み対象事業体および零細企業を除き、第8項に基づき所管当局から特定された金融機関は、少なくとも3年ごとに脅威主導型侵入テスト(TLPT)を実施しなければなりません。

当局はリスクプロファイルと業務状況に応じて頻度の増減を要請できます。特定の判断基準は、(a)当該機関のサービス・活動が金融セクターに与える影響の程度、(b)金融安定性への懸念(EUレベル又は国内レベルにおけるシステミックな性質を含む)、(c)特定のICTリスクプロファイル、ICT成熟度、関連する技術的特徴、の三つです。

範囲(第2項)——テストは重要機能・主要機能の一部又は全部を対象とし、実稼働システム(production systems)上で実施しなければなりません。金融機関は対象機能を評価して範囲を画定し、その範囲は所管当局の検証を受けます。前文第59項が明らかにしたとおり、単一のテストで全ての重要機能を網羅する義務はありません。

ICT第三者サービス提供者の関与(第3項・第4項)——提供者が範囲に含まれる場合、金融機関はその参加を確保するために必要な措置・安全対策を講じ、規則遵守について常に全責任を負います。もっとも、当該提供者が規則の適用範囲外の顧客に提供するサービスの品質・セキュリティ又はデータの機密性に悪影響が及ぶと合理的に予想される場合には、書面による合意により、提供者が指定金融機関の指導の下で外部テスターと直接契約し、複数の金融機関が参加する共同テスト(joint testing)を実施することができます。共同テストは参加各機関の脅威主導型侵入テスト(TLPT)とみなされ、参加機関数は対象サービスの複雑さ・種類に応じて適切に調整されます。

リスク管理統制(第5項)——金融機関は、提供者やテスターを含む関係者(所管当局を除く)の協力を得て、データへの影響、資産の損害、自機関・取引相手・金融セクターの重要機能等への混乱リスクを軽減するための効果的な統制を適用しなければなりません。実稼働環境でのテストゆえの当然の要請です。

終了手続と証明(第6項・第7項)——テスト終了後、報告書と是正計画について合意が得られた時点で、金融機関(および該当する場合は外部テスター)は、調査結果の概要、是正計画、要件に従って実施されたことを証明する文書を、指定当局に提出します。当局は相互承認を可能にするための証明書(attestation)を交付し、金融機関はこれを関連する所管当局に通知します。ただし条文は明示的に、証明書にかかわらず金融機関はテストの影響について常に全面的な責任を負うと定めます。前文(61)が「証明は相互承認のみを目的とし、監督当局による承認とみなされてはならない」と述べたことに対応する重要な規定です。

テスターの選択(第8項)——内部テスターを用いる場合は3回のテストごとに外部テスターと契約しなければなりません。SSM規則(規則(EU)1024/2013)第6条第4項に基づき「重要(significant)」と分類される信用機関は、外部テスターのみを使用しなければなりません。

当局体制とRTS(第9項〜第11項)——加盟国は国内のTLPT関連事項について単一の公的機関を指定でき、指定がない場合、所管当局は任務の一部又は全部を金融セクター内の他の国内当局に委任できます。ESAsはECBと合意のうえTIBER-EUフレームワークに従って共同RTS案を策定するものとされ(2024年7月17日提出期限)、特定基準、内部テスター活用の要件、テストの範囲・方法論・アプローチ・結果・終了・是正措置の各段階、そして相互承認促進のための監督協力の類型を規定します。規則本文がTIBER-EUの名を挙げて技術基準の策定を委ねている点が、前回ご説明したソフトローと法の往復運動の条文上の根拠です。

2.4.6 第27条——テスターの要件

共通要件(第1項)——(a)最高の適格性と信頼性、(b)脅威インテリジェンス・侵入テスト・レッドチームテストにおける実証された技術的・組織的能力と専門知識、(c)加盟国の認定機関による認定又は正式な行動規範・倫理枠組みの遵守、(d)TLPT実施に伴うリスクの適切な管理(機密情報の保護と事業リスクへの是正措置を含む)に関する独立した保証又は監査報告書の提供、(e)不正行為や過失のリスクを含む専門職賠償責任保険による適切かつ完全な補償。

(e)号は実務上きわめて重要で、テスターの選定において保険の付保状況が法定要件となることを意味します。事前の統制で吸収しきれないリスクを保険に担わせるという発想が、DORAでは既にテスター要件として明文化されているわけです。

内部テスター使用時の追加要件(第2項)——(a)所管当局又は第26条第9項・第10項に基づく指定機関による承認、(b)当該当局による専任リソースの十分性の確認と、設計・実施の全段階における利益相反回避の確保、(c)脅威インテリジェンス提供者が当該金融機関の外部にあること。

契約上の要件(第3項)——外部テスターとの契約において、TLPTの結果が適切に管理されること、および結果の生成・保存・集計・草案作成・報告・通信・破棄を含むあらゆるデータ処理が金融機関にリスクをもたらさないことを確保しなければなりません。テスト成果物そのものが攻撃者にとって価値ある情報である以上、当然の手当てです。

2.5 第Ⅴ章 ICTにおける第三者リスクの管理

2.5.1 とるべき措置(28条から30条)

ここでは、「第三者リスク」という用語が、

アウトソーシング契約などを通じて、ICT第三者サービスプロバイダーまたはその下請業者から提供されるICTサービスの利用に関連して、金融機関に生じ得るICTリスクをいうをいう

と定義されています。そして、金融機関は、第三者リスクについて、以下の措置を講じなければならないとされています。

第28条——一般原則

責任の非委譲(第1項(a)号)——事業運営のためにICTサービスを利用する契約上の取決めを有する金融機関は、DORAおよび適用される金融サービス法に基づくすべての義務の遵守・履行について常に全面的な責任を負うとされます。第6条第10項、第19条第5項と同じ構造で、外部委託によって規制上の責任が移転しないという原則の明文化です。同項(b)号は比例性原則の適用にあたり、ICT関連の依存関係の性質・規模・複雑性・重要性と、契約上の取決めから生じるリスクを考慮すべきものとします。

戦略と方針(第2項)——簡素化枠組み対象事業体および零細企業を除く金融機関は、第6条第9項のマルチベンダー戦略を考慮しつつ、ICT第三者リスクに関する戦略を策定・定期見直しし、重要・主要機能を支えるICTサービスの利用に関する方針を含めなければなりません。個別・準連結・連結の各ベースで適用され、経営陣が特定されたリスクを定期的に見直す義務を負います。

情報登録簿(第3項)——DORAの目玉の一つです。金融機関は、事業体・準連結・連結の各レベルで、すべてのICTサービス契約に関する情報の登録簿(register of information)を維持・更新し、重要・主要機能を支えるものとそうでないものを区別して文書化しなければなりません。少なくとも年1回、新規契約件数、プロバイダーの区分、契約の種類、提供サービス・機能を所管当局に報告し、当局の要請に応じて登録簿の全部又は一部を提供します。さらに、重要・主要機能を支えるICTサービスの計画中の契約、および既存の機能が重要・主要となった場合には、速やかに当局へ通知しなければなりません。第9項により、ESAsが共通の標準テンプレートをITSで定めます。

なお、これに関する定めは、委員会実施規則(EU) 2024/2956(2024年11月29日)です。2024年12月2日にEU官報に掲載されました。正式名称は「規則(EU) 2022/2554の適用に関し、情報登録簿の標準テンプレートに係る実施技術基準を定める委員会実施規則」で、EUR-LexのELIは http://data.europa.eu/eli/reg_impl/2024/2956/oj です(全EU公用語版あり)。

内容——第3条により、金融機関は事業体レベル又は準連結・連結レベルで、附属書I〜IVに定めるテンプレートを用いて登録簿を維持・更新しなければならないとされています。本体は第1条(定義)、第2条(サプライチェーンにおけるICT第三者提供者のランク付け)、第3条(テンプレートの一般要件)、第4条(データ形式要件)、第5条(登録簿の内容)、第6条(準連結・連結レベルにおける範囲)、第7条(発効)という簡潔な構成です。

契約締結前の義務(第4項)——(a)当該取決めが重要・主要機能を支えるものかの評価、(b)監督上の条件の充足の評価、(c)第29条のICT集中リスクの増大への寄与可能性を含む関連リスクの特定・評価、(d)候補プロバイダーに対するデューデリジェンスの実施と選定・評価の全過程を通じた適切性の確保、(e)生じうる利益相反の特定・評価。

情報セキュリティ基準(第5項)——適切な情報セキュリティ基準を遵守するプロバイダーとのみ契約でき、重要・主要機能に関わる場合は、締結前に最新かつ最高水準の情報セキュリティ基準を採用していることを十分考慮しなければなりません。

監査権の行使(第6項)——アクセス権・検査権・監査権の行使にあたり、リスクベース・アプローチにより監査・検査の頻度と対象領域を事前に決定し、一般に認められた監査基準を遵守します。高度な技術的複雑性を伴う場合は、監査人が実効的な監査を行う適切な技能・知識を有することを確認しなければなりません。

解除権(第7項)——(a)プロバイダーによる適用法令・規制・契約条項の重大な違反、(b)モニタリングを通じて特定された、機能の遂行に影響を及ぼしうる状況(取決め又はプロバイダーの状況に影響する重要な変更を含む)、(c)プロバイダーの全体的なICTリスク管理、特にデータ(個人データか否かを問わない)の可用性・真正性・完全性・機密性の確保方法に関する証拠に基づく脆弱性、(d)契約条件又は関連状況の結果として所管当局が当該金融機関を効果的に監督できなくなった場合。(d)号は、監督可能性そのものを契約の維持要件とする点で特徴的です。

エグジット戦略(第8項)——重要・主要機能を支えるICTサービスについてエグジット戦略の策定を義務付けます。契約関係の終了が、①自社の事業活動への支障、②規制要件の遵守の制限、③顧客へのサービスの継続性・品質の毀損、のいずれももたらさずに行えることを確保しなければなりません。退出計画は包括的に文書化され、十分に検証・定期見直しの対象となり、代替案の特定、データの切り離しと代替プロバイダーへの安全かつ完全な移行又は社内への再統合を可能にする移行計画の策定が求められます。

第29条——ICT集中リスクの予備的評価

第28条第4項(c)号のリスク評価の一環として、次の点を考慮する義務です。

集中の類型(第1項)——(a)容易に代替できないプロバイダーとの契約か、(b)同一又は密接に関連するプロバイダーとの間で重要・主要機能に関する複数の契約関係を結ぶことになるか。そのうえで、異なるプロバイダーの利用等の代替案について便益とコストを比較衡量し、想定される解決策が自社のデジタルレジリエンス戦略上の事業ニーズ・目標に合致するかを検討しなければなりません。

再委託(サブアウトソーシング)(第2項)——契約に再委託の可能性が含まれる場合、特に第三国に拠点を置く下請業者について、便益とリスクを比較衡量します。重要・主要機能に関する契約では、プロバイダーの倒産時に適用される倒産法上の規定と、自社データの緊急復旧に関して生じうる制約を十分考慮しなければなりません。第三国のプロバイダーと契約する場合には、これに加えてEUデータ保護規則への準拠と当該第三国における法の有効な執行を考慮します。さらに、再委託の連鎖が長期化・複雑化した場合に、契約上の機能を完全に監視する自社の能力と、所管当局が自社を効果的に監督する能力にどのような影響が及びうるかを評価しなければなりません。

倒産法の抵触規定と第三国における執行可能性の考慮を明文で求めている点は、契約交渉の実務において法務部門の関与を不可避にする規定です。

第30条——主要な契約条項

形式要件(第1項)——権利義務を明確に配分して書面で定め、契約の全文はSLAを含み、単一の書面文書として作成し、紙媒体又はダウンロード可能で耐久性がありアクセス可能な形式で当事者が利用できるようにしなければなりません。

すべての契約に必要な条項(第2項)——(a)機能・ICTサービスの明確かつ完全な説明と、重要・主要機能を支えるサービスの再委託の許否および条件、(b)サービスの提供地とデータ処理地(地域又は国)およびデータ保存場所、ならびに場所変更予定時の事前通知義務、(c)個人データを含むデータの可用性・真正性・完全性・機密性に関する規定、(d)プロバイダーの破産・破綻処理・事業中断・契約終了時における、金融機関が処理したデータへのアクセス・復旧・返還を容易にアクセス可能な形式で確保する規定、(e)サービスレベルの記述(更新・改訂を含む)、(f)ICTインシデント発生時にプロバイダーが追加費用なし又は事前決定された費用で支援を提供する義務、(g)所管当局および破綻処理当局(その任命者を含む)への全面協力義務、(h)当局の期待に沿った解除権と最低通知期間、(i)第13条第6項に基づく金融機関のセキュリティ意識向上プログラム・研修へのプロバイダーの参加条件。

重要・主要機能を支える契約に追加される条項(第3項)——(a)完全なサービスレベルの説明(正確な定量的・定性的パフォーマンス目標を含み、効果的な監視と不当な遅延なき是正措置を可能にするもの)、(b)サービス提供能力に重大な影響を及ぼしうる事態の通知期間と報告義務、(c)事業継続計画の実施・検証およびICTセキュリティ対策・ツール・方針の整備義務、(d)第26条・第27条のTLPTへの参加と全面協力の義務、(e)継続的監視権——(i)金融機関・指名された第三者・所管当局による制限のないアクセス・検査・監査の権利および関連文書の写しを現場で取得する権利(その実効的行使が他の契約や方針によって妨げられないこと)、(ii)他の顧客の権利が影響を受ける場合に代替的保証水準を合意する権利、(iii)現地検査・監査への全面協力義務、(iv)検査・監査の範囲・手順・頻度の詳細提供義務——、(f)エグジット戦略、特に義務的な適切な移行期間の設定(業務中断リスクの低減又は実効的な破綻処理・再建の確保のためにプロバイダーがサービス提供を継続する期間と、複雑性に応じて他プロバイダーへの移行又は内製化を可能にする期間)。

なお(e)号については、プロバイダーと零細企業である金融機関は、アクセス権・検査権・監査権をプロバイダーが指名する独立した第三者に委任することに合意でき、その場合金融機関はいつでも当該第三者に情報と保証を求めることができます。

標準契約条項(第4項)——交渉に際し、公的当局が特定のサービス向けに策定した標準契約条項の利用を検討しなければなりません。第5項では、ESAsが第2項(a)号の再委託に関する要素を具体化するRTS案を策定します(2024年7月17日提出期限)。

2.5.2 重要なICT第三者サービスプロバイダーの監督枠組み

概要の枠組

この枠組みは、以下のような構造になります。

1. 重要ICT第三者サービスプロバイダー（CTPP）の指定と、主監督機関（Lead Overseer）の任命 → 31条。指定基準は31条2項(下記で詳述)、Lead Overseerの任命は31条1項(b)によります。

重要プロバイダーの指定基準

委任規則（EU）2024/1502に基づき、ICT第三者サービスプロバイダーは、2段階の評価を経て「重要プロバイダー」として指定され、ESAの直接的な監督下に置かれることがあります。

評価の手法（1条）

31条第2項に定められた基準があります。同項は、

第1項(a)に言及する指定は、当該ICT第三者サービス提供者が提供するICTサービスに関して、以下のすべての基準に基づくものとする：

(a) 当該ICT第三者サービス提供者がサービス提供において大規模な運用障害に直面した場合に、金融サービスの安定性、継続性または提供の質に及ぼすシステミックな影響。この際、当該ICT第三者サービス提供者がサービスを提供する金融機関の数およびそれらの金融機関の資産総額を考慮するものとする；

(b) 当該ICT第三者サービス提供者に依存する金融機関のシステミックな性質または重要性 -サービス提供者に依存している金融事業体のシステミックな性質または重要性。これは、以下のパラメータに従って評価される：

(i) 当該ICT第三者サービス提供者に依存しているグローバル・システミック重要機関（G-SII）またはその他のシステミック重要機関 （O-SII）の数が、当該ICT第三者サービスプロバイダーに依存しているか；

(ii) (i)項で言及されたG-SIIまたはO-SIIと他の金融機関との間の相互依存関係。これには、G-SIIまたはO-SIIが他の金融機関に金融インフラサービスを提供している状況も含まれる；

(c) 金融事業体の重要または主要な機能に関連して、当該ICT第三者サービス提供者が提供するサービスへの依存度。この依存関係は、最終的に同一のICT第三者サービス提供者を巻き込むものであり、金融事業体が当該サービスに直接依存しているか、下請け契約を通じて間接的に依存しているかを問わない；

(d) ICT第三者サービス提供者の代替可能性の程度。この際、以下のパラメータを考慮する：

(i) 特定の市場で活動しているICT第三者サービス提供者の数が限られていること、あるいは当該ICT第三者サービス提供者の市場シェア、または（部分的なものであっても）技術的な複雑さや高度さ（独自技術を含む）に起因して、実質的な代替手段 、たとえ部分的なものであっても、特定の市場で活動しているICT第三者サービスプロバイダーの数が限られていること、または当該ICT第三者サービスプロバイダーの市場シェア、あるいは独自技術を含む技術的な複雑さや高度さ、もしくは当該ICT第三者サービスプロバイダーの組織や活動の特異性によるもの；

(ii) 当該ICT第三者サービスプロバイダーから別のICT第三者サービスプロバイダーへの関連データおよびワークロードの部分的または完全な移行に関連する困難。これは、移行プロセスに伴う多額の財務的コスト、時間、その他のリソース、あるいは当該移行を通じて金融機関が被りうるICTリスクの増大またはその他の運用リスクのいずれかによるものである。

と定めています。指定基準については、検討する際

(a)　第一段階として、欧州監督機構は、当該ICT第三者サービス提供者が、第2条第1項、第3条第1項及び第5条第1項に規定される「ステップ1」の各サブ基準をすべて満たしているかどうかを評価するものとする；
(b)　第二段階として、(a)に言及される「ステップ1」のサブ基準をすべて満たすICT第三者サービス提供者について、欧州監督機構は、第2条第5項、第3条第4項、第4条第1項および第5条第5項に言及される「ステップ2」のサブ基準に照らして評価を行うものとする。

DORA31条2項	委任規則の条文	ステップ1（定量）	ステップ2（定性）
(a) 金融サービスの安定性・継続性・質へのシステミックな影響	2条	1.1(金融機関の数の割合)、1.2(金融機関の資産総額に占める割合)	1.3(停止が活動および業務に及ぼす影響の程度、ならびに影響を受ける当該金融機関の数)、1.4(同一の下請業者への依存度)
(b) 依拠する金融機関のシステミックな性格・重要性	3条	2.1(グローバル・システミック重要機関（G-SII）およびその他のシステミック重要機関（O-SII）の数)、2.2(システミックと特定され、かつ、重要または極めて重要な機能を支援する形で、ICTサービスの提供を受けているものの数)	2.3 (相互依存関係にあること)
(c) 支えられる機能の重要性	4条	（なし）	3.1 (当該金融機関の活動にとって極めて重要な性質を有すること)
(d) 代替可能性の程度	5条	4.1(必要な能力を有する代替のICT第三者サービス提供者が存在しない金融機関の割合)、4.2 (他のICT第三者サービス提供者に移行することが極めて困難な金融機関の割合)	（DORA31条2項(d)(i)を参照）

評価は個社単位で行われますが、DORA31条3項に該当する場合はグループ単位で行われ、また前文(3)に基づきICT下請業者も評価対象となり、重要プロバイダーとして指定されうる点は、サプライチェーン管理上の重要な含意を持ちます。

1.  監督フォーラム（Oversight Forum）の設立 → 32条（監督枠組みの構造）。ICTリスク・脆弱性の動向に関する協議とEU全体で一貫した監視アプローチの推進、監督活動の年次評価、CTPPに関する包括的ベンチマークの提出は、いずれも32条の各項に根拠があります。
2.  主たる監督機関の任務と権限 → 33条（Lead Overseerの任務）。CTPPの規則・手続・メカニズムの包括的評価は33条2項が定めます。権限の具体的内容は35条に列挙され、情報請求は37条、一般調査は38条、立入検査は39条、継続的監督は40条、勧告のフォローアップは42条が規律します。EU域外での権限行使（第三国での検査を含む）は36条が根拠です。監督手数料は43条です。
3.  EBA・EIOPA・ESMAによる、ICT第三者リスクに関するEU域外当局との協力 → 44条1項（国際協力）。
4.  EU域外当局との対応状況に関する5年ごとの機密報告書の提出 → 44条2項。欧州議会、理事会および委員会が提出先です。

2.6 第Ⅵ章 情報共有の取り決め

金融機関は、以下の条件を満たす場合に限り、相互にサイバー脅威に関する情報やインテリジェンスを交換することができる(45条)

• デジタル・オペレーショナル・レジリエンスの強化を目的としていること；
• 信頼できるコミュニティ内で行われること；
• 企業の機密情報および個人データを保護し、競争政策の規則を遵守していること。

2.7  第Ⅶ章 以下

第VII章「所管当局」(第46条〜第56条)は、DORAの実施と執行を担う当局の指定、当局間の協力、そして制裁と公表・秘密保持の枠組みを定める部分です。

2.7.1　所管当局の指定(第46条)

第V章第II節の重要ICT第三者サービス提供者に対する監督枠組みに関する規定を損なうことなく、本規則の遵守は、金融機関の類型ごとに、既存の各分野別法令に基づき指定された当局によって確保されます。DORAは独自の監督当局を新設せず、既存の監督体制に乗せるという設計です。

具体的には、信用機関についてはCRD IV(指令2013/36/EU)第4条に基づく当局、SSM規則第6条第4項に基づき「重要」と分類される信用機関についてはECB、決済機関・電子マネー機関・口座情報サービス提供者についてはPSD2第22条に基づく当局、投資会社についてはIFD第4条に基づく当局、暗号資産サービス提供者についてはMiCAに基づく当局、中央証券保管機関についてはCSDR、中央清算機関・取引リポジトリについてはEMIR第22条、取引所・データ報告サービス提供者についてはMiFID II第67条、AIFM・UCITS運用会社・保険会社・保険媒介者・職業年金機関についてはそれぞれの分野別指令に基づく当局、というように、a号からm号までにわたって列挙されています。

2.7.2　NIS2との機関的接続(第47条)

DORAとNIS2の連結を担う条文であり、本シリーズの視点から最も注目に値します。

第1項により、欧州監督機構および所管当局は、金融機関に関する事項についてNIS2第14条のCooperation Group(協力グループ)の活動に参加することができ、また、NIS2の適用対象であり、かつDORA第31条に基づき重要ICT第三者サービス提供者にも指定されている必須・重要事業体に関する事項について、参加を要請することができます。第2項では単一連絡窓口およびCSIRTとの協議・情報共有が、第3項では技術的助言・支援の要請と、効果的かつ迅速な対応を可能とする調整メカニズムの構築が定められています。

第4項はさらに具体的で、こうした協力体制は、両法制の適用が重なる事業体に関する監督・監視活動の調整手続を規定することができ、国内法に従った調査・実地検査の実施と、DORA上の当局とNIS2上の当局との間の情報交換メカニズム(後者が要求する情報へのアクセスを含む)を定めるものとされています。金融規制とサイバーセキュリティ規制が、事業体レベルで重複適用される場面を制度的に処理する規定です。

2.7.3　当局間の協力(第48条)

所管当局は相互に、また該当する場合は主監督者(Lead Overseer)と緊密に協力しなければなりません。所管当局と主監督者は、それぞれの職務遂行に必要な、重要ICT第三者サービス提供者に関するすべての関連情報——特に特定されたリスク、主監督者の監督業務の一環として講じられたアプローチと措置——を、適時に相互に交換する義務を負います。

2.7.4　セクター横断的な演習と情報共有(第49条)

欧州監督機構は合同委員会を通じ、所管当局、BRRD第3条の破綻処理当局、ECB(SRM規則の適用範囲にある事業体についてはSRB)、ESRB、そしてENISAと連携して、金融セクター間で優良事例を共有し、状況認識を高め、セクター横断的に共通するサイバー脆弱性とリスクを特定する仕組みを確立することができます(任意)。あわせて、サイバー攻撃シナリオを織り込んだ危機管理・緊急時対応演習を策定し、伝達経路を整備して、EUレベルでの効果的な協調的対応を段階的に可能にすることが目的とされます。これらの演習は、金融セクターの他の経済セクターへの依存度を検証することもできるとされており、セクター横断的な相互依存を視野に入れた規定です。

第2項では、所管当局・欧州監督機構・ECBが第47条から第54条の職務遂行のため緊密に協力・情報交換し、違反の特定と是正、優良事例の策定・促進、解釈の一貫性の確保、意見の相違が生じた場合の管轄区域を横断した評価のために、監督業務を緊密に調整すべきことが定められています。

2.7.5　制裁と是正措置(第50条・第51条)

所管当局は、監督・調査・制裁のすべての権限を有します。最低限の権限として、①いかなる形式で保持されている文書・データにもアクセスし写しを取得すること、②実地検査・調査の実施(金融機関の代表者の召喚と口頭・書面による説明の徴求、同意する第三者への聞き取りを含む)、③違反があった場合の是正措置・救済措置の要求が挙げられています。

加盟国は、効果的・比例的かつ抑止力のある行政罰・是正措置を定めなければならず、少なくとも、違反行為の中止と再発防止の命令、慣行・行為の一時的または恒久的な中止命令、金銭的性質を含むあらゆる措置、電気通信事業者が保有する通信記録の提供要求(国内法で認められる範囲内)、そして違反者の身元と違反の性質を示す公表声明の発出を可能とする権限を当局に付与する義務を負います。

第5項が実務上重要です。 これらの措置が法人に適用される場合、加盟国は、国内法の条件に従い、経営機関の構成員および国内法上当該違反について責任を負う個人に対しても行政処分・是正措置を適用する権限を当局に付与しなければなりません。第5条の経営陣の最終責任と呼応し、ICTリスク管理の懈怠が役員個人の制裁に接続しうることを示しています。

第51条は権限行使の方法(直接、他当局との連携、委任、司法当局への申請)と、制裁の種類・水準の決定にあたって考慮すべき事情——故意か過失か、違反の重要度・重大性・継続期間、責任の程度、財務力、得た利益または回避した損失、第三者に生じた損失、協力の程度、過去の違反歴——を列挙します。

2.7.6　刑事罰との調整(第52条)

加盟国は、国内法上刑事罰の対象となる違反については行政罰・是正措置に関する規則を定めないことを選択できます(第1項)。刑事罰を選択した場合には、所管当局が刑事捜査・手続に関する具体的情報を受領し、他の所管当局およびEBA・ESMA・EIOPAに同様の情報を提供できるよう、司法当局・検察当局と連携するために必要な権限を有することを確保しなければなりません(第2項)。行政制裁と刑事制裁の並存という、EU法に特徴的な二重の執行構造への手当てです。

2.7.7　公表と秘密保持(第54条・第55条)

制裁決定は、上訴の余地がなくなった後、不当な遅滞なく公式ウェブサイトに公表され、違反の種類・性質、責任者の身元、課された制裁が明示されます。もっとも、個別事案の評価に基づき、身元や個人データの公表が個人データ保護のリスクを含めて不均衡である、金融市場の安定または進行中の刑事捜査を危うくする、あるいは当事者に不均衡な損害をもたらすと判断される場合には、公表の延期、匿名化した公表等の措置を講じなければなりません。公表の掲載期間は5年を超えてはなりません。制裁の公表による抑止効果と、比例性・個人データ保護との調整が図られた規定です。

第55条は職務上の秘密を定め、NIS2上の当局との情報交換を含め、秘密の対象となる情報はEU法または国内法の規定による場合を除き開示してはならないとします。

2.7.8　データ保護(第56条)

欧州監督機構および所管当局は、DORA上の義務・職務の遂行に必要な場合に限り——特に調査、検査、情報提供の要請、通報、公表、評価、検証、査定、監督計画の策定のために——個人データを処理することができ、処理はGDPR(規則(EU) 2016/679)またはEU機関に適用される規則(EU) 2018/1725に従わなければなりません。個人データの保存期間は、監督上の職務が履行されるまで、かついかなる場合も最長15年とされます(係属中の裁判手続がある場合を除く)。