SCS評価制度とは?★3・★4の違いとクラウド利用企業が進めるべき5つの準備

SCS評価制度(サプライチェーン強化に向けたセキュリティ対策評価制度)は、企業の情報セキュリティ対策状況を共通の基準で確認し、その水準を★で示す制度です。参加は任意ですが、取引先から★3・★4の取得を求められる可能性があります。本記事では、制度の概要、クラウド利用時の注意点、準備すべきステップ、AWS環境の確認ポイントを解説します。
- SCS評価制度は、企業のセキュリティ対策状況を共通基準で確認し、★で見える化する制度です。
- ★3・★4は2027年3月頃の運用開始が予定されています。
- AWSやMicrosoft Azure、SaaSなどのクラウドサービスも評価範囲に含まれます。
- 最初に取り組むべきことは、評価範囲の決定、IT資産の棚卸し、現在の対策とのギャップ分析です。
目次:
- 1. SCS評価制度とは
- 1-1. なぜSCS評価制度が必要なのか
- 1-2. 従来のチェックシートとの違い
- 2. SCS評価制度は義務なのか
- 2-1. 特に関係が深い企業
- 2-2. 特定のセキュリティ製品は必須ではない
- 3. 評価対象にはクラウドも含まれる
- 3-1. 主な評価対象
- 3-2. 原則として評価対象外となるもの
- 3-3. 評価範囲は会社全体とは限らない
- 4. ★3・★4・★5の違い
- 4-1. ★3を取得してから★4へ進む必要はない
- 4-2. ★3の評価方法
- 4-3. セキュリティ専門家とは
- 5. クラウドでは「責任共有モデル」の整理が必要
- 5-1. クラウド事業者と利用企業の役割
- 5-2. 管理者アカウントの多要素認証
- 5-3. 不要なアカウントや権限の確認
- 5-4. インターネットへの公開範囲の確認
- 5-5. ログの取得と保存
- 5-6. バックアップからの復元確認
- 6. ISMSやSECURITY ACTIONとの関係
- 6-1. ISMSを取得済みの場合
- 6-2. SECURITY ACTIONとの関係
- 6-3. NIST CSFとの関係
- 7. 今後のスケジュール
- 8. SCS評価制度に向けて準備する5ステップ
- 8-1. Step 1:目標と評価範囲を決める
- 8-2. Step 2:IT資産を棚卸しする
- 8-3. Step 3:責任分担と不足点を確認する
- 8-4. Step 4:対策を実施し、証跡を残す
- 8-5. Step 5:継続できる運用にする
- 9. 10項目の簡易チェックリスト
- 9-1. チェック方法
- 9-2. チェック結果の見方
- 10. AWS環境の技術的な現状を確認する
- 10-1. クラウドセキュリティチェック for AWS
- 10-2. 技術チェックだけでは制度対応は完了しない
- 11. SCS評価制度に関するよくある質問
- 11-1. SCS評価制度は義務ですか
- 11-2. クラウドを使っている場合も対象ですか
- 11-3. AWSを利用していれば安全と説明できますか
- 11-4. ISMSを取得していれば★3を取得できますか
- 11-5. ★3を取得してから★4へ進む必要がありますか
- 11-6. 社内に資格保有者がいれば専門家確認を依頼できますか
- 11-7. SCS評価制度への対応には新しい製品が必要ですか
- 11-8. 何から始めればよいですか
- 12. まとめ
1. SCS評価制度とは
SCS評価制度の正式名称は「サプライチェーン強化に向けたセキュリティ対策評価制度」です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPA(独立行政法人情報処理推進機構)が運営します。企業のセキュリティ対策状況を共通の基準で確認し、取引先同士で説明しやすくすることが目的です。
発注企業が業務を外部委託する際には、どの程度のセキュリティ対策を求めるべきか、委託先が実際に対策しているか、取引先ごとに異なるチェックシートを作る必要があるかといった課題があります。受注企業側にも、複数の発注企業から異なるチェックシートへの回答を求められ、対応に時間がかかるという問題があります。
SCS評価制度は、企業ごとに異なっていた確認方法に共通の基準を設け、委託元が委託先の情報セキュリティ対策状況を確認しやすくするとともに、委託先側の確認対応の負担軽減につなげることを目的としています。
1-1. なぜSCS評価制度が必要なのか
サイバー攻撃では、対策が手薄な取引先や委託先へ侵入し、そこを足掛かりとして本来の標的へ攻撃する手法があります。委託先でシステム障害や情報漏えいが発生すれば、発注企業にも製品・サービスの提供停止、顧客情報や設計情報の漏えい、取引ネットワークを経由した不正侵入、復旧や取引先対応にかかる費用増加などの影響が及びます。
自社だけを守るのではなく、取引先を含むサプライチェーン全体で一定のセキュリティ水準を確保することが、制度創設の背景です。
1-2. 従来のチェックシートとの違い
これまでは、発注企業が独自のセキュリティチェックシートを作成し、委託先や取引先へ回答を求める方法が一般的でした。しかし、取引先によって質問内容や評価方法が異なるため、受注企業は似た内容のチェックシートへ繰り返し回答しなければなりません。SCS評価制度は、企業ごとに異なっていた確認基準を共通化し、取引先のセキュリティ対策状況を確認しやすくする仕組みです。
2. SCS評価制度は義務なのか
SCS評価制度への参加は任意です。★3・★4を取得していないことだけを理由に、法律によって商取引が禁止されたり、すべての入札から自動的に除外されたりする制度ではありません。ただし、発注企業が取引内容や扱う情報の重要度を踏まえ、委託先に★3や★4の取得を求めることは想定されています。「任意だから何もしなくてよい」という意味ではありません。まずは主要取引先がどの水準を求める可能性があるかを確認しましょう。
2-1. 特に関係が深い企業
次のような企業は、早めに制度の影響を確認しておく必要があります。
- 大企業や自治体から業務を受託している
- 顧客情報や個人情報を預かっている
- 発注元のシステムへ接続している
- SaaSやITサービスを顧客に提供している
- 製造業のサプライチェーンに参加している
- クラウド上で顧客データや重要業務を扱っている
2-2. 特定のセキュリティ製品は必須ではない
SCS評価制度は、特定のセキュリティ製品の導入を必須とする制度ではありません。例えば、「この製品を導入しなければ★3を取得できない」「SCS評価制度への対応にはこのサービスが必須」といった説明には注意が必要です。必要なのは、自社のリスクや取引内容に応じた対策を選び、実施状況を説明できる状態にすることです。
3. 評価対象にはクラウドも含まれる
SCS評価制度では、企業の業務を支えるIT基盤が評価対象になります。オンプレミスのサーバーやネットワーク機器だけでなく、AWSやMicrosoft Azureなどのクラウド環境、業務で利用するSaaSも対象になり得ます。
3-1. 主な評価対象
| 分類 | 具体例 |
|---|---|
| エンドポイント | 業務用パソコン、スマートフォン、タブレット |
| サーバー | ファイルサーバー、認証サーバー、業務サーバー |
| 公開システム | Webサーバー、メールサーバー |
| クラウド | AWS、Microsoft Azureなどのクラウド環境 |
| SaaS | メール、ファイル共有、顧客管理など、IT基盤を構成するサービス |
インターネットに公開しているWebサーバーやメールサーバーは、適用範囲に含めることとされています。
3-2. 原則として評価対象外となるもの
一般的なIT基盤に該当しない製造設備の制御システム(OT)や、顧客へ納品する製品そのものは、SCS評価制度の直接の評価対象とはせず、別の制度やガイドラインに基づいて対策することが想定されています。ただし、「SCS評価制度の対象外」であることは、「セキュリティ対策が不要」という意味ではありません。製造設備や自社製品についても、それぞれの特性に合った対策が必要です。
3-3. 評価範囲は会社全体とは限らない
申請主体は原則として法人または個人事業主ですが、専門家や評価機関による適用範囲の妥当性確認を経たうえで、事業部単位やグループ単位などを申請主体とすることも想定されています。そのため、どの事業、拠点、ネットワーク、クラウド環境、SaaS、委託先との接続を対象にするかを最初に決める必要があります。
評価範囲を決めないまま資産棚卸しを始めると、対象が際限なく広がり、作業が進まなくなる可能性があります。まずは仮の範囲を設定し、棚卸しを進めながら見直すことが重要です。
4. ★3・★4・★5の違い
SCS評価制度で中心となるのは★3と★4です。★5は、今後、要求事項や評価方法が具体化される予定です。★4の43件には、★3の26件が含まれます。評価基準153件のうち、81件が★3に適用され、残りが★4で追加される基準です。
| 項目 | ★3 | ★4 | ★5 |
|---|---|---|---|
| 位置づけ | 最低限実装すべき対策 | 標準的に目指す包括的な対策 | より高度な対策 |
| 要求事項数 | 26件 | 43件 | 今後検討 |
| 評価方法 | 専門家確認付き自己評価 | 第三者評価と技術検証 | 今後検討 |
| 有効期間 | 1年 | 3年 | 今後検討 |
★1・★2については、IPAの自己宣言制度「SECURITY ACTION」を参照する位置づけです。SCS評価制度の★3・★4と同じ評価スキームではありません。
4-1. ★3を取得してから★4へ進む必要はない
★3を先に取得する必要はありません。★4は★3の要求事項を含む上位水準ですが、取引先から★4を求められている場合などは、直接★4を目指すことができます。自社の目標を決める際は、主要取引先が求める水準、自社が預かる情報の重要度、システム停止時の取引先への影響、評価に対応できる人員と予算、★3と★4の有効期間の違いを確認します。
4-2. ★3の評価方法
★3では、企業が要求事項と評価基準に基づいて自己評価し、登録されたセキュリティ専門家が内容を確認します。必要に応じて専門家が助言を行い、経営層が自己適合を宣誓したうえで評価結果を事務局へ提出します。問題がなければ台帳に登録・公開される流れが想定されています。
重要なのは、情報システム担当者だけでは完結しないことです。経営層による宣誓が必要になるため、経営者、総務、情報システム、法務、調達などの関係者を早い段階で巻き込む必要があります。
4-3. セキュリティ専門家とは
★3の確認を行う専門家には、指定された資格の保有と、制度に関する研修の受講が求められます。対象となる資格は、情報処理安全確保支援士、公認情報セキュリティ監査人、CISSP、CISA、CISM、ISO 27001主任審査員です。資格を持っているだけではなく、所定の研修を受講し、SCS評価制度の事務局に登録される必要があります。社内に対象資格の保有者がいる場合でも、その人が制度上の専門家として登録できるかを確認する必要があります。
5. クラウドでは「責任共有モデル」の整理が必要
AWSやMicrosoft Azureなどのクラウドでは、クラウド事業者と利用企業が役割を分担してセキュリティを確保します。これを「責任共有モデル」と呼びます。クラウド事業者がデータセンターや物理サーバーを安全に管理していても、自社のアカウントやクラウド設定に問題があれば、情報漏えいや不正アクセスが発生する可能性があります。
5-1. クラウド事業者と利用企業の役割
| 範囲 | 主に対応する者 |
|---|---|
| データセンターや物理設備 | クラウド事業者 |
| 利用者アカウント、権限 | 利用企業 |
| クラウドに保存するデータ | 利用企業 |
| インターネットへの公開設定 | 利用企業 |
| ログを取得・確認する運用 | 利用企業 |
| OSやミドルウェア、暗号化や可用性の設定 | 利用サービスによって分担が異なる |
SCS評価制度では、クラウドなど他社と責任を共有するサービスについて、自社が担当する範囲の対策を実施すること、またはクラウド事業者側の対策状況を確認することが必要です。クラウド事業者側の確認資料として、ISMAPへの登録状況やSOC 2レポートなどを確認する方法があります。
5-2. 管理者アカウントの多要素認証
管理者アカウントに多要素認証が設定されているか確認します。一般ユーザーだけでなく、AWSやAzureの管理者アカウント、緊急時に使用する管理者アカウント、委託先が利用する保守アカウント、SaaSの全体管理者、共有している管理者アカウントも確認対象に含めます。
5-3. 不要なアカウントや権限の確認
退職者や異動者のアカウント、過去の委託先に付与した権限が残っていないか確認します。誰のアカウントを確認したか、いつ確認したか、不要なアカウントをいつ削除したか、権限をどのように変更したか、誰が変更を承認したかを記録することが重要です。
5-4. インターネットへの公開範囲の確認
Webサーバー、管理画面、データベース、ストレージなどが、意図せずインターネットへ公開されていないか確認します。特に、過去に作成した検証環境や、一時的に公開した設定が残っていないか注意が必要です。
5-5. ログの取得と保存
ログとは、「誰が、いつ、何を操作したか」を確認するための記録です。どのシステムのログを取得するか、どこに保存するか、どの程度の期間保存するか、誰が確認するか、異常を検知した場合に誰へ連絡するかを決めておきましょう。
5-6. バックアップからの復元確認
バックアップ処理が正常終了しているだけでは不十分です。実際に復元し、どの程度の時間で業務を再開できるかを確認します。復元試験では、復元を実施した日、復元対象、復元にかかった時間、復元したデータが正常に利用できたか、発生した問題、次回までに改善する内容を記録します。
6. ISMSやSECURITY ACTIONとの関係
既存のセキュリティ制度やガイドラインに対応している企業は、その取り組みをSCS評価制度の準備に活用できます。ただし、既存制度を取得しているだけで、自動的に★3や★4へ適合するわけではありません。
6-1. ISMSを取得済みの場合
ISMSで整備した情報セキュリティ基本方針、リスク管理表、IT資産台帳、教育記録、インシデント対応手順、委託先管理記録、内部監査の記録、経営層によるレビュー記録は、SCS評価制度への対応にも活用できる可能性があります。ただし、SCS評価制度の要求事項・評価基準と既存の規程や運用を対応付け、足りない部分を確認する必要があります。
特に、評価範囲が一致しているか、クラウドやSaaSが資産台帳に含まれているか、重要な取引先の対策状況を確認しているか、技術設定について説明できる記録があるか、インシデント対応や復旧訓練を実施しているかを確認しましょう。
6-2. SECURITY ACTIONとの関係
SECURITY ACTIONは、中小企業が情報セキュリティ対策に取り組むことを自己宣言する制度です。これから対策を始める企業にとって、SECURITY ACTIONや「中小企業の情報セキュリティ対策ガイドライン」は、★3・★4に向けた準備として活用できます。ただし、SECURITY ACTIONは自己宣言制度であり、専門家確認や第三者評価を伴うSCS評価制度の★3・★4とは評価方法が異なります。
6-3. NIST CSFとの関係
★3・★4の要求事項は、SCS評価制度の要求事項・評価基準は、NIST Cybersecurity Framework(CSF)の機能に対応した6分類に、「取引先管理」を加えた7分類で整理されています。
主な分類は、統治、識別、防御、検知、対応、復旧、取引先管理です。技術的なセキュリティ対策だけでなく、経営層の関与、体制、手順、事故対応、復旧、委託先管理なども評価されます。
7. 今後のスケジュール
2026年10月時点で公表されている主なスケジュールは次のとおりです。SCS評価制度では、制度規程や評価機関・技術検証事業者などに関する情報が順次公開されています。★3・★4は2027年3月頃の運用開始が予定されているため、最新情報はIPAのSCS評価制度公式サイトで確認しましょう。
サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)
| 時期 | 予定 |
|---|---|
| 2026年8月頃 | 制度規程、評価機関・技術検証事業者・研修事業者に関する情報などを順次公開 |
| 2026年10月頃 | ★3・★4要求事項・評価基準の解説書、取得ガイド、申請方法を公開予定 |
| 2026年12月末頃 | 評価機関などを公表予定 |
| 2027年1月以降 | SCSセキュリティ専門家を公表予定 |
| 2027年3月頃 | ★3・★4の運用開始予定 |
制度の詳細がすべて決まるまで、準備を待つ必要はありません。IT資産の棚卸し、アカウントと権限の確認、多要素認証の導入、OSやソフトウェアの更新、ログの取得、バックアップの復元試験、インシデント対応手順の整備、委託先のセキュリティ状況確認は、制度の有無にかかわらず必要な取り組みです。運用記録は後からさかのぼって作ることが難しいため、今から記録を残し始めることが重要です。
8. SCS評価制度に向けて準備する5ステップ
8-1. Step 1:目標と評価範囲を決める
主要取引先から求められる可能性がある水準を確認し、★3と★4のどちらを目標にするか仮決めします。同時に、会社全体、特定事業部、国内拠点など、どこを評価範囲とするか整理します。最初から完全に確定する必要はありません。まずは仮の範囲を設定し、棚卸しを進めながら見直します。
8-2. Step 2:IT資産を棚卸しする
パソコン、スマートフォン、オンプレミスサーバー、ファイアウォール、ルーター、VPN装置、AWS、Microsoft Azureなどのクラウド、メールやファイル共有などのSaaS、Webサーバー、メールサーバー、管理者アカウント、委託先が管理しているシステムを一覧化します。すべてを一度に把握できなくても、「把握できていない資産」を明確にすることが第一歩です。
8-3. Step 3:責任分担と不足点を確認する
要求事項ごとに、現在の対応状況を「対応済み」「一部対応」「未対応」の3段階で整理します。クラウドについては、自社が設定するもの、クラウド事業者が管理するもの、自社がクラウド事業者の対策状況を確認するものに分けます。優先順位は、事故が発生した場合の影響と、取引先から求められる可能性を踏まえて決めます。
8-4. Step 4:対策を実施し、証跡を残す
| 対策 | 証跡の例 |
|---|---|
| 多要素認証 | 適用対象、適用率、設定日 |
| アカウント管理 | 棚卸し記録、削除・無効化の履歴 |
| ログ管理 | 取得対象、保存期間、確認記録 |
| バックアップ | 実行結果、復元試験日、所要時間 |
| 委託先管理 | 契約条項、確認票、改善依頼の記録 |
証跡の中心は、設定画面の画像だけではありません。「誰が、いつ、何を確認し、問題があった場合にどう対応したか」を記録することが重要です。
8-5. Step 5:継続できる運用にする
★3の有効期間は1年です。申請前だけ一時的に書類を整えるのではなく、月次や四半期ごとの業務として運用します。例えば、アカウント棚卸しは四半期ごと、IT資産台帳の更新は機器導入・廃止時、パッチ適用状況の確認は毎月、復元試験は年1回以上、委託先確認は契約時および年1回、インシデント訓練は年1回を目安に実施します。
9. 10項目の簡易チェックリスト
「未対応」や「判断できない」が多い場合は、まず評価範囲とIT資産の整理から始めましょう。AWS環境について設定状況を客観的に確認したい場合は、専門家によるチェックを活用する方法もあります。
9-1. チェック方法
各項目を「対応済み」「一部対応」「未対応」の3段階で確認してください。このチェックリストだけで★3・★4への適合を判定することはできませんが、自社の課題を把握する入口として活用できます。
| 確認項目 | 評価 | |
|---|---|---|
| 1 | セキュリティ方針を文書化し、経営層が承認している | |
| 2 | セキュリティ責任者と連絡体制を決めている | |
| 3 | パソコン、サーバー、クラウド、SaaSの資産台帳がある | |
| 4 | 管理者を含む重要アカウントに多要素認証を設定している | |
| 5 | 退職・異動時にアカウントを削除・変更する手順がある | |
| 6 | OSやソフトウェアの更新状況を記録している | |
| 7 | 公開サーバーやVPN装置を一覧化している | |
| 8 | バックアップからの復元試験を実施している | |
| 9 | インシデント対応手順と社内外の連絡先がある | |
| 10 | 重要な委託先のセキュリティ対策状況を確認している |
9-2. チェック結果の見方
「未対応」が多い場合は、製品選定に進む前に、資産棚卸しと現状分析を優先します。「一部対応」が多い場合は、ルールはあっても、実施記録や定期点検が不足している可能性があります。ほとんどが「対応済み」の場合は、要求事項との対応付けや専門家確認に向けた書類整理を進めます。
10. AWS環境の技術的な現状を確認する
SCS評価制度への対応では、規程や体制の整備だけでなく、クラウドの設定状況も確認する必要があります。過去に構築したAWS環境では、管理者権限を持つアカウントを把握できていない、不要なネットワーク公開設定が残っている、ログやアラームの設定状況が分からない、Amazon S3などのストレージ公開範囲に不安がある、といった課題が残っている場合があります。
10-1. クラウドセキュリティチェック for AWS
NTT東日本の「クラウドセキュリティチェック for AWS」では、AWS CIS BenchmarkやAWSのセキュリティベストプラクティスをもとに、ツールと手動確認を組み合わせてAWS環境の設定を点検します。NTT東日本の「クラウドセキュリティチェック for AWS」では、AWS CIS Benchmarkに沿った設定や、AWSのベストプラクティスを踏まえた項目について、ツールと手動確認を組み合わせてチェックします。IAM、AWS CloudTrail、監視、ネットワーク設定、Amazon EC2、Amazon S3などの設定を確認し、結果をレポートでご説明します。
10-2. 技術チェックだけでは制度対応は完了しない
クラウドセキュリティチェック for AWSは、SCS評価制度への適合可否を判定したり、★3・★4の取得を保証したりするサービスではありません。SCS評価制度では、AWSの技術設定に加えて、経営層の関与、セキュリティ方針、社内規程、従業員教育、委託先管理、インシデント対応、復旧手順、証跡の管理なども確認されます。
11. SCS評価制度に関するよくある質問
11-1. SCS評価制度は義務ですか
任意の制度です。取得していないことだけを理由に、法律で商取引が一律に禁止される制度ではありません。ただし、発注企業が委託先に★3や★4の取得を求める可能性はあります。
11-2. クラウドを使っている場合も対象ですか
対象です。クラウド環境が自社のIT基盤を構成している場合は、責任共有モデルに基づいて、自社の設定や運用、クラウド事業者側の対策状況を確認します。
11-3. AWSを利用していれば安全と説明できますか
AWSを利用していることだけでは十分ではありません。管理者アカウント、アクセス権、公開設定、ログ、バックアップなど、利用企業が決定・管理する項目を確認する必要があります。
11-4. ISMSを取得していれば★3を取得できますか
ISMSで整備した規程や記録を活用できる可能性はありますが、自動的に★3へ適合するわけではありません。SCS評価制度の要求事項・評価基準との対応付けと、差分確認が必要です。
11-5. ★3を取得してから★4へ進む必要がありますか
必要ありません。取引先から求められる水準や自社のリスクに応じて、直接★4を目指すこともできます。
11-6. 社内に資格保有者がいれば専門家確認を依頼できますか
対象資格を保有しているだけでは、制度上のセキュリティ専門家にはなりません。所定の研修を受講し、SCS評価制度の事務局へ登録されている必要があります。
11-7. SCS評価制度への対応には新しい製品が必要ですか
必ずしも必要ではありません。既存の製品や運用で要求事項を満たしている場合は、その実施状況を証明できる記録を整備します。不足している対策が見つかった場合に、初めて製品導入や運用改善を検討します。
11-8. 何から始めればよいですか
最初に行うことは、評価範囲の仮決めと、IT資産・クラウドサービスの棚卸しです。その後、要求事項と現在の対策を比較し、不足している対策と証跡を整理します。
12. まとめ
SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策状況を、共通基準で確認・可視化する制度です。クラウド環境も評価対象に含まれるため、クラウド事業者へ任せきりにするのではなく、自社が管理するアカウント、権限、データ、公開設定、ログ、バックアップなどを確認する必要があります。
- 本記事は2026年10月時点で公表されている、経済産業省、内閣官房国家サイバー統括室およびIPAの情報に基づいて作成しています。制度の運用開始時期、申請方法、費用、要求事項・評価基準の解説などは今後更新される可能性があります。最新情報はIPAのSCS評価制度公式サイトでご確認ください。
- Amazon Web Services(AWS)は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
- Microsoft Azureは、Microsoft Corporationの米国及びその他の国における登録商標または商標です。
RECOMMEND
その他のコラム
相談無料!プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。




