SCS評価制度とISMS・ISO27001の違い｜既存認証を活かした対応方法

SCS評価制度への対応を検討する企業の中には、「すでにISMS（ISO/IEC 27001）を取得しているため、追加対応は不要ではないか」と考える方も少なくありません。結論からいえば、ISMS認証はSCS評価制度への対応を大きく効率化できる重要な土台ですが、ISMSを取得しているだけでSCS評価制度の★3・★4を自動的に取得できるわけではありません。 両者はどちらも情報セキュリティを扱いますが、目的と評価の考え方が異なります。ISMSは、組織が情報セキュリティを継続的に管理するためのマネジメントシステムをISO/IEC 27001に基づいて第三者が認証する仕組みです。一方、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、取引先・委託先のセキュリティ対策状況を共通の基準で可視化し、サプライチェーン全体のリスク低減につなげることを目的としています。 そのため、ISMS取得済み企業にとっての実務上のポイントは「新しい制度だからゼロから作り直す」ことではなく、既存のISMS文書・運用・証跡を棚卸しし、SCS評価制度で追加的に求められる具体的な対策や技術検証との差分を埋めることです。本記事では、両制度の違いと共通点、既存認証を活かす具体的な進め方を解説します。 この記事で分かること SCS評価制度とISMS（ISO/IEC 27001）の目的・評価方法の違い ISMS取得済み企業でもSCS評価制度への対応が必要になる理由 ISMSの規程・リスクアセスメント・監査記録などをSCS対応へ転用する方法 ★3・★4で追加確認しやすい技術対策と証跡 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストをどう位置付けるか 費用と期間を抑えながらSCS評価制度へ対応するための進め方 SCS評価制度とISMS（ISO27001）は何が違うのか 最も大きな違いは、ISMSが「組織として情報セキュリティを継続的に管理する仕組み」を評価する制度であるのに対し、SCS評価制度は「サプライチェーン上の取引先として、共通に求められるセキュリティ対策を実装しているか」を段階別に可視化する制度である点です。 ISMS適合性評価制度では、JIS Q 27001（ISO/IEC 27001）を認証基準として、情報セキュリティ方針、リスクアセスメント、リスク対応、内部監査、マネジメントレビュー、継続的改善といったマネジメントシステム全体の適合性を第三者である認証機関が評価します。 これに対してSCS評価制度では、★3はセキュリティ専門家の確認を伴う自己評価、★4は評価機関による第三者評価と技術検証が予定されています。IPAは、★3・★4を取得するには、それぞれに定められたすべての要求事項・評価基準を満たす必要があるとしています。 比較項目ISMS（ISO/IEC 27001）SCS評価制度主な目的情報セキュリティマネジメントの継続的な確立・運用・改善取引・委託におけるセキュリティ対策水準の可視化とサプライチェーンリスク低減評価の考え方リスクベースで組織が必要な管理策を選定し運用★ごとに定められた要求事項・評価基準への適合を確認評価主体認証機関による第三者認証★3：専門家確認付き自己評価／★4：第三者評価＋技術検証主な活用場面顧客への信頼性説明、内部統制、継続的改善調達・委託先管理、取引条件、サプライチェーン管理技術面管理策の選定はリスクアセスメントに基づく★4では文書確認に加え実地審査・技術検証を実施ISMS取得済み企業への意味既存の管理体系をそのまま土台にできる差分確認と不足対策が必要。ISMS認証のみで自動取得にはならない 出典：IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html ／ ISMS-AC「情報セキュリティマネジメントシステム(ISMS)適合性評価制度の概要」https://isms.jp/isms/about.html なぜISMS取得済みでもSCS評価制度への対応が必要なのか 理由1：評価する目的が異なる ISMSは、組織の情報セキュリティマネジメントを継続的に改善するための国際規格です。企業ごとの事業特性やリスクに応じて管理策を選び、リスクを受容するか、低減するか、移転するかなどを判断します。したがって、認証取得企業同士であっても、実装している具体的な対策が完全に同じになるとは限りません。 一方、SCS評価制度は、取引先ごとに異なるチェックシートや要求を共通化し、委託元が委託先の対策状況を確認しやすくすることを狙っています。取引時に「この★水準を満たしているか」を確認できるようにするため、共通の最低ラインを具体的に示す性格が強い制度です。 理由2：★3・★4は定められた要求事項をすべて満たす必要がある IPAのFAQでは、★3・★4の取得には、それぞれで定められたすべての要求事項・評価基準を満たす必要があるとされています。ISMSのリスクベースアプローチで適切と判断した管理方法であっても、SCS側で明示された基準との間に差分があれば、その部分を追加で整備する必要があります。 出典：IPA「SCS評価制度 よくある質問」https://www.ipa.go.jp/security/scs/faq.html 理由3：★4では技術検証が組み込まれる ★4では、評価機関による文書確認と実地審査に加え、技術検証が求められます。ここがISMS運用だけでは埋まりにくい代表的な差分です。外部公開資産、ネットワーク、Webアプリケーション、クラウド設定などについて、実際の攻撃可能性を技術的に確認する場面が生じます。 そのため、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストなどを、単発のセキュリティ施策としてではなく、「SCS評価制度で要求される対策を技術面から裏付ける活動」として整理することが重要です。 既存のISMS認証はSCS対応にどう活かせるか ISMS取得済み企業の最大の利点は、SCS評価制度への対応に必要な「管理の骨格」がすでに存在していることです。特に従業員100～1,000名規模の企業では、規程を一から新設するよりも、既存のISMS文書と運用証跡をSCS要求事項へマッピングする方が、社内負荷と外部委託費の両方を抑えやすくなります。 情報セキュリティ方針・規程類を流用する ISMSで整備している情報セキュリティ方針、アクセス管理規程、情報資産管理規程、インシデント対応手順、委託先管理規程、バックアップ規程、教育規程などは、SCS評価制度の要求事項を満たすための基礎資料として活用できます。重要なのは文書名をSCS向けに変えることではなく、SCS要求事項が求める内容が実際に規定され、運用されているかを確認することです。 リスクアセスメント結果を対象範囲の決定に使う ISMSで保有している情報資産台帳、リスクアセスメント表、適用宣言書、ネットワーク構成図は、SCSの適用範囲を決める際に有効です。特に、重要な顧客情報を扱うシステム、外部公開サーバー、VPN、クラウドサービス、業務委託先との接続点などを洗い出す際には、既存のリスク分析結果を利用できます。 内部監査・教育・マネジメントレビューの証跡を活用する ISMS運用では、教育受講記録、内部監査報告、是正処置記録、マネジメントレビュー議事録などが継続的に残ります。SCS評価でも「規程がある」だけでなく、「実際に運用されている」ことを示す証跡が重要になるため、こうした記録は有力な説明資料になります。 供給者管理・委託先管理の仕組みを発展させる SCS評価制度はサプライチェーンリスクを直接の対象としています。ISMSで実施している委託先評価、秘密保持契約、再委託管理、クラウドサービス評価、契約終了時の情報返却・削除などの仕組みを、SCSの要求事項に照らして具体化すると効率的です。 ISMS取得済み企業が確認すべき主な追加ギャップ 実務では、ISMSとSCSの要求事項を1項目ずつ比較する「ギャップ分析」を行います。特に確認したいのは、次の領域です。 外部公開システムやネットワーク機器の脆弱性管理が、規程だけでなく定期的な確認・是正まで運用されているか 管理者アカウント、多要素認証、権限棚卸しなどのアクセス管理が実装され、証跡が残っているか EDR、ログ監視、異常検知など侵入後を想定した監視・検知策が機能しているか インシデント対応手順が机上の規程ではなく、連絡網、初動判断、証拠保全、復旧まで具体化されているか バックアップが本番環境と適切に分離され、復旧テストまで行われているか 委託先・再委託先のセキュリティ要求と確認方法が契約・運用に反映されているか 技術検証の対象となる可能性があるシステムについて、診断結果と是正状況を説明できるか この段階で重要なのは、すべてを同じ優先順位で改善しないことです。取引先から求められる★水準、重要システム、インターネット公開範囲、情報の機密性、事業停止時の影響を基準に、優先順位を付けて改善します。 Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストの位置付け 既存のISMS取得企業でも、技術的な安全性を客観的に説明できないケースは珍しくありません。例えば「脆弱性管理規程はあるが、公開Webサービスを最後に診断したのが数年前」「サーバーのパッチ適用ルールはあるが、外部から見える不要ポートを確認していない」といった状態です。 Webアプリケーション診断 Webアプリケーション診断では、認証・認可の不備、SQLインジェクション、クロスサイトスクリプティング、セッション管理、入力値検証など、アプリケーション固有の脆弱性を確認します。顧客向けポータル、EC、SaaS、自社業務システムを外部公開している企業では重要度が高い領域です。 プラットフォーム診断 プラットフォーム診断は、サーバー、ネットワーク機器、OS、ミドルウェア、公開ポート、既知の脆弱性などを確認します。VPN装置やファイアウォール、クラウド上の公開サーバーは、サプライチェーン経由の侵入経路になり得るため、継続的な点検が必要です。 ペネトレーションテスト ペネトレーションテストは、個別の脆弱性の有無だけでなく、複数の弱点を組み合わせた場合にどこまで侵入・権限拡大・情報到達が可能かを攻撃者視点で確認します。重要事業や機密情報を扱うシステムでは、診断結果を経営リスクとして評価するうえで有効です。 なお、どの技術検証をどの範囲で実施すべきかは、SCSの取得段階、評価対象範囲、システム構成によって異なります。不要な診断を広く実施するより、制度要求と事業リスクに沿って対象を決める方が費用対効果は高くなります。 既存認証を活かしたSCS評価制度対応の進め方 ステップ1：経営層が取得目的と目標★を決める まず、「取引先から求められる可能性がある」「大手企業との新規取引を想定している」「自社のセキュリティ水準を客観的に示したい」など、取得目的を整理します。★3と★4では評価方法や準備負荷が異なるため、経営層が事業上の必要性を踏まえて目標を決めることが重要です。 ステップ2：ISMS文書とSCS要求事項をマッピングする 情報セキュリティ方針、適用宣言書、各種規程、リスクアセスメント、委託先管理、教育、内部監査などを、SCSの要求事項・評価基準と対応付けます。「既に満たしている」「一部不足」「未対応」「証跡不足」に分類すると、追加作業を可視化できます。 ステップ3：不足している証跡と技術対策を確認する 規程は存在しても、実施記録が残っていないケースがあります。アカウント棚卸し記録、脆弱性対応履歴、バックアップ復旧テスト、教育受講記録、インシデント訓練結果など、実施を証明できる記録を整理します。同時に、Webアプリケーション診断やプラットフォーム診断など技術面の不足も確認します。 ステップ4：事業影響を基準に改善順位を決める 改善項目は、重大な脆弱性、インターネットから直接攻撃される資産、特権ID、顧客情報、基幹業務、復旧困難なシステムなどから優先します。単純な「項目数」ではなく、事故時の売上停止、取引停止、復旧費用、信用毀損への影響で順位を付けることが経営判断として重要です。 ステップ5：審査・評価を想定した証跡セットを作る 評価時に担当者が社内を探し回らないよう、要求事項ごとに規程、手順書、実施記録、システム画面、診断報告書、是正記録をひも付けます。ISMSの審査資料をベースにSCS用の証跡台帳を作ると、更新対応や取引先からの問い合わせにも再利用できます。 実施期間と費用を左右する要因 ISMS取得済み企業では、未取得企業に比べて規程整備や管理体制の構築を短縮できる可能性があります。しかし、期間と費用は、ISMS認証の有無だけでは決まりません。 特に影響が大きいのは、対象拠点数、外部公開システム数、クラウド環境の数、委託先の数、既存文書の整備状況、運用証跡の量、脆弱性診断・ペネトレーションテストの対象範囲、発見された問題の改修難易度です。 社内稟議では「SCSの申請費用」だけでなく、ギャップ分析、規程改定、システム設定変更、診断、改善、再確認、社内工数を分けて説明すると予算の妥当性を示しやすくなります。また、取引要件への対応、新規取引機会、顧客監査対応工数の削減、事故発生時の損失抑制といった事業効果も合わせて整理すると、単なるコンプライアンス費用として扱われにくくなります。 SCS対応支援会社を選ぶ際のポイント ISMS取得済み企業が外部支援を利用する場合、単に規程テンプレートを提供する事業者ではなく、既存ISMSとの重複を見極め、必要最小限の追加対策に整理できる会社を選ぶことが重要です。 ISMS／ISO 27001とSCS評価制度の双方を理解しているか 規程・リスク管理だけでなく、ネットワークやWebアプリケーションの技術対策まで支援できるか 脆弱性診断やペネトレーションテストを制度対応と一体で設計できるか 要求事項ごとの証跡整理、是正計画、経営報告まで支援できるか 評価対象範囲を過度に広げず、事業リスクに応じて設計できるか 個人情報や機密情報を扱う資料の管理方法、再委託方針が明確か RFPや見積依頼では、「SCS取得支援一式」だけでなく、ギャップ分析、文書改定、証跡整備、技術診断、改善支援、評価前レビューを分けて見積もってもらうと、比較しやすくなります。 よくある失敗と注意点 「ISMSがあるから大丈夫」と判断して差分確認をしない 既存認証は大きな強みですが、SCSは目的と評価基準が異なります。まず要求事項をマッピングし、差分を客観的に確認する必要があります。 規程だけ追加して運用証跡が残っていない 審査・評価では、ルールの存在だけでなく実際に運用しているかが重要です。新しい規程を増やしすぎると現場運用が追い付かないため、既存ISMSの仕組みに統合する方が継続しやすくなります。 診断結果を取得しただけで改善が止まる 脆弱性診断は「発見」が目的ではありません。重大度、悪用可能性、対象システムの重要度を踏まえて改修順位を決め、修正後の再確認まで実施する必要があります。 情報システム部門だけで進める SCS評価制度は取引や委託管理と密接に関係するため、経営層、情報システム部門だけでなく、営業、調達、法務、総務、事業部門の関与が必要です。特に取引先から要求される★水準や契約更新時期は営業・調達部門が把握しているケースがあります。 Librus株式会社が提供できる支援 Librus株式会社では、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応を、制度要件の確認だけで終わらせず、技術対策と運用改善まで一気通貫で支援します。 ISMS取得済み企業に対しては、既存の情報セキュリティ方針、規程、リスクアセスメント、内部監査資料、委託先管理、教育記録などを確認し、SCS要求事項との対応関係を整理します。そのうえで、不足している証跡、技術対策、運用プロセスのみを優先して改善することで、重複投資を抑えた対応を目指します。 また、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT支援、インシデントレスポンス、デジタルフォレンジック、SBOM、リスクアセスメントなどを組み合わせ、制度対応で見つかった課題を実装・改善までつなげることが可能です。経営層には事業・財務・取引上のリスクとして整理し、情報システム部門には具体的な技術課題と優先順位として提示するなど、経営と現場の双方が判断しやすい形で支援します。 よくある質問 ISMSを取得していればSCS評価制度の★3・★4は自動的に取得できますか？ いいえ。ISMS認証とSCS評価制度は別制度です。IPAは、★3・★4の取得には各段階で定められたすべての要求事項・評価基準を満たす必要があるとしています。ISMSの規程や運用は有効に活用できますが、差分確認が必要です。 ISMSを取得済みならSCS対応の負担は小さくなりますか？ 既存の方針、規程、リスクアセスメント、内部監査、教育、委託先管理、証跡を活用できるため、ゼロから体制を作る企業より効率化できる可能性があります。ただし、技術対策や証跡が不足していれば追加対応が必要です。 ISO27001の適用範囲とSCSの対象範囲は同じにすべきですか？ 必ずしも同一とは限りません。取引先から求められる範囲や重要システム、サプライチェーン上の役割を踏まえてSCSの対象範囲を整理する必要があります。 SCS対応では脆弱性診断が必須ですか？ 必要となる技術検証の具体的な範囲は取得段階や対象環境によって異なります。特に★4では技術検証が組み込まれるため、外部公開資産や重要システムについて診断が必要になる可能性があります。 ISMSの内部監査報告書はSCSの証跡に使えますか？ 要求事項との対応関係を説明でき、対象期間や実施内容が適切であれば有力な証跡になります。内部監査だけで不足する項目については、追加の実施記録や技術資料を用意します。 SCS対応のためにISMS規程を全面改定する必要がありますか？ 通常は全面改定から始める必要はありません。まず既存文書を要求事項へマッピングし、足りない内容だけを改定・追加する方が運用負荷を抑えやすくなります。 ★3と★4のどちらを目指すべきですか？ 取引先から求められる水準、事業の重要性、扱う情報、供給停止時の影響などで判断します。★4は第三者評価と技術検証を伴うため、準備負荷も大きくなります。 いつから準備を始めるべきですか？ ★3・★4は2027年3月頃の運用開始が予定されています。規程改定だけでなく運用実績や是正期間が必要になるため、取引先から要求されてから着手するのではなく、早めにギャップ分析を行うことが有効です。 まとめ｜ISMSを「土台」にしてSCS評価制度の差分を埋める SCS評価制度とISMS（ISO/IEC 27001）は、同じ情報セキュリティ領域の制度でも目的と評価方法が異なります。ISMSは組織のリスクに応じて情報セキュリティマネジメントを継続的に運用するための国際規格であり、SCS評価制度はサプライチェーン上で共通に求めるセキュリティ対策水準を可視化する制度です。 したがって、ISMS取得済み企業もSCS対応が不要になるわけではありません。しかし、既存の規程、リスクアセスメント、内部監査、教育、委託先管理、改善活動はSCS対応の大きな資産になります。最初に行うべきことは、新しい文書を大量に作ることではなく、既存ISMSとSCS要求事項のギャップを整理することです。 そのうえで、証跡不足、アクセス制御、脆弱性管理、監視・検知、インシデント対応、バックアップ、委託先管理、技術検証などを優先順位に沿って改善すれば、制度対応と実際のセキュリティ強化を同時に進められます。 SCS評価制度は2027年3月頃の★3・★4運用開始が予定されています。今の段階でISMS資産を棚卸しし、差分と必要予算を把握しておけば、取引先から要求された際にも対応計画を立てやすくなります。 既存ISMSを活かしたSCS評価制度対応をご相談いただけます Librus株式会社では、「ISMSは取得しているが、SCS評価制度で何が追加になるのか分からない」「★3・★4のどちらを目指すべきか決まっていない」「規程はあるが、技術面や証跡に不安がある」といった段階からご相談いただけます。 既存のISMS文書・運用を確認し、SCS要求事項との重複部分と不足部分を整理することで、不要な規程作成や重複投資を避けながら、実務に即した対応計画を立てることができます。必要に応じて、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、運用体制整備、改善支援まで一気通貫で対応します。対象範囲や実施方法がまだ固まっていない場合でも、取引状況・システム構成・既存認証を踏まえ、優先順位と進め方の整理から支援可能です。 参考情報 IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」https://www.ipa.go.jp/security/scs/index.html IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html IPA「要求事項・評価基準」https://www.ipa.go.jp/security/scs/requirements-criteria.html IPA「よくある質問」https://www.ipa.go.jp/security/scs/faq.html 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」https://www.meti.go.jp/press/2025/03/20260327001/20260327001.html ISMS-AC「情報セキュリティマネジメントシステム（ISMS）適合性評価制度の概要」https://isms.jp/isms/about.html 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 105-0004東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム https://librus.co.jp/contact

