この記事を読むと
- DORAとは何か、EU金融機関だけでなくSaaSやクラウド委託先にどう波及するかがわかります。
- DORA ICT third-party registerテンプレート、クラウド委託管理、出口戦略の考え方を整理できます。
- Cyber Resilience Act、SBOM、VEX、CycloneDX、GitHub Actionsを実務証跡としてどう準備するかがわかります。
この記事の監修者
宮﨑 一旗
宅地建物取引士 / 連続起業家 / 株式会社ライフワンネクスト取締役
宅地建物取引士(登録番号:(神奈川)第129630号)。補助金SEOメディア「補助金プラス」運営、AIスタートアップAtlas株式会社共同創業者。不動産・住宅領域のSEO/LLMOコンサルティングと記事監修を行う。
プロフィールを見る最新確認：DORAは2025年1月17日から適用済み
DORAはすでにEUで適用されています。EIOPAのDORAページは、DORAが2025年1月17日に適用開始され、金融機関がICT障害、サイバー攻撃、システム障害に耐え、対応し、復旧できるようにする規則だと説明しています。
- 直接の対象はEU金融機関ですが、SaaS、クラウド、監視、ID基盤などのICT委託先にも契約・証跡要求が波及します。
- 金融顧客を持つSaaSは、DORAのRegister of Information、再委託、出口戦略、インシデント対応の説明を求められやすくなります。
- CRA、SBOM、VEXはDORAそのものではありませんが、ソフトウェア証跡を整えるうえで同時に見たい実務論点です。
DORAとは金融のICTリスク管理を統一するEU規則
DORAとは、EU金融セクター向けのデジタル運用レジリエンス規則です。金融機関がICTリスク管理、インシデント報告、レジリエンス試験、ICT第三者リスク管理、情報共有を整えるための枠組みです。
| 検索で知りたいこと | 実務での答え | SaaS側の準備 |
|---|---|---|
| DORAとは？ | EU金融機関のICTリスクと運用レジリエンスを管理する規則です。 | 金融顧客に出す委託先情報を整える |
| 日本SaaSに関係ある？ | EU金融機関にサービス提供する場合、契約・監査・委託先管理の要求が波及します。 | サブ委託、SLA、BCP、出口戦略 |
| CRAやSBOMも必要？ | DORAと別制度ですが、ソフトウェア製品やサプライチェーン証跡として同時に準備すると説明しやすくなります。 | SBOM、VEX、脆弱性対応ログ |
DORAは金融機関向けの規則ですが、金融機関が使うSaaS、クラウド、セキュリティ製品、監視サービス、ID基盤、メール配信、決済関連サービスに実務上の影響が出ます。金融顧客から「委託先情報を出してください」「再委託一覧を更新してください」「出口戦略を説明してください」と求められる場面が増えるためです。
この記事では、DORAの定義だけでなく、DORA ICT third-party registerテンプレート、クラウド委託管理SaaS、Cyber Resilience Actのソフトウェア対象、SBOM/VEX/CycloneDX/GitHub Actionsまで、実装と実務の視点で整理します。
DORAとは金融機関だけでなくICT委託先に波及する規則
DORAは、EU金融機関のICTリスク管理を統一するための規則です。銀行、保険、投資会社などの金融機関は、サイバー攻撃やシステム障害が起きても重要な業務を継続・復旧できるように、ICTリスク管理体制を整える必要があります。
日本企業にとって重要なのは、DORAの直接対象かどうかだけではありません。EU金融機関へSaaSを提供する場合、その金融機関がDORAに対応するために、委託先であるSaaS企業へ情報提供や契約対応を求める可能性があります。特に、クラウド基盤、監視、ID、サポート、データ保存、再委託、障害時の連絡体制は確認されやすい領域です。
DORA ICT third-party registerテンプレート：SaaS側が先に揃える項目
EBAのRegister of Information ITSは、金融機関がICT第三者サービス提供者との契約関係について維持・更新すべきテンプレートを定めるものです。また、EBAのDORA register準備ページは、DORAが2025年1月17日に適用され、対象金融機関はICT第三者との契約関係を包括的に登録しておく必要があると説明しています。
SaaS企業は、金融機関が台帳を作る時に必要な情報を先に整えておくと、商談や更新契約で詰まりにくくなります。
| 台帳項目 | 金融顧客が知りたいこと | SaaS側が用意する資料 |
|---|---|---|
| 契約ID・契約主体 | どの契約がどのICTサービスに対応するか。 | 契約書、SLA、注文書、サービス記述書 |
| ICT機能 | 本人確認、決済、監視、データ保存など、どの業務を支えるか。 | サービス概要、機能一覧、重要機能への該当性 |
| 委託先識別子 | 委託先企業を一意に識別できるか。 | 法人情報、LEIがある場合はLEI、所在地、連絡先 |
| サブ委託 | クラウド、CDN、監視、メール、サポートを再委託しているか。 | サブプロセッサ一覧、リージョン、変更通知手順 |
| 出口戦略 | 契約終了時に移行・データ返却・削除ができるか。 | データエクスポート、削除証明、移行支援手順 |
DORAクラウド委託管理SaaS：再委託と出口戦略を説明する
金融顧客がSaaSを見る時、アプリケーション機能だけでなく、その裏側のクラウド、監視、ログ、バックアップ、サポート、データ所在地も確認します。DORAのICT第三者リスク管理では、重要機能を支える委託先を継続的に把握する必要があるためです。
SaaS側が準備しておきたい資料は次の通りです。
- クラウド構成: 利用クラウド、リージョン、可用性ゾーン、バックアップ方針。
- サブプロセッサ一覧: CDN、監視、メール配信、ID、サポート、決済など。
- BCP/DR: RTO、RPO、障害連絡、復旧訓練、ステータスページ。
- セキュリティ証跡: SOC2、ISO 27001、脆弱性診断、ペネトレーションテスト、ログ保存。
- 出口戦略: データエクスポート、削除、移行支援、アカウント停止後のデータ保持。
金融顧客向けには、これらを営業資料ではなく「委託先管理パック」としてまとめると実務で使いやすくなります。契約前のセキュリティチェック、年次レビュー、インシデント時の説明に同じ資料を再利用できます。
Cyber Resilience Actソフトウェア対象とDORAの関係
DORAと同時に見たいEU規制がCyber Resilience Actです。欧州委員会のCyber Resilience Actページは、CRAがデジタル製品をサイバー脅威から守るためのEUの規則で、2024年12月10日に発効し、主な義務は2027年12月11日から、報告義務は2026年9月11日から適用されると説明しています。
CRAの概要ページは、ネットワークやデバイスへ直接または間接に接続する目的・合理的に予見可能な利用を持つ「products with digital elements」が対象になると説明しています。クラウドSaaS単体が常にCRA対象になるとは限りませんが、ソフトウェア製品、エージェント、デスクトップアプリ、モバイルアプリ、接続機器、製品に付随するリモートデータ処理は注意が必要です。
| 規制 | 主な対象 | SaaS/ソフトウェア企業が見る実務 |
|---|---|---|
| DORA | EU金融機関とICT第三者リスク管理。 | 金融顧客向けの委託先情報、再委託、障害対応、出口戦略。 |
| CRA | EU市場に出されるデジタル要素を持つ製品。 | 脆弱性報告、セキュア開発、SBOM、技術文書、CEマーキング。 |
| 共通準備 | サプライチェーンと脆弱性対応の証跡。 | SBOM、VEX、依存関係管理、GitHub Actionsでの継続生成。 |
SBOM VEX CycloneDX GitHub Actions：監査証跡をCIで作る
SBOMはソフトウェア部品表です。VEXは、その脆弱性が特定製品の文脈で実際に悪用可能か、影響があるかを伝えるための情報です。CycloneDXのVEXページは、VEXが脆弱性の実際の悪用可能性を文脈に沿って示し、不要な対応を減らして優先順位付けを助けると説明しています。OpenSSFのOpenVEXも、VEXを最小限で相互運用可能な形式として説明しています。
GitHubを使っている場合、まずはGitHub ActionsでSBOMを継続生成し、成果物として保存する運用から始めます。GitHubのdependency submission APIは、ビルド時に解決された依存関係をGitHub Actionsから送信できると説明しています。
# 例：SBOMをGitHub Actionsで生成し、成果物として保存する考え方
name: sbom
on:
push:
branches: [ main ]
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
path: .
format: cyclonedx-json
output-file: sbom.cdx.json
- name: Upload SBOM artifact
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.cdx.json
VEXは、単にスキャナ結果から自動で作ればよいものではありません。脆弱性が自社製品で悪用可能か、影響しない理由は何か、修正済みか、回避策があるかを判断する必要があります。DORAやCRA対応では、SBOMとVEXを「出せます」と言うだけでなく、いつ、どのリポジトリで、どのバージョンに対して生成し、誰が判断したかを残すことが大切です。
DORA対応の社内チェックリスト
金融顧客向けSaaSのDORA準備パック
- 契約: SLA、障害連絡、監査権、再委託変更通知、終了時データ返却。
- 台帳: ICT機能、契約ID、委託先識別子、サブ委託、リージョン。
- 運用: BCP/DR、インシデント報告、脆弱性管理、復旧訓練。
- 証跡: SOC2/ISO 27001、ペンテスト、脆弱性対応ログ、監査レポート。
- ソフトウェア: SBOM、VEX、依存関係更新、GitHub Actionsの生成履歴。
- CRA確認: EU市場向けソフトウェア製品に該当するか、報告義務の準備が必要か。
DORA対応で重要なのは、規制名を知ることより、金融顧客に説明できる証跡を毎月更新できる状態にすることです。SaaS企業は、セキュリティ質問票に都度回答するだけでなく、DORA/CRA/SBOMを見据えた標準パックを作ると、営業と監査の両方が楽になります。
DORAとは実務でよくある質問
DORAとは何ですか？
DORAとは、EU金融セクターのICTリスク管理とデジタル運用レジリエンスを統一する規則です。2025年1月17日から適用されています。
DORAは日本のSaaSにも関係しますか？
直接対象ではなくても、EU金融機関にSaaSやクラウド関連サービスを提供する場合、委託先管理、再委託、障害対応、出口戦略などの情報提供を求められる可能性があります。
DORA ICT third-party registerとは何ですか？
金融機関がICT第三者サービス提供者との契約関係を管理する台帳です。契約、ICT機能、委託先識別子、サブ委託、出口戦略などを記録します。
Cyber Resilience ActとDORAは同じですか？
別制度です。DORAは金融セクターのICTレジリエンス、CRAはEU市場に出されるデジタル要素を持つ製品のサイバーセキュリティを扱います。ただし、ソフトウェア証跡や脆弱性対応では重なる準備があります。
SBOMとVEXはDORA対応に必要ですか？
DORA本文がすべてのSaaSにSBOM/VEXを直接求めるというより、金融顧客がサプライチェーンと脆弱性対応の証跡として求める可能性があります。CRA対応も見据えるなら、CIでSBOMを生成し、VEX判断を残す運用が有効です。
出典・一次情報
- EIOPA: Digital Operational Resilience Act (DORA)
- EBA: ITS to establish templates for the register of information
- EBA: Preparations for reporting of DORA registers of information
- EUR-Lex: Digital operational resilience for the financial sector
- European Commission: Cyber Resilience Act
- European Commission: CRA summary
- European Commission: CRA reporting obligations
- CycloneDX: Vulnerability Exploitability eXchange
- OpenSSF: OpenVEX
- GitHub Docs: Dependency submission API
最終確認日：2026年6月19日。DORA、CRA、SBOM/VEXの要求は業種、契約、製品形態、EU市場での提供方法により変わります。具体的な適用判断は公式情報と専門家確認を前提にしてください。