レッドチームは監督下のサプライチェーンになった:DORAのTLPT制度が実際に求めるもの

TL;DR. DORAのTLPT制度は、レッドチーム演習を監督下の義務へと変えます。制約となるのは技術ではなく、テスト事業者の市場、3年周期、そして第三者提供者です。

主な要点

テストがTLPTになると、実際に何が変わるのか. 多くの銀行はすでに攻撃的セキュリティを運用しています。そのため、TLPTを既存の能力にコンプライアンスの包装を被せたものとして扱いたくなります。その直感は、次の4か所で明確に誤っており、いずれも予算に跳ね返ります。.
誰が対象になるのか、そしてなぜ自分では決められないのか. DORAは、その適用範囲にあるすべての金融機関にTLPT義務を課しているわけではありません。実施を求められる金融機関は、システム上の重要性、規模、ICTリスクプロファイルを踏まえて所管当局が特定します。零細企業は除外されます。.
制約条件はテスト事業者の市場です. ここは取締役会の資料に載るべき論点ですが、実際に載っていることはめったにありません。.
内部チームは助けになりますが、制度を担いきれません. 成熟した攻撃的能力を持つ銀行が、内部チームで吸収できないかと問うのはもっともです。答えは、部分的には可能、です。.

脅威ベースのペネトレーションテストは、書類仕事が増えただけのペネトレーションテストではありません。 DORA Article 26に基づく規制技術基準がCommission Delegated Regulation (EU) 2025/1190として発効したいま、欧州の金融における敵対者シミュレーションは監督下の活動になりました。名指しされた対象範囲があり、実施周期が義務づけられ、認定された供給者の市場があり、そして演習全体の性格を静かに作り替える1つのルールがあります。脅威インテリジェンスの提供者は、常にテスト対象の金融機関の外部でなければならない、というルールです。多くの銀行はテストの費用を見積もりました。それが依存するようになったサプライチェーンの費用を見積もった銀行は、はるかに少数です。

エグゼクティブサマリー

制度は素描ではなく、具体的に規定されました。 2025年6月18日に欧州連合官報で公示されたCommission Delegated Regulation (EU) 2025/1190は、対象範囲、方法論、結果、内部テスト担当者の利用、そして加盟国間の相互承認を含む監督当局間の協力をカバーする規制技術基準によって、DORA Article 26を補完します。

土台はTIBER-EUです。 この制度は、脅威インテリジェンスに基づく倫理的レッドチーミングの欧州フレームワークの上に構築されています。TIBERの経験がある金融機関はゼロからの出発ではありません。ただしTIBERへの参加は任意であり、こちらは任意ではありません。

3年は下限であって、計画ではありません。 指定された金融機関は、重要機能を対象に少なくとも3年に1回テストを実施します。所管当局は、その金融機関のリスクプロファイルに応じて頻度を引き上げることも引き下げることもできます。

テストは成果物の半分にすぎません。 TLPTは監督上の証跡を生みます。スコーピングの根拠、脅威インテリジェンス、攻撃の経過記録、是正と再テストという一連のアーティファクトこそが意味のある産出物であり、事後にかき集めるのではなく演習の最中に作り込む必要があります。

テストがTLPTになると、実際に何が変わるのか

多くの銀行はすでに攻撃的セキュリティを運用しています。そのため、TLPTを既存の能力にコンプライアンスの包装を被せたものとして扱いたくなります。その直感は、次の4か所で明確に誤っており、いずれも予算に跳ね返ります。

表1:従来の攻撃的テストとDORAにおけるTLPT

論点	従来のペネトレーションテスト	DORAにおけるTLPT
実施を決めるのは誰か	金融機関自身が、自らのリスク選好に基づいて決定	所管当局が対象機関を指定し、頻度は少なくとも3年に1回
何を標的にするか	セキュリティ部門が選定したシステム	本番稼働中のものと外部委託されたものを含む、重要または重大な機能
脅威モデルはどこから来るか	内部の判断、またはテスト事業者自身のライブラリ	金融機関の外部の提供者から調達した、委託ベースの脅威インテリジェンス
誰が実行できるか	能力のある供給者、または内部チーム	Article 27の条件を満たすテスト事業者。内部チームは3回のうち最大2回まで
産出物は何のためか	内部向けの報告書と是正のバックログ	監督上の証跡。結果と是正は当局の精査と国境を越えた承認の対象

