SCS評価制度の星3・星4の違い｜準備で確認すること

取引先からSCS評価制度について確認を受けると、星3と星4のどちらを見ればよいか、脆弱性診断を発注すれば足りるのかが分かりにくくなります。星の名称だけを先に比べると、制度資料で確認することと自社で準備することが混ざりがちです。

結論から言うと、星3・星4は名称だけで準備内容を決めず、要求事項、確認に関わる主体、自社に残す証跡を分けて読みます。SCSは法令に基づかない制度であり、2026年9月時点では開始前の準備段階として公表資料を確認する位置付けです。

発注準備では、制度に関する確認と、脆弱性診断の対象・承諾範囲・成果物の確認を別々に進めます。取引先に説明する資料、自社の記録、診断会社へ渡す仕様を整理すると、確認の漏れを見つけやすくなります。

本記事で分かること

• 星3・星4を比べるときの確認軸
• 準備段階で見る記録と担当者
• 脆弱性診断との関係の分け方
• 公式資料の更新を確認する順番

結論：星3・星4は確認軸を分けて読む（早見表）

星の名称だけで準備内容を決めず、要求事項・確認主体・自社の証跡を分けて読みます。比較の目的は星に優劣を付けることではなく、自社の取引関係と運用に必要な確認を特定することです。

段階の違いを準備項目へ翻訳する

段階比較は取得実績ではなく、要求事項の確認から始めます。公表資料で星3・星4の要求事項と評価基準を読み、取引先が何を確認したいのかを自社の資産・運用・責任者の記録に置き換えます。

法令に基づかない制度の確認範囲

SCSの正式名称は、サプライチェーン強化に向けたセキュリティ対策評価制度です。法令に基づかない制度であるため、法律上の義務と同じ表現で扱わず、公式資料に示された要求事項・評価基準・今後の案内を確認します。自社に関係する取引先要請がある場合も、制度資料と契約上の依頼を別欄に残します。

星3・星4の資料を読む際は、星の呼び方だけを社内の達成状況に置き換えません。対象となる項目、確認の単位、記録が必要になる場面を確認し、該当する自社資料を対応付けます。資料に書かれていない開始済みの状況や取得実績を前提にした判断は避け、公式ページの更新を確認します。

確認に関わる主体

制度に関する確認では、取引先への回答を担う担当、運用記録を管理する担当、資産一覧を確認する担当を分けます。ひとりの担当者が制度資料、技術的な対象、契約の質問をすべて判断する形にすると、確認の根拠が不明確になりやすくなります。

IPAは制度に関する案内と、評価実施団体・セキュリティ専門家・研修事業者に関する情報を公開しています。公表の予定や案内の状況は変わり得るため、誰が何を確認するかを先に決め、公式資料を確認した日を記録します。外部の担当者が関わる場合も、自社の窓口を一本化します。

証跡として残す情報

自社で残す証跡は、制度名を並べた一覧ではなく、要求事項に対応する運用の記録です。たとえば、対象資産を管理する一覧、担当者と連絡先、社内で確認した日、取引先から受けた質問を分けて保管します。どの資料がどの確認に使われるかを追える形にします。

証跡の不足を見つけたときは、空欄を推測で埋めず、確認先と次の確認日を残します。制度資料に合わせて新しい記録を作る場合も、既存の資産管理や変更管理の資料と重複しないようにします。更新担当を決めておけば、取引先から再確認を受けた際にも説明しやすくなります。

脆弱性診断との関係を切り分ける

診断の発注は制度名だけで自動的に決まりません。制度の要求事項を確認したうえで、診断で確認したい資産や機能を決め、制度資料で準備する記録とは別の発注仕様としてまとめます。

診断で確認できる範囲

脆弱性診断では、管理下にある対象資産、認証後の機能、連携に関わる範囲などを、発注時の合意に沿って確認します。診断で何を確認するかは、対象一覧、管理者の承諾、実施上の制約で決まります。制度の星を基準に対象を自動で広げるのではなく、自社の運用と取引先に説明したい範囲を起点にします。

