SCS評価制度の★3取得に必要な対策とは？要求事項と準備方法を解説

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3は、一般的なサイバー攻撃に対して、企業が最低限実装すべき基礎的な組織対策とシステム防御策を備えていることを示すための段階です。2026年10月時点では、★3・★4は2027年3月頃の運用開始が予定されています。 結論から言えば、★3取得に向けて最初に行うべきことは、セキュリティ製品を追加購入することではありません。自社のIT基盤と業務範囲を整理し、公開されている★3要求事項・評価基準とのギャップを確認し、不足する対策を実装して、その実施を説明できる証跡をそろえることが重要です。 また、★3は単なる自己チェックではありません。取得希望企業が自己評価を行い、所定の要件を満たすセキュリティ専門家による確認・助言と署名を受け、さらに経営層による自己適合宣誓を含めて申請する仕組みです。したがって、情報システム部門だけで完結させるのではなく、経営層、管理部門、現場部門を含めた準備が必要になります。 この記事で分かること ・SCS評価制度の★3が求めるセキュリティ水準 ・★3取得までの評価スキームと専門家確認の役割 ・企業が優先して整備したい組織面・技術面の対策 ・Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストの使い分け ・申請前にそろえておきたい資料・証跡と社内体制 ・準備期間や費用を左右する要因、支援会社の選び方 SCS評価制度の★3とは SCS評価制度は、取引先ごとに異なっていたセキュリティ確認を共通化し、サプライチェーンに参加する企業の対策状況を分かりやすく可視化することを目的とした制度です。制度は任意であり、取得しなければ一律に商取引が禁止されるものではありません。ただし、発注企業が契約や調達の中で、取引先に一定の★取得や同等水準の対策を求める活用が想定されています。 ★3は、広く認知された脆弱性などを悪用する一般的なサイバー攻撃への対応を想定した水準です。経済産業省は、★3を「全てのサプライチェーン企業が最低限実装すべきセキュリティ対策」と位置付け、基礎的な組織的対策とシステム防御策を中心に実施する段階と説明しています。 出典：IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html 出典：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」https://www.meti.go.jp/policy/netsecurity/scs.html ★3は「専門家確認付き自己評価」 ★3の評価主体は取得希望企業自身です。ただし、企業が記入した自己評価について、社内外のセキュリティ専門家が内容を確認し、必要に応じて修正を含む助言を行います。最終的に専門家が提出内容を了承した場合に署名し、企業は経営層による自己適合宣誓を含めて事務局へ提出します。 ここで注意したいのは、単に「社内の情報システム担当者が確認した」だけでは足りない点です。IPAが示す専門家には、情報処理安全確保支援士、公認情報セキュリティ監査人、CISSP、CISA、CISM、ISO27001主任審査員などの資格保持に加え、制度上必要な研修・登録要件が設けられています。 ★3取得には全ての要求事項・評価基準への適合が必要 IPAのFAQでは、★3・★4の取得には、それぞれで定められた全ての要求事項・評価基準を満たす必要があると明示されています。「重要な項目だけできていればよい」「一定点数を超えれば取得できる」という考え方ではありません。 そのため、申請直前にチェックリストを埋めるよりも、まず現状を棚卸しし、不適合項目に対して担当者・期限・予算を設定した改善計画を作る方が現実的です。特に従業員100～1,000名規模では、拠点、クラウドサービス、端末、委託先、部門ごとの例外運用が増えやすく、規程だけ整っていて実運用が追いついていないケースに注意が必要です。 出典：IPA「よくある質問」https://www.ipa.go.jp/security/scs/faq.html ★3取得で企業が整備したい主な対策 ★3の具体的な判定はIPAが公開する要求事項・評価基準に沿って行う必要があります。以下は、公開されている制度方針と一般的な実務を踏まえ、企業が準備時に優先して確認したい領域を整理したものです。実際の申請では必ず最新の公式要求事項・評価基準と照合してください。 1．経営責任とセキュリティ体制を明確にする 最初に必要なのは、誰がセキュリティ対策を決定し、誰が実行し、インシデント時に誰が判断するかを明確にすることです。情報セキュリティ方針、責任者、担当部門、報告経路が曖昧な状態では、技術対策を導入していても継続的な運用につながりません。 経営層は、★3を単なるIT部門の認証取得業務として扱うのではなく、取引継続、顧客情報保護、事業停止リスクの低減に関わる経営課題として位置付ける必要があります。最終申請には経営層による自己適合宣誓が含まれるため、対策状況を経営会議等で説明できる状態にしておくことが望まれます。 2．対象となるIT資産を把握する 対策の前提は、守る対象を把握することです。PCやサーバだけではなく、クラウドサービス、ネットワーク機器、VPN、アカウント、外部公開システム、管理者端末なども含めて棚卸しします。誰が管理しているか、どの業務で使われているか、インターネットからアクセス可能かといった情報も整理すると、その後の優先順位付けがしやすくなります。 SCS評価制度は企業等のIT基盤を主な対象として設計されています。製造設備のOTシステムや、委託元へ提供する製品自体は直接の評価対象とは異なる整理が示されているため、自社の業務範囲と制度対象を混同しないことも重要です。 3．アカウントとアクセス権限を管理する サイバー攻撃では、盗まれたID・パスワードや過剰な管理者権限が侵入・被害拡大の起点になります。入社・異動・退職時のアカウント管理、管理者権限の限定、不要アカウントの削除、認証強化、リモートアクセスの制御などを確認します。 特に、退職者のアカウントが残っている、共有IDを複数人で使っている、管理者権限が日常業務用PCに付与されているといった運用は、ルールと実態の両面から見直す必要があります。規程だけではなく、アカウント一覧や棚卸し記録を残すことで、実施状況を説明しやすくなります。 4．脆弱性管理とパッチ適用を仕組み化する ★3が想定する脅威には、広く認知された脆弱性を悪用する一般的な攻撃が含まれます。そのため、OS、ミドルウェア、ネットワーク機器、VPN、Webサーバなどの脆弱性情報を収集し、影響を判断し、更新プログラムや回避策を適用する流れを定めておくことが重要です。 実務では、「重大な脆弱性が公表されたら誰が確認するか」「何日以内に対応方針を決めるか」「業務都合でパッチを当てられない場合に代替策をどう承認するか」まで決めておくと、属人的な対応を減らせます。 5．マルウェア対策、バックアップ、ログ管理を確認する ランサムウェアや不正プログラムへの備えとして、端末・サーバの防御、メールやWeb経由の感染対策、バックアップ、復旧手順を確認します。バックアップは取得しているだけでは不十分で、復元できることを定期的に確認することが重要です。 また、インシデント発生時には、いつ、どの端末から、どのアカウントで何が行われたかを追跡できるログが必要になります。すべてのログを長期間保存すればよいわけではありませんが、重要システムや管理者操作を中心に、取得対象、保管期間、確認方法を定めることが実務上有効です。 6．インシデント対応手順と連絡体制を整える セキュリティ対策は、侵入を防ぐ施策だけでは完結しません。感染や不正アクセスが疑われた場合に、初動判断、端末隔離、経営報告、取引先への連絡、外部専門家への相談をどのように行うかを事前に決めておく必要があります。 例えば、取引先から預かったデータを扱うシステムで不審な通信が発生した場合、情報システム部門だけで調査を続けると、報告判断が遅れることがあります。法務、管理、広報、経営層を含む連絡経路と、重大度に応じたエスカレーション基準を用意しておくと、事業継続と信用毀損の双方に対応しやすくなります。 7．従業員教育と委託先管理を運用に組み込む フィッシングメール、パスワードの使い回し、機密情報の誤送信など、人を起点としたリスクは技術製品だけでは抑えきれません。入社時教育だけでなく、定期的な教育、注意喚起、必要に応じた標的型メール訓練などを実施し、受講記録を残すことが有効です。 また、クラウド事業者、保守会社、業務委託先など、自社のシステムや情報へアクセスする第三者についても、契約・権限・セキュリティ条件を確認します。取引先管理を「契約書を締結したら終わり」にせず、重要度に応じて継続的に見直すことが重要です。 Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストは必要か SCS評価制度は、特定のセキュリティ製品やサービスの導入を一律に義務付ける制度ではありません。そのため、すべての★3取得企業に同じ内容の脆弱性診断やペネトレーションテストが必須になる、と単純に考えるべきではありません。自社のシステム構成、公開範囲、リスク、要求事項への適合状況を踏まえて必要性を判断します。 Webアプリケーション診断 顧客向けWebサービス、会員サイト、管理画面、APIなどを公開している場合は、SQLインジェクション、クロスサイトスクリプティング、認証・認可の不備などを確認するWebアプリケーション診断が有効です。自社開発だけでなく、外部ベンダーが開発したシステムでも、運用責任を自社が負う場合は診断範囲を検討する価値があります。 プラットフォーム診断 インターネット公開サーバ、VPN装置、ファイアウォール、クラウド上の仮想マシンなどについて、不要なポート、古いソフトウェア、危険な設定、既知の脆弱性を確認するのがプラットフォーム診断です。資産棚卸しと組み合わせることで、外部から攻撃可能な箇所を効率的に把握できます。 ペネトレーションテスト ペネトレーションテストは、個別の脆弱性の有無だけでなく、複数の弱点を組み合わせた場合に実際に重要情報や管理権限まで到達できるかを検証する手法です。★3取得のために一律実施するというより、重要システムの事業リスクが高い場合や、単純な診断では把握しにくい攻撃経路を確認したい場合に適しています。 ★3取得に向けた準備手順 ステップ1：対象範囲と責任者を決める まず、対象となる組織、拠点、IT基盤、クラウド環境、委託関係を整理し、プロジェクト責任者を決めます。営業部門や製造部門が独自に利用しているクラウドサービスなど、情報システム部門が把握していないITがないかも確認します。 ステップ2：公式要求事項とのギャップ分析を行う IPAが公開する★3・★4要求事項・評価基準を用いて、現状が適合しているかを確認します。「規程あり」「運用あり」「証跡あり」を分けて評価すると、不足が明確になります。例えば、パッチ適用ルールがあっても実施記録が残っていなければ、証明可能性の面で課題が残ります。 出典：IPA「要求事項・評価基準」https://www.ipa.go.jp/security/scs/requirements-criteria.html ステップ3：不足対策をリスクベースで改善する ギャップが見つかったら、すべてを同時に実施するのではなく、外部公開システム、管理者権限、重要データ、ランサムウェア対策など、事故時の影響が大きい領域から着手します。改善内容は、担当、期限、必要予算、完了条件を設定し、経営層が進捗を確認できる形にします。 ステップ4：証跡を整備する 自己評価を説明するためには、「実施している」と口頭で説明するだけでなく、実施状況を裏付ける資料が必要です。規程、組織図、資産台帳、アカウント一覧、パッチ適用記録、バックアップ記録、教育記録、インシデント対応手順、委託先管理記録などを整理します。 証跡には個人情報や機密情報が含まれることがあります。外部専門家へ共有する場合は、NDA、アクセス制御、保存場所、削除方法を事前に確認し、必要以上の情報を渡さない運用にします。 ステップ5：セキュリティ専門家による確認を受ける 自己評価がまとまった段階で、制度要件を満たすセキュリティ専門家に確認を依頼します。申請直前に初めて依頼すると、大きな不備が見つかった際に改善期間を確保できません。早い段階でギャップ分析やプレチェックを受け、最終確認までの修正期間を確保する方法が効率的です。 ステップ6：経営層が適合状況を確認し、申請準備を行う 最終的には経営層による自己適合宣誓が必要です。経営層には、技術的な項目をそのまま説明するのではなく、未対応事項の有無、残存リスク、取引先への影響、取得・維持コスト、次年度の改善計画をまとめて説明すると判断しやすくなります。 準備期間と費用を左右する要因 ★3取得までの準備期間は、企業規模だけでは決まりません。ISMSやPマーク等を運用していて資産管理・規程・教育・委託先管理の基盤が整っている企業は、既存資料を活用できる可能性があります。一方、拠点やクラウドサービスが多い、アカウント管理が部門ごとに分かれている、脆弱性管理が属人化している場合は、改善に時間を要します。 費用も同様で、申請・登録に関する費用だけでなく、専門家確認、コンサルティング、脆弱性診断、製品・サービス導入、社内工数、規程改定などを含めて考える必要があります。最初から大規模な製品導入を予算化するのではなく、ギャップ分析を行って必要な対策だけを見極めることで、過剰投資を避けやすくなります。 社内稟議で説明すべきポイント SCS評価制度への対応を稟議に上げる際は、「認証を取るための費用」とだけ説明すると、経営上の優先度が伝わりにくくなります。取引先からのセキュリティ要求への対応、サイバー事故による事業停止や信用毀損の低減、既存統制の標準化、将来の★4取得への基盤整備といった効果を整理すると、投資目的が明確になります。 特に、主要顧客が自社のサプライチェーン管理を強化している場合は、取引先アンケートや監査対応にかかる工数削減、一定水準を客観的に説明できることも経営上のメリットになり得ます。 支援会社を選ぶときのチェックポイント 外部支援を利用する場合は、チェックリストの記入代行だけでなく、現状分析、技術対策、証跡整備、専門家確認への準備、取得後の改善まで一貫して支援できるかを確認します。 見積依頼やRFPでは、支援範囲、対象拠点・システム、成果物、打合せ回数、脆弱性診断の有無、専門家確認との関係、追加費用が発生する条件、機密情報の取扱いを明記すると比較しやすくなります。また、制度上の専門家確認を行える人材と、コンサルティングや技術診断を担当する人材の役割分担も確認しておくと安心です。 よくある失敗と注意点 製品導入から始めてしまう SCS評価制度は、特定製品の導入を必須とする制度ではありません。現状を確認せずにEDR、資産管理、ログ管理製品などを先に購入すると、既存機能との重複や運用負荷の増加につながることがあります。まず要求事項とのギャップを把握し、運用改善で対応できるものと、技術投資が必要なものを分けることが重要です。 規程だけ整えて実運用を確認しない ルール上は定期棚卸しを行うことになっていても、実際には半年以上実施されていない、といった差異は珍しくありません。専門家確認を見据えるなら、規程、実運用、証跡の3点が一致しているかを確認する必要があります。 申請直前まで専門家に相談しない 専門家確認で大きな不足が判明すると、技術対策の導入や社内ルールの変更に時間がかかります。制度開始後すぐの取得を目指す場合は、正式申請前に現状評価と改善計画を進めておく方が現実的です。 Librus株式会社が提供できるSCS評価制度★3支援 Librus株式会社では、SCS評価制度への対応を、チェックリスト作成だけで終わらせず、企業ごとの環境と事業上の重要性を踏まえて支援します。現状把握、要求事項とのギャップ分析、改善計画策定、規程・運用整備、脆弱性診断、ペネトレーションテスト、教育、SOC／CSIRT、インシデント対応体制などを必要に応じて組み合わせることが可能です。 また、経営層に必要な判断事項と、情報システム部門が実行すべき技術対策を切り分け、取得のためだけではなく、取引先から説明を求められた際にも継続的に運用できる体制づくりを重視します。既にISMSやPマーク等の仕組みがある場合は、既存の規程・証跡を活かしながら、重複作業を抑える設計を検討します。 よくある質問 Q1．★3は中小企業だけが対象ですか？ いいえ。SCS評価制度は業種や事業規模を問わず幅広い事業者を対象とする設計です。従業員100～1,000名規模の企業も対象になり得ます。 Q2．★3を取得しないと取引できなくなりますか？ 制度自体は任意です。一律に取引が禁止されるものではありません。ただし、個別の取引契約や調達条件で、発注企業が一定の★取得や同等水準の対策を求める可能性はあります。 Q3．★3は自己評価だけで取得できますか？ 自己評価だけでは完結しません。所定の要件を満たすセキュリティ専門家による確認・助言と署名、経営層による自己適合宣誓が必要です。 Q4．すべての要求事項を満たす必要がありますか？ IPAは、★3取得には★3で定められたすべての要求事項・評価基準を満たす必要があると説明しています。 Q5．EDRや資産管理ツールは必須ですか？ 特定のセキュリティ製品を一律に導入することは求められていません。自社の規模、システム構成、既存対策を踏まえ、要求事項を満たす方法を選択します。 Q6．脆弱性診断は必須ですか？ すべての企業に同一内容の診断が一律必須とは限りません。ただし、外部公開システムの脆弱性を把握し改善することは、一般的なサイバー攻撃への備えとして有効です。自社の対象範囲と要求事項に照らして必要性を判断します。 Q7．ISMSやPマークがあれば★3対応は不要ですか？ 不要とはいえません。既存認証の規程や証跡を活用できる可能性はありますが、SCS評価制度独自の要求事項・評価基準との照合が必要です。 Q8．★3を取得してからでないと★4を申請できませんか？ いいえ。IPAは、上位段階が下位段階の事項を包含するものの、★3を事前取得しなければ★4を取得できない関係ではないと説明しています。 まとめ｜★3取得は「現状把握→改善→証跡→専門家確認」の順で進める SCS評価制度の★3は、一般的なサイバー攻撃に備えるために、すべてのサプライチェーン企業が最低限実装すべきセキュリティ対策を可視化する段階です。取得には公開された要求事項・評価基準をすべて満たし、専門家確認付き自己評価と経営層の自己適合宣誓を行う必要があります。 重要なのは、申請書作成から始めるのではなく、自社のIT基盤を把握し、公式要求事項とのギャップを確認し、必要な対策と証跡を整えることです。Webアプリケーション診断やプラットフォーム診断、ペネトレーションテストも、目的と対象を明確にしたうえで活用すれば、技術的な弱点の把握と改善に役立ちます。 2027年3月頃の制度開始を見据える場合、制度開始後に初めて準備するよりも、現在の対策状況を把握し、時間を要する改善から先に進めておく方が、予算・人員・稟議の面でも進めやすくなります。 SCS評価制度★3の準備段階からご相談いただけます 「どこまでが対象になるのか分からない」「要求事項とのギャップを自社だけで判断しにくい」「既存のISMSやPマークの資料をどこまで活用できるか確認したい」といった段階でも、Librus株式会社へご相談いただけます。 Librus株式会社では、対象範囲の整理、現状評価、改善計画、規程・証跡整備、技術診断、取得に向けたプロジェクト推進まで、企業ごとの環境に合わせて支援します。最初から実施方法が決まっていなくても、必要な対策と優先順位を整理することで、過剰な投資を避けながら、取引先への説明や将来の★4対応も見据えたロードマップを検討できます。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 105-0004東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム https://librus.co.jp/contact

