SCS評価制度のバックアップ要件を満たす ― 遠隔地保管・リストア手順書・復元テストの実装
SCS評価制度の全体像については SCS評価制度 対策ガイド もあわせてご覧ください。
SCS評価制度のセルフチェックで、多くの企業が「はい」と答えたくなるのがバックアップの項目です。「クラウドを使っているから大丈夫」「毎晩NASに取っている」——しかし要求事項を正確に読むと、★3の時点で求められているのはそれだけではありません。
- バックアップの取得対象・頻度・保管期間が設定されていること
- 重要な機密情報の遠隔地バックアップがあること
- リストア手順書が整備されていること
そして★4では、**「リストア手順書どおりに、かつ目標復旧時間（RTO）内で復元できることを実際に確認する」**ことが加わります。
この記事では、これらを中小企業の環境でどう実装するかを整理します。
要求事項の整理
| 項目 | ★3 | ★4 |
|---|---|---|
| バックアップの取得 | 対象・頻度・保管期間を設定して実施 | 同左 |
| 遠隔地バックアップ | 重要な機密情報について必要 | 同左 |
| リストア手順書 | 整備が必要 | 同左 |
| 目標復旧レベルの設定 | 事業継続上重要なシステムについて設定 | RPOまで戻せるようバックアップを保管 |
| 復元の実地確認 | ― | 手順書どおり・RTO内で復元できることを確認 |
★3の時点で「取得・遠隔地・手順書」の3点が揃っている必要があります。**★4で加わるのは「本当に戻せるかを試すこと」**です。
よくある誤解：「M365 / GWSを使っているからバックアップは不要」
最も多い誤解です。クラウドサービスはインフラ障害からのデータ保護は行いますが、利用者側の操作に起因するデータ消失は責任範囲外というのが基本的な考え方（責任共有モデル）です。
| 起こりうること | クラウド標準で守れるか |
|---|---|
| データセンター障害 | 守れる（冗長化） |
| 誤削除（ごみ箱の保持期間内） | 復元可能 |
| 誤削除（保持期間経過後） | 戻せない |
| 退職者アカウント削除に伴うデータ消失 | 戻せない場合がある |
| ランサムウェアによる暗号化ファイルの同期 | 版管理で戻せる場合もあるが保証されない |
| 悪意ある内部者による大量削除 | 戻せない場合がある |
★の評価では「取得対象・頻度・保管期間を設定している」ことが問われます。標準機能の保持期間を把握し、それを自社のバックアップ方針として明文化するか、不足するならバックアップサービスを追加するかの判断が必要です（M365のバックアップは必要か、SaaSバックアップ戦略）。
実装ステップ
Step 1. 対象を決める（データの棚卸し）
まず「何を守るか」を決めます。すべてを同じ頻度・同じ期間で守る必要はありません。
| 分類 | 例 | 頻度 | 保管期間 | 遠隔地 |
|---|---|---|---|---|
| 事業継続に不可欠 | 基幹システムのDB、受発注データ | 日次 | 1か月〜 | 必要 |
| 重要な機密情報 | 設計データ、顧客情報、契約書 | 日次 | 3か月〜 | 必要 |
| 業務データ | 部門の共有ファイル | 日次 | 1か月 | 推奨 |
| 個人作業データ | 各自のドキュメント | クラウド同期 | 標準の保持期間 | ― |
「重要な機密情報」に遠隔地バックアップが必要という点が★3の要件です。表の形で方針を書き出せば、そのまま自己宣言の証跡になります。
Step 2. 「遠隔地」をどう確保するか
遠隔地バックアップと聞くと大がかりに感じますが、中小企業では次のいずれかで成立します。
| 方式 | 内容 | コスト感 |
|---|---|---|
| クラウドストレージ | オンプレのデータをクラウドへバックアップ | 容量課金。中小規模なら月数千〜3万円 |
| クラウド間バックアップ | M365 / GWSのデータを別のクラウドへバックアップ | ユーザー課金 |
| 別拠点のNAS | 本社と支店で相互にレプリケーション | 機器費のみ。同一障害の影響を受けない距離か要確認 |
| 外付けHDDのオフサイト保管 | 週次で持ち出し、金庫等に保管 | 最安。運用が属人化しやすい |
ランサムウェア対策の観点では、常時接続されていない（またはイミュータブルな）保管先を1つ持つことが重要です。ネットワーク上のNASだけでは、感染時に一緒に暗号化されます。3-2-1ルールの考え方が参考になります（3-2-1ルールの解説）。
Step 3. リストア手順書を書く
★3の要件で最も抜けやすいのがこれです。「バックアップは取っているが、戻す手順が書かれていない」——中小企業で最も多いパターンです。
手順書に必要な項目は次のとおりです。難しく考える必要はありません。A4で2〜3枚が目安です。
- 対象システムと担当者（不在時の代行者も）
- バックアップの保管場所（サービス名、URL、保管先の物理的な場所）
- アクセスに必要な認証情報の保管場所（パスワード自体は書かない）
- 復元手順（画面遷移レベルで具体的に。スクリーンショットがあるとなお良い）
- 復元後の確認方法（何が見えれば成功か）
- 想定所要時間（＝RTOとの比較材料）
- 関係者への連絡先（ベンダー、業務部門）
認証情報の保管場所は要注意です。バックアップの管理者アカウントが1人の頭の中にしかない、という状態は、その人が不在のときに復旧できないことを意味します。
Step 4. 目標復旧レベルを定める（★3）
★3では「事業継続上重要なシステムについて、サイバー攻撃を念頭に業務の目標復旧レベルを定め、そのレベルまで回復するために必要な対策（待機系の整備、電話・FAX等による代替手段の確保など）を整備していること」が求められます。
厳密なRTO/RPOの算出は不要です。次のように書ければ十分です。
| システム | 止まると困る度合い | 目標復旧時間 | 復旧までの代替手段 |
|---|---|---|---|
| 受発注システム | 半日で業務停止 | 1営業日 | 電話・FAXで受注、復旧後にデータ投入 |
| ファイルサーバ | 1日は凌げる | 2営業日 | クラウド上の直近版を参照 |
| メール | 半日で影響 | 4時間 | 携帯電話・代表アドレス |
「サイバー攻撃を念頭に」という点が重要です。地震・水害を想定したBCPは「拠点が使えない」前提で作られていることが多く、「システムは動くがデータが暗号化された」「感染拡大を防ぐためネットワークを止めた」という状況が抜けています。ここを補うだけで要件に近づきます。
Step 5. 復元テストを実施する（★4）
★4では、手順書どおりに、RTO内で復元できることを実際に確認する必要があります。
全システムを毎年フルリストアするのは非現実的なので、次の設計が現実的です。
- 対象を絞る：ファイルサーバの1フォルダ、基幹システムの検証環境への復元など
- 年1回、日時を決めて実施する（例：毎年10月の第2週）
- 手順書を見ながら、普段作業していない担当者が実施する（手順書の実効性が試せる）
- 所要時間を計測し、記録する
- RTOを超えた場合は、原因と改善策を記録する
時間内に戻せなかった記録は、マイナスではありません。 課題を把握し改善計画を持っていることを示す証跡になります。むしろ「毎年問題なく成功」という記録だけが並ぶほうが、実施の実態を疑われます。
記録として残すもの
| 証跡 | 内容 |
|---|---|
| バックアップ方針 | 対象・頻度・保管期間・保管先の一覧（Step 1の表） |
| バックアップの実行記録 | ジョブの成功／失敗ログ、または管理画面のスクリーンショット |
| リストア手順書 | 版数・更新日入り |
| 目標復旧レベルの定義 | Step 4の表 |
| 復元テスト記録（★4） | 実施日・実施者・対象・所要時間・結果・課題 |
バックアップの失敗を検知する仕組みがあるかどうかも問われます。ジョブが3か月前から失敗していたことに気づかない、という状態では「実施している」とは言えません。失敗時にメール通知が飛ぶ設定にし、その設定画面も証跡にしておきましょう（証跡・監査ログ実装ガイド）。
情シス365による支援
情シス365では、バックアップ設計から復元テストの実施まで支援しています。
- 現状評価： 現在のバックアップ範囲と保持期間を洗い出し、要件とのギャップを明確化
- 設計・構築： クラウドバックアップ、遠隔地保管、ランサムウェア耐性のある構成の設計
- 手順書作成： 実際に戻せる粒度のリストア手順書を作成
- 年次の復元テスト： 実施の代行と記録の整備（★4対応）
まとめ
- ★3の時点で**「取得（対象・頻度・保管期間）」「遠隔地バックアップ」「リストア手順書」**の3点が必要
- ★4では**「手順書どおり・RTO内で復元できることの実地確認」**が加わる
- クラウドを使っているだけではバックアップ要件を満たさない。標準の保持期間を把握し、方針として明文化する
- 遠隔地保管は大がかりでなくてよい。ただし常時接続でない保管先を1つ持つのがランサムウェア対策の要
- リストア手順書はA4で2〜3枚。認証情報の保管場所と想定所要時間を必ず書く
- 復元テストは時間内に戻せなかった記録こそ価値がある。課題と改善策をセットで残す
参考リンク：