取引先からBCPチェックシートへの回答を求められた際、「クラウドを利用しているため問題ありません」という説明だけでは、データ保全の実効性を示せない場合があります。必要なのは、利用サービスの仕様、自社が許容できる停止時間・データ損失量、障害時の対応手順を整理し、根拠資料とともに文書化することです。

本記事では、総務・管理部門や情報システム部門の担当者に向けて、データ冗長性をBCP文書へ記載するための確認項目と、ベンダーへの確認手順を紹介します。 

BCP文書で確認すべき「データ冗長性」とは

データ冗長性とは、同じデータを複数の機器や拠点に保持し、一部に障害が発生してもデータへのアクセスやシステム運用を継続しやすくする仕組みです。ただし、BCPの観点では「複製されているか」だけでなく、どのような事故を想定し、いつまでに、どの時点のデータを使って業務を再開するかまで確認する必要があります。

冗長化・バックアップ・災害復旧の違い

これらは似た言葉ですが、目的が異なります。冗長化だけで、誤削除やランサムウェア感染前の状態へ戻せるとは限りません。

用語主な目的BCP文書で確認する内容
冗長化機器や拠点の障害時にもサービスを継続しやすくする複製先、拠点分散、切り替え方式、障害時の影響範囲
バックアップ削除・破損・改ざん前のデータへ戻す取得頻度、保持期間、世代数、復元手順、復元テスト
災害復旧（DR）大規模障害や災害後にシステム・業務を復旧する代替環境、復旧手順、連絡体制、目標復旧時間

したがって、BCP文書では「データが複数箇所に保存されている」という説明だけで完結させず、バックアップや復元方法も分けて記載することが重要です。

RTO・RPOは自社の業務要件から設定する

RTO（Recovery Time Objective／目標復旧時間）は、業務やシステムをいつまでに復旧させるかという目標です。RPO（Recovery Point Objective／目標復旧時点）は、障害発生時にどの時点までのデータを復元できればよいかを示します。

たとえば、毎日18時にバックアップを取得し、翌日の18時直前に障害が発生した場合、最大で約24時間分の更新データを失う可能性があります。この場合、バックアップ設計上のRPOは最大24時間程度です。

重要なのは、ベンダーが示す数値をそのまま自社のRTO・RPOとして記載しないことです。まず重要業務の停止による影響を整理し、自社として許容できる時間とデータ損失量を決めたうえで、利用サービスや社内運用がその目標を満たせるかを確認します。

SLAはRTOやデータ復元を直接保証するものではない

SLA（Service Level Agreement）は、サービス提供者と利用者の間で合意するサービス水準です。稼働率が99.9％の場合、単純計算では年間約8時間46分の停止に相当します。ただし、SLAの稼働率は通常、一定期間におけるサービス提供状況を示すものであり、個別障害からの復旧時間や、消失したデータをどの時点まで復元できるかを直接示す数値ではありません。

BCP文書では、SLA、サービス側の復旧方針、自社のRTO・RPO、社内の代替手順をそれぞれ確認し、役割を分けて記載します。

BCP文書へ記載するために確認したい6つの項目

取引先への回答や監査資料として説明できる状態にするには、次の6項目を確認します。公開情報だけで判断できない項目は、ベンダーへ問い合わせて根拠資料を取得してください。

1．データの保管地域と拠点分散

データが国内・海外のどこに保管されるか、単一拠点か複数拠点か、地理的に分離されているかを確認します。所在地の詳細がセキュリティ上開示されない場合は、リージョン、国内外の別、災害リスクが共通しない設計かなど、開示可能な範囲で確認します。

2．複製方式と障害時の切り替え

同一拠点内の複製か、離れた拠点間の複製か、同期・非同期のどちらかを確認します。あわせて、障害時に自動で切り替わるのか、復旧操作や利用者側の対応が必要かも確認します。

3．バックアップ・世代管理・復元方法

バックアップの取得頻度、保持期間、世代数、削除済みファイルの保持、バージョン管理の範囲を確認します。復元を依頼する場合の窓口、所要時間、費用、利用者自身で復元できる範囲も記録します。

4．SLA・障害通知・復旧情報

SLAの対象機能、計測方法、除外条件、未達時の取り扱いを確認します。障害発生時の通知方法、ステータスページの有無、復旧状況の更新頻度、事後報告の提供有無もBCPの連絡フローに関わります。

5．データのエクスポートと代替手段

サービス停止や契約終了に備え、データを一括で取り出せるか、出力形式、処理時間、追加費用、契約終了後の保持期間を確認します。重要データについては、別環境へ退避する運用や代替の共有手段も検討します。

6．責任分界と自社側の運用

クラウド事業者が担う範囲と、利用企業が担う範囲を分けます。アカウント管理、アクセス権限、端末対策、誤削除への対応、バックアップ設定、緊急連絡網など、自社側の運用不備で事業継続性が損なわれないよう整理します。

ベンダー確認からBCP文書更新までの手順

手順1．重要業務と対象データを特定する

停止した場合に影響が大きい業務を選び、その業務で利用するファイル、システム、取引先との共有データを洗い出します。すべてのデータを同じ水準で保護するのではなく、重要度に応じて優先順位を付けます。

手順2．業務ごとのRTO・RPOを決める

売上、顧客対応、法令・契約、信用への影響を踏まえ、業務をいつまでに再開する必要があるか、どの程度のデータ損失まで許容できるかを決めます。情報システム部門だけでなく、業務責任者と合意することが重要です。

手順3．サービス仕様と契約条件を確認する

サービス仕様書、利用約款、SLA、サポート資料、管理画面の設定を確認します。不明点はベンダーへ問い合わせ、回答メールや提供資料を保管します。

手順4．自社目標とのギャップを整理する

サービスの機能だけで目標を満たせない場合は、追加バックアップ、代替サービス、手作業での業務継続、復元手順の整備などで補います。

手順5．BCP文書と連絡先を更新する

確認結果をテンプレートへ反映し、確認日、担当部署、根拠資料、次回見直し日を記載します。サービス変更や契約更新時にも再確認できるよう、文書の保管場所と更新責任者を決めます。

手順6．復元・切り替え手順をテストする

文書化だけで終わらせず、定期的にファイル復元、代替端末からのアクセス、緊急連絡、権限付与などを試します。テスト結果と改善点を記録し、BCPを継続的に見直します。

BCPを意識したファイル管理を検討する

BCPでは、災害時だけ利用する仕組みではなく、平時から重要文書を安全に保管し、必要な人が必要な場所からアクセスできる運用を整えておくことが重要です。企業向けオンラインストレージのFleekdriveは、ファイル共有、文書管理、アクセス権限、バージョン管理など、法人のファイル管理に必要な機能を提供しています。

自社のRTO・RPO、データ保全要件、権限設計に適合するかは、最新のサービス仕様書や契約条件を確認したうえで判断してください。具体的な要件がある場合は、資料ダウンロードや問い合わせを通じて確認できます。

まとめ：冗長化の有無ではなく、復旧できる根拠まで記録する

データ冗長性をBCP文書へ記載する際は、「クラウドだから安全」「複数拠点だから復旧できる」といった抽象的な説明を避けます。冗長化、バックアップ、SLA、RTO・RPOの違いを整理し、自社の業務要件とサービス仕様を照合することが必要です。

確認結果、根拠資料、責任者、代替手段、テスト結果まで記録しておけば、取引先への回答や監査時にも説明しやすくなります。BCPは一度作成して終わりではありません。サービスや組織、重要業務の変更に合わせて、定期的に見直してください。