【クラウド法務】BCP データ保護 SLAでトラブルになりやすい3つのポイント― Azure / M365 時代の「クラウドBCP × データ保護 × SLA」をどう結びつけるか ―
- 山崎行政書士事務所
- 2025年12月12日
- 読了時間: 9分
導入：バックアップも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 の記事を見た」 と書いていただけるとスムーズです。
コメント