1. 序論

欧州連合全域で事業を営む大規模な金融グループが、単一の法人として事業を営むことはまれである。それは親会社と扇状に広がる子会社群として、典型的には各加盟国に一社ずつの規制対象会社として事業を営み、各社が自らのライセンスを保持し、各社が自国の監督当局に答え、各社が共通の欧州ルールの上に重なる現地ルールによって形づくられる。その理由は一部は歴史的、一部は規制的、一部は商業的である。ライセンスは国別であり、監督当局は国別であり、現地の名称と現地の貸借対照表を持つ現地エンティティは、認可を受けるにも、監督されるにも、販売の受け皿とするにも容易だからである。グループがほぼ常に集権化するもの、それは情報技術である。同じ基幹バンキングプラットフォーム、同じ契約管理システム、同じデータセンター、同じセキュリティオペレーションセンターを十一回も構築するのは無駄であり、そこでグループはそれらを一度だけ、親会社または専用のグループIT会社に構築し、共有サービスとして各子会社に供給する。事業は現地的であり、配管は中央集権的である。

デジタル・オペレーショナル・レジリエンス法は、実装されるまでは見落としやすい仕方で、この取り決めを横断的に貫く。DORA、すなわちRegulation (EU) 2022/2554は2025年1月17日以降適用されており、その基本単位はグループではなく個々の規制対象エンティティである(DORA, Arts 1–2)。各子会社は、自らICTリスク管理フレームワークを維持し、自らの重大なインシデントを分類・報告し、自らのレジリエンスをテストし、自らのICTサードパーティのレジスターを保持し、自らの取締役会の下でそれらをガバナンスしなければならない(DORA, Arts 5–30)。規制は、子会社が自らの稼働するプラットフォームを構築しておらず、それを変更できないことを意に介さない。義務はそれでもなお子会社のものである。そして、グループが実際にそのプラットフォームを構築したエンティティ、すなわち親会社に目を向けると、DORAがすでにその関係に名を与えていることに気づく。自グループの規制対象エンティティにICTを供給するグループ会社はICTグループ内サービスプロバイダーであり、DORAはほぼあらゆる目的においてそれをサードパーティとして扱う(DORA, Art 3(20))。

二つの問題がそこから生じ、それらが本稿の主題である。第一は、義務の所在と統制の所在とのあいだのミスマッチである。DORAは義務を子会社に課し、統制を持株会社に残す。そして持株会社は、それ自体が規制対象の金融エンティティでなければ、規制の直接の射程の外にあり、子会社がそれに課すことを義務づけられた契約と監督を通じてのみ触れられる。我々はこれをコンプライアンスと統制の非対称性と呼び、第3.1節でそれを解剖する。第二は、ICTを集権化することがリスクを集中させることである。共有コアは単一の点であり、その障害はある一社の子会社の問題ではなく、すべての子会社の問題を同時に意味する。独立し分散可能な事象ではなく、相関した共通要因事象である。そして影響を受けた各子会社は自国の監督当局へ報告しなければならないため、一つの技術的障害が、連合全体にわたる同時多発的な規制報告の扇となる。第3.2節がこれを述べ、第4節がそれをモデル化する。

本稿の貢献は診断と設計であって、法的注釈ではない。我々は二つの構造的問題を率直に述べ、集中の問題については、グループが自らの集権化の度合いがエンティティごとの信頼性とグループ全体の相関リスクをどうトレードオフするかを見られるよう、小さな定量モデルを示す(第4節)。そして、DORAの主要な義務、すなわちレジスターと契約(第5節)、インシデント報告(第6節)、テスト(第7節)、ガバナンス(第8節)が、集権化されたグループにとりわけ何を求めるかを順に検討する。第9節は、グループをそもそも集権化させた効率を保ちつつ規制を満たす目標オペレーティングモデルを提案する。第10節から第12節は、反論に答え、限界を述べ、結論づける。全体を貫く問いは次のものである。各エンティティが自らのICTを統制することを前提とする規制に対して、実際には一つの共有コアがそれらすべてを統制しているとき、グループはいかにしてエンティティごとにコンプライアンスを果たすのか。

2. DORAが求めるもの、そして誰に求めるか

2.1 五つの柱

DORAは金融エンティティのオペレーショナル・レジリエンスを五つの領域に整理しており、グループの問題はその五つすべてに触れるため、一度ここで述べておく価値がある。第一はICTリスク管理(Chapter II, Arts 5–16)である。経営機関が所有し、識別、保護、検知、対応、復旧を網羅するガバナンスと統制のフレームワークであり、一定の小規模なエンティティには、より軽い簡素化されたフレームワークが用意されている(Art 16)。第二はICT関連のインシデント管理と報告(Chapter III, Arts 17–23)である。インシデントを検知し処理するプロセス、その重大度の調和された分類(Art 18)、そして重大なインシデントを所管当局へ、初期報告・中間報告・最終報告という定められたスケジュールで報告する義務(Art 19)である。第三はデジタル・オペレーショナル・レジリエンス・テスト(Chapter IV, Arts 24–27)である。すべてのエンティティに対する定期的なテストのプログラムと、当局が重要と特定したエンティティに対する、少なくとも三年ごとの高度な脅威主導型ペネトレーションテスト(TLPT)である(Arts 26–27)。第四はICTサードパーティリスクの管理(Chapter V, Arts 28–44)であり、ここがグループ構造の最も強く食い込む箇所であって、以下で詳しく扱う。第五はサイバー脅威に関する情報共有(Chapter VI, Art 45)であり、これは任意であって、ここで立ち止まる必要はない。

