SCS評価制度とSECURITY ACTIONの違い｜準備の進め方を分けて考える

SCS評価制度とSECURITY ACTIONは、どちらもセキュリティ対策に関する名称として見かけます。そのため、同じ手続きなのか、どちらかを準備すれば脆弱性診断も済むのかと考えやすくなります。

結論から言うと、二つは目的と確認方法を分けて扱います。SCSはサプライチェーン強化に向けたセキュリティ対策評価制度であり、SECURITY ACTIONは中小企業が情報セキュリティ対策に取り組むことを自己宣言する制度です。どちらも法令に基づかない制度であり、同一の認証として比べるものではありません。

準備では、自社の宣言・運用記録、取引先に説明する資料、脆弱性診断の対象資産を別々に確認します。制度名を発注仕様へ直接書き込む前に、何を確認し、誰が判断するかを整理しましょう。

本記事で分かること

• SCSとSECURITY ACTIONの目的の違い
• 確認に関わる主体と自社記録の分け方
• 脆弱性診断を置く位置
• 取引先対応と発注準備の順番

結論：二つの制度は目的と確認方法で分ける（早見表）

SCS評価制度とSECURITY ACTIONは、同じ尺度で取得状況を比べず、目的と確認方法を別に整理します。制度資料で確認する内容と、診断会社へ渡す発注条件は、それぞれ別表で管理します。

制度名ではなく役割を比べる

自己宣言と評価制度を同一の認証として扱わないことが大切です。制度名ではなく、誰に何を説明するための資料か、自社でどの記録を残すかという役割から確認します。

法令に基づかない制度の目的

SCSは、サプライチェーン強化に向けたセキュリティ対策評価制度としてIPAが案内しています。2026年9月時点では開始前の準備段階の情報を含むため、公式資料に示された要求事項や案内を確認し、開始済みの実績を前提にしないことが必要です。取引先がSCSについて尋ねる場合は、質問の目的と必要な資料を分けて確認します。

SECURITY ACTIONは、中小企業が情報セキュリティ対策に取り組むことを自己宣言する制度です。制度の案内や中小企業の情報セキュリティ対策ガイドラインを読み、自社の対策状況を確認する入口として使います。SCSと同じ評価結果や同じ確認手続きが得られるものとして扱わず、目的に合わせて資料を選びます。

確認に関わる主体

SCSでは、公式に案内される評価に関わる主体と、自社で資料を確認する担当を区別します。取引先対応の窓口、対象資産を管理する担当、契約条件を確認する担当を決め、誰がどの資料を確認したかを残します。制度の案内を読むことと、自社の対策が十分かを決めることは別の作業です。

SECURITY ACTIONでは、自社が取り組む内容を確認し、自己宣言に関わる担当を定めます。情報システムだけでなく、経営層や業務部門が関わる記録もあるため、技術担当だけに判断を集めません。取引先への回答が必要な場合は、回答の根拠となる資料と回答者を対応付けます。

自社で残す記録

SCSに備える記録としては、対象資産の一覧、運用を確認した日、担当者、取引先から受けた質問を整理します。要求事項の名称だけを並べるより、どの社内資料が説明に使えるかを記録する方が、更新時の確認に役立ちます。未確認の項目は推測で埋めず、確認先と期限を残します。

SECURITY ACTIONに関しては、自己宣言の内容と、日常的に行う対策の確認記録を結び付けます。手順書、連絡体制、資産の管理方法などが複数の担当に分かれている場合は、所在を一覧にします。二つの制度の資料を同じ保存先に置く場合でも、目的と確認日を区別します。

脆弱性診断をどこに置くか

診断は制度名の代替ではなく、対象資産の確認手段として整理します。組織的な対策や自己宣言の資料とは別に、対象、承諾、成果物、再確認の条件を発注仕様にまとめます。

診断対象を棚卸しする

診断の対象は、制度の名称から決めるのではなく、管理下にある画面、機能、認証後の領域、連携先を棚卸しして決めます。対象ごとに管理者と承諾を得る窓口を確認し、対象外にする領域も理由を残します。自社が利用しているだけの外部サービスを、管理者の確認なしに含めないようにします。

セキュリティ診断の発注ガイドを参照し、目的、対象、実施上の制約、成果物を一つの仕様表にまとめます。制度対応で必要な資料と診断の対象一覧を分けることで、見積を受け取った後も条件差を確認しやすくなります。

組織的な対策と分ける

脆弱性診断の報告書は、対象範囲で確認した内容を示す資料です。一方で、制度や自己宣言に関して必要になる担当体制、日常の運用記録、取引先への説明を、診断報告書だけで代替できるとは限りません。診断の成果物に何が含まれるかを確認し、別途残すべき資料を整理します。

組織的な対策を確認するために診断を発注する場合も、診断対象に含める資産と、社内の管理手順を一つの項目にしません。診断で確認したい機能、運用で確認する担当、制度資料で示す記録を分け、必要な情報をそれぞれの担当へ依頼します。

取引先要求と照合する

取引先からSCSやSECURITY ACTIONに関する質問を受けたら、質問票の項目、回答期限、添付が必要な資料を確認します。質問の目的が制度資料の確認なのか、特定システムの診断状況なのかを切り分けます。回答に必要な情報が未確認なら、未確認として関係者へ共有します。

診断の方式を検討する場合は、目的と対象を対応付けます。脆弱性診断とペネトレーションテストの違いを確認し、何を確認したいのかを短い文で定義してから、実施の承諾範囲と報告内容を依頼先へ伝えます。制度名だけで依頼内容を決めないことが重要です。

準備の確認順

最新の公表資料を確認し、予定と実績を混同しないことが必要です。資料の確認日、社内の担当分担、見積へ渡す情報を順に整えます。

公式資料の確認日

SCSとSECURITY ACTIONの資料を確認したら、ページ名、資料の版、確認日、確認者を記録します。SCSは準備段階の案内を含むため、以前に読んだ情報だけで開始状況や実績を判断しません。取引先へ回答する前と、診断の発注を決める前に公式資料を見直します。

確認日を残すことで、制度の更新が自社の回答や発注条件に影響するかを追えます。資料に変更があった場合は、担当者が対象資産、運用記録、取引先への説明のどこを見直すかを決めます。更新がないことを推測で補わず、確認した事実を残します。

社内の担当分担

制度資料を確認する担当、対象資産を整理する担当、取引先へ回答する担当を分けます。確認の途中で判断が必要になった場合の相談先も決め、担当者の不在時に引き継げるようにします。誰が確認したかだけでなく、何を確認したかまで記録します。

社内会議で制度対応と発注準備を扱う場合も、結論を一つにまとめすぎません。制度に関する未確認事項、契約上の質問、診断対象の判断を別の議題にし、それぞれの確認先と期限を残します。これにより、見積の前提が曖昧なまま進むことを防げます。

見積へ渡す情報

見積へ渡す情報は、対象資産、認証後の機能、連携先、実施を避ける時間帯、連絡先、希望する成果物です。制度資料の名称だけを渡すのではなく、何をどこまで確認したいかを具体化します。対象外にする範囲と、その理由も仕様表に記載します。

脆弱性診断の費用構造を参考に、対象や成果物などの比較条件を同じ欄へそろえます。制度対応として確認した内容は別表に残し、見積書で差がある点を質問します。二つの整理を分けることで、取引先への説明と発注判断の両方に使えます。

まとめ

SCS評価制度とSECURITY ACTIONは、目的、確認方法、自社で残す記録を分けて扱います。制度に関する準備と脆弱性診断の発注条件を別表にし、公式資料の確認日と担当を残すことで、取引先対応と発注準備を進めやすくなります。

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