DORA第28条の要件：なぜ英国の銀行はICTサードパーティサービスの文書化された退出戦略が必要なのか

英国の金融機関は、ICTサードパーティとの関係全体を包括的に管理していることを証明するよう、ますます強い圧力に直面しています。DORA（デジタル・オペレーショナル・レジリエンス法）第28条は、銀行が重要なベンダーとの関係を業務の継続性や規制コンプライアンスを損なうことなく終了できるよう、文書化された出口戦略の策定を義務付けています。

課題は、単なる契約終了条項にとどまりません。銀行は、完全なデータ移行の実行、サービスの継続性の維持、ベンダー移行期間中の規制文書の保存を証明する必要があります。この運用上の複雑性は、多くの金融機関がまだ十分に実現できていないアーキテクチャ設計を求めています。

本分析では、英国の銀行がDORA第28条の要件を満たしつつ、競争力のあるサードパーティ関係に必要な俊敏性を維持できる、防御可能な出口戦略の構築方法を検討します。

DORAの英国銀行への適用範囲（ブレグジット後）

DORAはEU規則であり、デフォルトですべての英国銀行に直接適用されるわけではありません。しかし、その影響範囲は当初考えられるよりも英国金融セクターに広く及んでおり、各機関は自らのリスクエクスポージャーを慎重に評価する必要があります。

EU域内に支店・子会社・規制対象事業体を持つ英国銀行は、DORAの直接適用を受け、第28条の出口戦略規定を含むすべての要件を遵守しなければなりません。同様に、英国企業がサードパーティプロバイダーとしてEU金融機関にICTサービスを提供している場合も、当該サービスが規則のリスク分類基準で「重要」または「重大」と見なされれば、DORAの適用対象となる可能性があります。

一方、EU事業やEU向けICTサービス関係を持たない英国国内限定の機関には、直接的な法的義務はありません。しかし、FCA（金融行為規制機構）やPRA（健全性監督機構）は、SS2/21やPS6/21といった独自のオペレーショナル・レジリエンス・フレームワークを通じて、DORAの原則と明確に歩調を合わせており、サードパーティリスク管理、出口計画、サービス継続性について同等の期待を課しています。したがって、英国の銀行は、DORA第28条の基準を、正式な適用範囲か否かにかかわらず、国内規制の方向性を示す指標として捉えるべきです。

エグゼクティブサマリー

DORA第28条は、金融機関に対し、すべての重要なICTサードパーティサービスについて、詳細なデータポータビリティ計画、サービス継続措置、規制コンプライアンスの維持を含む包括的な出口戦略を維持することを義務付けています。英国の銀行は、業務の中断やコンプライアンスのギャップを生じさせることなくベンダー移行を実行できることを証明しなければならず、出口対応力を契約後の付け足しではなく、関係開始時からサードパーティ関係に組み込むアーキテクチャ的アプローチが求められます。

主なポイント

1. DORA第28条の義務。 重要なICTサードパーティサービスに対する包括的な出口戦略（データポータビリティ、サービス継続、規制コンプライアンスの維持など）を要求。
2. 英国銀行の適用範囲。 EU事業やEU企業向けICTサービスを持つ機関には直接適用。それ以外はFCAやPRAのオペレーショナル・レジリエンス要件に準拠する必要。
3. 出口戦略の中核要素。 データ分類、標準化された移行フォーマット、代替プロバイダーの特定、移行期間中の継続的な監査証跡の維持が求められる。
4. 積極的なアーキテクチャ対応力。 出口計画は、セキュリティ・コンプライアンス・業務継続性を規制当局の監督下で確保するため、関係開始時からサードパーティガバナンスに組み込む必要がある。

DORA準拠の出口戦略に必要な重要要素

銀行は、複数の運用面を同時に考慮した出口戦略を設計しなければなりません。DORA第28条の要件は、従来の契約管理を超え、ベンダー移行期間中のデータ主権、サービス継続性、規制文書の保存までを包括します。

効果的な出口戦略は、銀行とサードパーティプロバイダー間のすべての情報フローを特定する包括的なデータ分類から始まります。このマッピングには、主要なデータリポジトリだけでなく、メタデータ、監査証跡、規制当局がベンダー移行期間中および移行後もアクセス可能であることを期待するコンプライアンス文書も含める必要があります。