2.2 エンティティ原則

本稿のすべてを規定するDORAの特徴は、その義務が個々の認可されたエンティティに付随するという点である。銀行グループは認可されておらず、認可されているのはその銀行子会社である。DORAの適用範囲規定は、それが拘束する金融エンティティの種類を列挙しており、そのいずれもがライセンスを保持するエンティティである(Art 2)。その帰結として、コンプライアンスは、そのエンティティ自身の所管当局によって、一社ずつ評価され、執行される。子会社に代わってコンプライアンスを果たすグループのライセンスは存在せず、グループ全体がそのレジリエンスについて答える単一の欧州の監督当局も存在しない。情報レジスターは、グループの次元が明示される唯一の場である。エンティティはそれを自らのレベルだけでなく、グループの一部である場合にはサブ連結および連結のレベルでも保持しなければならず(Art 28(3))、それによって連結エンティティがグループ全体の視界を組み立てる。しかし、コンプライアンスを果たし、ガバナンスし、報告し、テストする義務は、個々の子会社のものであり続け、親会社を上に指し示すことによって果たすことはできない。

2.3 グループ内ICTはサードパーティICTである

本稿を規定する第二の特徴は、グループ内部から供給されるICTに対するDORAの扱いである。子会社が自らの親会社から受けるサービスは内部的なものであり、DORAが外部ベンダーに向ける第三者規制の外にある、と想定するのは自然であろう。DORAはその想定を封じる。それはICTグループ内サービスプロバイダーを、グループの一部であり、主として同じグループのエンティティにICTサービスを提供する事業体として定義し(Art 3(20))、そのようなプロバイダーをサードパーティ規則の内側に取り込む。すなわち、サービスを受ける子会社は、その取り決めを自らのレジスターに記録し(Art 28(3))、必須条項を備えた書面契約の下でそれをガバナンスし(Art 30)、それが生み出す集中を評価し(Art 29)、それが重要または重大な機能を支える場合には、それに対する出口の取り決めを保持しなければならない(Art 28(8))。関係のグループ内という性質は、記録されるべきものであって、適用除外の理由ではない。要するに、親会社がプラットフォームを供給するとき、DORAは親会社をサードパーティプロバイダーとして、子会社をその顧客として読み、外部のクラウドまたはソフトウェアのベンダーの顧客が負うであろうすべての義務を伴わせる。この関係を、DORA準拠の契約ではなくサービスカタログとグループ会社間の付替によってガバナンスされる、純粋に内部的な事柄として扱うグループは、コンプライアンスを果たしていない。

3. 集権的持株会社パターン

図1は本稿が主題とするパターンを描いている。持株会社またはグループIT会社が重要なICTコアを運用し、それを複数の規制対象子会社に供給する。各子会社はそれぞれの加盟国にあり、それぞれの自国の所管当局によって監督される。サービスの矢印はコアから下方へ走り、監督とインシデント報告の矢印は各子会社からその自国の当局へ走る。序論の二つの問題がこの図の中に見てとれる。グループを結びつけているもの、すなわちコアは、規制当局が間接的にしか到達しないエンティティによって供給されており、図の上部での障害はあらゆる枝へ一斉に伝播する一方で、報告は下部のあらゆる当局へと分断される。

3.1 コンプライアンスと統制の非対称性

教科書的なエンティティでは、DORAの義務を負う会社がシステムも運用するため、義務とそれを果たすためのてこは同じ手の中にある。集権化されたグループはそれらを引き離す。子会社は、認可されたエンティティであるがゆえに義務を負うが、コアを運用しておらず、それにパッチを当てることも、そのアーキテクチャを選ぶことも、その復旧目標を設定することも、単独でそれをテストすることもできない。持株会社はコアを運用し、それらのてこをすべて握っているが、それ自体が認可された金融エンティティでなければ——純粋なIT会社または持株会社は通常そうではない——直接のDORA義務を負わない。規制はまさにこれを見越して、それを迂回する。すなわち、子会社を通じて持株会社に到達するのであり、子会社が自ら所有しないシステムに対する義務を果たせるようにするアクセス、監査、協力、インシデント通知、テスト、出口の各権利を、契約によって課すことを子会社に求めるのである(Art 30)。したがって子会社のコンプライアンスは、自らの親会社に対する契約上の力に依存しており、それは行使せねばならないものとしては異例で居心地の悪いものである。