Webアプリケーションの対象を整理する際は、公開画面だけでなく、利用者区分や認証後の機能を分けて記録します。Webアプリ診断の対象範囲を参照し、画面名だけでなく、誰が管理し、どこまで承諾を得られるかを確認します。

対象と成果物を一つの仕様表にそろえる基本は、セキュリティ診断の発注ガイドで確認できます。制度対応の説明に使う資料と、依頼先へ渡す対象一覧を分けておくと、対象変更があった場合にも根拠を追いやすくなります。

診断だけでは代替しない範囲

診断報告書は、対象範囲と確認結果を説明する材料になります。しかし、制度資料が求める運用の記録、担当者の体制、取引先への回答を、診断報告書だけで置き換えられるとは限りません。報告書に含まれる内容と、自社で別途残すべき記録を照合します。

反対に、制度に関する資料を読んだだけで、対象システムの確認が完了したとは判断できません。診断対象、対象外、認証後の範囲、連携先を発注仕様に残し、見積書の条件と一致しているかを確認します。二つの資料を同じフォルダに置くだけで完了扱いにせず、役割を別表にします。

取引先要求と見積条件の分け方

取引先からSCSに関する質問を受けた場合は、質問の目的、回答期限、必要な資料を整理します。そのうえで、診断を依頼するなら対象、成果物、実施時の連絡方法を別の表に記入します。取引先の質問文をそのまま見積条件にすると、対象範囲が曖昧なまま依頼が進むおそれがあります。

見積書では、手動の確認をどこまで含めるか、対象をどう数えるか、報告内容をどう受け取るかを確認します。手動診断とツール診断の違いを参考に、方式の名称だけで判断せず、必要な確認を仕様としてそろえます。制度対応の説明と発注条件を分けることで、差分を質問しやすくなります。

準備段階で確認する順番

開始・登録の状況を推測せず、最新の公式資料を確認します。資料の確認日、自社の担当、対象資産の一覧を順に整えると、取引先対応と発注準備を並行して進めやすくなります。

公表資料の確認日を残す

公式資料を確認したら、ページ名、資料の版、確認日、確認した担当を一覧に残します。SCSに関する案内は準備段階の情報を含むため、以前の資料をそのまま前提にせず、取引先へ回答する前と発注を決める前に見直します。

確認日は、資料を読んだ事実だけでなく、どの判断の根拠になったかを示すための情報です。たとえば取引先への回答に使った場合は、回答文と確認した資料を対応付けます。更新が見つかった場合は、対象資産や発注条件に影響するかを担当者と確認します。

自社の担当者を決める

制度の資料を確認する担当、対象資産を整理する担当、取引先へ回答する担当を決めます。担当名だけではなく、判断が必要になったときに誰へ確認するか、連絡が取れない場合に誰が引き継ぐかも記録します。これにより、制度対応が一部の担当者の記憶に依存しにくくなります。

担当者が決まったら、未確認の項目を質問として残します。制度の情報、契約条件、技術的な対象を同じ会議で扱う場合も、回答の根拠を別々に記録します。回答が揃っていない項目は、発注仕様で確定したように扱わないことが重要です。

発注前の対象資産を棚卸しする

診断を検討する対象は、資産名だけでなく、管理者、利用者区分、連携先、変更の予定を含めて整理します。外部サービスや委託先の領域がある場合は、自社が確認できる範囲と承諾を得る窓口を先に確かめます。対象外にする領域も理由とともに残します。

棚卸しの結果を制度資料に無理に当てはめず、診断会社へ渡す対象一覧として整えます。取引先への説明に必要な範囲と、実際に承諾を得られる範囲に差がある場合は、先に差分を共有します。対象と担当の関係を明確にすると、条件変更があっても見積を見直しやすくなります。

まとめ

SCSの星3・星4は、要求事項、確認主体、自社に残す証跡という確認軸で読みます。SCSは法令に基づかない制度であり、準備段階の公式資料を確認しながら、制度対応と脆弱性診断の発注条件を別々に整理することが重要です。

制度に関する記事は、法令・制度の記事一覧から確認できます。