SCS評価制度★3のバックアップ要件は、「取得していること」ではなく必要なときに実際に戻せることを説明できるかで見られます。対象範囲・保存世代・保管先・復元手順を文書化し、年1回以上の復元テストの記録を残すところまでが1セットです。Microsoft 365やGoogle Workspaceを使っていても、標準の保持機能はバックアップの代わりにはなりません。
SCS評価制度の★取得について、現状アセスメントからギャップ分析、技術対策の実装、申請サポートまでをワンストップでご支援しています。
SCS評価制度 対応支援 を見る →SCS評価制度 総合ガイド「取っている」だけでは要件を満たさない
SCS評価制度★3の26要求事項には、重要データのバックアップに関する項目が含まれます。ここでつまずく企業の多くは、バックアップを取っていないのではありません。取ってはいるが、要件が問う水準を説明できないという状態です。
自己評価の場面で実際に詰まるのは、次のようなパターンです。
- バックアップは動いているが、何が対象で何が対象外かを誰も説明できない
- 同じ場所に上書きしており、世代が1つしかない
- 取得はしているが、復元を試したことが一度もない
- 設定した担当者が退職しており、手順が残っていない
- クラウドを使っているのでバックアップは不要だと思っていた
いずれも「バックアップの有無」ではなく、設計と運用の記録が欠けていることが問題です。逆に言えば、既存の仕組みのままでも整理と記録で満たせる部分が少なくありません。
問われるのは取得・保管・復元の3点
バックアップの要求は、大きく3つの観点に分解できます。それぞれで「決めているか」「記録があるか」を問われると考えてください。
| 観点 | 問われること | よくある不足 |
|---|---|---|
| 取得 | 何を、どの頻度で取得するか決めているか | 対象が曖昧。ファイルサーバだけでSaaSや端末が抜けている |
| 保管 | どこに、何世代、どれだけの期間保管するか | 同一サーバ・同一拠点のみ。1世代上書きで過去に戻れない |
| 復元 | 実際に戻せることを確認しているか | 復元テスト未実施。手順が担当者の頭の中にしかない |
なお、個々の評価基準の文言はIPAが公開する★3の評価基準（81基準）に定義されています。本記事はその文言の解説ではなく、要求を満たすために実務でどう設計するかを整理したものです。申請前には必ず公開されている最新の基準を参照してください。
何をバックアップ対象にするか
対象を決める基準は「価値が高いもの」ではなく、失うと業務が止まるものと二度と再作成できないものの2つです。
| 対象 | 優先度 | 見落としやすい点 |
|---|---|---|
| 基幹業務システムのデータ | 高 | アプリの設定・マスタが別管理になっていることがある |
| ファイルサーバ／共有ストレージ | 高 | アクセス権情報まで戻せるか |
| メール・クラウドストレージ（M365／Google Workspace） | 高 | 標準の保持機能をバックアップと誤解している |
| サーバ・ネットワーク機器の構成情報 | 中 | データだけ戻しても環境を再現できない |
| 端末のローカル保存データ | 中 | ルール上は禁止でも実際には保存されている |
| SaaSの設定・権限・アカウント構成 | 中 | データではなく設定が失われる想定が抜けている |
とくに抜けやすいのが最後の2つです。端末のローカル保存は「禁止しているから対象外」と整理しがちですが、実態と乖離していれば評価の場で説明が破綻します。Intuneでの端末管理とあわせて、保存させない設計にするか、対象に含めるかを決めてください。
保存世代と復旧目標（RPO／RTO）
「何世代残すか」は単独では決められません。どこまで戻れれば業務が成立するか（RPO）といつまでに戻す必要があるか（RTO）を業務側と合意してから決めます。
| 業務影響 | RPOの目安 | RTOの目安 | 構成例 |
|---|---|---|---|
| 停止が即座に売上・顧客対応に影響 | 1時間以内 | 数時間 | 短間隔のスナップショット＋別拠点保管 |
| 半日〜1日の停止なら許容できる | 24時間 | 1営業日 | 日次バックアップ＋週次の別保管 |
| 数日の停止でも代替手段がある | 1週間 | 数営業日 | 週次バックアップ＋月次の長期保管 |
世代については、単一世代の上書きは避けてください。ランサムウェアや誤操作は発覚までに時間がかかることがあり、直近の1世代だけでは「壊れた状態を上書き保存しただけ」になります。日次を一定期間分残し、そこに週次・月次を重ねる構成が現実的です。
ランサムウェアを前提にした分離
近年の攻撃は、業務データを暗号化する前にバックアップを先に破壊または暗号化します。ネットワーク越しに常時マウントされ、業務用の管理者アカウントで書き込めるバックアップは、同時に失われる前提で考える必要があります。
基本となるのが3-2-1ルールです。データの複製を3つ持ち、2種類の異なる媒体に保存し、うち1つは別の場所に置く、という考え方です。これに加えて、書き換えを技術的に拒否する仕組みを1系統確保します。
| 手法 | 内容 | 向くケース |
|---|---|---|
| イミュータブル保管 | 設定した期間、削除・上書きをストレージ側で拒否する（オブジェクトロック等） | クラウドストレージを使っている場合 |
| オフライン保管 | 取得後にネットワークから切り離して保管する | 容量が限られ、頻度が低くてよい場合 |
| 認証情報の分離 | バックアップ用のアカウントを業務用の管理者と分け、多要素認証を必須にする | すべての構成で実施すべき最低条件 |
認証情報の分離は追加費用がかからないため、まず着手すべき項目です。業務用のドメイン管理者でバックアップ先に書き込める状態は、それだけで単一障害点になります。
クラウドを使っていてもバックアップは必要
Microsoft 365やGoogle Workspaceは責任共有モデルで提供されています。事業者が責任を負うのはサービス基盤の可用性であり、利用者が消したデータ・改ざんされたデータを元に戻す責任は利用者側にあります。
ごみ箱、保持ポリシー、訴訟ホールドといった標準機能は、誤削除からの短期的な救済や証跡保全のための仕組みであって、任意の時点に戻すためのバックアップではありません。保持期間を過ぎたもの、保持の対象外だったものは戻せません。
| 機能 | できること | バックアップの代替になるか |
|---|---|---|
| ごみ箱・復元可能な削除済みアイテム | 一定期間内の誤削除の復旧 | ×（期間経過後は不可） |
| 保持ポリシー・訴訟ホールド | 削除の抑止と証跡の保全 | ×（任意時点への復元ではない） |
| バージョン履歴 | ファイル単位の巻き戻し | ×（大量改ざん時の一括復旧に向かない） |
| Microsoft 365 Backup／サードパーティ製品 | 時点指定での一括復元 | ○ |
Microsoftは自社サービスとしてMicrosoft 365 Backupを提供しており、Exchange Online・OneDrive・SharePointを対象に従量課金で利用できます。サードパーティ製品を含め、M365での★3対応を進める際は、ここが標準機能では埋まらない領域だと理解しておいてください。
復元テストが最も問われる
3つの観点のうち、実務で最も指摘を受けやすいのが復元です。取得と保管は設定を見せれば説明できますが、復元できるかどうかは実際に試した記録がなければ証明できません。
復元テストは大掛かりにする必要はありません。次の条件を満たせば、記録として十分に機能します。
- 対象を絞る：全システムではなく、重要度の高い1〜2系統で実施する
- 本番に戻さない：検証環境または別領域へ復元し、業務影響を出さない
- 所要時間を測る：RTOの目安と実測値を突き合わせる
- 設定した本人以外が実施する：属人化していないかを同時に検証できる
- 手順書を更新する：実施して気づいた差分を必ず反映する
頻度は年1回以上を目安とし、システム構成を大きく変えたときは追加で実施します。★取得後の年次運用にも組み込んでおくと、更新時に慌てずに済みます。
残しておく証跡
自己評価では、次の資料が揃っていれば説明に困りません。いずれも新規に作る必要はなく、既存の運用を書き起こせば足ります。
- バックアップ設計書：対象・頻度・世代・保管先・保管期間・責任者を1枚にまとめたもの
- 実行ログ：成功／失敗の記録。失敗時に誰がどう対応したかまで残す
- 復元テスト報告書：実施日・対象・手順・所要時間・結果・是正事項
- 復元手順書：担当者以外が実行できる粒度で記述したもの
- 権限の一覧：バックアップ先にアクセスできるアカウントと、その多要素認証の状況
失敗の記録を隠す必要はありません。失敗を検知して是正した記録があるほうが、運用されている証拠として評価されます。実行ログが常に成功しか出ていない場合、そもそも監視していないのではないかと見られることもあります。
よくある質問
SCS★3ではどのくらいの頻度でバックアップを取ればよいですか？
一律の頻度が定められているわけではありません。どこまで戻れれば業務が成立するかというRPOを業務側と合意し、そこから頻度を決めます。半日から1日の停止が許容できる業務であれば日次、即座に売上や顧客対応へ影響する業務であればより短い間隔が必要になります。
Microsoft 365を使っていればバックアップは不要ですか？
不要にはなりません。Microsoft 365は責任共有モデルで提供されており、事業者が責任を負うのはサービス基盤の可用性です。利用者が消したデータや改ざんされたデータを元に戻す責任は利用者側にあります。ごみ箱や保持ポリシーは誤削除からの短期的な救済であって、任意の時点に戻すためのバックアップではありません。
復元テストはどこまでやれば「実施した」と言えますか？
全システムを対象にする必要はありません。重要度の高い1〜2系統を検証環境または別領域へ実際に復元し、所要時間を測って記録すれば十分です。設定した本人以外が手順書だけで実施できるかを同時に確認すると、属人化の検証も兼ねられます。頻度は年1回以上が目安です。
バックアップのために新しい製品を買う必要がありますか？
必ずしも必要ではありません。対象範囲の整理、世代の見直し、バックアップ用アカウントを業務用の管理者と分けて多要素認証を必須にすることは、追加費用なしで着手できます。買い足しが避けられないのは、クラウドの標準機能では時点復元ができない領域や、分離保管の受け皿がない場合です。
証跡としては何を残せばよいですか？
バックアップ設計書（対象・頻度・世代・保管先・保管期間・責任者）、実行ログ、復元テスト報告書、復元手順書、バックアップ先にアクセスできるアカウントの一覧です。失敗の記録は隠す必要がなく、検知して是正した記録があるほうが運用されている証拠として評価されます。
まとめ
SCS評価制度★3のバックアップ要件は、高価な製品を導入すれば満たせるものではありません。問われるのは対象を決めているか、分離して保管しているか、実際に戻せることを確認しているかの3点です。
まず対象範囲を書き出し、世代を1つしか持っていない部分を洗い出してください。そのうえで、バックアップ用の認証情報を業務用の管理者と分けるところまでは、追加費用なしで着手できます。残った不足だけを投資の検討対象にすれば、無駄なく要件を満たせます。
自社の対応状況を項目単位で確認したい場合は、SCS★3 セルフチェック（無料・登録不要） ↗で26要求事項・81評価基準への適合率を測れます。