この非対称性には鋭い実務上の切っ先がある。子会社の取締役会は、エンティティのICTリスクについて最終的な責任を負い、その責任を委譲できないとDORAによって告げられる(Art 5(2))。にもかかわらず、そのリスクの大半を担うコアに対する取締役会の実際の影響力は、その取締役会にではなく親会社に報告するグループ機能を通じて流れる。取締役会が単に中央を信頼するなら、法的に委譲してはならないものを実質的に委譲したことになる。真正な監督を行使しようとするなら、気楽なグループ内関係では提供されない情報、保証、権利が必要となる。第9節で展開する設計上の応答は、子会社の取締役会がまさにコアを覗き込み異議を申し立てられるように、その関係に外部ベンダーとのあいだに持つであろう形式性を与えること、そして各取締役会の監督が儀礼ではなく実際のインプットとなるようにグループのフレームワークを構築することである。

3.2 集中リスク

第二の問題は、共有コアが一つの集中であることである。DORAは集中リスクを直接に名指し、各エンティティに対し、契約の前にそれを評価し、継続的にレビューすることを求めており、グループ内の取り決めや代替の難しいプロバイダーに由来するリスクを明示的に含めている(Art 29)。集権化されたグループでは、集中はほぼ全面的である。一つのコア、一つのセキュリティオペレーションセンター、一組の復旧の取り決めが、グループ内のすべての規制対象エンティティに仕える。これを支持する効率の論拠こそが、まさにその危険である。一度構築すれば安く、守るのも容易である同じ単一のプラットフォームは、同時に、それに依存するすべての者がその障害を共有する単一の点でもある。それぞれが自らのICTを運用する連邦的な子会社群であれば障害を一度に一つずつ、独立して被るところを、集権化されたグループはそれらを一緒に被る。障害が共通の原因を持つからである。

これは、安全性およびシステミックリスクの文献が長らく主張してきた、独立した障害と共通要因故障との区別である(Perrow, 1999; Leveson, 2011; ESRB, 2022)。独立した障害は分散する。多くが一斉に倒れる確率は、小さな確率の積であり、消えてなくなるほど小さい。共通要因故障は分散しない。共有された原因が故障すると、その下流にあるすべてが一緒に故障し、グループのレジリエンスは、負荷を分け合うエンティティの数によって改善されるのではなく、最も弱い共有コンポーネントのレジリエンスによって上限を画される。ICTを集中させることは、リスクを子会社全体に分散させるのではない。それは子会社を単一のリスクへと結合する。次節がこの点を精確にする。

4. 相関したグループリスクの最小モデル

このモデルはスケッチであって、仕組みを明示し、グループが自らの集権化の度合いについて推論できるようにするためのものであり、較正されたリスク推定ではない。それは、子会社が単独で被る障害を、グループ全体が一緒に被る障害から切り分け、集権化がどのようにリスクを第一の種類から第二の種類へと動かすかを示す。

4.1 エンティティごとの機能障害

$n$ 社の規制対象子会社からなるグループを考える。そのうちの割合 $c$ ——これを、任意の子会社が重要または重大な機能について持株会社の共有コアに依存する確率として扱う——が、コアに配線されている。$c$ を集権化比率と呼ぶ。ある期間において、共有コアは確率 $p_0$ で重大な障害を被る。これは共通要因事象である。それが起きると、配線されたすべての子会社が同じ瞬間に、同じ理由で機能障害に陥る。コアとは独立に、各子会社自身の現地ICTはその期間に確率 $q$ で故障する。したがって、配線された子会社は、コアまたは自らの現地ICTのいずれかが故障したときに機能障害に陥る。

これは、単一の子会社の取締役会が自らのインシデント記録を見るときに目にする数値である。子会社をよく運用されたコアに配線する集権化は $q$ を下げる傾向がある。専門的な共有プラットフォームは通常、小さな現地のものよりうまく運用されるからであり、それゆえグループが集権化するにつれて $u$ は下がりうる。一社ずつ見れば、集権化はレジリエンスを改善する。そしてこれは効率の論拠の正直な半面である。

4.2 独立から相関へ

グループはそのリスクを一社ずつ経験するのではない。グループにとって、そして規制当局にとって重要なのは、複数の子会社が同時に機能障害に陥る確率である。なぜなら、それこそがシステミックで、国境を越え、同時に報告義務を生じさせる事象だからである。共有コアがなければ、二つの子会社が一緒に倒れる唯一の道は、そのうちの二つが同じ期間にたまたま現地で故障することであり、それは確率が $q^{2}$ のオーダー、すなわち二次的に小さい、独立した事象の偶然の一致である。共有コアがあれば、単一のコア障害が配線されたすべての子会社を一斉に倒すため、同時多発的な複数エンティティ事象の確率は、コア自身の障害確率のオーダーとなる。

