【クラウド法務】BCP データ保護 SLAでトラブルになりやすい3つのポイント― Azure / M365 時代の「クラウドBCP × データ保護 × SLA」をどう結びつけるか ―

導入：バックアップもDRもある。でも「BCP データ保護 SLA」として大丈夫かは誰も答えられない

クラウド環境での BCP・データ保護対策は、Azure / M365 や各種SaaSのドキュメントが充実しており、冗長化・バックアップ・多リージョン構成といった 技術的な情報 は探せば一通り揃います。

しかし、全国の情シス・IT部門の方から相談を受けていると、次のような声を非常によく耳にします。

「バックアップも DR も一応入れたが、BCP データ保護 SLA としてどう整理していいか分からない」「“重要データはクラウド上で守られています” と言ってきたが、実際の復旧時間・復旧範囲・責任分界があいまいなまま になっている」「監査や大口取引先から “BCP上のデータ保護 SLA を出してほしい” と言われても、クラウド事業者・ベンダー・自社の責任をどう切り分けるか説明しきれない」

本記事では、「BCP データ保護 SLA × クラウド法務」 という視点から、全国の製造業・SaaS・IT企業の案件で実際に見えてきた よくある落とし穴 と、実務で使える 整理のフレーム をご紹介します。

1. クラウドBCPにおける「データ保護」の実態整理（技術の“事実”）

まずは、「技術としてどうなっているか」をざっくりと言語化しておきます。多くの企業での クラウドBCP × データ保護構成 は、次のようなイメージです。

• インフラ・アプリ構成

  • 基幹系・業務系：Azure VM / App Service / Azure SQL / Storage

  • コラボ・メール：M365（SharePoint / OneDrive / Exchange / Teams）

  • 一部はSaaS（CRM / ERP）を併用

• データ保護の仕組み

  • Azure Backup / サードパーティ製バックアップ

  • Geo冗長ストレージ（GRS / GZRS）

  • M365 バックアップ（標準保持＋外部サービス）

  • ログ・監査証跡は Log Analytics や SIEM で保管

• BCP/DR対策

  • 別リージョンへのレプリケーション（Site Recovery 含む）

  • 月次・年次バックアップによる長期保管

  • 障害検知・アラート・一部自動切替

このあたりまでは、多くの企業で 「技術構成図」 としてきれいに整理されています。

しかし一方で、次のような “BCP データ保護 SLA の図” が存在しないケースが非常に多いのが実情です。

• データ種別ごとに「どの時点まで（RPO）」「どの時間内に（RTO）」「どこまで復旧するか」 を整理した表

• 障害・災害時にクラウド事業者・ベンダー・自社の責任範囲を切り分けた責任分界図

• 取引先・監査・親会社に対してどのレベルまでを “BCP データ保護 SLA” として約束できるか を示した資料

ここまでは“技術構成”としてのクラウドBCP図はあっても、「BCP上のデータ保護 SLA として、どこまで誰が責任を持つのか」 が抜けがちです。

ここから先が「BCP データ保護 SLA × クラウド法務」の話になります。

2. 全国の案件で見えてきた「BCP データ保護 SLA」の落とし穴3選

代表的なものを3つだけ挙げると、次のようなパターンです。

① 「バックアップがある＝BCPとしていつでも戻せる」と思い込んでいる

技術的にはOK

• 重要サーバやDBは毎日バックアップ

• ジョブ失敗時はアラートが飛び、運用ベンダーが一次対応

BCP・SLA的にはNGになりうる点

• 実際の復旧には、

  • 復元対象の特定

  • データ量・ネットワーク帯域に応じた復元時間

  • アプリケーションの整合性確認

  • ユーザー部門による動作確認・棚卸などが必要で、設計値よりずっと時間がかかることが多い

• にもかかわらず、「バックアップがあるので、データはいつでも戻せます」「BCP上、データ消失リスクはありません」といった表現で社内・取引先に説明すると、SLA上の期待値と現実のギャップ が生まれる

② クラウド事業者の耐久性・可用性 ＝ 自社の「データ保護 SLA」だと思っている

