TLPT実施後の対応ガイド【2026年版】結果報告・改善計画・経営層への説明方法

TLPTは「実施完了」で終わりではない

TLPTの最終報告書を受け取った翌日から、本当の意味での対応フェーズが始まります。テストそのものより、その後にどう動くかが金融庁への対応実績として評価され、組織のセキュリティ成熟度を左右します。

金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年改訂版）は、TLPTの実施を義務化するだけでなく、発見事項の是正・経営層への報告・継続的なモニタリングまで一体的に求めています。報告書を「引き出しにしまって終わり」にすることは、ガイドラインの趣旨に反します。

本記事では、TLPT実施後の一連の対応プロセスを、報告書の読み方から改善計画の策定、経営層説明、リテスト判断まで体系的に解説します。

1. TLPT実施後に何が起きるか：報告書の読み方

報告書の基本構成を理解する

TLPTの最終報告書は、一般的なペネトレーションテスト報告書より分量が多く、構成も複雑です。主な構成要素は以下のとおりです。

発見事項の重大度分類を確認する

報告書の核となる「発見事項一覧」では、各項目がリスク重大度によって分類されています。一般的な分類基準は以下のとおりです。

Critical（緊急）：攻撃者が実際に侵害に成功した経路。コアバンキングシステムや顧客データベースへの到達など、業務継続に直結するリスク。即時対応が必要。

High（高）：単独では重大インシデントに至らないが、複数の脆弱性を組み合わせると深刻化する恐れがある。30日以内を目標に対処を開始する。

Medium（中）：現時点でのリスクは限定的だが、放置するとリスクが累積する。90日以内に対処計画を策定する。

Low（低）・Informational（情報提供）：ベストプラクティスへの準拠状況の差異。計画的に対応する。

「攻撃成功」と「検知成功」の両面を読む

TLPTの報告書が通常のペネトレーションテストと異なる点は、防御・検知側の評価も含まれることです。

• 攻撃が成功した経路（オフェンシブ評価）
• SIEMやSOCがどのタイミングでアラートを発報したか（ディフェンシブ評価）
• インシデントレスポンスチームが適切に動いたか（IR評価）

「攻撃は成功したが、SOCが20分以内に検知し封じ込めができた」という結果は、「攻撃が成功した」という事実だけを切り取るより、組織の実態を正確に反映しています。報告書を読む際は、攻撃成功と検知・対応の両軸で評価することが重要です。

2. 経営層・取締役会への報告のポイント（金融庁が求める報告体制）

金融庁ガイドラインが求める経営関与の実態

金融庁ガイドラインは、サイバーセキュリティを「経営課題」として位置づけることを明示しています。TLPTの結果報告は、情報セキュリティ部門内で完結させず、取締役会または経営会議に正式に上程することが求められます。

具体的には次の3点を報告体制の柱として整備する必要があります。

1. 取締役会への定期報告：TLPTの実施結果および是正状況を取締役会議事録に残す
2. リスク管理委員会との連携：発見事項をオペレーショナルリスクとして管理台帳に登録する
3. CISO・CROのレビュー：是正計画の承認権限を明確化する

経営層向け説明資料の構成

経営層は技術的な詳細よりも、経営リスクと対応コスト・期間に関心があります。説明資料は以下の順序で構成すると理解を得やすくなります。

（1）結論を先に提示する

「今回のTLPTで、外部からコアバンキングシステムの認証を迂回できる経路が1件確認されました。現時点でのリスクレベルはHighです」と、結論から入ります。

（2）ビジネスインパクトに換算する

技術的な脆弱性の説明を、「万一この経路を悪用された場合、〇〇日間の業務停止と、顧客データ〇万件の漏洩リスクが生じる」というビジネス影響に翻訳します。

（3）対応計画と必要リソースを示す

是正にかかる工数・費用・期間の見積もりを、優先度別に提示します。「緊急対応は3件で工数30人日、費用はX百万円、完了目標は90日以内」という具体性が承認取得の鍵です。

（4）未対応リスクの受容を明示する