ここで括弧は、$n$ 社の子会社のうち少なくとも二つが配線されており、それゆえコアの障害が少なくとも二つを一斉に機能障害に陥れる確率である。要点は正確な形ではなくオーダーである。すなわち、集権化はグループ全体の事象の確率を、小さな現地確率における二次から、コアの確率における一次へと変える。まれにしか故障しないコアであっても、同時多発的な複数エンティティ障害の源としては、子会社の独立したリスクの総和よりもはるかに危険である。その障害が分散されるのではなく共有されるからである。図2は、この確率を二つのアーキテクチャについて集権化比率に対して描く。各子会社が自らのICT上にある連合型グループではほぼゼロで平らに保たれる一方、集権化されたグループのそれは、グループのより多くが共有コアに配線されるにつれて、その基準線から離れて上昇する。

4.3 規制負荷の乗数

共通要因事象には、DORAとグループ構造に固有の第二の帰結があり、それはレジリエンスではなく報告に関わる。各子会社が自らの所管当局に答える別個の規制対象エンティティであるため(第2.2節)、単一のコア障害は一つのインシデント報告を生むのではない。それが機能障害に陥れるすべての子会社から一つずつ、それぞれ異なる当局へ、それぞれその当局の時計に従って、場合によってはその当局の言語で、報告を生む。一つのコア障害によって引き起こされる同時多発的な重大インシデント報告の期待件数は、まさに配線された子会社の期待数である。

そのため、共有コアに完全に配線された十二社の子会社からなるグループは、単一の技術的事象を、DORAの初期報告の期限内に、十二の管轄区域における十二の並行した規制報告へと変える。そのいずれもが同じ根本原因を記述しているのである。この規制負荷の乗数は、いずれか一社の子会社の計画の中では見えず、グループのレベルにおいてのみ見えるようになる。そしてそれはまさに、DORAが単一のエンティティに責任を負わせないレベルである。それは、第9節が構築するグループレベルの調整のための、最も強力な実務上の論拠である。

5. レジスター、集中、契約

DORAのサードパーティに関する章は、集権化されたグループに、使わなければならない三つの道具を与える。そしてそのそれぞれは、正直に適用されれば、上述の問題を隠すのではなく表面化させる。

情報レジスター(Art 28(3))は、ICTサービスに関するあらゆる契約上の取り決めの目録であり、実施技術基準(ITS 2024/2956)が定める標準テンプレートに従って保持され、重要または重大な機能を支える取り決めをそうでないものから区別する。集権化されたグループにとって、レジスターはグループ内依存が否定しえなくなる場である。すなわち、各子会社のレジスターは持株会社を自らの重要サービスのプロバイダーとして列挙し、グループが組み立てなければならない連結レジスター(Art 28(3))は、一つのプロバイダーがグループ全体の重要機能の背後に座していることを、一枚のページの上に示す。レジスターをきちんと記入するグループは、自らの集中を文書化している。グループ内の取り決めを、内部的だからという理屈で除外したい誘惑に駆られるグループは、レジスターの義務に違反すると同時に、まさにレジスターが示すために存在するそのリスクに対して自らを盲目にする。表1は、レジスターが保持される三つのレベルと、それぞれが何のためのものかを示す。

次に集中リスク評価(Art 29)は、レジスターが突きつける問いを問う。すなわち、このプロバイダーが故障したら、あるいは交代させねばならないとしたら、何が起きるのか。外部プロバイダーについては、その答えは代替分析である。グループ内コアについてはそれはより難しい。コアはグループ全体のために一度構築されており、通常、いかなる合理的な時間軸においてもまったく代替不能だからである。DORAは集中を禁じてはいないが、エンティティにそれを見て、それを秤にかけることを求める。そして集権化されたグループの正直な答え、すなわちコアはグループにとっての単一障害点であり、短期的には事実上代替不能であるという答えこそが、規制が同じく求めるレジリエンス投資と出口計画を駆動すべき知見そのものである(Art 28(8))。

契約上の取り決め(Art 30)は、子会社が自ら所有しないコアに対する力を獲得する仕組みである。DORAは、あらゆる取り決めに対する条項の下限と、重要または重大な機能を支える取り決めに対するより長いリストを規定する。すなわち、完全なサービスレベルの記述、サービスとデータの所在地、アクセス・検査・監査の権利、インシデントへの支援義務、当局との協力、監視の権利、再委託の条件(現在はRTS 2025/532によって詳細化されている)、そして文書化された出口戦略である(Arts 28(8), 30(2)–(3))。グループ内という設定は、これらのいずれをも緩めない。以下で展開する設計上の指示は、グループ内契約を、取引相手が独立当事者間の外部ベンダーであるかのように作成することである。なぜなら、それこそが、非対称性がさもなければ子会社の取締役会から奪う権利を、紙の上で取締役会に与える唯一の方法だからである。

6. 一つのインシデント、多数の規制当局