サービス継続計画では、サードパーティベンダーが提供するすべての重要な機能について、代替提供手段を特定する必要があります。この分析では、技術的な互換性、規制承認のタイムライン、移行実行を遅らせる可能性のある運用能力の制約も考慮しなければなりません。

データポータビリティと移行計画

データポータビリティは、DORA準拠の出口戦略の中でも技術的に最も複雑な側面の一つです。銀行は、すべての関連データを整合性や規制上の追跡性を損なうことなく抽出・検証・移行できることを保証しなければなりません。

効果的なデータ移行計画には、監査証跡の継続性や規制マッピングの正確性を維持する標準化されたエクスポートフォーマットが必要です。銀行は、抽出時のデータ完全性を検証する仕組みと、移行プロセス全体で機密情報が保護される仕組みの両方を備える必要があります。

移行スケジュールには、規制当局の承認要件、技術的な検証手順、同等のサービス提供能力を証明する運用テストも考慮しなければなりません。多くの銀行は、社内チーム・既存ベンダー・新規プロバイダー間の調整の必要性を過小評価しがちです。

サービス継続性と代替提供

サービス継続計画では、サードパーティ関係を開始する前に、すべての重要な機能について実現可能な代替手段を特定することが求められます。この積極的なアプローチにより、ベンダー変更時の業務リスクを低減しつつ、迅速な移行実行が可能となります。

代替提供の分析では、技術的な互換性、規制コンプライアンス状況、候補ベンダーの運用能力を評価する必要があります。銀行は、市場の代替案について、コスト構造や導入スケジュールも含めて最新の評価を維持し、必要時に迅速な移行を支えられるようにしておくべきです。

継続性テストでは、代替プロバイダーが規制コンプライアンスや業務効率を損なうことなく同等のサービスレベルを提供できるかを検証します。このテストは、銀行の要件やベンダーの能力が変化する中でも、代替案が有効であることを定期的に確認するために実施すべきです。

規制文書と監査証跡の保存

DORA準拠には、銀行がサードパーティ移行期間中も完全な監査証跡と規制文書を維持することが求められます。この保存は、単なるデータ保持を超え、コンプライアンスマッピング、リスク評価、業務モニタリング記録など、継続的な規制遵守を証明する記録全体に及びます。

文書保存戦略では、監査証跡がベンダー移行期間中もアクセス可能かつ法的に防御可能であることを保証しなければなりません。銀行は、コンプライアンス記録を抽出しつつ、その証拠価値が規制当局の調査や内部リスク管理プロセスで維持される仕組みを整備する必要があります。

規制マッピングの継続性では、代替ベンダーが監視や報告機能にギャップなく同等のコンプライアンス体制を維持できることを銀行が証明する必要があります。この継続性は、規制当局が検証できるテストや検証手順を通じて立証されなければなりません。

コンプライアンスフレームワークとの整合性

出口戦略では、ベンダー移行期間中も適用される規制フレームワークとの整合性が維持されていることを示す必要があります。この整合性には、ベンダーの能力と銀行が満たすべき具体的なコンプライアンス義務との詳細なマッピングが求められます。

コンプライアンス検証手順では、代替ベンダーが同等の規制報告・リスクモニタリング・監査証跡生成能力を提供できるかを確認します。銀行は、移行期間中に規制当局が検証できるテストや文書化を通じて、この同等性を証明しなければなりません。

フレームワーク整合性は、データプライバシー要件、業務レジリエンス基準、リスク管理の期待値など、規制当局が継続的に監督する領域にも及びます。出口戦略では、これらの義務がベンダー移行期間中も満たされていることを明示的に示す必要があります。

ベンダー移行期間中の運用リスク管理

ベンダー移行は、銀行が特定・評価・軽減しなければならない運用リスクを伴います。DORA第28条は、サードパーティ関係の変更期間中も業務レジリエンスを維持する重要性を強調しています。

リスク特定プロセスでは、技術統合の課題、データ移行の複雑性、サービス継続性のギャップなど、移行期間中の業務有効性を損なう可能性のある要素を把握しなければなりません。銀行は、予想される課題と代替アプローチが必要なコンティンジェンシーシナリオの両方を盛り込んだリスクレジスターを作成すべきです。