プログラムが作業量を見誤りやすいのは最後の行です。ペネトレーションテストの報告書は、指摘を直す人に向けて書かれます。TLPTのパッケージは、その場にいなかった監督当局に向けて書かれます。なぜ対象範囲をそこに引いたのか、インテリジェンスは何を示していたのか、レッドチームは実際に何をしたのか、その結果として何が変わったのかを、後から再構成できなければなりません。

誰が対象になるのか、そしてなぜ自分では決められないのか

DORAは、その適用範囲にあるすべての金融機関にTLPT義務を課しているわけではありません。実施を求められる金融機関は、システム上の重要性、規模、ICTリスクプロファイルを踏まえて所管当局が特定します。零細企業は除外されます。

ここから2つの帰結が導かれますが、いずれも見落とされがちです。

指定は成熟度の表彰ではありません。 名指しされたということは、あなたの機能不全が波及すると監督当局が判断したということであり、そこには実施周期の義務が付いてきます。正しい読み方は、一度きりのプロジェクトではなく、供給者の調達を伴う3年単位の恒常的なコミットメントです。

指定されないことは、同じ論理からの免除ではありません。 指定されていない金融機関も、DORAの一般的なテスト規定の下で、比例的な高度テストの実施を示さなければなりません。違いは制度の形式性であって、期待の有無ではありません。

制約条件はテスト事業者の市場です

ここは取締役会の資料に載るべき論点ですが、実際に載っていることはめったにありません。

Article 27は、単に能力のあるテスト事業者を求めているのではありません。求められているのは、脅威インテリジェンス、ペネトレーションテスト、レッドチーミングにおける具体的な専門性を伴う技術的・組織的能力を示せること、加盟国の認定機関による認証を受けているか、正式な行動規範または倫理フレームワークを遵守していること、テスト自体が生むリスクの適切な管理をカバーする独立した保証または監査報告書を提供できること、そして不正行為と過失に対する補償を含む専門職賠償責任保険を保有していることです。

表2:Article 27がテスト事業者に求めるもの、そして市場から除かれるもの

要件	それが本当に検証しているもの	市場から除かれるのは誰か
脅威インテリジェンス、ペネトレーションテスト、レッドチーミングにまたがる実証された専門性	供給者が鎖の一環ではなく、全体を回せること	攻撃技術には強いがインテリジェンス機能を持たないブティック
加盟国における認定、または正式な行動規範	評判ではなく検証可能な地位	個人事業のコントラクターや非公式な集団
リスク管理に関する独立した保証または監査報告書	本番稼働中の銀行をテストしても壊さないこと	自らのガバナンス成熟度を欠く供給者
不正行為と過失を含む専門職賠償責任保険	リスクの背後にバランスシートがあること	資本の薄い企業

この4行をまとめて読めば、市場の形が見えてきます。該当する事業者はそれほど多くなく、その多くは大手であり、そのすべてがEU域内のあらゆる指定金融機関に対して、同期した3年のリズムで販売しているということです。

テスト事業者の調達を、四半期前に予定を組めば済む通常の購買業務として扱う金融機関は、最悪のタイミングでこの制約に気づくことになります。希少なのはレッドチームそのものではありません。要件を満たし、適切な実施枠が空いていて、あなたの資産に対する利益相反がないレッドチームです。

内部チームは助けになりますが、制度を担いきれません

成熟した攻撃的能力を持つ銀行が、内部チームで吸収できないかと問うのはもっともです。答えは、部分的には可能、です。

内部のテスト担当者は、監督上の承認、十分なリソース配分、利益相反の管理を条件に認められます。ただし2つの厳しい上限があります。3回のテストごとに外部のテスト事業者と契約しなければならないため、内部チームがカバーできるのは3回のうち最大2回です。そして脅威インテリジェンスの提供者は、内部チームが実行する回を含め、すべてのテストにおいて金融機関の外部でなければなりません。