すべてのリスクを即時解消することは現実的ではありません。対応を後回しにする項目については、「残留リスクとして経営層が認識・受容した」という意思決定記録を残すことが、内部監査や金融庁検査への対応として重要です。

報告のタイミング

TLPTの最終報告書受領から取締役会報告までの目安は30〜45日以内です。この間に担当部門が発見事項を精査し、是正計画の素案を作成した上で報告に臨むことで、経営層からの「では何をするのか」という問いに即答できる状態を整えます。

3. 改善計画の立て方：優先度付けとロードマップ

リスクスコアリングで優先度を決める

発見事項が10件以上ある場合、すべてを同時並行で対処しようとするとリソースが分散し、どれも中途半端になるリスクがあります。優先度付けには、以下の2軸でスコアリングする方法が実用的です。

リスク影響度（Impact）：侵害された場合の業務・顧客・評判への影響 対策実施容易性（Ease of Fix）：技術的・組織的な対処難易度

この2軸を4象限にマッピングし、「影響大×対応容易」の項目を最優先フェーズに配置します。

3段階のロードマップ構成

実務上は以下の3段階を基本フレームとして設計します。

フェーズ1（0〜90日：緊急対応）

• Critical・Highリスクの技術的修正（パッチ適用・設定変更・アクセス制御強化）
• 攻撃成功経路の封鎖確認とSOCルールチューニング
• インシデントレスポンス手順の更新

フェーズ2（91〜180日：構造的対応）

• Mediumリスクへの対処
• セキュリティアーキテクチャの見直しが必要な中長期課題の設計着手
• 従業員向けセキュリティ教育の実施

フェーズ3（181〜365日：継続的改善）

• Lowリスク・ベストプラクティス準拠の整備
• 管理策のKPI化とモニタリング体制の構築
• 次回TLPTに向けた成熟度評価

改善計画に含めるべき必須項目

各発見事項の是正タスクには、以下の情報を紐付けて管理します。

• 発見事項ID（報告書との対応）
• 担当部門・担当者
• 完了目標日
• 進捗ステータス（未着手・進行中・完了・リスク受容）
• 完了確認方法（設定変更の証跡・テスト結果など）
• 経営層承認の要否

この管理台帳は、金融庁のオフサイトモニタリングや検査の際に提出を求められる可能性があります。Excel管理でも問題ありませんが、更新履歴と承認記録が残る形式が望まれます。

4. 再テスト（リテスト）のタイミングと判断基準

リテストの目的を明確にする

リテストとは、是正措置の実効性を確認するための追加検証です。単に「やり直し」ではなく、「修正した箇所が本当に塞がれているか」を客観的に検証する位置づけです。

金融庁ガイドラインは具体的なリテスト実施頻度を数値で規定していませんが、TIBER-EU（欧州中央銀行が策定したTLPTフレームワーク）では、主要な是正措置完了後に検証テストを実施することが推奨されています。

リテスト実施の判断基準

以下のいずれかに該当する場合、フォーマルなリテストの実施を検討します。

リテストを強く推奨する場合

• CriticalまたはHighリスクが3件以上検出された
• コアバンキング・決済システムへの侵害経路が確認された
• SOCが攻撃を検知できなかった（未検知率が50%超）
• 是正後に新たなシステム変更が加わった

スポット確認で足りる場合

• 発見事項がMedium以下のみ
• 是正措置が設定変更・パッチ適用など技術的に完結する内容のみ
• 独立した第三者によるシステム変更確認が取れている

リテストの実施形式

フルスコープのTLPTを再度実施する必要はありません。発見された脆弱性の経路に絞ったスコープ限定型のペネトレーションテストとして実施することが一般的です。費用・期間ともにフルTLPTの20〜40%程度に抑えられます。

5. 外部委託先・ベンダーへの展開

サプライチェーンリスクとしてのTLPT発見事項

TLPTで発見される脆弱性の中には、自社のシステムではなく外部委託先・ベンダーが管理するシステムに起因するものが含まれることがあります。クラウドサービスのAPIキー管理不備、外部連携先経由の認証迂回、保守ベンダーの特権アクセス管理の甘さなどがその典型です。

こうした発見事項は、自社だけで是正を完結できないため、特別な対応フローが必要です。