インシデント報告制度は、第4節の規制負荷の乗数が運用上の問題となる場である。DORAはエンティティに対し、ICT関連のインシデントを調和された基準に照らして分類し、それが重大であれば、短い期限で初期報告をもって所管当局に通知し、次いで状況が固まるにつれて中間報告を、次いで根本原因を含む最終報告を行うことを求める(Arts 18–19)。分類基準、しきい値、テンプレートは、Level 2規則によって連合全体で調和されており、これは助けになる。しかし報告は依然として各エンティティの自国の当局へ行き、時計は各エンティティがそれを認識した時点で始まる。

集権化されたグループにとって、単一のコア障害は、それが機能障害に陥れるすべての子会社にとって同時に重大インシデントである。各子会社はそれを分類しなければならず、各社はそれが重大のしきい値を越えるかどうかを判断しなければならず、各社は期限内に自国の当局へ提出しなければならない。子会社が独立に分類し独立に起草すれば、グループは、同じ事象を一貫性なく記述し、異なる時刻に到着し、自らのエンティティがその共有システムに何が起きたかについて見解を異にするのはなぜかという、監督上の明白な問いにグループをさらす、散らばった報告群を生み出す。この失敗様式は過少報告ではなく、不整合な過剰報告である。治療法は報告を集権化することではなく——義務は各エンティティのものであるため、DORAはそれを認めない——事実を集権化することである。すなわち、一つのインシデント分類、一つの根本原因の判定、そしてグループのセキュリティオペレーションセンターから運用される一つの時計であり、整合した事実の核を各子会社自身の提出へと供給し、それを各子会社自身の責任機能が所有し、署名し、自国の当局へ提出するのである。グループは真実を供給し、各エンティティは提出を供給する。第9節がこれを具体化する。

7. 共有コアをテストする

DORAのテスト制度は二つの階層を持ち、グループ構造はその両方を複雑にする。基本の階層は、すべてのエンティティに対し、その規模とリスクに比例した、レジリエンステストのプログラムを実施することを求める(Art 24–25)。高度な階層は、当局がそれに値するほど重要と特定したエンティティに対し、おおむね三年ごとの脅威主導型ペネトレーションテストを求める(Arts 26–27)。集権化されたグループにおいて、テストする価値のある対象は主として共有コアである。重要なシステムと集中がそこにあるからである。しかしテストの義務は、コアを運用していない子会社にある。

同じ共有コアを子会社ごとに別々にテストするのは無駄であり、さらに悪いことにリスクを伴う。グループ全体に仕える本番プラットフォームに対する繰り返しのライブなレッドチーミングは、テスト自体がインシデントを引き起こす確率を増大させるからである。DORAは共有プロバイダーを見越しており、複数のエンティティが同じICTプロバイダーに依存するか、同じグループに属してシステムを共有する場合に、一定の条件の下で、テストをプールするか共同で実施することを認める。そうすることで、共有コアの適切にガバナンスされた一つのテストが、参加するエンティティを満たしうる(Arts 26–27 およびTLPT技術基準)。プールは個々の義務を解消しない。参加する各子会社は依然としてその取り決めの当事者でなければならず、依然としてテストが自らの重要機能を網羅することを確保しなければならず、依然としてその知見に基づいて行動しなければならない。しかしそれは、グループが実際に重要なもの、すなわちコアを、何度も拙くではなく、一度しっかりとテストすることを可能にする。設計上の含意は、グループがコアから外側へ向けてテストを計画し、各子会社の重要機能を共有テストのスコープに入れ、子会社がそのプロバイダー、ここではその自らの親会社に参加を要求できるようにする契約上の権利(Art 30)を保持すべきである、ということである。

8. 上位へ委譲できない説明責任

あらゆる節を貫く糸は、各エンティティの経営機関がそのエンティティのICTリスクについて最終的な責任を負い、この責任は契約によって、あるいは委譲によって手放すことができない、というDORAの主張である(Art 5)。集権化されたグループにおいて、これは運用の現実と最も緊張関係にある規定である。その現実とは、子会社が実質的にICTをグループへ委譲してしまっている、ということだからである。DORAはグループがICTを中央で運用することを禁じてはいない。それが禁じるのは、子会社の取締役会がその取り決めを、責任を負うことをやめる理由として扱うことである。取締役会は、自らが依存するコアについての十分な理解、それがどのように運用され、どのように故障しているかについての十分な情報、そして異議を申し立て、極限においては行動するための十分な契約上およびガバナンス上の力を保持しなければならない。それによって、その法定の責任が名目的ではなく実際のものとなるように。

これは、自然で、たいていは善意から出る集権化の本能に逆らう。その本能とは、子会社の取締役会に技術的な詳細を免じてやり、中央の専門家にそれを処理させるというものである。DORAは正反対のことを求める。すなわち、各子会社の取締役会が、自らの親会社へ外部委託したリスクをガバナンスするために備えを与えられ、かつそうする義務を負うことを。その実務上の帰結は、グループICT機能から、親会社へだけでなく各子会社の取締役会への報告ラインであり、中央だけでなくすべての子会社における取締役会レベルのICTリスクリテラシーであり、各取締役会の監督が真正な統制点となるように設計されたグループのフレームワークである。共有コアを構築しながら子会社の取締役会を知らされないままにしておくグループは、コンプライアンスと統制の非対称性をその最も危険な形で生み出している。法的に責任を負う人々が、実際にはその責任を行使する能力を最も欠いている、という形である。