技術的にはOK

• Azure ストレージの耐久性（99.999999999％）

• サービス可用性（99.9% など）を把握している

法務・契約的にはNGになりうる点

• これらはあくまで「クラウド基盤としての耐久性・可用性」 の話であり、自社の設計ミス・運用ミス・ユーザー誤操作による消失をカバーしない

• それにもかかわらず、「クラウドは 11ナインで安全だから、データ保護もそれと同等」と説明してしまうと、

  • 誤削除・誤上書き

  • 誤った保持期間設定

  • 容量不足によるバックアップ失敗など 人・設計起因のリスク を度外視したデータ保護 SLA になりかねない

③ 法令・契約・社内規程で求められる「保存期間」と実際のクラウド設定がずれている

技術的にはOK

• コストを考慮して、

  • 90日バックアップ保持

  • ログは 180日でローテーションといった設定を採用

コンプラ・契約的にはNGになりうる点

• 個人情報・会計データ・取引記録などについて、法令・業界ガイドライン・取引先契約では1〜7年単位の保存を求められる ケースが普通にある

• M365 の標準保持と、自社の「メール○年保管方針」「監査証跡○年保存」との間で矛盾が生じがち

• 結果として、「BCPとしては守れているつもりだが、データ保護 SLA と法令・契約が噛み合っていない」という危うい状態になる

3. BCP データ保護 SLA を考えるときの「整理のフレーム」3つ

技術構成をいじる前に、最低限、次の3つを紙に落としておくと、その後のベンダー調整・社内説明・契約見直しが格段に楽になります。

① データ分類 × 保存場所 × RPO/RTO を1枚に落とす

まずはデータをざっくり分類し、一覧化します。

• データ分類の例

  • 基幹データ（受発注・請求・在庫など）

  • 個人情報を含むデータ

  • ログ・監査証跡

  • ナレッジ・ドキュメント（M365上のファイル等）

• それぞれについて

  • どこに保存しているか（Azure SQL / Blob / M365 / SaaS など）

  • RPO（どこまで遡れるか：1時間前まで／前日まで 等）

  • RTO（どれくらいで復旧できるか：2時間／24時間 等）

  • 法令・契約・社内規程上の保存期間

「データ分類 × 保存場所 × RPO/RTO × 保存期間」 を1枚で見える化すると、どこまでを BCP データ保護 SLA として約束できるかが見えやすくなります。

② クラウドSLA／ベンダーSLA／自社BCP データ保護 SLA を分けて整理する

• クラウド事業者（Microsoft等）のSLA

  • ストレージ・Backup・DB・SaaS の可用性・耐久性

• ベンダー（構築・運用）のSLA／責任範囲

  • バックアップジョブ監視・設計・設定変更・障害調査

  • 復旧作業に着手するまでの時間

• 自社として対外的に約束する「BCP データ保護 SLA」

  • “この種のデータ” を “この時間軸まで” “この時間内で” 復旧する

  • 復旧不能時の取り扱い（代替手段・賠償上限・免責条件）

この3つを混ぜずに整理することが、「どこまでなら責任を持てるか」 を冷静に決めるうえで重要です。

③ BCPシナリオごとの「誰が・どこまで・いつまでに」を文書化する

BCP データ保護 SLA は、“平常時の設計” だけでなく、シナリオごとの対応フロー とセットで設計する必要があります。

• 典型的なシナリオ

  • 誤削除（ユーザーの誤操作）

  • システム障害・ランサムウェア等によるデータ破損

  • リージョン障害・災害による広域停止

• 各シナリオで整理すべきこと

  • 誰がインシデントを検知するか（監視／ユーザー申告等）

  • 誰が復旧方針（どの時点まで戻すか）を決めるか

  • 誰が実作業を行うか（ベンダー／情シス）

  • どこまで確認したら “復旧完了” と見なすか（事業部門のOK 等）

これを BCP計画・インシデント対応手順・SLAの説明資料 に反映させることで、「バックアップはあるが、誰も動けない」という事態を避けやすくなります。