後者のルールのほうが興味深い意味を持ちます。これは能力の話ではないからです。内部のインテリジェンス機能は、どの結論が都合が悪いかを知っています。インテリジェンスを外部から取ることを求めるのは、組織がすでにテストされても平気だと感じているものだけを静かに狙うレッドチーム、つまり演習を有益なものではなく安心材料に変えてしまう失敗モードに対する、構造的な防御です。

計画上の実務的な帰結はこうです。内部の能力は、それが担える周期のために構築する。ただし外部インテリジェンスは、周期的な支出ではなく恒常的な費目として扱う。

第三者提供者もテストの内側にあります

重要または重大な機能がICT第三者提供者に依存している場合、その提供者のシステムはTLPTの対象範囲に入り得ますし、提供者に参加を求めることもできます。

ホールセールバンクにとって、これは脚注ではありません。決済、カストディ、決済照合における重要機能は、ベンダーのプラットフォーム、マネージドサービス、クラウドの上で動いている比率が突出して高いからです。重要機能に対して正直に対象範囲を引いたテストは、必ず供給者へ届きます。そしてそこに届いた瞬間、技術ではなく契約の問題である3つの問いが立ち上がります。

契約はそれを許容していますか。 従来型のアセスメントを想定して書かれたテスト実施権の条項は、提供者の運用担当者に事前通知しないままインテリジェンス主導のレッドチームが本番環境に対して活動することを、想定していないことがよくあります。
テストがインシデントを起こしたとき、誰がリスクを負いますか。 銀行、テスト事業者、提供者の間で、これはスコーピングの前に書面で決着させるべきであり、実施枠が押さえられてから時間に追われて交渉するものではありません。
提供者は全社に同時に対応できますか。 多数の指定金融機関に提供する集中度の高い事業者は、テスト事業者の市場と同じ同期需要に直面します。しかも、あなたを優先する義務はありません。

条項の整備は、テストそのものよりリードタイムが長い作業です。他のあらゆる監督上のアクセス権と同じ理由、同じ論理で、いま更新ひな型に入れるべきものです。

防御側が演習に対して負うもの

静かに成功したレッドチームは、金融機関にほとんど何も教えません。価値は再構成にあります。何が発信され、何が検知され、何がエスカレーションされ、それぞれに何分かかったのかです。

証跡を生む演習と、物語を生むだけの演習を分けるのは、次の3つのコミットメントです。

再構成のための計装は、テストの最中ではなく、その前に行う。 検知テレメトリが十分な粒度で保持されていなければ、事後分析は記憶に頼る作業になります。技術的には成功した演習が、脆弱な監督用パッケージしか生まない最も典型的な経路がこれです。

結果だけでなく、時間を測る。 レッドチームが目的を達成したかどうかは、最も面白くない発見です。最初の検知までの時間、正しい帰属までの時間、封じ込めまでの時間こそが防御能力を記述する数値であり、周期をまたいで改善していく数値です。

ブルーチームへのループを意図的に閉じる。 防御側との協働は後付けではなくフレームワークに組み込まれており、これこそが単発の演習を持続的な能力へ変えるものです。テストを実施し、報告書を提出し、観測できる変化を何ひとつ起こさなかった金融機関は、周期を満たしただけで何も学んでいません。

実務プレイブック

指定を受ける見込みがあるかを見極め、受ける前提で計画する。 調達のリードタイムは長く、正式な通知を待つのは高くつく選択肢です。
テスト事業者の調達を、プロジェクト日程ではなく3年の先行計画に載せる。 認定または行動規範の遵守、保証報告書、賠償責任保険というArticle 27の条件に照らして、実施枠が必要になるずっと前にパネルを審査しておきます。
外部の脅威インテリジェンスを恒常的な契約として確保する。 誰がテストを実行するかにかかわらず毎回必要になるため、これは変動費ではありません。
第三者との契約条項を今四半期に整える。 テスト実施権、参加義務、インシデントリスクの配分です。ここに挙げた中で最もリードタイムが長く、かつエンジニアリングの作業ではありません。
最初の演習に先立って検知テレメトリの粒度を上げる。 証跡パッケージの品質は、レッドチームが活動していた間に記録されていたものが上限になります。
判定ではなく、時間を報告する。 検知、帰属、封じ込めまでの時間を周期をまたいで追跡することが、コンプライアンス上の一事象ではなく能力を監督当局に示す指標です。