9. グループのための目標オペレーティングモデル

二つの問題に答える設計は、ICTを分権化することではない。それは効率を投げ捨てることになり、第4節のモデルによれば、共有コアがよく運用されている限り、グループのレジリエンスを改善しさえしないかもしれない。それは、中央のコアを保ちつつ、DORAが求める構造でそれを包むことであり、それによって義務と統制が所有権によってではなくガバナンスと契約によって再接続されるようにすることである。分析からは五つの打ち手が導かれる。

一つのグループICTリスクフレームワークを、すべての取締役会から可視な形で運用せよ。 ICTリスク管理フレームワークを、DORAとそのRTSが求める基準に従って(Art 6; RTS 2024/1774)、グループにおいて一度だけ構築する。ただしその報告を、親会社のそれだけでなく各子会社の経営機関へと配線し、各取締役会が実際の情報をもって共有リスクをガバナンスできるようにする。フレームワークは中央集権的であり、説明責任は、規制が求めるとおり、分散されたままである。

親会社とは、それがベンダーであるかのように契約せよ。 重要または重大な機能のあらゆるグループ内供給に、完全なArticle 30の条項、アクセスと監査の権利、インシデント支援と協力の義務、再委託の条件、そして文書化された出口戦略を備えた書面契約を、子会社が外部のクラウドプロバイダーに課すのとまったく同じように与える。この形式性は官僚的なオーバーヘッドではない。それは、子会社の紙の上の責任を、コアに対する実際の力へと変える道具である。

連結レジスターを保持し、それをリスクマップとして読め。 レジスターを、エンティティ、サブ連結、連結の各レベルで維持し(Art 28(3))、連結の視界を、提出のための雑務としてではなく、グループ自身の集中の地図として、すなわち集中リスク評価(Art 29)と、そこから導かれるレジリエンス投資へのインプットとして扱う。

インシデントの事実を集権化し、提出を分散せよ。 グループのセキュリティオペレーションセンターから、一つのインシデント分類、一つの根本原因プロセス、一つの時計を運用し、いかなるコアインシデントについても単一の整合した説明を、影響を受けた各子会社自身の報告へと供給する。その報告は、当該子会社が所有し、自国の当局へ提出する(Arts 18–19)。グループは一つの真実を供給し、各エンティティは自らの義務を果たす。

コアを、それに依存するすべての者のために、一度テストせよ。 レジリエンステストと脅威主導型テストを、共有コアから外側へ向けて、DORAのプールされたテストおよびグループテストの規定(Arts 26–27)を用いて計画する。そうすることで、集中を担うものが、繰り返し薄くではなく、適切にまれにテストされ、各子会社の重要機能がスコープに入れられ、各子会社がその知見に基づいて行動するようにする。

これらのいずれも集権化を元に戻すものではない。そのそれぞれは、DORAが子会社に課した義務を、グループが持株会社に置いた統制へと再接続する。合わせて、それらは、グループが一度構築したプラットフォームを保ちつつ、それでもなお各規制対象エンティティと各国の監督当局に、規制が求めるガバナンスされ、契約され、文書化され、テストされた関係を与えることを可能にする。

10. 反論と応答

親会社は規制対象エンティティではないのだから、DORAはそれに適用されない。 直接には適用されない。だがその子会社を通じては、全面的に適用される。DORAは、各子会社にそれをガバナンスし、それと契約し、それを監督することを義務づけることによって、ICTグループ内サービスプロバイダーとして持株会社に到達する(Arts 3(20), 30)。親会社のライセンスの欠如をDORAからの自由と読むグループは、義務の経路をその不在と取り違えており、その義務が、あらゆる子会社のレジスター、契約、監査の中で待ち構えているのを見出すことになる。

ICTの集権化はレジリエンスを改善するのだから、集中はリスクではなく長所である。 両方とも真であり、それこそが第4節の要点である。よく運用された共有コアは、各子会社自身の独立した障害確率を下げる。それは同時に、グループ全体を一斉に機能障害に陥れる単一の相関事象の確率を高める。DORAの集中に関する規定(Art 29)が存在するのは、まさにこの第二の効果が実在し、いずれか一つのエンティティの内側からは見えないからである。設計上の課題は、第一の便益を捉えつつ、第二のものを見て、価格づけし、緩和することであり、トレードオフが存在することを否定することではない。

