【クラウド法務】Azure Backup利用時に契約・規程で整理しておきたい3つの点― “バックアップを取っている”から、“復旧できる・説明できる”へ ―

（※本記事は一般的な情報提供であり、個別案件の法的助言ではありません）

────────────────────────────

はじめに

────────────────────────────

Azure Backupを導入すると「バックアップは取れている＝安心」という空気が出ます。ただ、事故・監査・取引先照会で本当に問われるのは次です。

・いつまでに復旧できるのか（RTO）・どこまでのデータ損失を許容するのか（RPO）・誰が、何を根拠に、どう説明するのか（説明責任と証跡）

ここを契約・規程で先に固めないと、バックアップは“あるのに安心できない”状態になります。以下、Azure Backup利用時に最低限整理しておきたいポイントを3つに絞って解説します。

────────────────────────────

1. 復旧のゴール（RTO/RPO）と「復旧できる」の定義────────────────────────────

なぜ重要か

バックアップは「保存」です。BCPで必要なのは「復旧」です。ダッシュボードが緑でも、復旧の順番・権限・手順・テストがなければ、取引先にも監査にも説明できません。

ここを決める（最低限）

・対象システムごとのRTO（何時間で戻す必要があるか）・対象システムごとのRPO（どこまで戻れれば許容か）・復旧の優先順位（どれから戻すか）・復旧の成否判定（“復旧完了”はログイン可能？業務処理可能？データ整合性確認まで？）・復旧実行の権限（誰が復旧操作を行い、誰が承認するか）・復旧テストの頻度と証跡（年1回なのか、四半期なのか、変更時は必須なのか）

契約で固めるべき要点（委託がある場合）

委託先（MSP等）に任せるなら「監視」だけでなく、復旧支援の範囲を明文化しないと揉めます。

・復旧作業の範囲（どこまでやる／どこから先は自社判断か）・対応時間帯（平日日中のみか、夜間休日も含むか）・一次通知とエスカレーション（検知→報告→指揮命令の流れ）・復旧操作に必要な権限付与の前提（緊急時の特権アクセスの扱い）・復旧テストの支援（準備・実施・結果報告は含むか／別料金か）・追加費用が発生する条件（緊急対応、長時間対応、調査協力、報告書作成など）

規程（社内ルール）に入れるべき要点

・BCP発動の判断者（誰が「復旧開始」を宣言するか）・復旧時の承認ルート（情シスだけで独断しない）・復旧手順書の管理（更新責任者、更新タイミング）・復旧テスト結果の保管（どこに、何年、誰が保管）・取引先・社内向け報告（誰が文章を出すか）

────────────────────────────

2. バックアップデータの取扱い（保持・削除・保全・権限）────────────────────────────

なぜ重要か

バックアップは「最重要データの塊」です。ここが弱いと、事故時に最後の砦が壊れます（侵害者に消される／期限で消える／必要な時点が残っていない）。

ここを決める（最低限）

・保持期間（業務・監査・契約要件と整合。30日で足りるのか、年単位が必要か）・削除の統制（誰が削除できるか、二重承認にするか、緊急時の例外）・保全（リーガルホールド相当）の扱い　- 事故・紛争・内部不正の疑いが出たとき「消さずに凍結する」手順があるか・暗号化と鍵の責任者（誰が鍵を管理し、引継ぎ・変更・事故時にどうするか）・権限分離（バックアップ設定変更・削除権限を、通常運用と分けるか）

契約で固めるべき要点（委託がある場合）

委託先がバックアップ領域に触れるなら、特権アクセスの統制を契約に落とします。

・削除・設定変更ができる権限の付与条件（期限付き、承認付き、個人アカウント）・操作ログの提出義務（いつ誰が何をしたか）・誤削除・誤設定時の責任分界（是正、復旧支援、報告義務）・契約終了時の出口（委託先が持つ情報・設定・ログの引渡し、アクセス剥奪の証明）

規程（社内ルール）に入れるべき要点

・保持期間の決定プロセス（誰が決め、どの根拠で見直すか）・削除・変更の承認フロー（誰が承認し、何を記録するか）・保全（凍結）手順（発動条件、指示系統、保全対象、保全解除条件）・棚卸し（バックアップ対象が増減したときの反映ルール）

────────────────────────────

3. 証跡・監査・事故対応の「提出能力」（ログ／報告／協力義務）────────────────────────────

なぜ重要か

事故の初動で求められるのは、「原因の完全特定」よりも先に**“いま説明できる事実”**です。つまり「証跡が出せるか」「保全できるか」「報告書が出せるか」が勝負になります。

ここを決める（最低限）

・監査で出す“証跡パック”の定義（何を出すか）　例：　- バックアップ設定（対象・頻度・保持）- 実行結果（成功/失敗の履歴）- 復旧テスト記録（いつ・誰が・何を・結果どうだったか）- 変更履歴（誰が設定を変えたか）・提出期限（取引先・監査に「何営業日以内に出せるか」）・事故時の保全協力（必要な期間のデータを凍結できるか）・報告のテンプレ（一次報告／詳細報告／再発防止）

契約で固めるべき要点（委託がある場合）

委託先が運用・監視・SIEM等に関与するなら、ここが“空白”だと説明不能になります。

・一次通知（検知から何分以内、どのチャネルで）・ログ提出義務（提出期限・形式・対象範囲）・保全協力（削除停止・隔離・抽出者記録への協力）・調査協力（原因分析、再発防止情報の提供、報告書作成協力）・再委託（国外SOC等）の扱い（条件・範囲特定・監督責任）・目的外利用の禁止（ログ・バックアップ情報をサービス改善/学習等に使わない、使うなら条件とオプトアウト）

規程（社内ルール）に入れるべき要点

・事故時の指揮命令系統（情シス→CSIRT→法務→経営など）・証跡の保管場所と保管責任者・取引先回答の責任者（“誰が文章を出すか”）・例外運用（緊急復旧の権限付与や手順変更）の台帳化と期限管理

────────────────────────────

まとめ：3点を揃えると「取っている」から「説明できる」に変わる────────────────────────────

Azure Backup利用時に、契約・規程で整理しておきたい3つの点は次です。

1）復旧のゴール（RTO/RPO）と「復旧できる」の定義（手順・権限・テストまで）

2）バックアップデータのガバナンス（保持・削除・保全・権限分離）

3）証跡と提出能力（監査・取引先・事故時に出せるログ／報告／協力義務）

この3点が揃って初めて、Azure Backupは“取っていれば安心”ではなく、「復旧できることを説明できる」バックアップになります。