4. ケーススタディ：BtoB SaaS企業A社（売上120億円、契約社数約400社）の場合

実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。

• 業種：BtoB SaaS（業務支援クラウドサービス）

• 売上規模：約120億円

• 契約社数：約400社（うち上場企業多数）

• テーマ：クラウドBCPのデータ保護を前提にした「BCP データ保護 SLA」の再設計

課題の整理

• サービス基盤は Azure 上に構築、Azure Backup／Site Recovery も導入済み→ 技術構成はそれなりに整っている

• しかし、取引先向けには「重要データは全てクラウド上で保護」「BCP対策済み」とだけ説明しており、どのデータをどこまで復元できるかの定義がない

• 一部の大口顧客から、「BCP データ保護 SLA の明示」「ランサムウェア発生時の復旧方針」などを求められ、営業・情シス・法務の間で回答調整に時間がかかっていた

当事務所の支援内容（抜粋）

• データ分類とクラウド構成の棚卸し

  • 顧客データ・ログ・設定情報・監査証跡などを分類

  • それぞれが Azure / M365 / 外部SaaS のどこに保管されているか整理

• RPO/RTO・保存期間・法令要件の整理

  • 顧客契約・自社規程・業界ガイドラインを踏まえ、データ種別ごとに求められる保存期間・復旧要件を明文化

• BCP データ保護 SLA のドラフト作成

  • サービス標準のデータ保護 SLA を策定（例：「申告から○時間以内に直近○時間以内のデータまで復旧を試みる」 等）

  • 大口顧客向けのオプション（より短いRPO/RTO）の設計

• 社内・顧客向け説明資料の作成支援

  • 営業向け「BCP データ保護 SLA 説明スライド」

  • 顧客・監査向けの技術＋契約をまとめた資料

  • インシデント対応フロー図

結果として

• 「どのデータを」「どこまで」「どの時間内で」復旧できるか を自信を持って説明できるようになり、営業・情シス・法務の認識が揃った

• 大口顧客との契約交渉でも、どこまでが標準・どこからが有償対応かを整理して提案できるようになった

• 監査や親会社からの「BCP データ保護体制」の質問にも、技術構成とSLA・規程をセットにした “一枚絵” で回答できるようになった……といった声をいただいています。

5. BCP データ保護 SLA を検討・見直すときのチェックリスト

自社で検討を進める際のチェックリストとして、次の項目を挙げておきます。

• □ 重要データ・ログ・監査証跡などを データ種別ごとに分類 できている

• □ それぞれのデータについて、　 保存場所（Azure / M365 / SaaS 等）・保存期間・RPO/RTO を一覧化できている

• □ Microsoft 等の クラウドSLAと、自社のBCP データ保護 SLA を明確に分けて説明 できる

• □ 誤削除・ランサムウェア・リージョン障害などのシナリオごとに、　 「誰が・どこまで・いつまでに・どう復旧するか」 が文書化されている

• □ 営業資料・契約書・社内規程・BCP計画のあいだで、　 「約束しているデータ保護レベル」と「実際にできる復旧レベル」が一致している

「すべて自信を持って YES と言える企業」は、全国的に見てもまだ多くありません。

6. 全国からのご相談について

山崎行政書士事務所では、Microsoft Azure / M365 等のクラウド構成と、BCP・データ保護・SLA・契約・監査対応をセットで整理する「クラウド法務支援」 を行っています。

• クラウドBCPを進めてきたが、データ保護 SLA と法令・取引先契約・社内規程の整合が不安

• Azure / M365 上のデータ保護構成を、RPO/RTO・保存期間・責任分界の観点から棚卸ししたい

• 監査・親会社・大口取引先からの質問に、技術と契約をセットにした “BCP データ保護” のストーリーで答えられるようにしたい

といったお悩みがあれば、オンライン（全国対応） にて初回のご相談を承っております。

👉 ご相談フォームはこちら

👉 お問い合わせの際に、「BCP データ保護 SLA の記事を見た」 と書いていただけるとスムーズです。