親会社とその自らの子会社とのあいだに完全なArticle 30の契約を書くのは、法律家じみた芝居にすぎない。 契約の唯一の目的がチェックリストを満たすことであるなら、そのとおりであろう。その本当の目的は、自ら所有しないコアについて法的に責任を負う子会社の取締役会に、そのコアに対する情報、監査、支援、出口の執行可能な権利を与えることである。それらがなければ、取締役会の法定の責任(Art 5)は名目的である。この形式性は責任を行使可能にする仕組みであり、取引相手が同じ最終的所有者を持つ姉妹エンティティであるグループ内の設定こそ、まさに非公式な取り決めがそれらの権利を書かれないまま残しがちな場である。

プールされたテストは、グループを個々のテストの義務から解放する。 そうではない。プール(Arts 26–27)は共有コアを効率的かつ安全にテストする方法であって、他者のテストを指し示すことによってエンティティの義務を果たす方法ではない。参加する各子会社は依然として個別に、自らの重要機能がスコープに入っていることを確保し、その知見に基づいて行動する義務を負う。プールが関わるのはテストがどのように実施されるかであって、それが誰の義務であるかではない。

11. 限界

これは実務家に向けた分析であり、その限界は率直に述べておくべきである。これは法的助言ではない。統制する本文は規則とそのLevel 2法令であり、欧州監督当局(European Supervisory Authorities)および関連する各国の所管当局の指針とともに読まれるべきものであって、グループ自身の法律顧問が、ここでの一般的な構造を、その具体的なエンティティ、ライセンス、加盟国へと対応づけなければならない。本稿の条文への言及は、2025年初頭の時点でのDORA、すなわちその時点で採択されていた委任法令および実施法令に基づく。技術基準の詳細、およびそれらの下での監督実務は、今後も発展を続けるであろう。第4節のモデルはスケッチであり、その諸量は測定できる程度に明確に定義されているが、その関数形と例示的な値は、グループのデータから推定されたのではなく、仕組みを可視化するために選ばれたものである。グループは、曲線から何らかの結論を引き出す前に、$c$、$p_0$、$q$ を自らのアーキテクチャとインシデント履歴から埋めるべきである。本稿はまた、単一の中央コアと明確な親子会社の分割という、ありふれた明快な事例を扱っている。現実のグループは、複数のコア、部分的な集権化、中間の持株会社、グループ内プロバイダーの背後にある共有された外部プロバイダー、そしてある加盟国では重要だが別の加盟国ではそうでない機能を持ち、そのいずれもが、二つの基本的な問題を変えることなく状況を複雑にする。

12. 結論

重要なICTを中央から、規制対象の事業を周縁から運用する汎欧州の金融グループは、効率にとって最も理にかなった構造を、そしてDORAにとって最も厄介な構造を築いてしまっている。規制は各子会社を個別に拘束し、各社が自らのICTを統制すると想定するが、その代わりに見出すのは、規制が間接的にしか到達しない親会社によって供給される一つの共有コアが、それらすべてを統制している、ということである。二つの問題がそこから生じる。コンプライアンスの義務は統制の所在しない場所にあること、そしてICTを集権化することが、グループのリスクを、その障害がすべての子会社を一斉に機能障害に陥れ、すべての監督当局へ別々に報告される単一の相関点へと集中させることである。我々は両方を明らかにし、第二のものをモデル化して、集権化がより低いエンティティごとの障害確率を、より高いグループ全体の相関確率と引き換えにすることを示し、その結果をDORAのレジスター、集中、契約、インシデント、テスト、ガバナンスの各規定に照らして読み解いた。

答えは、中央のコアを捨てることではなく、DORAが求めるとおりにそれをガバナンスすることである。すなわち、すべての取締役会から可視な一つのグループフレームワーク、外部ベンダーに対するかのように書かれるグループ内契約、集中の地図として読まれる連結レジスター、多数の提出へと分散される一組のインシデントの事実、そしてそれに依存するすべての者のために一度テストされる共有コアである。そのそれぞれの打ち手は、規制が子会社に課した義務を、グループが持株会社に置いた統制へと再接続し、それによって、グループが一度構築したものが、それに依存するすべてのエンティティによってコンプライアンスを保ちつつ運用されうるようにする。より深い教訓は、DORAが教えるために書かれたものである。すなわち、オペレーショナル・レジリエンスはプラットフォームの性質ではなくそれを取り巻く取り決めの性質であること、そしてグループにおいては、その取り決めこそが——所有関係図ではなく——効率の単一の点が同時に障害の単一の点でもあるかどうかを決めるものである、ということである。

付録 A. モデルの全体

第4節のモデルは四つの量を用い、そのいずれもグループが自らのアーキテクチャとインシデント履歴から推定できる。集権化比率 $c$ は、グループの規制対象子会社のうち、その重要または重大な機能が共有コアに依存するものの割合である。グループはそれを連結レジスター(Art 28(3))から、自らの子会社のうち何社が重要機能の背後にグループ内コアを列挙しているかを数えることによって読み取れる。コア障害確率 $p_0$ は、共有コアが、選ばれた期間において依存する子会社の重要機能を機能障害に陥れるほど重大な障害を被る確率である。それは、いずれか一社の子会社の記録からではなく、コア自身のインシデント記録から推定される。現地障害確率 $q$ は、子会社自身の共有されていないICTについての対応する確率である。カウント $n$ は規制対象子会社の数である。

