EUの金融機関から「DORA条項を締結したい」「Register of Information用のデータを埋めてほしい」と依頼された日本のSaaS企業にとって、最初の難所は規則を読むことではありません。営業、法務、セキュリティ、運用が別々の資料を返し、同じサービスの名称、提供法人、データ所在、再委託先、復旧時間が一致しないことです。
DORA対応の中心は、金融機関が重要機能を継続できるよう、ICTサービスの実体を登録可能なデータ、執行可能な契約、検証可能な証拠、試せる退出手順へ変えることです。ISO認証やSOC報告書は有力な証拠ですが、それだけで事故通知、再委託、監査権、移行支援を満たしたことにはなりません。
本記事は2026年9月1日時点のDORA本体、欧州委員会の委任・実施規則、欧州監督当局のRegister of Information関連資料を基に、日本のICT事業者が顧客から受ける実務要求へ翻訳しました。個別契約では提供国、顧客区分、サービスの重要性、既存契約、データ処理の実態が異なるため、EU法務と顧客担当者による確認が必要です。
自社がEU企業かではなく提供関係を一行ずつ確認する
法人の所在地ではなく、金融機能とICTサービスの関係から対象を切り分けます。
DORAは金融機関のデジタル・オペレーショナル・レジリエンスを定める規則です。直接の義務主体は銀行、保険、投資サービス、暗号資産サービスなど対象となる金融事業者ですが、その金融機関が利用するICT第三者サービスも契約、情報登録、監督を通じて対応を求められます。
日本本社からEU金融機関へSaaSを直接提供する契約、欧州子会社が契約し日本で開発・運用する形、グローバル親会社のサービスを日本法人が販売支援する形では、回答主体と責任範囲が違います。「当社はEU域外だから対象外」と一文で返すと、顧客が自社の委託関係を登録・評価できません。
顧客ごとに、契約法人、サービス名、機能、利用国、データ種別、処理・保管場所、運用拠点、再委託先、停止時の影響、代替可能性を一行にします。顧客側で重要または重大な機能を支えると評価されているかも確認します。自社の認識だけで「非重要」と決めません。
DORA適用判定の最小単位は会社ではなく、「金融機関のどの機能を、どの契約法人とICTサービスが、どの場所・再委託網で支えるか」という提供関係です。
金融機関の第三者サイバーリスク では金融機関側の委託管理を扱っています。本記事では、その要求を受けるICT事業者側の契約・証拠・運用に絞ります。
顧客回答を契約、構成、再委託の正式台帳へ接続します。
DORAは金融機関に、ICT第三者との契約上の取決めに関する情報登録簿の維持を求めています。欧州監督当局はテンプレートとデータモデルを定め、金融機関はグループ内外の契約、ICTサービス、提供者、機能、再委託などを関係付けて報告します。
顧客から届く表には、法人識別、契約識別、サービス種別、提供国、データ保管・処理場所、支援する機能、再委託の情報などが含まれます。営業管理のサービス名と契約書の商品名、運用部門の基盤名が異なると、同じ契約を三つのサービスとして回答したり、反対に重要なオプションを落としたりします。
回答マスターでは、顧客向け名称、正式契約名、SKU・プラン、提供法人、運用責任法人を別欄にします。住所や法人番号は登記情報と一致させ、国名・サービス分類は顧客指定のコード体系へ変換します。自由記述へ「グローバル」と書くのではなく、処理国・保管国・バックアップ国を分けます。
Register of Information回答で最も危険なのは空欄より、契約・構成・再委託台帳と矛盾する確信的な回答です。誰が、どの根拠を、いつ確認したかをセル単位で追えるようにします。
EBAの準備資料では、情報登録簿がDORAの監督枠組みにとって重要であることが示されています。顧客が重要ICT第三者の指定や集中リスクを評価する基礎にもなるため、単発の質問票として返して終わらせません。
回答の所有者を項目ごとに決める
契約法人と請求は法務・経理、データ所在はアーキテクト、再委託は調達、復旧目標は運用、インシデントはCSIRTが持っている場合があります。一人の営業担当が過去回答をコピーすると、変更を見落とします。
項目を「法人・契約」「サービス・機能」「データ」「拠点」「再委託」「継続性」「セキュリティ」に分け、承認者と証拠を割り当てます。四半期更新に加え、データセンター移転、子会社再編、サービス統合、再委託追加、終了条件変更を更新イベントにします。
契約は条文の有無ではなく事故日に動くかで読む
要求を担当、開始条件、期限、提出物へ変換します。
DORA第30条は、ICTサービス契約についてサービス記述、提供場所、データへのアクセス・回復・返還、サービス水準、インシデント支援、当局との協力、終了権などを求め、重要または重大な機能を支える場合にはさらに厳しい要素を定めています。
顧客から提示されるDORA付属契約は、全条項を無条件で受け入れるか拒否するかの二択ではありません。自社サービスの責任分界へ落とし、実行不能な表現を運用可能な手続へ変えます。たとえば「直ちに通知」だけでは、検知時点、暫定連絡、更新頻度、最終報告、連絡経路が分かりません。
契約レビュー表には、要求、担当、開始条件、期限、提出物、顧客の役割、再委託先への流し込み、費用、例外を並べます。「合理的な支援」は、ログ抽出、会議、フォレンジック、当局質問対応の標準時間と追加費用へ分けます。
条文ごとに、開始条件、担当、期限、提出物、再委託先への連鎖を割り当てます。
契約できる条項とは、法務が同意できる文章ではなく、深夜の障害でも運用担当が期限内に実行し、後から証拠を提出できる手順です。
取引先サイバーリスク管理 の質問票・証拠・契約・継続監視の考え方を使い、DORA固有の登録データと条項を上乗せします。
監査権を年一回の訪問予約にしない
監査条項では、顧客、共同監査、第三者監査、監督当局の権利、通知期間、対象範囲、施設・システム・文書へのアクセス、機密保持、安全、費用を整理します。SOC報告書やISO認証で通常確認を代替できても、重大事故、疑義、当局要請まで個別監査を全面禁止すると合意が難しくなります。
証拠を三層に分けます。第一層は認証書、独立監査報告、侵入試験要約など定期提供物です。第二層はアクセス管理記録、復旧試験、脆弱性対応、教育など質問に応じて提示する資料です。第三層は重大事故や当局要請時に、機密性を保ちながら追加確認する手続です。
顧客ごとに無制限な現地監査を受けるのではなく、共同監査、監査報告の再利用、仮想データルーム、閲覧のみ、個人情報・他顧客情報のマスキングを設計します。代替証拠を断る条件と、個別監査を受ける条件を契約へ書きます。
再委託は会社名一覧ではなく機能の鎖で説明する
下位事業者の役割、場所、データ、変更を重要機能へ結びます。
欧州委員会の委任規則2025/532は、重要または重大な機能を支えるICTサービスの再委託について、金融機関がリスクを評価・管理するための条件を定めています。再委託先の所在地、データ処理・保管場所、サービス連鎖、重要な変更、監視、監査・アクセス、継続性などが焦点になります。
クラウド基盤、CDN、メール配信、監視、サポート、バックアップ、本人確認などを一つの「サブプロセッサ一覧」にまとめるだけでは、停止時の影響を判断できません。各社がどの機能、データ、地域、復旧へ関与し、さらに下位の再委託があるかを結びます。
変更通知は、公開ページを更新するだけか、顧客へ能動通知するか、何日前か、異議申立て・解約が可能かを決めます。緊急のセキュリティ変更で事前通知できない場合の事後説明も必要です。契約上の通知期間と、実際の調達・技術変更プロセスが一致しているかを試します。
再委託管理の合格は「一覧を公開している」ではありません。重要機能のどこが止まり、データがどこへ移り、顧客が変更を評価・拒否・退出できる時点を示せることです。
集中リスクにも注意します。複数の機能を同じクラウド地域、同じID基盤、同じサポート会社へ集めると、契約数が多くても障害点は一つです。顧客から代替地域やマルチクラウドを求められた場合、可用性の効果だけでなくデータ整合、切替時間、運用複雑性、費用を説明します。
インシデント通知を顧客の報告時計へ接続する
金融機関はDORAに基づく重大ICT関連インシデントの分類・報告を行います。ICT事業者の通知が遅い、影響範囲が曖昧、更新が止まると、顧客は自社の報告判断を進められません。
通知手順には、検知、社内重大度判定、顧客影響の仮説、暫定通知、定期更新、原因・是正報告を置きます。初報で根本原因を断定する必要はありません。発生・検知時刻、影響サービス、国・顧客、可用性・完全性・機密性、継続時間、回避策、次回更新時刻を、確認済みと未確認に分けます。
顧客の契約窓口だけへメールすると、休日や担当交代で止まります。24時間窓口、暗号化連絡、緊急電話、ステータスページ、顧客固有の報告先を登録し、半年ごとに到達試験をします。機微情報を不特定多数へ公開しない経路も必要です。
事故通知SLAは「24時間以内」の数字だけでは不十分です。顧客が規制報告を判断できる最小情報、更新間隔、訂正方法、連絡不能時の代替経路まで決めます。
ログ保存期間と時刻同期も契約回答へ影響します。顧客が事故発生から数週間後に追加分析を求めた時、該当ログが消えていれば説明できません。サービスごとのログ種類、保管期間、抽出時間、個人情報・他顧客データの制約を明示します。
Exitは解約条項ではなく移行作業として試す
実データ量に近い退出演習で、移行時間と欠落を確認します。
DORAは金融機関に、重要ICTサービスからの退出戦略や移行計画を求めます。供給者側の契約にデータ返還と削除が書かれていても、形式、量、API制限、暗号鍵、構成、ログ、並行稼働が決まっていなければ移行は止まります。
退出パックを平常時に用意します。データ項目と形式、完全エクスポート時間、差分取得、添付ファイル、監査ログ、設定値、ID対応表、暗号鍵の扱い、削除証明、支援窓口、料金を一覧にします。顧客所有データと、事業者の知的財産・統計情報を分けます。
退出可能性は契約文では測れないため、実データ量に近いエクスポート、復元、差分同期を試します。
テスト用テナントで、エクスポート開始から受領、検証、別環境への取込みまで時間を測ります。APIのレート制限、文字コード、参照整合性、添付欠落、削除フラグ、監査ログの不足を記録します。契約終了直前ではなく、サービス設計の段階で直します。
Exit計画の核心は「データを返せる」ことではなく、金融機関が許容停止時間内に業務を別手段へ移し、データ完全性と規制記録を検証できることです。
移行先が未決定でも、標準形式、API仕様、エクスポート容量、必要日数は試せます。倒産、長期障害、重大違反、商業上の解約では協力状況が異なるため、協力的退出と緊急退出を分けます。
90日で契約回答を運用へつなぐ
最初の30日で対象顧客とサービスを棚卸しし、既存契約、Register回答、再委託、データ所在、証拠の矛盾を洗います。顧客の重要機能評価と回答期限を確認し、重要度と契約更新日で順番を決めます。
31日目から60日目は、標準付属契約、証拠カタログ、インシデント通知票、再委託変更手順を作ります。営業が受けた質問を法務へ転送するだけにせず、回答マスターと例外承認へ登録します。要求を受けられない場合は、代替統制と残余リスクを提示します。
61日目から90日目は、暫定事故通知、監査資料提出、再委託変更通知、データ退出を机上・実動で試します。顧客担当者にも参加してもらい、連絡先、時差、承認、データ形式を確認します。所要時間と欠落を契約・手順へ戻します。
KPIは「DORA条項締結率」だけにしません。Register回答の根拠付与率、再委託先不明件数、期限超過回答、事故連絡到達率、監査証拠提出時間、退出テスト成功率、未解決例外の経過日数を測ります。
締結率100％でも、再委託変更を通知できず、事故情報が届かず、データを期限内に戻せなければDORA対応は未完成です。契約KPIと実行KPIを並べます。
要求をそのまま価格へ埋め込まない
24時間窓口、顧客固有報告、長期ログ、個別監査、退出支援には費用が発生します。基本サービスに含む規制対応と、個別作業として見積もる部分を分けます。費用を曖昧にすると、事故時に見積承認を待って支援が遅れます。
標準証拠の提供、通常の再委託通知、標準エクスポートは基本範囲とし、専用環境、特別な保存期間、個別現地監査、常駐支援などを追加範囲にする設計が考えられます。ただし当局協力や法令上不可欠な義務を、料金未合意だけで停止できるとは限りません。契約前に法務・財務・運用で整理します。
受注判断にもDORAを使う
全ての要求を受けることが正解ではありません。重要機能を支えるのに、単一障害点を解消できない、必要ログを保存できない、再委託先が監査条項を受けない、退出形式を提供できない場合、契約範囲を縮めるか受注を見送る判断が必要です。
反対に、回答データと証拠を標準化できれば、顧客ごとの質問票作業を減らし、金融機関に対してサービスの透明性と復旧可能性を示せます。DORA対応を法務コストだけでなく、規制産業へ提供するための製品要件として扱います。
ゼロトラスト導入ロードマップ で自社のアクセス統制を点検し、SBOMとソフトウェア供給網 でソフトウェア依存関係の証拠を補います。DORA付属契約へ広い約束を書く前に、製品・運用が実行できる範囲を確認します。
まとめ
DORA対応は、EU法の文言を日本語の契約へ貼り付ける仕事ではありません。金融機関の重要機能とICTサービスを結び、情報登録、契約、証拠、再委託、事故連絡、退出を一つの運用へそろえる仕事です。
日本のSaaS企業が最初に完成させるべき成果物は、条文一覧ではなく、顧客・契約・サービス・場所・再委託・証拠・通知・退出を同じIDで追えるDORA対応台帳です。そこから契約と演習を更新します。
参考情報
以下は2026年9月1日に確認した一次情報です。
よくある質問 気になる質問を開くと、本文の重要点を短く確認できます。
Q EUに拠点がない日本のSaaS企業もDORA対応が必要ですか？ A DORAの直接義務主体かだけでなく、EU金融機関へICTサービスを提供しているかを確認します。顧客の情報登録、契約、監査、再委託管理を通じて対応を求められる場合があります。契約法人、利用機能、提供国を顧客と確認します。
Q ISO 27001やSOC 2があればDORA付属契約は不要ですか？ A 不要にはなりません。認証・監査報告は統制の証拠になりますが、顧客固有の事故通知、監査権、再委託変更、データ返還、退出支援などの契約要件を自動的に満たしません。
Q DORAのRegister of Informationには何を回答しますか？ A 顧客指定テンプレートに従い、契約、ICTサービス、提供法人、提供国、データ処理・保管場所、支援機能、再委託などを回答します。自由記述ではなく、契約・構成台帳と一致する根拠付きデータにします。
Q 再委託先を全て顧客へ開示する必要がありますか？ A 契約とサービスの重要性により確認範囲が変わります。少なくとも重要機能を支える再委託の機能、場所、データ、依存関係、変更通知を顧客が評価できる形にし、機密情報の扱いと開示方法を契約で決めます。
Q 顧客の現地監査を全て受け入れなければなりませんか？ A 通常確認を共同監査や独立報告書で効率化する設計は可能ですが、重大事故、疑義、監督当局要請を含めて個別確認を全面的に排除できるとは限りません。代替証拠と個別監査の発動条件、範囲、安全、費用を決めます。
Q DORA対応の完了を何で測ればよいですか？ A 契約締結率だけでなく、回答根拠付与率、再委託先不明件数、事故連絡到達率、監査証拠提出時間、退出試験成功率、期限超過例外を測ります。書面と実行の両方が合格して完了です。
Q 顧客ごとに異なるDORA質問票へ毎回ゼロから答えますか？ A 質問文は違っても、サービス名、提供法人、機能、データ所在、再委託先、復旧目標、事故連絡、監査証拠、退出支援の基礎事実は共通化できます。顧客固有の契約要求だけを差分として審査すると、回答速度と整合性を両立できます。