VIEW MORE

SCS評価制度とは？制度の概要・対象企業・開始時期をわかりやすく解説

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、企業のセキュリティ対策状況を段階別に可視化し、取引先との間で必要な対策水準を確認しやすくするための制度です。経済産業省と内閣官房国家サイバー統括室が制度構築方針を示し、独立行政法人情報処理推進機構（IPA）が運営します。 結論から言えば、SCS評価制度は特定の業種や大企業だけを対象にした制度ではありません。サプライチェーンを構成する幅広い企業が対象となり得ます。★3・★4は2027年3月頃の運用開始が予定されており、取引先から取得を求められる可能性がある企業だけでなく、自社のセキュリティ対策を客観的に整理したい企業にとっても重要な制度です。 一方で、SCS評価制度は現時点で法律によって一律に取得を義務付けるものではありません。実務上は、発注企業が委託先に一定の★を求めるなど、取引条件の一部として活用されることが想定されています。そのため、「義務ではないから様子を見る」だけではなく、自社の主要取引先や事業上の重要性を踏まえて準備時期を判断することが重要です。 この記事で分かること SCS評価制度の目的と仕組み、★3・★4・★5の位置付け 対象となり得る企業と、特に対応を検討すべき企業 2026年10月時点で公表されている開始時期と今後のスケジュール 取得に向けて必要になる規程、証跡、技術対策、診断の考え方 費用・期間を左右する要因と、社内での準備の進め方 SCS評価制度とは何か SCSは「Supply Chain Security」の略称です。SCS評価制度は、取引関係を通じてつながる企業群の中で、各社がどの程度のセキュリティ対策を実施しているかを可視化し、委託元と委託先が必要な対策水準を共有しやすくする仕組みです。 背景には、サプライチェーン経由のサイバー攻撃があります。攻撃者が大企業を正面から狙うのではなく、取引先や委託先のネットワーク、リモート接続、クラウドアカウント、公開サーバーなどを足掛かりに侵入し、機密情報の窃取や業務停止につなげるケースが問題となっています。発注企業側から見ると、委託先の対策状況を外部から判断しにくいことが課題です。一方、受注企業側も複数の顧客から異なるチェックシートへの回答を求められ、対応負担が大きくなっています。SCS評価制度は、こうした双方の課題を軽減することを狙っています。 出典：IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.ipa.go.jp/security/scs/index.html ★3・★4・★5は何が違うのか 制度は段階別の評価を採用しています。2026年10月時点で具体的な運用準備が進められているのは★3と★4です。★5は、より高度な脅威への対応を想定した水準として検討中です。 区分想定する位置付け評価方法主な考え方★3全てのサプライチェーン企業が最低限実装すべき水準専門家確認付き自己評価基礎的な組織対策とシステム防御を中心に確認★4標準的に目指すべき水準第三者評価ガバナンス、取引先管理、防御・検知、インシデント対応等を包括的に確認★5到達点として目指す高度な水準第三者評価を想定未知の攻撃も含む高度な脅威への対応。詳細は検討中 ★3では、取得希望組織が自己評価を行い、登録されたSCSセキュリティ専門家が書類を確認します。★4では、評価機関による文書確認と実地審査に加え、技術検証事業者による技術検証が行われる想定です。制度上の「★」は単なる自己宣言ではなく、段階に応じた確認・評価プロセスを伴います。 出典：IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html SCS評価制度の対象企業は？ SCS評価制度は、業種や企業規模を限定した制度ではありません。経済産業省のFAQでは、業種や事業規模を問わず幅広い事業者が対象となり得るとされています。特に、取引先のシステムや情報資産にアクセスする企業、重要な業務を受託する企業、製造・物流・金融・ITサービスなどサプライチェーンへの依存度が高い企業は、早めに制度との関係を確認しておく必要があります。 従業員100～1,000名規模の企業では、顧客からセキュリティチェックシートへの回答を求められている一方、情報システム部門や管理部門の人員が限られているケースも少なくありません。SCS評価制度が取引先管理に活用されるようになると、従来の個別チェックシートに加えて「★3を取得しているか」「★4相当の対策があるか」といった確認が行われる可能性があります。 特に対応優先度が高い企業 次のような企業は、制度開始前から現状把握を進める価値があります。 大企業や重要インフラ企業から業務委託を受けている企業 顧客の個人情報、営業秘密、設計情報、ソースコードなどを扱う企業 リモート接続やAPI連携などで顧客環境に接続する企業 製造、物流、保守、IT運用など、停止すると顧客業務に影響するサービスを提供する企業 新規取引や入札、RFPでセキュリティ要件が増えている企業 取引先監査、IPO、M&Aなどでセキュリティ体制の説明が必要な企業 SCS評価制度はいつ始まる？ IPAのFAQでは、★3・★4は2027年3月頃の運用開始が予定されています。2026年10月時点では、要求事項・評価基準、制度規程、評価機関・技術検証事業者等の指定手続など、運用開始に向けた具体化が進められています。評価機関は2026年12月末頃、SCSセキュリティ専門家は2027年1月頃から公表予定です。 したがって、2027年3月になってから準備を始めるのではなく、2026年度中にギャップ分析、対象範囲の整理、規程整備、証跡収集、技術的な弱点の洗い出しまで進めておく方が現実的です。特に★4を目指す場合、実地審査や技術検証に備え、運用実績を示せる状態にしておく必要があります。 出典：IPA「よくある質問」 https://www.ipa.go.jp/security/scs/faq.html なぜ今、企業にSCS評価制度への準備が必要なのか 最大の理由は、セキュリティ対策が情報システム部門だけの課題ではなく、取引継続や営業機会に関わる経営課題になっているためです。SCS評価制度は任意制度ですが、発注企業が委託先に必要な★を提示し、契約や取引判断に活用することが想定されています。 例えば、同じ価格と品質で競合する2社があり、一方が★3を取得して対策状況を説明でき、もう一方が規程や運用証跡を提示できない場合、発注側のリスク管理では前者が選ばれやすくなる可能性があります。逆に、既存取引先から一定水準を求められたときに準備が整っていなければ、改善計画の提出や追加監査を求められ、営業・管理・情報システム部門に急な負担が生じます。 対応しなかった場合に起こり得る問題 SCS評価制度を取得しないこと自体に直ちに罰則があるわけではありません。しかし、取引先が調達基準に活用する場合、実務上の影響は別です。新規取引の条件を満たせない、契約更新時に追加説明を求められる、個別のセキュリティチェックが長期化するといった可能性があります。 また、制度対応を先送りした結果、ランサムウェア、認証情報窃取、VPNや公開サーバーの脆弱性悪用などによる事故が発生すれば、復旧費用だけでなく、取引先への報告、信用低下、受注停止、調査対応など事業面の影響が大きくなることがあります。制度対応は「マーク取得のための作業」ではなく、実際のリスク低減とセットで考えることが重要です。 取得・対応に向けて企業が準備すべきこと SCS評価制度への準備は、最初から全項目を完璧にするのではなく、対象範囲を決め、現状と要求事項の差分を把握し、優先順位を付けて改善する方法が現実的です。 1. 目標とする★と対象範囲を決める 主要顧客から求められる可能性、自社サービスの重要度、扱う情報、システム構成を踏まえ、★3か★4かを検討します。全社を一度に対象とするのではなく、制度上認められる適用範囲を整理することも重要です。 2. 要求事項に沿ってギャップ分析を行う 規程、組織体制、アカウント管理、脆弱性管理、ログ監視、バックアップ、委託先管理、インシデント対応などについて、現在できていることと不足していることを整理します。 3. 規程と実運用を一致させる 情報セキュリティ規程を作るだけでは不十分です。退職者アカウントの削除記録、パッチ適用記録、教育記録、インシデント訓練記録、バックアップ復旧確認など、実際に運用していることを示す証跡が必要です。 4. 技術的な弱点を確認する インターネット公開資産、Webアプリケーション、クラウド、VPN、OSやミドルウェアなどの弱点を確認します。Webアプリケーション診断やプラットフォーム診断により既知の脆弱性や設定不備を洗い出し、重要度に応じて改修します。 5. 必要に応じてペネトレーションテストを検討する 脆弱性の有無だけでなく、複数の弱点を組み合わせて実際にどこまで侵入・権限拡大・重要情報への到達が可能かを確認したい場合は、ペネトレーションテストが有効です。★4等を視野に入れる場合、単なるチェックリスト対応ではなく、実環境の耐性を検証する発想が重要です。 6. 改善計画と経営判断を結び付ける 発見事項をすべて同じ優先度で対応するのではなく、事業影響、攻撃可能性、顧客要請、改善費用を踏まえて優先順位を付けます。経営層には「制度対応費」ではなく、取引継続、受注機会、事故損失の低減という観点で説明すると意思決定しやすくなります。 実施前にそろえておきたい資料 準備段階では、組織図、情報セキュリティ関連規程、IT資産台帳、ネットワーク構成図、クラウドサービス一覧、アカウント管理手順、委託先一覧、インシデント対応手順、バックアップ方針、教育記録、脆弱性対応記録、監視ログや点検記録などを集めます。資料が散在している場合は、それ自体が運用上の課題です。審査に備えるだけでなく、平時の運用を効率化する観点から保管場所や責任者も整理します。 費用と期間を左右する要因 SCS評価制度への対応費用は、単純な「申請料」だけでは決まりません。実際には、現在のセキュリティ成熟度、対象範囲、★3か★4か、不足している規程数、システム改修、診断・技術検証、専門家支援の範囲などで大きく変わります。 特に期間を左右するのは、証跡です。規程は短期間で作成できても、教育、点検、バックアップ復旧、脆弱性対応などの運用記録は、一定期間実施しなければ蓄積できません。そのため、制度開始直前に文書だけを整えるより、早い段階で運用を開始して記録を残す方が効率的です。 なお、IPAは2026年9月18日にSCS評価制度の料金設定に関する情報を公開していますが、評価を受ける企業の総費用は、評価機関や技術検証、改善対応等を含めて個別に異なります。見積依頼時には「評価そのもの」「事前ギャップ分析」「規程整備」「技術診断」「改修支援」「再確認」のどこまで含むかを分けて確認すると比較しやすくなります。 支援会社を選ぶときのチェックポイント SCS評価制度の支援会社を選ぶ際は、制度文書を説明できるだけでなく、現場の技術対策まで支援できるかが重要です。規程だけを整えても、公開サーバーの脆弱性、クラウドの設定不備、特権アカウント管理、ログ監視不足などが残れば、実態との乖離が生じます。 RFPや見積依頼では、SCS要求事項とのギャップ分析方法、成果物の形式、改善優先順位の付け方、Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストへの対応可否、経営層向け報告、評価後の継続支援まで確認するとよいでしょう。また、機密情報やネットワーク構成図を渡すことになるため、情報管理体制やNDA、データ保管・削除方針も確認が必要です。 よくある失敗と注意点 よくある失敗は、制度対応を「規程作成プロジェクト」にしてしまうことです。実際には、規程、運用、技術対策、証跡がつながっている必要があります。また、IT部門だけに任せると、購買・人事・法務・営業・経営層が関与する要求事項で進まなくなることがあります。 もう一つの注意点は、★取得をゴールにしないことです。サイバー攻撃の手法や自社システムは変化します。取得後も脆弱性管理、定期診断、ログ監視、教育、インシデント訓練、委託先管理を継続し、必要に応じて再診断や改善を行う運用が求められます。 Librus株式会社が提供できる支援 Librus株式会社では、SCS評価制度への対応を、制度文書の解釈だけでなく、実際のセキュリティ改善まで一気通貫で支援します。企業ごとの事業環境や取引先要件を踏まえて対象範囲を整理し、要求事項とのギャップ分析、規程・証跡の整備、改善計画の策定を支援します。 また、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジック、教育・訓練など、技術面・運用面の改善にも対応できます。診断だけで終わらせず、発見された課題を経営リスクや取引リスクに置き換え、優先順位を付けて改善することを重視しています。 経営層、情報システム部門、営業・管理部門の間で認識がそろっていない場合も、制度対応の目的、投資効果、取引先への説明方法まで含めて整理できます。M&A、IPO、取引先監査など、セキュリティ体制を外部に説明する重要局面と合わせた支援も可能です。 よくある質問 Q1. SCS評価制度は義務ですか？ 制度自体は任意です。ただし、委託元が取引条件として一定の★取得を求める可能性があります。自社の主要顧客や業界動向を確認したうえで対応時期を判断する必要があります。 Q2. 中小企業も対象ですか？ はい。業種や企業規模を問わず幅広い企業が対象となり得ます。IPAは特にサプライチェーンを構成する中小企業にとって活用効果が大きいと説明しています。 Q3. ★3・★4はいつ始まりますか？ IPAは2027年3月頃の運用開始を予定しています。評価機関は2026年12月末頃、SCSセキュリティ専門家は2027年1月頃から公表予定です。 Q4. ISMSを取得していれば対応不要ですか？ 必ずしもそうではありません。ISMSとSCS評価制度は目的や評価スキームが異なります。既存のISMS文書や運用を活用できる部分はありますが、SCSの要求事項に照らしたギャップ確認が必要です。 Q5. ★3と★4のどちらを目指すべきですか？ 取引先からの要求、事業の重要性、扱う情報、システム接続範囲などで判断します。取引先から指定がない段階では、まず現状を評価して、費用対効果を見ながら決める方法が現実的です。 Q6. 脆弱性診断は必須ですか？ 必要な技術対策は対象範囲や要求事項によります。ただし、公開資産やWebアプリケーションの弱点を把握せずに実効性のある対策を説明することは困難です。診断はギャップ把握と改善優先順位付けに有効です。 Q7. どのくらい前から準備すべきですか？ 不足項目の多さによります。規程だけでなく運用証跡を蓄積する必要があるため、取引先から要請されてから着手するより、数か月単位で前倒しして準備する方が安全です。 Q8. 何から始めればよいですか？ まずは対象範囲と目標水準を仮決めし、SCSの要求事項に沿ったギャップ分析を行うことをおすすめします。対象範囲や取得水準が決まっていない段階でも、現状整理から始められます。 まとめ｜SCS評価制度は「取引に使われるセキュリティ基準」として早めの準備を サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、企業のセキュリティ対策を段階別に可視化し、委託元と委託先の間で必要な水準を共有しやすくする制度です。★3・★4は2027年3月頃の開始が予定され、業種や企業規模を問わず幅広い企業が対象となり得ます。 重要なのは、制度が始まってから申請書を作ることではありません。規程、実際の運用、証跡、技術対策を一致させ、自社のリスクと取引先要求に応じて改善しておくことです。特に、主要顧客からセキュリティチェックを受けている企業、重要な業務や情報を扱う企業は、制度開始前からギャップ分析を進めることで、急な取引先要請にも対応しやすくなります。 SCS評価制度への対応範囲が決まっていない段階でもご相談いただけます「★3と★4のどちらを目指すべきか分からない」「既存のISMSや社内規程をどこまで流用できるか確認したい」「取引先から要請される前に準備したい」といった段階でも、Librus株式会社では現状整理から支援できます。制度対応と技術対策を分けて考えるのではなく、取引継続・新規受注・事故リスク低減まで含めて優先順位を整理することで、必要な投資を判断しやすくなります。対象範囲、実施方法、予算が固まっていない場合も、現状の課題と想定される対応範囲の整理からご相談ください。 主な公的情報 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/faq.html IPA 要求事項・評価基準：https://www.ipa.go.jp/security/scs/requirements-criteria.html 経済産業省 SCS評価制度に関するFAQ：https://www.meti.go.jp/press/2025/03/20260327001/20260327001-gr.pdf 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

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