独立したベースラインは、集中を可視にする比較である。もし共有コアがなく、各子会社が確率 $q$ で独立に故障するとすれば、少なくとも二つの子会社が同じ期間に機能障害に陥る確率は $1-(1-q)^{n}-nq(1-q)^{n-1}$ となり、これは小さな $q$ については近似的に $\binom{n}{2}q^{2}$ であって、二次の量である。共有コアがあれば、同じ確率の主要項は $p_0$ に少なくとも二つの子会社が配線されている確率を乗じたものであり、$p_0$ における一次の量である。両者の比は、集権化がグループの同時多発的な複数エンティティ事象への曝露を高める倍率であり、それは $p_0$ が $q^{2}$ よりそれほど小さくないとき——そしてそれはほとんど常にそうなのだが——常に大きい。これは、集中が子会社間でリスクを分散させるのではなく、子会社を単一のリスクへと結合するという主張の形式的な内容である。

二つの落とし穴が注意に値する。第一は、$p_0$ を単一の子会社のコア経験から推定することであり、これはそれを過小評価する。なぜなら、ある子会社は、たまたま自らを機能障害に陥れたコアインシデントしか見ないからである。$p_0$ は、すべての依存者にわたるコア自身の記録から読み取られなければならない。第二は、$c$ が一つの決定であるにもかかわらず、それを固定されたものとして扱うことである。グループは機能ごとに、どれだけをコアに配線するかを選ぶのであり、モデルの価値は、その選択の各増分の、相関したグループ全体のリスクにおけるコストを示すことにある。そうすることで、その選択が効率の論拠だけに基づいてではなく、図2のトレードオフを視野に入れてなされるようにするのである。

付録 B. グループ内契約条項のチェックリスト

以下のチェックリストは、重要または重大な機能のグループ内供給に関する契約において子会社が確保すべきArticle 30の条項を集めたものである。それは規則の、あるいは法的助言の代替ではない。それは、グループの中央IT機能とその子会社の取締役会とのあいだの設計上の対話のための作業リストである。各条項は、子会社が自ら所有しないコアに対して、DORAがそれに課す義務を果たすために必要とするものである。グループ内の設定こそ、それぞれが最もしばしば暗黙のまま残され、代わりに書き記されるべき場である。

参考文献

European Union (2022). Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 1–79. https://eur-lex.europa.eu/eli/reg/2022/2554/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1773 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on the policy on contractual arrangements on the use of ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1502 supplementing Regulation (EU) 2022/2554 with regard to criteria for the designation of ICT third-party service providers as critical for financial entities. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1502/oj

European Commission (2024). Commission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to the standard templates for the register of information. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj

European Commission (2025). Commission Delegated Regulation (EU) 2025/532 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2025/532/oj

European Supervisory Authorities (EBA, EIOPA and ESMA) (2024). Final report on draft regulatory technical standards on subcontracting under Article 30(5) of Regulation (EU) 2022/2554 (JC 2024 53). Joint Committee of the European Supervisory Authorities. https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024_53_Final_report_DORA_RTS_on_subcontracting.pdf

Basel Committee on Banking Supervision (2021). Principles for operational resilience. Bank for International Settlements. https://www.bis.org/bcbs/publ/d516.htm

Financial Stability Board (2019). Third-party dependencies in cloud services: Considerations on financial stability implications. https://www.fsb.org/2019/12/third-party-dependencies-in-cloud-services-considerations-on-financial-stability-implications/

Financial Stability Board (2023). Enhancing third-party risk management and oversight: A toolkit for financial institutions and financial authorities. https://www.fsb.org/2023/12/enhancing-third-party-risk-management-and-oversight-a-toolkit/

European Systemic Risk Board (2022). Mitigating systemic cyber risk. European Systemic Risk Board. https://www.esrb.europa.eu/pub/pdf/reports/esrb.SystemicCyberRisk220127~b6655fa027.en.pdf

European Banking Authority (2019). Guidelines on outsourcing arrangements (EBA/GL/2019/02). https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements

European Union Agency for Cybersecurity (ENISA) (2023). ENISA threat landscape 2023. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023

Perrow, C. (1999). Normal accidents: Living with high-risk technologies (Updated ed.). Princeton University Press. ISBN 978-0-691-00412-9.

Leveson, N. G. (2011). Engineering a safer world: Systems thinking applied to safety. MIT Press. ISBN 978-0-262-01662-9.

Kaufman, G. G., & Scott, K. E. (2003). What is systemic risk, and do bank regulators retard or contribute to it? The Independent Review, 7(3), 371–391. https://www.independent.org/pdf/tir/tir_07_3_scott.pdf