これを落ち着いて捌ける金融機関は、最も見栄えのする内部レッドチームを持つ組織ではありません。監督下のテスト義務を、サプライチェーンと証跡の問題として、余裕をもって解けるだけ早い段階で捉えた組織です。

よくある質問

DORAの規制対象となるすべての金融機関がTLPTを実施しなければならないのですか。
いいえ。実施を求められる金融機関は、システム上の重要性、規模、ICTリスクプロファイルに基づいて所管当局が特定し、零細企業は除外されます。指定されていない金融機関も、DORAの一般的なデジタル・オペレーショナル・レジリエンス・テストの要件に引き続き服します。期待そのものが消えるわけではなく、消えるのは形式的な制度だけです。

指定された金融機関はどのくらいの頻度でテストしなければなりませんか。
重要または重大な機能を対象に、少なくとも3年に1回です。所管当局は、その金融機関のリスクプロファイルと業務上の状況に応じて、より高い頻度またはより低い頻度を求めることができます。

自社のレッドチームを使えますか。
3回のテストのうち最大2回までは可能で、監督上の承認、十分なリソース配分、利益相反の管理が条件です。3回に1回は外部のテスト事業者と契約しなければなりません。これとは別に、脅威インテリジェンスの提供者はすべての周期において金融機関の外部でなければなりません。

外部委託先の提供者も参加しなければならないのですか。
参加を求められることがあります。重要または重大な機能がICT第三者提供者に依存している場合、その提供者のシステムはテストの対象範囲に入り得ますし、提供者に参加を求めることもできます。だからこそ、テスト実施権とインシデントリスクの配分は、事前に契約で決着させておく必要があるのです。

すでにTIBER-EUの演習を実施しています。これで適合していますか。
制度が同じフレームワークの上に構築されているため有利な位置にはいますが、両者は同等ではありません。TIBERへの参加は任意でした。DORAの義務は監督下にあり、実施周期が義務づけられ、規制技術基準が定める具体的なテスト事業者の条件と、国境を越えた承認の枠組みを伴います。

参考文献

欧州議会および欧州連合理事会, 2022. Regulation (EU) 2022/2554 金融セクターのデジタル・オペレーショナル・レジリエンスに関する規則(DORA). ブリュッセル:欧州連合官報. 出典:欧州議会および欧州連合理事会, 2022年.
欧州委員会, 2025. Commission Delegated Regulation (EU) 2025/1190、脅威ベースのペネトレーションテストに関する規制技術基準についてRegulation (EU) 2022/2554を補完するもの. ブリュッセル:欧州連合官報. 出典:欧州委員会, 2025年.
欧州中央銀行, 2026. TIBER-EU:脅威インテリジェンスに基づく倫理的レッドチーミングの欧州フレームワーク. フランクフルト・アム・マイン:欧州中央銀行. 出典:欧州中央銀行, 2026年.

最終確認日 2026-08-06.

この記事を転載

レッドチームは監督下のサプライチェーンになった:DORAのTLPT制度が実際に求めるもの — Sebastien Rousseau

DORAのTLPT制度は、レッドチーム演習を監督下の義務へと変えます。制約となるのは技術ではなく、テスト事業者の市場、3年周期、そして第三者提供者です。

本記事のライセンスは Creative Commons Attribution 4.0 International. 転載の際は正規URLへの帰属表示が必要です。

レッドチームは監督下のサプライチェーンになった:DORAのTLPT制度が実際に求めるもの — Sebastien Rousseau

DORAのTLPT制度は、レッドチーム演習を監督下の義務へと変えます。制約となるのは技術ではなく、テスト事業者の市場、3年周期、そして第三者提供者です。

Originally published at https://sebastienrousseau.com/ja/2026-07-29-threat-led-penetration-testing-dora-tlpt-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER