SCS評価制度★4の対策実装ガイド ― ★3との差分を領域別に埋める進め方
SCS評価制度の全体像については SCS評価制度 対策ガイド もあわせてご覧ください。
SCS評価制度の★4は、要求事項43項目・評価基準153件。★3（26項目・81件）と比べると、項目数で1.7倍、評価基準では1.9倍に増えます。しかも評価方法が自己評価から第三者評価（書類審査・実地審査・技術検証）に変わるため、「やっているつもり」が通用しません。
一方で、★4は★3の要求事項をすべて包含する構造です。つまり**★3を固めたうえで、差分を埋めれば★4に届きます**。この記事では、その差分を領域別に整理し、中小〜中堅企業が現実的に実装する道筋を示します。
★3側の実装は★3の対策要件をM365 / GWSで実装するを先にご覧ください。
そもそも★4を目指すべきか
★4が必要になるのは、おおむね次のいずれかに当てはまる企業です。
- ITベンダー・SIer・MSPとして顧客システムへのアクセス権限を持っている
- 重要インフラ（15分野）のサプライチェーンに属している
- 取引先から設計データ・個人情報など機密性の高い情報を預かっている
- 政府調達への参加を検討している
- 自動車・防衛など、業界ガイドラインで高い水準を求められている
該当しないのであれば、まず★3で十分です。★4は実装費用に加えて、第三者評価の審査費用と実地審査の対応工数が発生します。目標★の選び方は★3・★4の評価基準比較を参照してください。
領域別の差分と実装方法
1. ガバナンス ― 「体制がある」から「回っている」へ
★4で追加される要件：
- 法令・所管省庁の基準・取引先の要求事項を踏まえた社内ルールの策定と年1回以上の点検
- 経営層が参加する情報セキュリティ委員会等の意思決定体制の設置
- サイバー攻撃の監視・分析体制の整備
- セキュリティ対策推進計画を経営層へ報告し、指示を計画へ反映する仕組み
実装のポイント： ここは製品では解決しません。中小企業で現実的なのは、四半期に1回・30分の「セキュリティ委員会」を実開催し、議事録を残すことです。参加者は経営層＋情シス＋各部門の代表。議題は「インシデント有無」「対策の進捗」「次期計画」の3点で足ります。
第三者評価では、議事録・報告資料・経営層の指示とその反映記録が証跡になります。「年1回だけ形式的に開いた」形跡は見抜かれるため、頻度より継続性を意識してください。
2. 取引先管理 ― 年1回の実確認が必要になる
★4で追加される要件：
- 機密情報を共有する取引先について、取引手段や情報資産の取扱いまで把握
- 重要な取引先を対象に、年1回以上セキュリティ対策状況を確認（★の取得状況の確認、訪問点検、チェックシート回答等が例示）
- 契約終了時に機密情報とアクセス権を回収・破棄する手順の整備
実装のポイント： ★3では「取り決めがあること」で足りましたが、★4では確認の実施と記録が求められます。委託先を重要度でランク分けし、上位のみ年次確認する設計が現実的です。運用の型は委託先管理の実装ガイドにまとめています。
契約終了時の回収・破棄は、退職者対応と同じ発想です。アクセス権の削除記録とデータ破棄証明をセットで残せる手順にしておきます。
3. リスクの特定 ― 脆弱性管理体制が要件化
★4で追加される要件：
- リモートワークで使用する機器・機密情報の条件のルール化
- 脆弱性の管理体制と管理プロセスを定め、それに基づく管理を行うこと
実装のポイント： 脆弱性管理は★4からの新規要件で、「体制」と「プロセス」の両方が問われます。中小企業では次の形が最小構成です。
- 脆弱性情報の収集元を決める（JVN、製品ベンダーの通知、Defender脆弱性の管理等）
- 担当者と判断者を決める（誰が緊急度を判断し、誰が適用を承認するか）
- 緊急度別の対応期限を決める（例：緊急は72時間以内、高は2週間以内）
- 記録を残す（検知→評価→対応→確認のログ）
詳細な作り方はSCS★4の脆弱性管理体制の作り方で扱います。
4. 攻撃等の防御 ― 最も追加項目が多い
★4で追加される要件：
- サーバ設置エリアへの入退室管理と記録
- 可搬媒体の持込み・持出しの制限
- 保管データの暗号化ルール、データ保管先・取引先との情報共有ルール
- ログの取得・保管：ファイアウォール／プロキシサーバ／認証サーバのログを各6か月保管し、認証サーバのログは月1回以上モニタリング
- サポート期限切れOS・ソフトウェアの利用停止と更改
- 経営層を含む全要員へのセキュリティ意識向上教育
- ネットワークのセグメンテーション（社外公開サーバ・重要サーバの分離）
実装の当て方を整理すると次のようになります。
| 追加要件 | M365 / GWSで満たせる範囲 | 追加が必要になりやすいもの |
|---|---|---|
| ログの6か月保管 | M365監査ログは既定180日（Audit Standard）／GWS監査ログは6か月 | FW・プロキシのログは機器側の設定かログ収集基盤 |
| 認証サーバのログを月1回モニタリング | Entra IDのサインインログ／GWSのログイン監査を定例確認 | 確認記録を残す運用そのもの |
| 暗号化 | BitLocker（Intuneで強制）／ChromeOSは既定で暗号化 | 外部媒体・NASの暗号化ルール |
| 可搬媒体の制限 | Intuneのリムーバブル記憶域制御／GWSは端末側で制御 | USB制御が必要な現場端末 |
| サポート切れOSの排除 | Intune / エンドポイント管理でOSバージョンを可視化 | 更改予算そのもの |
| 意識向上教育 | ― | eラーニングまたは集合研修 |
| 入退室管理 | ― | 物理対策（施錠管理・入退室記録） |
| ネットワークセグメンテーション | ― | VLAN設計・機器設定 |
特に注意すべきはログです。 M365 / GWSの監査ログだけでは「ファイアウォール／プロキシのログ」要件を満たせません。UTMのログをどこに、どうやって6か月残すか——この設計が★4対応で最初に詰まるポイントです。機器のローカル保存では容量が足りないことが多く、外部のログサーバやクラウドのログ保管を検討することになります（監査ログの長期保管、証跡・監査ログ実装ガイド）。
入退室管理は、サーバー室がない企業ほど悩みます。オンプレのサーバーがラック1本だけなら、施錠管理と入退室記録簿で足ります。クラウド移行を進めてサーバー室そのものをなくすほうが、要件・コストの両面で有利になるケースもあります。
ネットワークセグメンテーションは、社外公開サーバ・重要サーバ・一般業務セグメントの分離が中心です。中小企業ではVLANによる分離が標準解になります（VLANとネットワークセグメンテーションの基礎）。
5. 攻撃等の検知 ― EDR相当が事実上の前提に
★4で追加される要件：
- 情報機器・ソフトウェアの状態や挙動の監視（EDR等）
- インシデントのレベル定義と、レベルごとの対象範囲の明確化
実装のポイント： M365 Business Premiumに含まれるDefender for Businessで、中小企業のEDR要件は実務上カバーできます。問題は導入ではなく運用です。アラートを誰が見て、どう判断し、どこまで対応するか。ここが空白だと、第三者評価の実地審査で必ず突かれます。
自社で24時間監視するのは非現実的なので、アラートの一次確認は平日日中、重大アラートはメール/Teams通知＋当番制という現実的な設計にし、それを文書化します。運用負荷が読めない場合はマネージドサービスの活用も選択肢です（SOCライトの始め方）。
インシデントのレベル定義は、**「レベル1：業務影響なし／レベル2：一部業務停止・情報漏えいの疑い／レベル3：事業停止・確定した漏えい」**の3段階程度から始め、レベルごとに報告先と対応期限を決めれば足ります。
6. インシデントへの対応
★3と★4で要求事項の差は小さい領域ですが、★4では周辺（検知のレベル定義、ガバナンスの監視・分析体制）と組み合わせて、対応力が実態として機能しているかが見られます。第三者評価では、訓練記録や過去のインシデント対応記録の提示を求められる可能性があります（インシデント発生時のSCS評価への影響）。
7. インシデントからの復旧 ― 「復元できること」の実証
★4で追加される要件：
- 目標復旧時点（RPO）まで戻せるようバックアップを保管
- リストア手順書どおりに、かつ目標復旧時間（RTO）内で復元できることを実際に確認
実装のポイント： ★3では「バックアップの取得・遠隔地保管・リストア手順書の整備」まで。★4では実地に復元テストを行い、その記録を残すことが求められます。
年1回、対象を絞って（例：ファイルサーバの1フォルダ、基幹システムの検証環境）テストし、所要時間を計測して記録します。RTOを守れなかった場合は、その原因と改善策も記録に残せば、むしろ前向きな証跡になります（バックアップとリストアの実装）。
実装の優先順位（モデルプラン）
★3を満たしている企業が★4へ進む場合の標準的な順序です。
| 順 | 作業 | 難易度 | 期間目安 |
|---|---|---|---|
| 1 | 情報セキュリティ委員会の設置と初回開催 | 低 | 1か月 |
| 2 | 脆弱性管理プロセスの文書化と運用開始 | 中 | 1〜2か月 |
| 3 | EDR（Defender for Business等）の展開とアラート運用の設計 | 中 | 1〜2か月 |
| 4 | ログの保管設計（FW・プロキシ・認証の6か月保管）と月次モニタリング開始 | 高 | 2〜3か月 |
| 5 | ネットワークセグメンテーションの設計・実装 | 高 | 2〜3か月 |
| 6 | 暗号化ルール・可搬媒体制限・入退室管理の整備 | 中 | 1〜2か月 |
| 7 | 全要員向け意識向上教育の実施 | 低 | 1か月 |
| 8 | 復元テストの実施と記録 | 中 | 1か月 |
| 9 | 取引先の年次確認の実施 | 中 | 2か月 |
4と5が★4対応の山です。ここに着手する順番を間違えると、後半で時間が足りなくなります。全体で6〜9か月を見込んでおくと安全です。
第三者評価を意識した証跡の作り方
★3の自己評価と決定的に違うのは、第三者が実地で確認するという点です。次の3つを意識してください。
- 設定と文書が一致していること。 規程に「72時間以内に緊急パッチを適用」と書いたなら、実際の適用記録がそれを裏づけている必要があります。守れないルールは書かない
- 記録が継続していること。 直近1か月分だけ整った記録は不自然に映ります。運用開始から審査までの期間が短い場合は、開始日を正直に示すほうが誠実です
- 担当者が説明できること。 実地審査ではヒアリングがあります。外部委託で設定した部分も、自社の担当者が「なぜそうしているか」を説明できる状態にしておく必要があります
審査当日の流れと準備は★4の第三者評価フロー徹底解説にまとめています。なお、評価機関の一覧公開は2026年12月末頃の予定です。
情シス365による支援
情シス365では、★4対応で最も詰まりやすい「ログ設計」「ネットワーク分離」「EDR運用」を中心に支援しています。
- ギャップ分析： ★3達成状態から★4までの差分を項目単位で洗い出し、難易度と期間で並べ替え
- ログ基盤の設計： UTM・プロキシ・認証ログの6か月保管とモニタリング運用の構築
- ネットワーク設計： VLANによるセグメンテーションの設計・実装
- EDR運用： Defender for Businessの展開とアラート運用の代行
- 委員会運営の支援： 議題設計・資料作成・議事録テンプレートの提供
まとめ
- ★4は★3を包含する構造。差分を領域別に埋めるのが最短ルート
- 追加要件の山は①ログの6か月保管とモニタリング、②ネットワークセグメンテーションの2つ
- 脆弱性管理体制・EDRによる挙動監視・暗号化・入退室管理・意識向上教育が★4からの新規要件
- 復旧領域では**「実際に復元できることの確認」**が加わる
- ガバナンスは製品では解決しない。経営層が参加する委員会を実開催し、議事録を残す
- 第三者評価では設定と文書の一致・記録の継続・担当者の説明力が見られる
- 全体で6〜9か月を見込む。評価機関の公開は2026年12月末頃、運用開始は2027年3月頃
参考リンク：