VIEW MORE

SCS評価制度の★3と★4の違いとは？要求事項・評価方法・選び方を徹底比較

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）では、★3と★4で求められるセキュリティ水準だけでなく、評価方法や準備負担も大きく異なります。結論から言えば、★3は一般的なサイバー攻撃に対処するための基礎的な組織対策・システム防御を整え、セキュリティ専門家の確認を受けて自己評価する水準です。一方の★4は、供給停止や機密情報漏えいがサプライチェーン全体へ大きな影響を及ぼす企業・資産を想定し、ガバナンス、取引先管理、検知、インシデント対応まで含む包括的な対策を、第三者評価・実地審査・技術検証によって確認する水準です。 したがって、「★3と★4のどちらが上か」だけで選ぶのではなく、自社がサプライチェーンで担う役割、停止時の影響、扱う情報の重要性、取引先から求められる水準を基準に選ぶことが重要です。なお、★3を先に取得しなければ★4を取得できないという制度設計ではありません。 SCS評価制度は2026年3月に経済産業省と内閣官房国家サイバー統括室が公表した制度構築方針に基づき、IPAが運営する制度です。★3・★4は2027年3月頃の運用開始が予定されています。出典：IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html この記事で分かること SCS評価制度における★3と★4の目的・対象・要求水準の違い ★3の「専門家確認付き自己評価」と★4の「第三者評価」の違い ★4で実施される実地審査・技術検証と脆弱性診断の関係 従業員100～1,000名規模の企業が★3・★4を選ぶ際の判断基準 取得準備で必要になる資料、期間、費用、社内稟議、ベンダー選定のポイント SCS評価制度とは SCS評価制度は、企業が自社のセキュリティ対策の実施状況を共通の基準で評価し、その結果を登録・公表することで、サプライチェーン上の取引先同士が必要な対策水準を確認しやすくする仕組みです。委託元にとっては取引先の対策状況を判断しやすくなり、委託先にとっては取引先ごとに異なるチェックシートへ何度も回答する負担を軽減することが期待されています。 制度上、★3や★4の取得そのものは一律の法的義務ではありません。ただし、IPAは2社間の取引契約等で委託元が委託先に適切な段階を提示し、対策を求める利用方法を想定しています。つまり制度が任意でも、実務上は取引条件、調達条件、監査要件として特定の★取得を求められる可能性があります。出典：IPA「サプライチェーン強化に向けたセキュリティ対策評価制度」 https://www.ipa.go.jp/security/scs/index.html SCS評価制度の★3と★4の違いを一覧で比較 比較項目★3★4想定する脅威広く認知された脆弱性等を悪用する一般的なサイバー攻撃供給停止などによりサプライチェーンへ大きな影響を与える攻撃、重要な機密情報等を狙う攻撃対策の考え方全てのサプライチェーン企業が最低限実装すべき基礎的な組織対策・システム防御ガバナンス、取引先管理、システム防御・検知、インシデント対応等を含む包括的な対策評価方式セキュリティ専門家の確認を受けた自己評価指定された評価機関による第三者評価文書確認ありあり実地審査原則なしあり。規程、運用、操作画面、証跡等を確認技術検証制度上の評価プロセスとしては実施なしあり。対象機器に対する脆弱性検査等を実施主な想定企業一般的なサプライチェーン企業。まず共通の基礎水準を整えたい企業停止や情報漏えいが取引先・社会へ大きく波及する企業、重要資産を扱う企業上位関係★3取得後でなければ★4に進めないわけではない★3を事前取得せず直接★4を目指すことも可能 経済産業省は★3を「全てのサプライチェーン企業が最低限実装すべきセキュリティ対策」、★4を「サプライチェーン企業等が標準的に目指すべきセキュリティ対策」と整理しています。単純にチェック項目が増えるというより、★4では「組織として機能しているか」「攻撃を検知し、侵入後の被害拡大を抑えられるか」「取引先を含めたサプライチェーンの強靭化に取り組んでいるか」まで確認範囲が広がる点が重要です。出典：経済産業省「SCS評価制度の実現」 https://www.meti.go.jp/press/2026/04/20260403003/20260403003-b.pdf ★3とは？一般的なサイバー攻撃に備える基礎水準 ★3は、広く知られた脆弱性や一般的な攻撃手法を悪用したサイバー攻撃に対処し得る水準を想定しています。経営者の承認を伴う体制整備、IT資産やアカウントの管理、脆弱性への対応、バックアップ、インシデント時の連絡・対応など、企業として最低限欠かせない対策を「実施していると言える状態」にすることが重要です。 ★3の評価方法は「専門家確認付き自己評価」 ★3では、取得希望企業が要求事項・評価基準に基づいて自己評価を行い、その内容をSCS評価制度に登録されたセキュリティ専門家が確認します。専門家は記載内容や評価基準との整合性を確認し、必要に応じて修正・助言を行います。最終的には、経営層による自己適合宣誓を含めて事務局へ提出する流れです。 「自己評価だから簡単」という意味ではありません。IPAのFAQでは、★3・★4とも定められたすべての要求事項・評価基準を満たす必要があるとされています。不適合がある場合は、是正して専門家の了承を得るプロセスが必要です。出典：IPA「よくある質問」 https://www.ipa.go.jp/security/scs/faq.html ★3で企業が準備しておきたい証跡 自己評価では「規程に書いてある」だけでなく、実際に運用されていることを説明できる資料をそろえることが重要です。例えば、情報セキュリティ方針、組織図・責任分担表、IT資産台帳、アカウント一覧、脆弱性・パッチ管理記録、バックアップ結果、教育実施記録、インシデント対応手順、取引先管理ルールなどが候補になります。 従業員100～1,000名規模では、情シスだけで資料を集めきれないケースが少なくありません。人事、総務、法務、購買、事業部、開発部門などが保有する証跡を横断的に整理し、「誰が、何を、どの頻度で実施しているか」まで明確にすると評価準備が進みやすくなります。 ★4とは？停止・漏えいの影響が大きい企業向けの包括的水準 ★4は、初期侵入を防ぐだけでなく、侵入された後の被害拡大防止、検知、インシデント対応、復旧、取引先管理まで含めて、より包括的にサイバーリスクを管理する水準です。供給停止が大きな影響を及ぼす事業、重要な顧客データや機密情報を扱う事業、サプライチェーンの中核を担う企業では、★4が現実的な目標となる可能性があります。 ★4は第三者評価・実地審査・技術検証が必要 ★4では、取得希望企業の自己評価だけでは完結しません。指定された評価機関が文書確認に加えて実地審査を行い、さらに技術検証事業者による技術検証が実施されます。IPAの制度構築方針では、実地審査で脆弱性管理体制、インシデント対応手順、事業継続要件に沿った復旧準備などを確認する例が示されています。 技術検証では、インターネットに公開している機器のうち、脆弱性を悪用された場合に組織内部へ侵入されるリスクが高い機器を対象に、既知脆弱性の悪用等を想定した検査を行う方針が示されています。制度文書ではVPN装置やルータが例示されています。出典：経済産業省・IPA「制度構築方針」 https://www.ipa.go.jp/security/scs/rcu1hd0000007ajp-att/20260327001-br.pdf Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストとの関係 SCS評価制度への対応と、脆弱性診断やペネトレーションテストは同じものではありません。特に★3では、制度上の評価プロセスとして技術検証は求められていません。一方で、実際に脆弱性管理やシステム防御が十分かを確認し、不適合の原因となる問題を早期に把握するために、Webアプリケーション診断やプラットフォーム診断を事前に実施することは有効です。 ★4では技術検証が評価プロセスに組み込まれます。ただし、通常の脆弱性診断やペネトレーションテストを受けているだけで★4を取得できるわけではありません。文書・運用・ガバナンス・インシデント対応など、制度全体の要求事項への適合が必要です。ペネトレーションテストは、複数の弱点を組み合わせた侵入可能性や攻撃経路を確認するために有効ですが、SCS評価制度の技術検証との目的・範囲をRFP段階で区別する必要があります。 ★3と★4、どちらを目指すべきか 判断の基本は「自社の規模」ではなく、「自社が止まった場合、または侵害された場合にサプライチェーンへどの程度影響するか」です。従業員数が同じ500名でも、一般的なバックオフィス業務を担う企業と、複数の大手企業の基幹システムを運用する企業では、求められる水準が異なります。 ★3を優先しやすい企業 まず共通の基礎対策を整備し、一般的なサイバー攻撃への耐性を説明できる状態を作りたい企業は★3が候補です。取引先から具体的な★4指定がなく、自社の停止や情報漏えいが直ちに広範な供給停止へつながる立場ではない場合、★3を基準にギャップ分析を始めることは合理的です。 ★4を検討すべき企業 一方、重要インフラに近い事業、製造・物流・金融・ITサービス等で多くの取引先の業務継続を支える企業、大量の機密情報・個人情報を扱う企業、取引先から高いセキュリティ保証を求められる企業は★4を検討する価値が高まります。M&A、IPO、大規模な新規取引など、セキュリティ管理水準を外部に説明する必要性が高い局面でも、★4を見据えた体制整備が有効です。 経営層が判断すべき4つのポイント 自社サービスが停止した場合、顧客や取引先の事業がどの程度止まるか 漏えいした場合に影響が大きい機密情報・個人情報・設計情報等を保有しているか 主要顧客・業界の調達基準としてどの★が求められそうか ★取得だけでなく、取得後の運用・継続改善に必要な予算と人員を確保できるか ★3・★4取得に向けた実務的な進め方 1. 適用範囲を決める 最初に、自社のどの組織・拠点・IT基盤・サービスを評価対象にするかを決めます。適用範囲が曖昧なままでは、資産台帳や規程、診断対象、証跡が膨らみ、見積もりも不安定になります。取引先との契約や重要サービスとの関係から、守るべき範囲を明確にすることが出発点です。 2. 要求事項とのギャップ分析を行う 現行の規程・運用・技術対策を要求事項と照合し、「適合」「一部適合」「未対応」「証跡不足」に分類します。ここでは、単に対策製品の有無を見るのではなく、責任者、手順、実施頻度、例外時の承認、記録保存まで確認します。 3. 優先順位を付けて是正する 不備をすべて同時に直すのではなく、外部公開システムの既知脆弱性、特権ID、MFA、バックアップ、インシデント連絡体制など、侵害時の影響が大きい項目から優先します。技術的な弱点が疑われる場合は、Webアプリケーション診断やプラットフォーム診断を組み合わせ、設定・実装上の問題を把握します。 4. 証跡を整え、評価に備える 評価では「実施している」という説明だけでは不十分になり得ます。ログ、チケット、教育記録、バックアップ確認結果、脆弱性対応記録、取引先評価記録など、運用の実態を裏付ける証跡を継続的に残します。★4では実地審査も想定されるため、担当者へのヒアリングに耐えられる状態まで運用を定着させることが重要です。 実施期間と費用を左右する要因 制度構築方針では、評価そのものの所要期間として文書確認や実地審査、技術検証についてそれぞれ1～2日程度の想定が示されていますが、これは事前準備や是正、報告書作成を除いた目安です。実際の取得準備は、ギャップの大きさや適用範囲によって大きく変わります。特に、規程未整備、資産管理未整備、MFA未導入、バックアップ復旧テスト未実施、インシデント対応体制未整備などが重なると、評価前の改善に時間がかかります。 費用は、制度運営機関への登録料だけでなく、専門家確認、第三者評価、技術検証、コンサルティング、必要なセキュリティ製品・運用改善などを含めて考える必要があります。IPAが2026年9月18日に公表した料金では、登録希望組織の登録料は、2028年3月31日まで★3が年1万円、★4が3年6万円、2028年4月1日以降は★3が年2万円、★4が3年6万円とされています。評価機関や専門家への費用は別途発生し得ます。出典：IPA「SCS評価制度 料金設定のお知らせ」 https://www.ipa.go.jp/security/scs/rcu1hd00000075om-att/pricelist.pdf 社内稟議では「認証取得費」だけで説明しない 社内稟議では「SCSのマークを取るための費用」とだけ説明すると、単なる認証コストと見られやすくなります。経営層には、①主要取引先との取引継続、②サプライチェーン上の信用維持、③インシデントによる事業停止・復旧費用の低減、④取引先ごとの個別監査対応の効率化、⑤M&A・IPO・大手企業との新規取引における説明力向上、といった経営上の目的を併せて示すべきです。 また、一度の評価取得で終わる施策ではありません。人事異動、新システム導入、クラウド移行、M&A、委託先変更などでリスクは変化します。取得後の運用費、継続監視、教育、再診断まで含めた複数年度の予算として計画すると、対策が形骸化しにくくなります。 サービス提供会社を選ぶ際のチェックポイント SCS評価制度への対応支援会社を選ぶ際は、「チェックシートを埋められるか」だけでなく、制度、技術、運用、経営の4つを横断して支援できるかを確認することが重要です。 ★3・★4の要求事項と評価プロセスを区別して説明できるか 適用範囲の設計からギャップ分析、規程整備、証跡作成まで支援できるか Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト等の技術検証にも対応できるか 不適合を単に指摘するだけでなく、費用・優先度を踏まえた改善計画を提示できるか 個人情報・機密情報の取扱い、データ保管、再委託の有無を明確にできるか 経営層向け報告と現場向けの具体的な改善指示の両方を提供できるか ★4では評価機関の中立性・公平性も重要になるため、取得支援を行う事業者と実際の第三者評価を担う評価機関の役割を整理してRFP・見積依頼を行う必要があります。 よくある失敗と注意点 ★3を「簡易版の★4」とだけ考える ★3は単なる項目数の少ない評価ではありません。一般的な脅威に対する共通の基礎水準として位置づけられています。まず★3で基礎を固める企業もあれば、取引先要件や事業影響を踏まえて最初から★4を目指す企業もあります。 ツール導入だけで適合すると考える EDR、MFA、SIEM、バックアップ製品などは重要ですが、制度では組織体制や運用手順、証跡も確認されます。製品を購入しただけでは、誰がアラートを確認し、異常時に誰へ連絡し、どの基準で復旧判断するかという運用上の課題は解決しません。 評価直前に証跡を集め始める 証跡は後から作るほど、実態との整合性を説明しづらくなります。脆弱性対応、アクセス権レビュー、バックアップ確認、教育、インシデント訓練などは日常運用として記録を残しておくことが重要です。 Librus株式会社が提供できるSCS評価制度対応支援 Librus株式会社では、SCS評価制度への対応を「評価取得のための書類作成」に限定せず、実際のセキュリティ水準を高めるプロジェクトとして支援します。要求事項とのギャップ分析、適用範囲の整理、規程・運用ルールの整備、証跡設計、経営層向けの説明、改善ロードマップ策定まで一気通貫で対応可能です。 技術面では、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジックなどを組み合わせ、制度対応と実際のサイバーリスク低減を同時に進められます。 また、企業ごとの事業特性、予算、既存のISMSや社内規程、取引先からの要求を踏まえて、★3を優先するのか、★4を見据えて整備するのかを個別に設計します。M&A、IPO、取引先監査など、経営上の重要局面に合わせてセキュリティ課題を整理できる点もLibrus株式会社の特徴です。 よくある質問 Q1. ★3を取得してからでないと★4は取得できませんか？ いいえ。IPAは、上位段階が下位段階の要求を包括するものの、★3を事前に取得していなければ★4を取得できない関係ではないと説明しています。事業上の必要性があれば、直接★4を目指すことも可能です。 Q2. ★3と★4はどちらも全項目を満たす必要がありますか？ はい。IPAのFAQでは、★3・★4とも、それぞれに定められたすべての要求事項・評価基準を満たす必要があるとされています。 Q3. ★3でも脆弱性診断は必須ですか？ 制度上の評価プロセスとして、★3には★4のような技術検証は設定されていません。ただし、脆弱性管理やシステム防御の実効性を確認し、取得前に問題を是正する目的で診断を実施することは有効です。 Q4. ★4ではペネトレーションテストが必須ですか？ 制度上は技術検証が必要ですが、一般的なペネトレーションテストと完全に同義ではありません。評価範囲や検証方法は制度文書・評価機関の指示に従う必要があります。 Q5. SCS評価制度は中小企業だけが対象ですか？ いいえ。IPAは全てのサプライチェーン企業を対象としています。特に中小企業で活用効果が大きいとされていますが、業種や企業規模を問わず対象となり得ます。 Q6. 取得すれば取引先のセキュリティチェックシートは不要になりますか？ 必ず不要になるとは限りません。SCS評価制度は共通化・可視化によって負担軽減を目指す制度ですが、取引先が独自に追加確認を行う可能性はあります。 Q7. ★3・★4の取得準備はいつ始めるべきですか？ 取引先から正式に要請されてからではなく、早めにギャップ分析を始めることが望まれます。規程整備やMFA導入、脆弱性対応、バックアップ・復旧訓練などは、短期間で形式的に整えるより、一定期間運用して証跡を蓄積した方が評価に備えやすいためです。 Q8. どちらを選ぶべきか判断できない場合はどうすればよいですか？ 自社のサプライチェーン上の役割、停止時の影響、保有情報、主要取引先の要求、現状の対策成熟度を整理し、★3・★4それぞれのギャップと費用を比較すると判断しやすくなります。 まとめ｜★3と★4の違いは「対策範囲」と「評価の客観性」 SCS評価制度の★3と★4の最大の違いは、求められる対策の広さと評価方法です。★3は一般的なサイバー攻撃に対処するための基礎的な対策を、専門家確認付き自己評価で確認します。★4は、供給停止や重要情報の漏えいによる影響が大きい企業を想定し、ガバナンス、取引先管理、検知、インシデント対応まで含む包括的な対策を第三者評価・実地審査・技術検証によって確認します。 重要なのは、「★4の方が上だから★4を取る」「まず★3を取らなければならない」と機械的に決めないことです。自社の事業影響と取引先要件を基準に必要な水準を選び、現状とのギャップを把握した上で、規程・運用・技術対策を計画的に改善することがSCS評価制度への実務的な対応となります。 SCS評価制度の★3・★4選定から取得準備までご相談いただけます 「取引先からどの★を求められる可能性があるのか分からない」「★3と★4のどちらを目標にすべきか判断できない」「現状の規程やシステムで何が不足しているのか把握したい」といった段階でもご相談いただけます。 Librus株式会社では、事業・取引関係・IT環境を整理した上で、SCS評価制度の要求事項とのギャップ、優先して改善すべき項目、必要な技術検証、取得までのロードマップを具体化します。対象範囲や実施方法が決まっていない段階から整理することで、不要な対策や重複投資を避けながら、取引継続と実際のセキュリティ向上の双方を見据えた計画を立てやすくなります。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015お問い合わせフォームhttps://librus.co.jp/contact

VIEW MORE

取引先のセキュリティチェックが厳しくなる？SCS評価制度で調達・委託はどう変わるか

結論から言えば、SCS評価制度の開始によって、すべての企業の取引先チェックが一律に「厳格化」されるわけではありません。一方で、発注企業が委託先に求めるセキュリティ水準を★3・★4という共通基準で示し、契約や取引先評価に組み込む運用は今後広がる可能性があります。受注側の企業にとっては、従来のセキュリティチェックシートへの回答だけでなく、必要な★の取得や、要求事項を満たしていることを証跡付きで説明できる状態が、取引継続・新規受注の判断材料になることが考えられます。 サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、委託元と委託先の双方が共通の基準で対策状況を確認できるようにする制度です。2027年3月頃の★3・★4の運用開始が予定されており、経済産業省は、2社間の取引契約等において委託元が委託先に適切な段階（★）を提示し、対策の実施と実施状況の確認を行う活用を想定しています。 出典：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.meti.go.jp/policy/netsecurity/scs.html この記事で分かること SCS評価制度によって調達・委託時のセキュリティ確認がどう変わり得るか 発注側が取引先に★3・★4を求める際の考え方と注意点 受注側が取引停止や失注リスクを避けるために準備すべきこと 既存のセキュリティチェックシート、ISMS、脆弱性診断との関係 社内稟議、見積依頼、RFP、契約更新で確認すべき実務ポイント Librus株式会社がSCS評価制度対応で支援できる範囲 SCS評価制度とは？取引先の対策状況を共通基準で可視化する制度 SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策状況を共通の基準で評価・可視化する仕組みです。制度の背景には、発注側から見て取引先の対策状況を外部から判断しにくいこと、反対に委託先側では複数の顧客から異なるセキュリティ要求を受け、個別回答の負担が大きいことがあります。 制度は任意であり、法律によって一律に★取得を義務付けるものではありません。ただし、どの★を取引条件として扱うかは契約当事者間で決められるため、実務上は「取引先が求める基準」として影響を持つ可能性があります。 IPAは、全てのサプライチェーン企業が対象となり得ると説明しており、業種や企業規模によって一律に除外される制度ではありません。中堅・中小企業であっても、大企業の委託先、ITサービス提供企業、個人情報や機密情報を取り扱う事業者などは、早い段階から自社の対応水準を確認しておくことが重要です。 出典：IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.ipa.go.jp/security/scs/index.html SCS評価制度で調達・委託はどう変わる？ 大きな変化は、発注側が「セキュリティ対策をしているか」を抽象的に確認するのではなく、取引の重要度や扱う情報に応じて、必要な対策レベルを★で示しやすくなることです。これは、従来のチェックシートを完全に置き換えるとは限りませんが、取引先評価の共通言語になり得ます。 1. 取引先選定の条件に★が加わる可能性がある 新規取引や委託先選定では、価格・品質・納期・実績に加えて、セキュリティ対策状況が評価項目に入るケースが増えています。SCS評価制度が普及すれば、RFPや見積依頼書に「SCS評価制度★3取得済み、または同等水準の対策を実施していること」などの条件が記載されることも想定されます。 ただし、制度開始時点で★取得企業が当然に存在するわけではありません。経済産業省のFAQでも、制度開始は申請受付の開始を意味するとされており、開始直後から一律に未取得企業を排除する運用が制度上定められているわけではありません。発注側には、移行期間や代替確認の方法を含めた現実的な設計が求められます。 2. 契約更新時にセキュリティ条件が見直される可能性がある 既存取引でも、基本契約や個別契約の更新時に、情報セキュリティ条項、事故報告義務、再委託管理、監査協力義務などとあわせて、SCS評価制度の取得状況を確認する運用が考えられます。特に長期契約では、必要な★を契約期間中維持することを求める運用も想定されています。 受注側は、契約更新直前に初めて対応を始めるのではなく、主要顧客がどのレベルを要求しそうか、現在の自社対策で不足する項目は何かを事前に整理しておく方が、価格交渉や改善計画の説明を行いやすくなります。 3. 「独自チェックシートへの回答」から「共通基準＋追加確認」へ SCS評価制度の狙いの一つは、複数の取引先から異なるチェックシートへの回答を求められる委託先の負担を軽減することです。そのため、制度が定着すれば、SCS評価制度の取得状況や要求事項への適合状況をベースにし、取引固有の事項だけを追加確認する形に整理される可能性があります。 一方で、金融、医療、重要インフラ、個人情報を大量に扱う業務、委託元固有のシステムへ接続する業務などでは、SCS評価制度だけで十分とは限りません。発注側は、自社特有のリスクについては追加の契約条件や質問項目を残す必要があります。 4. 技術的な確認の重要性が高まる ★4では、評価機関による文書確認だけでなく、実地審査と技術検証が求められます。IPAは、技術検証事業者について「脆弱性診断・ペネトレーションテストのサービスを提供する法人」を主な対象としており、★4の技術検証として脆弱性診断を実施する役割を示しています。 そのため、規程やチェックシート上は適切に見えても、インターネット公開資産に重大な脆弱性が残っている、不要なポートが開放されている、Webアプリケーションに認証・認可上の欠陥がある、といった技術的な問題は無視できません。Webアプリケーション診断、プラットフォーム診断、必要に応じたペネトレーションテストを、制度対応とは別物として切り離さず、実装状況を検証する手段として活用することが重要です。 出典：IPA「指定申請について（評価機関・技術検証事業者・研修事業者向け）」 https://www.ipa.go.jp/security/scs/security-experts-organization/shiteishinsei.html 発注側企業は、取引先に何を求めるべきか 発注側にとって重要なのは、すべての取引先へ同じ水準を機械的に要求することではありません。委託内容、扱う情報、システム接続の有無、代替可能性、停止時の事業影響などを踏まえ、必要な対策水準を合理的に決めることです。 取引の重要度を分類する 最初に、委託先を「止まった場合の事業影響」「自社ネットワークへの接続」「機密情報・個人情報の取扱い」「再委託の有無」「顧客向けサービスへの影響」などで分類します。基幹業務や顧客サービスの提供に直結する委託先と、限定的な情報しか扱わない委託先とでは、求める水準を分ける方が合理的です。 ★の取得だけでなく、未取得時の代替確認も決める 制度開始直後は、取引先が申請中である、改善対応中である、制度上の評価をまだ受けられていないといった状況が想定されます。そのため、調達基準には「取得済みか否か」だけでなく、未取得の場合にどの資料や証跡で確認するか、いつまでに改善を求めるかを設けておくと運用しやすくなります。 契約条件と費用負担をセットで検討する 発注側が新たなセキュリティ対策や認証・評価の取得を求める場合、委託先にはシステム改修、診断、教育、運用体制整備などの追加コストが生じることがあります。経済産業省と公正取引委員会は、発注者が取引先にセキュリティ対策を要請すること自体は直ちに独占禁止法上問題になるものではない一方、コスト上昇分を考慮せず一方的に著しく低い対価を定めることなどは問題となり得ると示しています。 そのため、調達部門と情報システム・セキュリティ部門だけで決めるのではなく、法務・購買・事業部門を含めて、要請内容、必要性、導入期限、費用負担、価格改定の考え方まで整理することが重要です。 出典：経済産業省「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」 https://www.meti.go.jp/policy/netsecurity/partnership2.html 受注側企業は何を準備すべきか 受注側にとってSCS評価制度対応は、単なる「認証取得プロジェクト」ではありません。重要なのは、顧客に対して、自社がどの範囲でどの対策を実施し、その運用をどの証跡で説明できるかを整理することです。 1. 主要顧客と取引条件を棚卸しする 売上構成上重要な顧客、契約更新が近い顧客、情報セキュリティチェックが厳しい顧客を洗い出します。そのうえで、現在の契約にセキュリティ基準、監査、認証、インシデント報告、再委託等の条項があるかを確認します。これにより、SCS評価制度への対応優先度を経営判断しやすくなります。 2. 自社の適用範囲とIT資産を明確にする クラウドサービス、社内ネットワーク、端末、認証基盤、インターネット公開サーバー、SaaS、委託先、テレワーク環境などを整理し、どの範囲を評価対象にするかを検討します。資産台帳が不完全な状態では、脆弱性管理やアクセス管理の説明も不十分になりやすいため、まず「何を守るのか」を明確にする必要があります。 3. 規程・運用・証跡のギャップを確認する 情報セキュリティ基本方針、アカウント管理、端末管理、脆弱性管理、バックアップ、ログ管理、インシデント対応、委託先管理、教育などについて、規程が存在するだけでなく、実際に運用されているかを確認します。例えば「退職者アカウントを速やかに削除する」と規程に書かれていても、棚卸記録や削除履歴がなければ、実施状況を説明しにくくなります。 4. 技術面の弱点を先に洗い出す 外部公開システムがある企業は、制度審査の直前ではなく、早期にWebアプリケーション診断やプラットフォーム診断を行い、重大な脆弱性を把握しておくことが有効です。攻撃経路や権限昇格を含めた実効性の確認が必要な場合は、ペネトレーションテストも選択肢になります。 発見事項はCVSS等の技術的な深刻度だけでなく、「顧客情報への到達可能性」「業務停止の可能性」「外部から悪用可能か」「修正の容易さ」などを踏まえ、事業影響と合わせて優先順位を決めます。 対応しない場合に起こり得る問題 SCS評価制度は任意制度であるため、未取得だけで直ちに法令違反になるわけではありません。しかし、取引先が★取得や一定の要求事項への適合を契約・選定条件にした場合には、営業上の影響が生じる可能性があります。 具体的には、新規RFPで候補から外れる、契約更新時に改善計画の提出を求められる、セキュリティチェックへの回答負担が増える、競合企業が★取得済みである場合に比較上不利になる、といった状況が考えられます。また、実際に事故が起きた際には、委託元への報告・復旧対応・原因調査に加えて、信用低下や事業停止が経営課題となります。 ただし、「★がない会社とは取引できない」と一律に考えるのは適切ではありません。制度上も契約当事者間での合意が前提です。発注側・受注側の双方が、必要な水準、移行期間、改善コストを共有しながら運用することが重要です。 SCS評価制度を調達・委託プロセスに組み込む実務手順 経営層が、重要取引先に求めるセキュリティ水準と許容リスクを決める 調達・購買部門が、委託先を重要度別に分類し、確認項目を標準化する 情報システム・セキュリティ部門が、SCS評価制度の要求事項と既存チェック項目をマッピングする 法務部門が、契約条項、監査権、事故報告、再委託、費用負担の条件を確認する 既存取引先には移行期間を設け、取得状況または同等対策を確認する 新規RFPでは必要な★と、その根拠、未取得時の代替要件を明確にする 年次または契約更新時に、取得状況、重大インシデント、改善状況を再確認する 社内稟議・RFP・見積依頼で確認したいポイント SCS評価制度対応の稟議では、「制度対応だから必要」とだけ説明するより、主要顧客から要求される可能性、売上への影響、対象システム、現状との差分、必要な改善費、取得・維持に必要な運用工数を整理すると、経営判断につながりやすくなります。 外部支援会社へRFPや見積依頼を出す場合は、SCS評価制度のギャップ分析だけを依頼するのか、規程整備、証跡設計、脆弱性診断、改善支援、専門家確認や★4評価に向けた準備まで含めるのかを明確にします。また、診断で扱う個人情報・機密情報の範囲、データの保管・削除方法、再委託の有無、報告書の取扱いも確認が必要です。 SCS評価制度の支援会社を選ぶ際のチェックポイント 支援会社は、制度文書の説明だけでなく、実際のIT環境と業務プロセスを理解し、必要な改善までつなげられるかで選ぶことが重要です。特に、規程作成だけで終わる支援では、技術的な脆弱性や運用実態との不整合が残る可能性があります。 SCS評価制度の要求事項・評価基準を、具体的な業務とシステムに落とし込めるか 経営・法務・調達・情報システムの各部門を横断して支援できるか Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストなど技術検証にも対応できるか 不足事項を「重要度」「対応コスト」「取引影響」で優先順位付けできるか 取得後の継続運用、再評価、教育、インシデント対応まで支援できるか よくある失敗と注意点 取引先すべてに同じ★を要求する 取引リスクを見ずに一律の要求を設定すると、必要以上のコストを委託先に負わせたり、調達先の選択肢を狭めたりする可能性があります。重要度に応じたリスクベースの設計が必要です。 未取得＝セキュリティが低いと判断する SCS評価制度は開始前後の移行期があり、未取得でも要求事項相当の対策を実施している企業はあり得ます。取得状況と実態を分けて確認する視点が重要です。 チェックシートの回答だけで安心する 自己申告だけでは、実装上の問題を見逃す場合があります。重大なシステムについては、設定確認、ログ、運用記録、脆弱性診断など客観的な証拠を組み合わせることが有効です。 セキュリティ強化の費用を委託先だけに負担させる 発注側の追加要請によってコストが発生する場合は、価格交渉や導入期限を含めて十分に協議することが必要です。調達部門だけでなく、法務・事業部門も交えて運用ルールを定めるべきです。 Librus株式会社が提供できるSCS評価制度対応支援 Librus株式会社では、SCS評価制度への対応を、チェックリストへの回答支援だけで終わらせず、経営・組織・技術の三つの観点から一気通貫で支援します。 例えば、現状の規程・運用・システム構成を確認したギャップ分析、対象範囲の整理、改善ロードマップ策定、社内規程・手順の整備、証跡の設計、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、インシデント対応体制やSOC／CSIRTの整備、教育・訓練まで、企業の状況に応じて組み合わせることが可能です。 また、取引先からSCS評価制度への対応を求められた受注側だけでなく、調達基準や委託先管理を整備したい発注側企業についても、必要な★の考え方、既存チェックシートとの整理、RFP・契約条件への落とし込みなどを支援できます。M&A、IPO、取引先監査など、経営上の重要局面に合わせた対応も可能です。 よくある質問 Q1. SCS評価制度が始まると、取引先は必ず★取得が必要ですか？ いいえ。SCS評価制度は任意制度です。ただし、委託元が契約条件として必要な★を提示することは想定されているため、個別の取引では実質的な条件になる可能性があります。 Q2. ★を取得していないと取引停止になりますか？ 制度上、一律に取引停止となるルールはありません。契約上どのように扱うかは当事者間で合意する必要があります。未取得時の代替確認や改善期限を設ける運用も考えられます。 Q3. 既存のセキュリティチェックシートは不要になりますか？ 必ずしも不要にはなりません。SCS評価制度を共通基準として使いながら、業界固有・取引固有の確認項目を追加する形が現実的です。 Q4. ISMSを取得していればSCS評価制度への対応は不要ですか？ 不要とは限りません。両制度は目的や評価方法が異なり、相互補完的と位置付けられています。SCS評価制度の要求事項との差分確認が必要です。 Q5. 発注側はすべての委託先に★4を求めるべきですか？ 一律に★4を求めるのではなく、委託内容、情報の重要度、システム接続、事業継続への影響等から必要水準を決めることが望まれます。 Q6. ★4では脆弱性診断が必要ですか？ ★4では第三者評価に加えて技術検証が求められます。IPAは技術検証事業者の業務として脆弱性診断を示しており、評価機関が文書確認・実地審査・技術検証を行う仕組みが示されています。 Q7. どのくらい前から準備すべきですか？ 社内規程、資産管理、アクセス管理、脆弱性管理、教育、証跡整備などに改善が必要な場合、短期間では整いません。主要顧客の契約更新やRFP予定から逆算し、早期にギャップ分析を始めるのが現実的です。 Q8. 取引先から突然SCS評価制度への対応を求められた場合、何から始めればよいですか？ まず、相手が求める★、対象範囲、期限、未取得時の代替条件を確認します。そのうえで自社の現状を要求事項と照合し、重大な不足から改善計画を作成します。 まとめ｜SCS評価制度は「取引先チェックの共通言語」になり得る SCS評価制度によって、すべての取引先チェックが一律に厳しくなるわけではありません。しかし、発注側が委託先に求めるセキュリティ水準を★3・★4で示し、契約・RFP・取引先評価に活用する仕組みが整うことで、調達・委託におけるセキュリティ確認の位置付けはこれまで以上に明確になると考えられます。 受注側企業は、★取得の有無だけに注目するのではなく、規程、運用、証跡、技術対策を実態として整えることが重要です。発注側企業も、必要性を説明できる合理的な水準設定と、費用・移行期間を含む取引先との協議が求められます。SCS評価制度を「選別のためのラベル」ではなく、サプライチェーン全体のリスクを共通言語で整理する仕組みとして活用することが、制度の趣旨に沿った対応です。 SCS評価制度への対応方針が固まっていない段階からご相談いただけます 「取引先から★取得を求められそうだが、どこから手を付ければよいか分からない」「自社が★3と★4のどちらを目指すべきか判断できない」「調達先にどの水準を求めるべきか整理したい」といった段階でも、Librus株式会社へご相談いただけます。 現状の規程・運用・IT環境を確認したうえで、SCS評価制度の要求事項とのギャップ、優先的に改善すべき項目、診断や技術検証が必要な範囲、社内稟議で説明すべき論点を整理します。対象範囲や実施方法がまだ決まっていない場合でも、過剰投資を避けながら、取引上必要となる水準に向けた現実的なロードマップを検討できます。 主な公的情報・一次情報 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.meti.go.jp/policy/netsecurity/scs.html IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.ipa.go.jp/security/scs/index.html IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html IPA「要求事項・評価基準」 https://www.ipa.go.jp/security/scs/requirements-criteria.html IPA「指定申請について（評価機関・技術検証事業者・研修事業者向け）」 https://www.ipa.go.jp/security/scs/security-experts-organization/shiteishinsei.html 経済産業省「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」 https://www.meti.go.jp/policy/netsecurity/partnership2.html 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム https://librus.co.jp/contact

VIEW MORE