>
>
公開日
最終更新日
取引先から★3の取得を求められた情シス担当者向けに、IPAが公開した★3の26要求事項・81評価基準（81項目）を、評価基準の原文と証跡の例つきのチェックリストにまとめました。★4との差分、取得の手続きと毎年の更新、登録料と受付時期も、一次情報の項番つきで整理しています。81評価基準に○△×を記入できるExcelのチェックリストは、本記事から無料でダウンロードできます。
SCS評価制度と★3の要点
SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）とは、取引先を含む企業のサイバーセキュリティ対策を共通の評価基準で可視化する制度です。経済産業省と内閣官房国家サイバー統括室が制度構築方針を公表し、IPAが制度の運営を担います。
項目 | ★3（星3） | ★4 |
|---|---|---|
評価方式 | 専門家確認付き自己評価。自己評価を★3確認責任者が確認・署名し、経営層が自己適合宣言をしたうえで登録を申請します（SCS-100 3.1.1、1.3.14） | 評価機関による第三者評価 |
要求事項・評価基準 | 26要求事項・81評価基準（81項目）。すべてを満たす必要があります（IPA FAQ Q3-2） | 43要求事項・153評価基準 |
費用（IPAの登録料・税込） | 1万円/1年（2028年4月以降は2万円/1年） | 6万円/3年 |
有効期間 | 1年（毎年、自己評価の更新版を提出） | 3年 |
いつから | 2027年3月頃の運用開始予定です（IPA FAQ Q1-1）。登録希望組織の受付は2027年3月以降の予定です（IPA料金設定、2026年9月18日） | |
★3の取得は、自己評価、確認責任者の確認・署名、自己適合宣言、登録申請、登録・公表の順で進みます。社内で実施する対策費、ツール費、外部支援費は、登録料とは別に見積もります。
★3チェックリスト：7領域・26要求事項・81評価基準（81項目）
本章では、★3の26要求事項を公式の7領域ごとに表にし、要求事項の原文、★3の評価基準の原文、証跡の例を掲載しています（IPA「★3・★4 要求事項・評価基準」2026年4月21日公開から転記）。
チェックリストの使い方
判定 | 状態 | 次にすること |
|---|---|---|
○ | 実施しており、証跡を確認できる | 証跡の保管場所を記録する |
△ | 実施しているが、証跡が無い・不明 | 運用の実態を文書や記録に残す |
× | 実施していない、または実施状況が分からない | 担当者と期限を決めて対策を計画する |
判定は評価基準の単位で行い、要求事項に属する評価基準がすべて○になったときに、その要求事項を満たしたと判断します。★3はすべての要求事項・評価基準を満たす必要があります（IPA FAQ Q3-2）。△は新しい対策を講じなくても記録を整えれば○にできるため、点検後に最初に着手しやすい項目です。証跡の例は社内記録の例で、IPAが書式を指定したものではありません。
点検は「3. リスクの特定」から始めます。端末・サーバ・ネットワーク・外部サービスの一覧が無いと、「4. 攻撃等の防御」の評価基準をどの機器やサービスについて判定するかが決まらないためです。
★3の領域別の要求事項と評価基準
★3の要求事項は7領域で構成され、攻撃等の防御が13要求事項・48評価基準で、評価基準の約6割を占めます。
領域 | 要求事項数 | 評価基準数 |
|---|---|---|
1. ガバナンスの整備 | 3 | 8 |
2. 取引先管理 | 3 | 4 |
3. リスクの特定 | 4 | 11 |
4. 攻撃等の防御 | 13 | 48 |
5. 攻撃等の検知 | 1 | 3 |
6. インシデントへの対応 | 1 | 6 |
7. インシデントからの復旧 | 1 | 1 |
合計 | 26 | 81 |
出典：IPA「★3・★4 要求事項・評価基準」（2026年4月21日公開。IPA SCS評価制度トップページから入手できます）。要求事項は対策テーマ、評価基準は要求事項を満たしているか判断する具体的な確認観点です。両者を単に「項目」として混同すると、確認範囲や証跡の不足を見落とします。
件数が少ない領域の負担が軽いとは限りません。「6. インシデントへの対応」は要求事項1件に評価基準が6件あり、「5. 攻撃等の検知」はリアルタイムで検知・遮断する仕組みの導入を求めています。
表で使う用語
シンクライアント：処理の大半をサーバ側で行う端末
ハイパーバイザ：仮想サーバを動かすための基盤ソフトウェア
CVSS：脆弱性の深刻度を0〜10の数値で表す共通の評価指標
ミドルウェア：OSとアプリケーションの間で動くソフトウェア
ファームウェア：機器に組み込まれた制御用のソフトウェア
1. ガバナンスの整備
ガバナンスでは、セキュリティを担当する体制、守秘義務、方針の制定と周知を確認します。
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
1-2-1 | セキュリティ推進活動部門 |
| 体制図、役割分担表、連絡先リスト、点検記録 |
1-2-3 | 守秘義務のルール |
| 守秘義務の規程（就業規則の条項など）、入社時・受入時の説明資料と実施記録 |
1-3-1 | セキュリティ対応方針の策定 |
| 方針文書、社内ポータルの掲載、周知記録 |
★4との境界：★4では、経営層が参加する委員会などの体制（1-2-1-4）、守秘義務の誓約書と派遣元・出向元との締結（1-2-3-3、1-2-3-4）、方針の年1回以上の点検（1-3-1-4）が上乗せされ、社内ルール、監視・分析体制、推進計画の要求事項が加わります。
経営層の役割や緊急連絡先が古いままでは、インシデント時に連絡が止まります。組織変更、人事異動、委託先変更の後に、少なくとも年1回の点検記録を残します。
2. 取引先管理
取引先管理では、自社資産と接続する外部組織、機密情報の取扱い、事故時の責任分担を契約前から明確にします。
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
2-1-1 | 取引先とのビジネス又はシステム上の関係 |
| 接続先システム一覧、点検記録 |
2-1-2 | 機密情報の取扱い |
| 秘密保持契約、契約書の該当条項 |
2-1-4 | セキュリティインシデント発生時の役割・責任 |
| 契約書・覚書の役割分担条項、役割分担表 |
★4との境界：★4では、取引先ごとの取引手段と授受する情報資産の把握（2-1-1-3）が上乗せされ、取引先の対策状況の把握と、機密情報の回収・破棄の要求事項が加わります。
秘密保持契約があっても、2-1-2が求める項目（機密情報の定義、利用制限、保管方法、複製・第三者提供の可否、返還・廃棄）がそろっているとは限りません。接続先一覧にある外部組織の契約書・覚書を照合し、不足する項目と、2-1-4のインシデント時の役割・責任の取り決めを確認します。条項が無い相手は、次回の契約更新か覚書の締結で補います。
3. リスクの特定
リスクの特定では、端末、サーバ、ネットワーク、外部情報サービス、機密情報を台帳化して管理対象を明らかにします。
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
3-1-1 | 情報機器、OS及びソフトウェアに関する情報の把握 |
| IT資産台帳（仮想基盤を含む）、管理規程、点検記録 |
3-1-2 | ネットワークに関する情報の把握 |
| ネットワークの一覧（所在地・用途）、ネットワーク機器の台帳（製造元・モデル・保守事業者） |
3-1-3 | 外部情報サービスの管理 |
| 利用中のSaaS一覧、要件確認記録、データ取扱いの合意文書 |
3-1-4 | 機密区分に応じた情報の管理 |
| 情報管理規程、機密情報管理台帳 |
★4との境界：★4では、スマートデバイスの台数や重要システムの設定情報の把握（3-1-1-5〜7）、ネットワーク図（3-1-2-3、3-1-2-4）、退職時の回収や廃棄時の抹消（3-1-4-4〜8）が上乗せされ、リモートワークのルールと脆弱性の管理体制の要求事項が加わります。
SCS-100の1.3.26は、IT基盤の例としてクラウドサービスを挙げています。3-1-3の対象は「自社の機密情報を扱う外部情報サービス」なので、利用中のSaaSを一覧にしたうえで機密情報を扱うものを特定し、セキュリティ要件の確認と取扱いの合意を記録します。
4. 攻撃等の防御
攻撃等の防御では、ID・認証・アクセス権・教育・バックアップ・構成・パッチ・マルウェア・ネットワーク境界を管理します。
4-1 アイデンティティ管理、認証、アクセス制御（7要求事項・評価基準27件）
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
4-1-1 | ユーザIDの管理手続 |
| ID申請・承認記録、アカウント一覧、退職者アカウントの削除記録 |
4-1-2 | 管理者IDの管理手続 |
| 管理者ID一覧、権限付与の申請記録 |
4-1-3 | 認証の強度・実装方法の決定 |
| 認証設定、多要素認証の適用状況一覧 |
4-1-4 | アカウントロック制御 |
| 端末のポリシー設定 |
4-1-5 | パスワード設定ルール |
| パスワード規程、周知記録 |
4-1-6 | パスワード管理ルール |
| 保管ルール、変更手順書、周知記録 |
4-1-7 | アクセス権の管理ルール |
| アクセス権・入室権の申請書と台帳、棚卸記録 |
4-2 意識向上とトレーニング／4-3 データセキュリティ（2要求事項・評価基準6件）
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
4-2-2 | セキュリティインシデント発生時の教育・訓練 |
| 教材・掲示物、受講記録、点検記録 |
4-3-4 | 適切なバックアップ |
| バックアップ設定、リストア手順書 |
4-4 プラットフォームセキュリティ／4-5 技術インフラのレジリエンス（4要求事項・評価基準15件）
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
4-4-1 | 情報機器、OS及びソフトウェアの安全な構成 |
| インストール制限の設定、自動実行・自動再生を無効化した設定、設定変更の申請・承認記録 |
4-4-4 | セキュリティパッチ・アップデートの手続 |
| パッチ適用記録（リリース日・適用日）、ソフトウェア一覧、未適用時の緩和策の記録 |
4-4-5 | マルウェア感染からの保護 |
| 導入状況一覧、スキャン設定 |
4-5-1 | ネットワーク境界防護 |
| ファイアウォール設定、ルール一覧、変更記録 |
★4との境界：★4では、多要素認証の対象拡大（4-1-3-5）、アクセス権の年1回以上の棚卸しなど（4-1-7-2〜6）、構成管理（4-4-1-4〜6）、境界機器の脆弱性（4-4-4-3）、Web・メールの対策（4-4-5-4、4-4-5-5）、セグメント分割など（4-5-1-8、4-5-1-9）が上乗せされ、8つの要求事項が加わります。
SaaS・アカウント・権限の把握は、4-1-1、4-1-2、4-1-7の証跡づくりの土台になります。SaaS管理ツールで取得できるアカウント一覧やログは棚卸しの材料として利用できますが、申請承認、最小権限の設計、削除判断、設定の実施は組織側の運用として残します。
5. 攻撃等の検知
攻撃等の検知では、インターネットから社内への通信と、社内から不正なサーバへの通信の双方について、不正なアクセスをリアルタイムで検知・遮断する仕組みと、アラートを判断する体制を確認します。手段の例は、境界に置くUTM（複数のセキュリティ機能を統合した機器）やIPS（不正侵入防止システム）、端末に入れるEDR（端末の不審な挙動を検知・対処する仕組み）です。
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
5-1-1 | ネットワーク接続・データの監視 |
| 検知・遮断製品の設定、アラート対応記録、速報レポート |
★4との境界：★4では、許可ソフトウェアの一覧作成を含む挙動監視（5-1-2）と、インシデントのレベルごとの対象範囲（5-2-1）の要求事項が加わります。
検知製品を導入していても、誰がアラートを確認し、どの条件でインシデントと判断して速報を出すかが決まっていなければ、5-1-1-2と5-1-1-3への対応を説明できません。確認する担当者、判断の基準、速報の送り先を対応手順書に書いておきます。
6. インシデントへの対応
インシデントへの対応では、発見から最終報告までの手順と、社内外への連絡ルートを文書化します。
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
6-1-1 | インシデント対応手順 |
| 対応手順書、連絡体制表、報告書様式 |
★4との境界：6-1-1の評価基準は★3と★4で同じ6件で、★4での上乗せはありません。
連絡先が担当者個人のメールアドレスだけになっている場合は、休日や退職時に機能しません。役割分担表、取引先連絡先、報告書様式を同じ保管場所で管理し、年1回の点検で更新します。
7. インシデントからの復旧
復旧では、重要システムをどの水準まで、どの方法で復旧するかを事前に決めます。
No. | 要求事項（原文） | ★3の評価基準（原文） | 証跡の例 |
|---|---|---|---|
7-1-1 | 事業継続要件に沿った復旧準備 |
| 復旧計画、事業継続計画 |
★4との境界：★4では、バックアップの保管と、目標復旧時間内での復元確認（7-1-1-2）が上乗せされます。
バックアップを取得している事実と、業務を復旧できることは別です。復旧対象、復旧順序、手作業へ切り替える業務、復旧責任者を復旧計画に記載し、実行可能な手順書として保管します。
補助資料として用意しているSCS評価制度★3チェックリスト（Excel）を無料ダウンロードには、81評価基準を○△×で記入できるExcelと、全評価基準の証跡例を収録しています。本文の表とあわせて、自己点検の記録にお使いください。
SCS評価制度とは
SCS評価制度とは、取引先を含む企業のサイバーセキュリティ対策を共通の評価基準で可視化する制度です。
経済産業省と内閣官房国家サイバー統括室は制度構築方針を公表し、IPAが制度の運営を担うと案内しています（参照：IPA SCS評価制度詳細ページ）。
SCS-100基本規程は、制度の狙いとして、発注者が受注者のセキュリティ対策を確認しやすくすることと、受注者の取組を通じてサプライチェーン・リスクを下げ、経済・社会全体のサイバーレジリエンスを強化することを挙げています（SCS-100 1.2）。
対象企業と適用範囲
SCS評価制度は、取引先から求められる評価水準に応じて、サプライチェーンに参加する企業が登録を目指す制度です。
顧客や親会社の情報を扱う企業、基幹システムの運用を受託する企業、クラウドサービスを利用して業務データを処理する企業では、取引先から評価水準の提示を求められる可能性があります。まずは取引基本契約、セキュリティ要求書、既存のチェックシートを確認し、★3または★4の指定があるかで準備の範囲を決めます。
SCS-100では、適用範囲の対象となるIT基盤として、サーバ、PC・スマートデバイスなどのエンドポイント機器、クラウドサービスや親会社等が提供するグループ共通のネットワークなど他社と対策の責任を共有するもの、ファイアウォール・ルータ・VPN装置などのネットワーク機器を挙げています（SCS-100 1.3.26）。クラウドサービスもこのIT基盤の範囲に含まれます。SaaSを利用している企業では、サービス一覧、契約主体、管理者、利用者、データの取扱いを棚卸しし、資産管理と取引先管理の双方で説明できる状態にします。
公式資料の公開状況
2026年10月6日時点で公開されている主な公式資料は、「★3・★4 要求事項・評価基準」（Excel、2026年4月21日公開）、SCS-100基本規程（2026年8月28日）、FAQ、料金設定（2026年9月18日）です。要求事項・評価基準の解説書、取得ガイド、申請方法は、IPAが2026年10月頃の公開予定としています（IPA SCS評価制度トップページ）。「チェックリスト」という名称の公式文書は、同日時点で確認できません。
解説書の公開前でも、要求事項・評価基準をもとに自己点検は進められます。判断に迷った評価基準は、△の判定と迷った理由を記録しておき、解説書の公開後にその項目から見直します。
制度開始までのスケジュール
★3・★4は2027年3月頃の運用開始を予定しています（IPA FAQ Q1-1）。2026年10月頃に公開予定とされているのは解説書・取得ガイド・申請方法で、申請受付の開始ではありません。
IPAの料金設定（2026年9月18日）では、★3・★4の登録希望組織の受付は2027年3月以降、SCSセキュリティ専門家の受付は2027年1月以降に開始する予定とされています。同日、評価機関、技術検証事業者、研修事業者の新規申請募集も始まりました。受付日程は更新されることがあるため、申請前にIPA SCS評価制度トップページで最新の受付状況を確認します。
▶ 関連記事: SCS評価制度とは？評価項目・いつから始まるかを情シス目線で解説
▲ SCS評価制度に関わる各機関・取引先と自社の役割構成図
★3と★4の評価方式と選定基準
★3は専門家確認付き自己評価（SCS-100 3.1.1）、★4は評価機関による第三者評価であり、取引先の指定と自社の業務上の責任範囲で選びます。
★3は、一般的なサプライヤーや委託先が基本的な防御・管理体制を整備し、その自己評価を確認責任者が確認する仕組みです。★4は、より広い要求事項に対して評価機関による第三者評価を受ける仕組みです。発注元から評価レベルを指定されている場合は、その指定を優先します。
評価レベルの比較
要求事項数、有効期間、評価方式を並べると、準備すべき体制と更新負荷の違いを把握できます。
比較項目 | ★3 | ★4 |
|---|---|---|
要求事項・評価基準 | 26要求事項・81評価基準 | 43要求事項・153評価基準 |
評価方式 | 専門家確認付き自己評価 | 評価機関による第三者評価 |
登録有効期間 | 1年 | 3年 |
費用（IPAの登録料・税込） | 1万円/1年（2028年4月以降は2万円/1年） | 6万円/3年 |
主な判断材料 | 取引先から★3を求められる、または基礎的な対策水準を示したい場合 | 取引先から★4を求められる、または重要な業務・情報を直接扱う場合 |
登録料はIPAの料金設定（2026年9月18日）に基づく税込金額で、料金の適用時期は申請日が基準です。SCSセキュリティ専門家の登録料は無料です。社内で実施する対策費、ツール費、外部支援費は登録料とは別に見積もります。
★4で追加される要求事項と評価基準
★4では、★3の26要求事項・81評価基準に、17要求事項・72評価基準が加わります（IPA「★3・★4 要求事項・評価基準」から集計）。72評価基準のうち30件は★3と共通の要求事項に上乗せされる基準、42件は★4で新たに加わる17要求事項の基準です。
領域 | ★3（要求事項／評価基準） | ★4（要求事項／評価基準） | ★4で追加される評価基準 |
|---|---|---|---|
1. ガバナンスの整備 | 3／8 | 6／19 | 11 |
2. 取引先管理 | 3／4 | 5／7 | 3 |
3. リスクの特定 | 4／11 | 6／29 | 18 |
4. 攻撃等の防御 | 13／48 | 21／82 | 34 |
5. 攻撃等の検知 | 1／3 | 3／8 | 5 |
6. インシデントへの対応 | 1／6 | 1／6 | 0 |
7. インシデントからの復旧 | 1／1 | 1／2 | 1 |
合計 | 26／81 | 43／153 | 72 |
★4で新たに加わる17要求事項は次のとおりです。
ガバナンスの整備：1-1-1 社内ルール、1-2-2 サイバー攻撃の監視・分析体制、1-4-1 セキュリティ対策推進計画
取引先管理：2-1-3 取引先のセキュリティ対策状況、2-1-5 機密情報の回収・破棄
リスクの特定：3-1-5 リモートワークにおけるルール、3-2-1 脆弱性の管理体制
攻撃等の防御：4-1-8 サーバ設置エリアへの入退室管理、4-1-9 可搬媒体の制限、4-2-1 セキュリティの意識向上のための教育・研修、4-3-1 データの暗号化、4-3-2 データの保管ルール、4-3-3 取引先との情報共有ルール、4-4-2 サポート期限の切れたOS及びソフトウェアへの対策、4-4-3 ログの取得
攻撃等の検知：5-1-2 情報機器及びソフトウェアの挙動監視、5-2-1 セキュリティインシデントのレベルごとの対象範囲
★3の取得後に取引先から★4を求められた場合は、上乗せされる30件で既存の対策と記録の水準を引き上げ、新設の17要求事項について規程・体制・仕組みを整備します。★3の自己点検で作った記録は、★4との差分を洗い出す出発点になります。
★4で上乗せされる30の評価基準
★4では、★3と同じ要求事項にも評価基準が30件上乗せされます。★3の段階でここまで把握しておくと、★4を求められたときに差分を整理しやすくなります（IPA「★3・★4 要求事項・評価基準」から抽出）。
★3の要求事項 | ★4で追加される内容 | 評価基準No. |
|---|---|---|
1-2-1 セキュリティ推進活動部門 | 経営層が参加する情報セキュリティ委員会など、経営判断ができる体制を設置する | 1-2-1-4 |
1-2-3 守秘義務のルール | 機密情報を扱う役員・従業員に守秘義務の誓約書を提出させる（社外要員を除く）。派遣社員・受入出向者は、派遣元・出向元と業務開始前に守秘義務を締結する | 1-2-3-3、1-2-3-4 |
1-3-1 セキュリティ対応方針の策定 | 方針の内容を年1回以上点検する | 1-3-1-4 |
2-1-1 取引先とのビジネス又はシステム上の関係 | 機密情報を共有する子会社・取引先ごとに、取引の手段と、授受・使用する情報資産とその取扱いを把握する | 2-1-1-3 |
3-1-1 情報機器、OS及びソフトウェアに関する情報の把握 | スマートデバイスの製造元・OS・台数と、重要なシステムを構成する機器の設定情報を把握し、年1回以上点検する | 3-1-1-5〜3-1-1-7 |
3-1-2 ネットワークに関する情報の把握 | ネットワーク図を作成し、年1回以上点検する | 3-1-2-3、3-1-2-4 |
3-1-4 機密区分に応じた情報の管理 | 重要な機密情報の把握項目を年1回以上点検する。退職時・任期満了時に機密情報・機器・アクセス権を回収し、回収状況を年1回以上点検する。機器や記憶媒体の廃棄時はデータを復元できないよう抹消し、記録を保管する | 3-1-4-4〜3-1-4-8 |
4-1-3 認証の強度・実装方法の決定 | 多要素認証の対象を、インターネット経由の社内接続、管理者のインターネット経由のアクセス、重要な機密情報を扱うシステムへのインターネット経由のアクセスにも広げる | 4-1-3-5 |
4-1-7 アクセス権の管理ルール | アクセス権を年1回以上棚卸しする。重要な機密情報を扱うシステムは、付与の条件、管理者の要件と設定手順、最小権限、利用状況の監視を定める | 4-1-7-2〜4-1-7-6 |
4-4-1 情報機器、OS及びソフトウェアの安全な構成 | 不要なサービス・プロトコルを無効化し、デフォルトのユーザIDを停止（または多要素認証などを適用）し、OS・ソフトウェアの標準構成・設定ルールを定める | 4-4-1-4〜4-4-1-6 |
4-4-4 セキュリティパッチ・アップデートの手続 | インターネットとの境界にあるネットワーク機器のOS・ファームウェアに、CVSS基本値7.0以上の脆弱性が無い状態にする | 4-4-4-3 |
4-4-5 マルウェア感染からの保護 | 不正なWebサイトへのアクセスを制限し、メールゲートウェイなどでマルウェアチェックを行う | 4-4-5-4、4-4-5-5 |
4-5-1 ネットワーク境界防護 | OSが対応していない場合を除き、すべてのPC・サーバでソフトウェアファイアウォールを有効化する。社外公開サーバと重要な機密情報を扱うサーバは専用のネットワークセグメントに置く | 4-5-1-8、4-5-1-9 |
7-1-1 事業継続要件に沿った復旧準備 | 目標復旧時点まで戻せるようバックアップを保管し、リストア手順書どおりに目標復旧時間内で復元できることを確認する | 7-1-1-2 |
★3の段階で作る記録の中には、★4の評価基準の土台になるものがあります。接続先システムの一覧（2-1-1）は、取引先ごとの取引手段と授受する情報資産の把握（2-1-1-3）に、ネットワークの一覧（3-1-2）はネットワーク図の作成（3-1-2-3）に、リストア手順書（4-3-4）は目標復旧時間内の復元確認（7-1-1-2）に、それぞれつながります。インストール制限（4-4-1）の運用は、★4の許可ソフトウェア一覧の作成（5-1-2-1）の準備にもなります。
★3確認責任者の確認と自己適合宣言
★3では、自社の自己評価を作成した後、★3確認責任者の確認と署名を受けて自己適合宣言と登録申請へ進みます。評価方式の名称「専門家確認付き自己評価」の「専門家確認」にあたるのが、この★3確認責任者による確認です（SCS-100 3.1.1）。
★3確認責任者は、社内・社外のどちらの人でも担えます。登録希望組織は、必要に応じて社内外の★3確認責任者から支援を受けて自己評価を行い、確認責任者は自己評価の妥当性を確認して署名します（SCS-100 3.1.1）。確認責任者の要件は別途定めるとされているため（SCS-100 1.3.7）、今後公開される申請方法などのIPA公式資料で確認します。社内に要件を満たす人がいない場合は、外部の専門家への依頼を検討します。
自己適合宣言は、自己評価の結果に基づき、適用範囲のIT基盤等が要求事項・評価基準のすべてに適合していることを、経営層が自社の責任で宣言するものです（SCS-100 1.3.14）。情シス部門だけで完結する手続きではないため、経営層への報告の時期も準備計画に入れておきます。
★4の第三者評価
★4では、自己評価だけで登録するのではなく、評価機関による第三者評価を受けます。
IPAは評価機関、技術検証事業者、研修事業者の新規申請募集を開始しています。★4を指定された企業では、評価機関の指定状況、技術検証の対象範囲、評価に必要な資料を確認し、通常のセキュリティ運用とは別に評価対応の担当者と日程を確保します。★4の取得可否を社内の既存認証だけで判断せず、153評価基準との差分を文書・設定・ログの三つに分けて整理します。
取得の手続きと毎年の更新
★3の登録は、自己評価、確認責任者の確認・署名、自己適合宣言、登録申請、登録・公表の順で進みます。
★3の有効期間は1年であり、満了前には確認責任者の確認・助言を受けた自己評価の更新版を提出します。
登録内容に変更が無くても更新版の提出は必要で、満了日前に提出していれば、審査が終わるまで登録の効力は続きます（SCS-100 3.1.2）。
★4の有効期間は3年で、有効期間中も1年ごとに自己評価を評価機関へ提出します（SCS-100 3.2.2）。
SCS-100は、不正があった場合の登録の取消しも定めています（SCS-100 3.1.3）。登録組織は、条件に従ってロゴマークを使用できます（SCS-100 4.1）。
申請時だけに証跡を集めるのではなく、毎月または四半期ごとの棚卸し、パッチ適用、教育、アクセス権点検の記録を残す運用にすると、更新時に過去の状態を再現しやすくなります。
▶ 関連記事: 【SCS評価制度】経産省セキュリティチェックシートの作り方
▲ 自社が目指すべき評価レベル（★3または★4）の選定フロー
制度対応に向けた情シスの進め方
制度対応は、81評価基準の自己点検、証跡の整理、不足対策の実装、確認責任者の確認の順で進めます。
最初から全社規程を書き換えたり、新しい製品を導入したりすると、実態と文書が乖離しやすくなります。現状の運用を確認し、証跡がある対策と、未実施または証跡不足の対策を分けてから改善計画を作成します。
自己点検とギャップ分析
最初の段階では、81評価基準ごとに○△×を付け、△と×を改善対象として一覧化します。
確認対象 | 確認する資料 | 判断後の進め方 |
|---|---|---|
規程・手順 | 情報セキュリティ方針、ID管理規程、インシデント対応手順 | 文書があり現行運用と一致すれば証跡候補にし、不一致なら改定対象にします。 |
資産・SaaS | 端末台帳、ソフトウェア一覧、SaaS契約一覧、ネットワーク一覧 | 一覧と実態が一致すれば点検記録を残し、不明なサービスがあれば利用部門への照会に進みます。 |
ID・権限 | アカウント一覧、管理者ID一覧、申請承認記録、退職者削除記録 | 付与から削除まで追跡できれば証跡候補にし、承認履歴がなければ申請フローを整備します。 |
技術対策 | MFA設定、パッチ記録、マルウェア対策設定、通信監視ログ | 設定と運用記録の両方があれば証跡候補にし、設定だけの場合はログ・点検記録を追加します。 |
既存のチェックシートを基に自社向けの管理表を整えたい場合は、セキュリティチェックシートの作り方で、質問設計と証跡管理の考え方を確認できます。
対策の優先順位
△と×が多い場合は、次の3段階で優先順位を付けます。
管理対象を確定する：「3. リスクの特定」で、端末・サーバ、ネットワーク、外部情報サービス、機密情報の一覧を作ります。
設定の見直しで対応できる評価基準を片付ける：下の一覧の評価基準は、既存の機器やサービスの設定で対応できる場合があります。設定画面や設定値の記録がそのまま証跡になります。
自社だけでは続けにくい評価基準の体制を決める：不正な通信のリアルタイムでの検知・遮断とアラートの分析・通知（5-1-1-1〜5-1-1-3）や、重大な脆弱性を修正するアップデートの14日以内の適用（4-4-4-2）には、製品の導入に加えて、日常の監視と脆弱性情報の確認を続ける体制が必要です。社内で担えない場合は、監視サービスや保守事業者などの外部支援を検討します。
設定の見直しで対応できる場合がある評価基準
重要な機密情報を扱うクラウドサービスで多要素認証を有効化する（4-1-3-2）
PCログオン・スマートデバイスのロック解除に試行回数の制限と6文字以上のパスワード／PINを設定する（4-1-4-1、4-1-4-2）
外部記録媒体の自動実行・自動再生を無効化する（4-4-1-2）
可能な範囲で自動アップデートを有効化する（4-4-4-1）
ファイアウォール・ルータの初期管理パスワードを変更する（又はリモートアクセスを無効化する）（4-5-1-1）
インターネット経由でファイアウォール・ルールを変更する場合に多要素認証かIPアドレス制限をかける（4-5-1-7）
半年で進める準備計画
既存の規程と資産台帳があり、主要な技術対策を導入済みなら、6か月を目安に証跡と運用を整えます。
1か月目：81評価基準の自己点検を行い、○△×と証跡の保管場所を記録します。
2〜3か月目：体制図、ID管理、取引先契約、資産台帳、インシデント手順の不足を修正します。
4か月目：MFA、パッチ、マルウェア対策、ネットワーク監視の設定と運用記録を確認します。
5か月目：教育、アクセス権棚卸し、バックアップ・復旧手順の点検を実施します。
6か月目：自己評価を更新し、確認責任者による確認・助言を受ける準備をします。
この期間は制度が定める取得期間ではありません。既存の規程・技術対策がある程度整備されている場合の準備順序の例で、実際の所要期間は現状のギャップによって変わります。パッチ適用記録や年1回の教育記録が不足している場合は、記録を作り直すのではなく、今後の実施日と責任者を定めて運用を開始します。
1年で進める準備計画
資産台帳、SaaS一覧、規程、ログ管理が未整備な場合、1年をかけて基盤整備と運用定着を進める例です。
1〜2か月目：端末、サーバ、ネットワーク、SaaS、外部接続先を棚卸しします。
3〜4か月目：セキュリティ推進体制、方針、守秘義務、取引先管理の文書を整備します。
5〜7か月目：ID管理、アクセス権、MFA、パスワード、パッチ、マルウェア対策の運用を実装します。
8〜9か月目：監視・アラート、インシデント対応、バックアップ、復旧計画を整備します。
10〜11か月目：教育、棚卸し、点検を実施し、証跡の不足を補います。
12か月目：自己評価を見直し、確認責任者へ提示する資料を整理します。
担当者が限られる場合は、81評価基準を一度に直そうとせず、上の「対策の優先順位」の順に進めます。未対応の項目は放置せず、改善計画、暫定対策、実施予定日を残しておくと、確認責任者に現状を説明しやすくなります。
年1回以上の実施・点検が求められる8つの評価基準
★3の81評価基準のうち8件は、年1回以上の実施または点検を求めています。★3の有効期間は1年なので、更新の準備とあわせて年間の予定に組み込みます。
評価基準No. | 内容 | 証跡の例 |
|---|---|---|
1-2-1-3 | セキュリティ推進体制（役割・責任、連絡先リスト）の点検 | 点検記録 |
2-1-1-2 | 接続先システムの把握内容の点検 | 点検記録、接続先システム一覧 |
3-1-1-4 | 情報機器・OS・ソフトウェアの管理ルールの遵守状況の点検 | 点検記録 |
3-1-4-2 | 機密情報の管理ルールの点検 | 点検記録、情報管理規程の改訂履歴 |
4-2-2-1 | インシデント対応の教育・訓練（新規受入時と年1回以上） | 教材、受講記録 |
4-2-2-3 | 教育・訓練の実施内容の点検 | 点検記録 |
6-1-1-4 | インシデント発生時の連絡先・報告ルートと役割・責任の点検 | 点検記録、連絡体制表 |
6-1-1-6 | インシデント事例と対応策の社内共有（年1回以上と重大事案の発生時） | 共有の記録 |
ツールと手作業の分担
SaaS管理や資産管理のツールは、一覧化、アカウント棚卸し、権限確認の作業を補助します。
一方で、体制図の作成、契約条項の確認、教育、インシデント時の判断、復旧計画の策定は、ツールだけでは完結しません。監査ログをAPIで取得できるSaaSは自動収集の対象にし、APIを利用できないSaaSはCSV出力または管理画面の確認記録を残す運用にします。
▶ 関連記事: サプライチェーン攻撃とは？手口・脅威の推移と中小企業の対策
▲ 領域別の評価基準数（★3の81件と★4で追加される72件）
確認責任者への提示資料と外部支援
★3確認責任者には、自己評価の回答と証跡が整合していることを示せる状態にしておきます。
確認責任者の確認は、製品の導入有無だけを見る手続きではありません。例えば、多要素認証を導入していても、対象となる重要な機密情報を扱うクラウドサービスが一覧化されていなければ、適用漏れを説明できません。規程、設定、運用記録を同じ要求事項単位で整理します。
確認責任者への提示資料
確認責任者には、自己評価表に加えて、回答の根拠となる証跡を要求事項ごとに提示します。
資料区分 | 主な資料 | 確認時の見方 |
|---|---|---|
組織・規程 | 体制図、方針、ID管理規程、教育資料 | 責任者、対象者、実施頻度、改定・周知の記録を確認します。 |
資産・契約 | 資産台帳、SaaS一覧、接続先一覧、契約書・覚書 | 管理対象が漏れなく把握され、契約上の責任が整理されているかを確認します。 |
設定・運用 | MFA設定、パッチ記録、アカウント一覧、監視アラート | 設定が存在するだけでなく、対象範囲と実施履歴を確認します。 |
点検・改善 | 棚卸記録、教育受講記録、点検記録、改善計画 | 年次または定期的な見直しが実施されているかを確認します。 |
フォルダ構成は「要求事項番号_資料名_対象年月」のように統一すると、自己評価と証跡の対応を追いやすくなります。個人情報や認証情報を含む資料は、確認責任者へ渡す前に閲覧権限、マスキングの要否、保管期限を整理します。
外部支援を使う場合の判断材料
社内で要求事項の解釈や証跡の妥当性を判断できない場合は、外部支援の対象範囲を分けて依頼します。
依頼範囲は、現状診断、規程作成、技術対策の実装、証跡整理、確認責任者による確認などに分けられます。見積もりでは、対象となる拠点・端末・サーバ・SaaS数、既存資料の有無、訪問の有無、ツール費用を含むかを明記します。登録料はIPAへの料金であり、外部支援費とは別です。「対策の優先順位」の3段目に挙げた検知・監視やパッチ適用の運用は、外部支援を検討する代表的な範囲です。
★3確認責任者の要件は別途定めるとされています（SCS-100 1.3.7）。外部支援先を選ぶ段階では、公開された要件を満たすか、確認できる範囲、証跡の取扱い、責任分界を確認します。確認責任者を担えない支援先には、ギャップ分析や文書整備など、確認責任者でなくても担える範囲を依頼します。
ISMS取得企業の差分整理
ISMSを取得している企業でも、SCSの要求事項と証跡を対応付ける作業は必要です。
ISMSの情報資産台帳、リスクアセスメント、教育記録、内部監査記録は活用できる場合があります。ただし、SCSでは外部情報サービス、取引先との情報取扱い、管理者ID、パッチ適用、ネットワーク接続の検知・遮断など、具体的な運用状態を確認する要求事項があります。既存のISMS文書をそのまま流用するのではなく、26要求事項のどれに対応するかを一覧で紐付け、証跡が不足する箇所だけを追加整備します。
ISMSで整備済みのことが多い文書・記録 | 証跡として照合する主な要求事項 |
|---|---|
情報セキュリティ基本方針、組織体制・役割分担 | 1-2-1、1-3-1 |
就業規則の守秘義務条項、入社時の説明記録 | 1-2-3 |
取引先との秘密保持契約、委託先管理の規程 | 2-1-2、2-1-4 |
情報資産台帳、機密区分の規程 | 3-1-1、3-1-4 |
アクセス制御規程、教育の受講記録 | 4-1-1、4-1-7、4-2-2 |
インシデント対応手順、事業継続計画 | 6-1-1、7-1-1 |
文書があっても、評価基準が求める条件（年1回以上の点検、報告フォーマット、関係当局を含む連絡先など）が書かれているかは個別に確認します。次の評価基準は、規程ではなく設定と運用記録で示します。
端末のロックとパスワード／PINの文字数（4-1-4）
重要な機密情報を扱うクラウドサービスの多要素認証（4-1-3-2）
リリースから14日以内のアップデート適用（4-4-4-2）
マルウェア対策ソフトの導入とスキャン（4-4-5）
不正な通信のリアルタイムでの検知・遮断（5-1-1）
制度対応で起こりやすい失敗パターン
SCS評価制度への対応で失敗しやすいのは、対策の導入と証跡の整備を同一視することです。
評価基準への対応では、実施している事実を説明できる状態が必要です。以下の失敗パターンを避けることで、自己評価のやり直しや確認責任者との認識齟齬を減らせます。
ツール導入だけで完了と判断するケース
MFA、EDR、資産管理ツールを導入しても、対象範囲、設定、点検、対応履歴がなければ要求事項への対応を説明できません。
例えば、MFAが一部のSaaSにしか適用されていない、退職者アカウントの削除記録がない、パッチ適用日が確認できない場合は、導入済みでも自己点検では△または×になります。ツールから取得できる一覧やログを定期保存し、どの要求事項の証跡にするかを明記します。
資産台帳と実態が一致しないケース
端末台帳だけを管理し、部門契約のSaaS、仮想サーバ、外部接続先が漏れると、リスクの特定とアクセス管理の基礎が崩れます。
特に、購買部門の契約一覧、人事の入退社情報、情シスのアカウント一覧が別々に管理されていると、利用終了後のアカウントが残りやすくなります。月次で入退社情報とアカウント一覧を照合し、四半期または年次でSaaS・外部接続先を棚卸しするなど、台帳の更新契機を決めます。
契約とインシデント連絡を後回しにするケース
取引先管理では、技術対策よりも契約条項や連絡責任の不足が課題になる場合があります。
機密情報を共有しているにもかかわらず、第三者提供、返還・廃棄、インシデント時の役割が契約書にない場合、発生後に責任範囲を調整することになります。新規契約だけでなく、既存の重要取引先を接続先一覧から抽出し、契約書・覚書の該当条項を確認します。
14日以内のパッチ適用を記録しないケース
評価基準4-4-4-2では、ベンダーが重大・高リスクとする脆弱性、CVSS基本値7.0以上の脆弱性、深刻度が示されていない脆弱性を修正するアップデートを、リリースから14日以内に適用することが求められます。期限内に適用できない場合は、機能の無効化、ベンダー推奨の回避策、ネットワークからの分離、通信の監視・遮断のいずれかでリスクを下げます。
パッチ管理の記録として残すべき主な情報は、脆弱性または更新の識別情報、リリース日、適用日、対象端末・対象サービス、未適用時の緩和内容です。完了件数だけを月次報告する運用では、期限を満たしたか判断できません。
目標復旧レベルを決めずにバックアップだけ取るケース
7-1-1-1は、事業継続上重要なシステムについて業務の目標復旧レベルを定め、そこまで回復するための対策を整備することを求めています。バックアップの取得記録だけでは、この評価基準への対応を説明できません。
復旧計画には、優先するシステム、目標復旧レベル、担当者、待機系や電話・FAXなど人手による代替手段、影響を受ける取引先の連絡先を書きます。リストア手順書どおりに目標復旧時間内で復元できるかの確認は★4の評価基準（7-1-1-2）ですが、★3の段階で一度試しておくと、手順書の不備を早く見つけられます。
よくある質問
よくある質問へ簡潔に回答します。
公式のチェックリストはありますか
「チェックリスト」という名称の公式文書は、2026年10月6日時点で確認できません。公式の要求事項・評価基準は、IPAが公開している「★3・★4 要求事項・評価基準」（Excel）で確認できます（IPA SCS評価制度トップページ）。本記事のチェックリストは、このExcelから★3の評価基準を転記したものです。
81評価基準のすべてを満たす必要がありますか
はい。★3はすべての要求事項・評価基準を満たす必要があります（IPA FAQ Q3-2）。△または×が残る評価基準は、証跡を補うか対策を実施してから、確認責任者への提示に進みます。
無料のチェックリストを選ぶときの注意点はありますか
要求事項（26件）と評価基準（81件）のどちらを単位にしているか、いつ時点の公式資料に基づいているか、公式にない独自項目が混ざっていないかを確認します。公式の番号（例：4-1-3）と照合できるチェックリストであれば、自己評価や確認責任者への提示資料と対応を取りやすくなります。
まとめ
★3は26要求事項・81評価基準のすべてを満たす必要があり、2027年3月頃の運用開始が予定されています。準備は次の順で進めます。
本記事のチェックリストで81評価基準に○△×を付け、△と×が「対策の不足」か「証跡の不足」かを分けて記録します。
「3. リスクの特定」で管理対象を確定させ、設定の見直しで対応できる評価基準から片付けます。
年1回以上の実施・点検が求められる8つの評価基準を、更新の準備とあわせて年間の予定に組み込みます。
2026年10月頃に公開予定のIPAの解説書・申請方法で確認責任者の要件と手続きを確認し、判断を保留した評価基準を見直します。
81評価基準の記録には、SCS評価制度★3チェックリスト（Excel）を無料ダウンロードを利用できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