リスク軽減策には、社内チーム・既存ベンダー・新規プロバイダー間の連携が不可欠であり、知識移転やサービス引継ぎが円滑に行われるよう調整する必要があります。この連携は、移行プロセス全体でセキュリティ管理と規制コンプライアンスが維持されるよう確保しなければなりません。

ステークホルダーコミュニケーションとチェンジマネジメント

効果的なベンダー移行には、すべてのステークホルダーに進捗・課題・スケジュール調整などを適切に伝える包括的なコミュニケーション戦略が必要です。このコミュニケーションは、機密性要件を守りつつ透明性を確保し、商業的・運用上の機密情報を保護しなければなりません。

チェンジマネジメントプロセスでは、社内チームが移行期間中の自らの役割と責任を理解し、日常業務への集中を維持できるようにする必要があります。銀行は、移行の成功や規制コンプライアンスを損なう可能性のある問題に対して明確なエスカレーション手順を用意すべきです。

外部ステークホルダー管理には、規制当局・ビジネスパートナー・顧客など、ベンダー移行によるサービス変更の影響を受ける関係者との調整が含まれます。銀行は、一貫したメッセージングと情報開示義務の両立を図るため、コミュニケーションテンプレートや承認プロセスを策定すべきです。

まとめ

DORA第28条は、金融機関のサードパーティICT関係のアプローチを、受動的な契約管理から、アーキテクチャ的に組み込まれた積極的な出口対応力へと大きく転換させるものです。EU事業、EU企業向けICTサービス、またはFCA・PRAの同等フレームワークへの準拠を通じて適用範囲となる英国銀行にとって、その運用・コンプライアンス要件は非常に大きなものとなっています。

これらの要件を満たすには、単なるベンダー契約の更新だけでは不十分です。銀行は、データポータビリティ、サービス継続性、監査証跡の保存、規制文書の完全性が、ベンダー移行期間中も審査下で維持できることを証明しなければなりません。出口計画を契約終了後の付け足しと捉える機関は、業務面でも規制面でもリスクに晒されることになります。

防御可能な出口戦略を構築するには、出口対応力をサードパーティガバナンスの初期段階から組み込み、どのベンダーが基盤サービスを提供していてもセキュリティとコンプライアンス管理が維持される技術アーキテクチャで支える必要があります。今この対応を進める機関こそが、規制当局の監督だけでなく、効果的なサードパーティリスク管理がもたらす商業的な俊敏性も手にすることができるでしょう。

ベンダー移行期間中の機密データ保護

従来の出口計画は、契約や運用面に重点が置かれがちで、ベンダー移行期間中のデータセキュリティと規制コンプライアンス維持の重要性が見落とされることが多くありました。銀行には、サードパーティリスク管理のあらゆる側面にセキュリティ管理と監査証跡の保存を組み込むアーキテクチャ的アプローチが求められます。

Kiteworksのプライベートデータネットワークは、ゼロトラストアーキテクチャにより、基盤サービスプロバイダーを問わず情報を保護し、ベンダー移行期間中も機密データの包括的な管理を可能にします。このアプローチにより、データプライバシーや規制文書要件を損なうことなく出口戦略を実行できます。

Kiteworksは、ベンダー変更期間中も規制コンプライアンスの証拠となる改ざん防止監査証跡を提供し、銀行が移行期間中もDORA要件への継続的な準拠を証明できるようにします。プラットフォームのデータ認識型制御により、機密情報を保護しつつ、効果的な出口戦略に不可欠なデータポータビリティと移行要件を実現します。FIPS 140-3規格に準拠し、データ転送にはTLS 1.3を使用、FedRAMP High-readyにも対応しており、DORAおよび金融セクター全体の厳格な技術的セキュリティ基準を満たすことが可能です。

既存のSIEM、SOAR、ITSMワークフローとの統合により、銀行はベンダー移行期間中も運用の可視性とリスク管理能力を維持できます。この統合により、セキュリティ監視やコンプライアンス報告が途切れることなく継続され、サードパーティ関係の変更期間中に規制当局が期待する文書化や証拠の記録も提供されます。

重要なサードパーティ関係の変更期間中も、セキュリティ・コンプライアンス・業務継続性を維持できるDORA準拠のベンダー移行フレームワークをKiteworksがどのように構築できるかについては、カスタムデモを予約してご確認ください。