ベンダーへの展開手順

ステップ1：情報共有の範囲を確認する

TLPTの報告書には機密情報が含まれます。ベンダーに共有する際は、NDA（秘密保持契約）の締結状況を確認し、共有する発見事項を当該ベンダーに関係する範囲に限定します。

ステップ2：是正要求書を発行する

口頭での依頼ではなく、「発見事項の概要・リスクレベル・是正要求事項・完了期限」を明記した書面（是正要求書）をベンダーに発行します。これにより責任の所在を明確にします。

ステップ3：是正状況を定期的にフォローする

ベンダーからの是正完了報告を受けたら、可能な範囲で証跡（設定変更履歴・テスト結果）の提出を求め、口頭確認だけに依存しない体制を整えます。

ステップ4：契約条項の見直しに反映する

次回の契約更新時に、セキュリティ基準への準拠義務・定期的なセキュリティ評価への協力義務を契約条項に明記することを検討します。これはサプライチェーンセキュリティ強化の観点からも金融庁が重視しているポイントです。

委託先管理の記録

ベンダーへの是正要求・対応結果の記録は、自社の改善計画管理台帳と連動させて一元管理することが望まれます。「誰に・いつ・何を求め・どう対応されたか」の証跡が、内部監査や金融庁検査で説明責任を果たす根拠となります。

6. AEVUSのTLPT支援サービス

AEVUSは、TLPTの実施支援だけでなく、実施後の一連の対応プロセス全体を支援するサービスを提供しています。

提供サービスの概要

結果報告書レビューサポート

TLPTを他社で実施した場合でも、報告書の内容精査・読み解き・優先度付けのアドバイザリーとして支援します。発見事項の技術的な正確性の確認や、自社環境での再現可能性の評価も対応します。

経営層向け報告資料作成支援

技術的な報告書を、経営層・取締役会向けのビジネスリスク報告資料に翻訳する作業を支援します。金融庁への対応実績を豊富に持つコンサルタントが、説明の切り口から想定Q&Aまでサポートします。

改善計画策定・進捗管理支援

発見事項のスコアリング、3段階ロードマップの設計、管理台帳の整備から、是正措置完了後の確認テストまで、改善サイクル全体を伴走支援します。

スコープ限定型リテスト

Critical・Highリスクの是正完了後、該当経路に絞ったリテストを実施します。フルTLPTと比較して短期間・低コストで、是正の実効性を第三者として確認します。

AEVUSを選ぶ理由

• 金融機関向けTLPT・ペネトレーションテストの豊富な実績
• 金融庁ガイドライン対応を熟知したコンサルタントによるアドバイザリー
• レッドチーム、脅威インテリジェンス、インシデントレスポンスを一貫して対応できる体制
• 報告書作成から是正支援・リテストまでワンストップで依頼可能

TLPTの実施後に何から手をつけるべきか分からない、経営層への説明に不安がある、改善計画を適切に立てられているか確認したい──そうした課題をお持ちの情報セキュリティご担当者は、まずAEVUSにご相談ください。

TLPTの実施後対応について相談する →

まとめ：TLPTの価値はアフターケアで決まる

TLPTは、実施することに意義があるのではなく、発見事項を組織の防御力向上に活かすことで初めて投資対効果が生まれます。報告書を正確に読み、経営層に適切に伝え、優先度に基づいた改善計画を着実に実行する──この一連のサイクルこそが、金融庁ガイドラインが求める「継続的なサイバーセキュリティ管理」の実践です。

TLPT実施後の対応チェックリストとして、以下の項目を確認することを推奨します。

• [ ] 報告書の発見事項をリスク重大度別に分類・整理した
• [ ] 経営層・取締役会への報告資料を作成し、30〜45日以内に上程した
• [ ] 発見事項の是正計画を担当者・期限付きで管理台帳に登録した
• [ ] CriticalまたはHighリスクの是正着手を90日以内に開始した
• [ ] 外部委託先に関連する発見事項を該当ベンダーに是正要求した
• [ ] リテストの要否を判断し、実施する場合はスケジュールを確定した
• [ ] 是正状況を経営層に定期報告する体制を整備した