SCS評価制度とPマークの違い｜既存認証があれば対応不要？

結論からいえば、Pマーク（プライバシーマーク）を取得している企業でも、SCS評価制度への対応が自動的に不要になるわけではありません。両制度には、規程整備、教育、委託先管理、インシデント対応など共通する要素がありますが、制度の目的と評価するリスクの範囲が異なります。Pマークは個人情報の適切な取扱いを中心に評価する一方、SCS評価制度はサプライチェーンを通じたサイバー攻撃や事業停止、機密情報の漏えい、踏み台化などのリスクに対するセキュリティ対策水準を可視化する仕組みです。 そのため、Pマークを保有している企業は「ゼロから準備する」必要はない場合が多いものの、既存の個人情報保護体制をSCS評価制度の要求事項に照らして棚卸しし、不足する技術対策やサプライチェーン管理、ログ監視、脆弱性管理などを追加することが実務的な進め方です。 この記事で分かること この記事では、SCS評価制度とPマークの違い、Pマーク取得企業がそのままSCS評価制度に対応できるのか、どの領域を追加で確認すべきか、社内でどのように準備を進めればよいかを解説します。特に、従業員100～1,000名規模の企業が、取引先からセキュリティ水準の説明を求められる場面を想定し、経営・情報システム・管理部門が確認すべき実務ポイントを整理します。 SCS評価制度とPマークは何が違うのか Pマークは「個人情報の適切な取扱い」を評価する制度 プライバシーマーク制度は、JIS Q 15001「個人情報保護マネジメントシステム－要求事項」に準拠した運用指針に基づき、個人情報について適切な保護措置を講ずる体制を整備している事業者を評価し、マークの使用を認める制度です。JIPDECによれば、Pマークは法人単位で付与され、個人情報保護マネジメントシステム（PMS）の構築と運用が重視されます。 つまり、Pマークの中心テーマは「個人情報をどのように取得し、利用し、保管し、委託し、廃棄するか」「個人情報の取扱いに関するルールをどのように継続運用するか」です。もちろん安全管理措置としてアクセス制御や認証、教育、委託先管理、事故対応なども含まれますが、評価の出発点は個人情報保護です。 SCS評価制度は「サプライチェーンのサイバーリスク」を評価する制度 SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）は、取引関係を通じたサイバーリスクに対応するため、企業のセキュリティ対策実施状況を段階別の★で可視化する制度です。IPAは、委託先への攻撃を起点とする事業・サービス停止、機密情報の漏えい・改ざん、委託先を踏み台とした不正侵入などのリスクへの対策を促進することを目的として示しています。 ★3は一般的なサイバー脅威への対処を想定し、専門家確認付きの自己評価を基本とします。★4は、初期侵入防御だけでなく、侵入後の被害拡大防止やサプライチェーン上の役割に応じた対策まで求め、第三者評価・実地審査・技術検証を含む仕組みです。★3・★4は2027年3月頃の運用開始が予定されています。 違いを一言で表すと「守る対象」と「確認方法」が異なる PマークとSCS評価制度は、どちらも社内規程、責任体制、教育、委託先管理などを扱うため、実務担当者から見ると似て見える部分があります。しかし、Pマークは個人情報保護を軸としたマネジメントシステムの評価であり、SCS評価制度は取引先との接続やシステム運用、サイバー攻撃への技術的耐性、事業継続まで含むサプライチェーンリスクへの対応を重視します。 そのため「Pマークを持っている＝SCS評価制度の要求事項を満たしている」とは整理できません。反対に、Pマークで整備済みの規程や教育記録、委託先管理台帳、事故対応手順などは、SCS評価制度への準備に活用できる可能性があります。重要なのは、既存認証を“代替”と考えるのではなく、“再利用できる統制資産”として扱うことです。 Pマーク取得済みでもSCS評価制度への対応が必要になる理由 理由1：SCS評価制度は個人情報以外の機密情報・システムも対象になり得る 企業間取引で守るべき情報は個人情報だけではありません。設計図、価格情報、営業秘密、認証情報、ソースコード、顧客企業のシステム情報、製造条件、研究開発データなども重大な保護対象です。SCS評価制度では、こうした情報やシステムがサプライチェーン経由で侵害されるリスクを考えます。 たとえば、委託先のリモート接続アカウントが侵害され、発注元の環境に不正侵入されるケースでは、個人情報が含まれなくても事業上の影響は大きくなります。Pマークで個人情報管理が適切でも、特権ID管理、ネットワーク分離、脆弱性管理、EDR、ログ監視などの技術統制が十分かは別に確認する必要があります。 理由2：SCS評価制度では技術的な実効性がより重視される SCS評価制度の★4では、文書確認に加えて実地審査と技術検証が想定されています。規程に「脆弱性を定期的に確認する」と書いてあっても、実際に対象システムが適切な頻度と範囲で診断されているか、重大な脆弱性が放置されていないか、是正が追跡されているかといった実装面が問われます。 この点では、Webアプリケーション診断やプラットフォーム診断、必要に応じたペネトレーションテストが重要になります。Webアプリケーション診断は、Webサービスに対してSQLインジェクションや認証・認可不備などの脆弱性を確認するものです。プラットフォーム診断は、OS、ミドルウェア、ネットワーク機器等の設定不備や既知脆弱性を確認します。ペネトレーションテストは、攻撃者の視点で複数の弱点を組み合わせ、実際にどこまで侵入・権限拡大・情報到達が可能かを検証する方法です。 理由3：取引先から求められる説明が変わる可能性がある IPAは、SCS評価制度について、2社間の取引契約等において委託元が委託先に適切な段階（★）を提示し、対策の実施を促し、状況を確認する活用を想定しています。つまり、今後の取引先管理では「Pマークがあります」という説明だけでなく、「SCS評価制度ではどの水準を満たしているか」「取引対象システムにどの対策を実装しているか」といった説明を求められる可能性があります。 特に、重要な情報やシステムへのアクセスを許可される委託先、クラウドやSaaSの運用事業者、システム開発・保守事業者、製造業のサプライヤーなどでは、セキュリティ水準の客観的な説明が取引上の論点になりやすいと考えられます。 Pマーク取得企業がSCS評価制度対応で活用できる既存資産 規程・責任体制・教育記録は流用できる可能性が高い Pマーク取得企業には、個人情報保護方針、内部規程、責任者・担当者の役割、教育記録、内部監査、事故対応、委託先管理などの仕組みがすでに存在します。これらはSCS評価制度への対応でも有効な土台になります。新しい制度だからといって、すべての規程を一から作り直す必要はありません。 実務では、まずSCS評価制度の要求事項と既存文書を対応付ける「ギャップ分析」を行い、既存資料で証明できる項目と追加整備が必要な項目を分けます。これにより、重複作業を減らし、追加コストと準備期間を抑えやすくなります。 一方で技術対策は別途棚卸しが必要 Pマーク取得企業でも、情報システム部門の運用がPMS文書とは別管理になっていることがあります。たとえば、パッチ適用基準、サーバーの構成管理、クラウド設定、MFA（多要素認証）、EDR、バックアップ、ログ保管、SOC監視、脆弱性診断の実施状況などです。 SCS評価制度を見据える場合は、こうした技術対策を「実施しているか」だけでなく、「対象範囲が明確か」「例外管理があるか」「証跡が残っているか」「発見事項が期限管理されているか」まで確認する必要があります。 対応しなかった場合に起こり得る問題 SCS評価制度そのものは、すべての企業に取得を法律上義務付ける制度ではありません。しかし、取引先が調達条件や委託先評価の基準として★取得や同等水準の対策を求める場合、未対応は商談や契約更新の説明負担につながる可能性があります。 また、取引先からセキュリティチェックシートを受け取った際に、社内の情報が分散していて回答に時間がかかる、証跡が不足して回答できない、対策済みと思っていたが実装状況を確認できない、といった問題が起きやすくなります。制度取得そのものよりも、取引先への説明能力を高めることが重要です。 経営上は、セキュリティ対策が受注継続、取引信用、事業継続に関係する点も見逃せません。サイバー事故が発生すれば、復旧費用だけでなく、取引停止、違約対応、顧客説明、信用毀損、経営層の意思決定負荷まで波及する可能性があります。 SCS評価制度対応の対象をどう決めるか 法人全体ではなく、まず重要な取引・システムから整理する SCS評価制度では、各取得希望組織が適用範囲を決定し、その中からサンプリングして評価等を実施する考え方が示されています。したがって、準備段階では、どの取引・事業・拠点・システムを重要対象とするかを整理することが欠かせません。 優先度が高いのは、取引先の機密情報を扱う業務、外部からアクセス可能なWebシステム、クラウド管理画面、VPN・リモート接続、ソースコード管理基盤、顧客システムへの保守接続、事業停止時の影響が大きい基幹システムなどです。 経営層が判断すべき3つの事項 経営層は、第一にどの取引先・事業を優先するか、第二に★3と★4のどちらを目標とするか、第三に不足対策へどこまで投資するかを判断する必要があります。すべてを同時に最高水準へ引き上げるのではなく、取引重要度と事業影響を踏まえた優先順位付けが現実的です。 Pマーク取得企業が進めるべき具体的な対応手順 ステップ1：既存のPマーク文書とSCS要求事項を対応付ける まず、Pマークで保有している規程、台帳、監査記録、教育記録、委託先評価記録、事故対応記録などを一覧化します。そのうえでSCS評価制度の要求事項・評価基準と照合し、流用可能、不足、対象外の3区分程度で整理します。 ステップ2：技術対策を現状確認する 情報資産台帳やシステム一覧、ネットワーク構成図、クラウド利用一覧、アカウント管理表、パッチ管理記録、バックアップ設計、ログ監視状況、脆弱性診断報告書などを確認します。文書上は対策済みでも、現場運用で例外が常態化していないかを確認することが重要です。 ステップ3：脆弱性診断・技術検証の必要性を判断する 外部公開Webサービスやインターネット接続機器については、Webアプリケーション診断やプラットフォーム診断を検討します。重要なシステムや高度な攻撃を想定する環境では、ペネトレーションテストにより侵入経路や権限拡大、横展開の可能性を確認する方法もあります。診断の種類は「制度対応だから実施する」のではなく、守る対象と想定脅威に合わせて選択します。 ステップ4：発見事項をリスクベースで是正する 指摘事項は、単純な件数ではなく、悪用可能性、影響範囲、外部公開の有無、保有情報の機密性、事業停止時の影響などを踏まえて優先順位を決めます。重大な脆弱性は早期対応し、中長期対応が必要な課題は経営承認を得て改善計画へ落とし込みます。 ステップ5：証跡を残し、取引先への説明可能性を高める 評価対応では、ルールが存在するだけでなく、実際に運用されていることを示せる証跡が重要です。教育履歴、レビュー記録、パッチ適用結果、診断報告書、是正記録、バックアップ試験、インシデント訓練の結果などを保存し、必要なときに提示できる状態を作ります。 費用と期間を左右する要因 SCS評価制度対応の費用は、単に申請費用だけでは決まりません。既存の規程や技術対策がどこまで整備されているか、対象システム数、拠点数、クラウド利用数、診断対象URL・IP数、追加導入するセキュリティ製品、改修の難易度、★3・★4のどちらを目標とするかによって大きく変わります。 Pマーク取得企業は、規程・教育・内部監査・委託先管理などの基盤があるため、非取得企業に比べて準備を短縮できる可能性があります。一方、技術対策の不足が大きい場合は、MFA導入、EDR導入、ログ監視、バックアップ強化、脆弱性対応などに追加投資が必要です。 社内稟議では「認証取得費用」だけでなく、取引継続、取引先監査への対応工数削減、事故リスク低減、システム停止リスク、顧客からの信用といった経営効果を含めて説明すると、投資目的が伝わりやすくなります。 SCS評価制度の支援会社を選ぶポイント 制度解説だけでなく、技術実装まで支援できるか SCS評価制度では、規程整備だけでなく技術的な実効性が重要です。支援会社を選ぶ際は、要求事項の解釈だけでなく、脆弱性診断、ペネトレーションテスト、SOC／CSIRT、インシデントレスポンス、クラウド・ネットワーク対策などを理解し、発見した課題を実装レベルまで落とし込めるかを確認するとよいでしょう。 既存認証を尊重し、重複作業を減らせるか PマークやISMSなどをすでに運用している企業に対して、すべてを作り直す支援は効率的とは限りません。既存規程・証跡・監査プロセスを評価し、SCS評価制度との差分だけを明確にできる事業者のほうが、社内負担を抑えやすくなります。 RFP・見積依頼で確認したい項目 見積依頼時には、ギャップ分析の対象範囲、成果物、技術診断を含むか、改善支援の範囲、再診断の有無、機密情報の取り扱い、再委託の有無、担当者の資格・経験、想定スケジュールを確認します。SCS評価制度そのものの第三者評価と、取得に向けたコンサルティング・技術支援は役割が異なるため、どこまでを依頼するのかを明確にすることも重要です。 よくある失敗と注意点 「Pマークがあるから大丈夫」と確認を止めてしまう 最も注意したいのは、既存認証を理由に追加確認をしないことです。Pマークで十分に整備された領域がある一方、SCS評価制度ではサプライチェーンリスクや技術対策の観点から追加確認が必要になります。 規程整備を優先し、技術的な未対応を後回しにする 制度対応では、文書を整えることより、実際のリスクを減らすことが本質です。外部公開サーバーに重大な脆弱性が残っている、退職者アカウントが残存している、バックアップから復旧できない、といった問題は、規程だけでは解決できません。 診断結果を受け取って終了する 脆弱性診断やペネトレーションテストは、報告書を受領することが目的ではありません。発見事項を修正し、再診断で解消を確認し、同種の問題を繰り返さない運用に反映することが重要です。 Librus株式会社が提供できるSCS評価制度対応支援 Librus株式会社では、SCS評価制度への対応を「規程作成だけ」「診断だけ」で切り分けず、企業ごとの事業・取引・システム環境に応じて一気通貫で支援します。Pマークなど既存認証を取得している企業には、既存の規程・台帳・証跡を活かしながら、SCS評価制度とのギャップを整理し、不足する管理策を優先順位付けします。 また、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジック、SBOM支援、リスクアセスメントなど、技術対策から運用改善まで対応可能です。 制度取得そのものを目的にするのではなく、取引先に説明できるセキュリティ体制を整え、改善活動を継続できる状態を目指します。経営層への説明、情報システム部門の実装、管理部門の規程・証跡整備を横断して整理できる点も、SCS評価制度対応では重要です。 よくある質問 Q1. Pマークを取得していればSCS評価制度は取得不要ですか？ 一律に不要とはいえません。PマークとSCS評価制度は目的・評価対象が異なるためです。Pマークの既存統制を活用しつつ、SCS評価制度の要求事項との差分を確認する必要があります。 Q2. PマークとSCS評価制度で共通する対策はありますか？ あります。責任体制、規程、教育、委託先管理、インシデント対応、内部監査などは重なる可能性があります。ただし、SCS評価制度ではサイバー攻撃やサプライチェーンリスクへの技術的な対策がより重要になります。 Q3. Pマーク取得企業なら★3は簡単に取得できますか？ 既存の管理体制を活用できるため準備負担を減らせる可能性はありますが、取得を保証するものではありません。SCS評価制度の要求事項・評価基準に照らして、不足部分を確認する必要があります。 Q4. SCS評価制度では脆弱性診断が必要ですか？ 対象となる要求事項や評価水準、対象システムによって必要性を判断します。特に外部公開システムや重要システムでは、Webアプリケーション診断やプラットフォーム診断などの技術検証が有効です。★4では第三者評価に加え、技術検証が制度上想定されています。 Q5. ISMSを取得している場合も同じですか？ ISMSもSCS評価制度と完全に同一ではありません。経済産業省の制度構築方針でも、SCS評価制度（★3・★4）とISMS適合性評価制度は目的・アプローチが異なるものとして整理されています。既存のISMS運用は有力な基盤になりますが、SCS要求事項との差分確認が必要です。 Q6. ★3と★4のどちらを目指すべきですか？ 取引先から求められる水準、扱う情報・システムの重要度、サプライチェーン上の役割を踏まえて判断します。高度な技術検証や第三者評価が求められる取引では★4が候補となります。 Q7. 何から始めればよいですか？ 最初に、取引先から求められている要求水準と対象範囲を確認し、既存のPマーク文書・情報セキュリティ規程・技術対策を棚卸しします。その後、SCS評価制度とのギャップ分析を行うと、優先順位が明確になります。 まとめ｜Pマークは有効な土台だが、SCS評価制度の代替ではない SCS評価制度とPマークは、どちらも企業の信頼性向上に役立つ制度ですが、目的は同じではありません。Pマークは個人情報保護マネジメントを中心に評価し、SCS評価制度はサプライチェーンを通じたサイバーリスクへの対応水準を評価します。 したがって、Pマーク取得企業でもSCS評価制度への追加対応が必要になる可能性があります。ただし、すでに整備している規程、教育、内部監査、委託先管理、事故対応などは大きな資産です。既存体制を活かして差分だけを整備することが、コストとスピードの両面で合理的です。 重要なのは、認証やマークの数を増やすことではなく、自社の取引先・事業・システムに対して必要なセキュリティ対策を説明でき、実際に運用できる状態を作ることです。 SCS評価制度と既存認証の整理からご相談いただけます 「Pマークを取得しているが、SCS評価制度で何を追加すべきか分からない」「★3と★4のどちらを目指すべきか判断できない」「取引先から質問される前に準備しておきたい」といった段階でもご相談いただけます。 Librus株式会社では、既存のPマーク・ISMS等の規程や証跡を確認し、SCS評価制度とのギャップを整理したうえで、必要な技術対策、脆弱性診断、改善計画、社内説明まで支援します。対象範囲や実施方法が決まっていない場合でも、取引上の重要度と現在のセキュリティ体制から優先順位を整理することで、過剰な投資を避けながら実務的な準備を進められます。 出典・参考情報 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 JIPDEC「プライバシーマークとは」：https://privacymark.jp/system/about/index.html JIPDEC「制度の概要」：https://privacymark.jp/system/about/outline_and_purpose.html 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」：https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度とISMSの違いとは？取得済み企業も対応が必要な理由

SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）への対応を検討する企業から、特に多く出てくるのが「すでにISMS（ISO/IEC 27001）を取得していれば、SCS評価制度への対応は不要なのか」という疑問です。 結論からいえば、ISMSを取得済みであっても、SCS評価制度への対応が別途必要になる可能性があります。両者には共通する管理領域がある一方、制度の目的、評価方法、技術検証の有無、取引先との関係が異なるためです。ISMS認証はSCS評価制度の取得を自動的に代替するものではありません。 ただし、ISMSで整備した情報資産管理、リスクアセスメント、アクセス管理、委託先管理、インシデント対応、教育などの仕組みは、SCS評価制度への準備で大きな土台になります。重要なのは「ゼロから作り直す」のではなく、既存のISMS運用とSCSの要求事項を突き合わせ、不足部分だけを具体的に補強することです。 本記事では、2026年10月14日時点の公表情報をもとに、SCS評価制度とISMSの違い、ISMS取得済み企業が確認すべきポイント、Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストとの関係、社内での進め方まで実務目線で解説します。 この記事で分かること SCS評価制度とISMS（ISO/IEC 27001）の目的・評価方法の違い ISMS取得済み企業でもSCS評価制度への対応が必要になり得る理由 既存のISMS文書・運用をSCS対応へ活用する方法 ★3・★4で求められる評価と技術検証の考え方 対応プロジェクトの進め方、費用・期間を左右する要因、ベンダー選定のポイント SCS評価制度とは何か SCS評価制度は、サプライチェーンを構成する企業等のセキュリティ対策状況を共通の基準で可視化し、発注元と委託先の双方がセキュリティ水準を確認しやすくするための制度です。経済産業省と内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、IPAが制度運営を担います。 IPAによると、★3は一般的なサイバー脅威に対処し得る水準、★4は初期侵入の防御だけでなく、侵入後の被害拡大防止や取引先のデータ・システム保護、サプライチェーン上の役割に応じた強靭化まで含む水準として整理されています。★3・★4は2027年3月頃の運用開始が予定されています。 出典：IPA「SCS評価制度の詳細情報」「よくある質問」 https://www.ipa.go.jp/security/scs/details.html https://www.ipa.go.jp/security/scs/faq.html ★3は専門家確認付きの自己評価 ★3では、企業が要求事項・評価基準に沿って自己評価を行い、SCS評価制度の要件を満たしたセキュリティ専門家による確認・助言を受けます。そのうえで経営層による自己適合宣誓を含む評価結果を事務局へ提出し、問題がなければ台帳へ登録・公表される流れです。単なる社内チェックではなく、専門家確認と経営層の関与が組み込まれている点が特徴です。 ★4は第三者評価と技術検証が加わる ★4では、評価機関による第三者評価に加え、文書確認、実地審査、技術検証が行われます。IPAは技術検証事業者の主な対象として、脆弱性診断やペネトレーションテストを提供する法人を挙げています。つまり、規程や証跡が整っていることだけでなく、実際のIT環境に技術的な弱点が残っていないかを確認する考え方がより明確です。 出典：IPA「指定申請について（評価機関・技術検証事業者・研修事業者向け）」 https://www.ipa.go.jp/security/scs/security-experts-organization/shiteishinsei.html ISMS（ISO/IEC 27001）とは何か ISMSはInformation Security Management Systemの略で、情報セキュリティを組織として継続的に管理するための仕組みです。ISO/IEC 27001は、そのISMSに対する要求事項を定めた国際規格です。日本ではJIS Q 27001として国際規格との整合が図られています。 ISMSでは、個別のセキュリティ製品を導入すること自体を目的とするのではなく、自社が保有する情報や事業上のリスクを評価し、必要な管理策を選び、責任者・ルール・運用・監視・改善のサイクルを組織として回すことが重視されます。ISMS-ACが認定した認証機関の審査を受け、要求事項への適合が認められることで認証を取得できます。 出典：情報マネジメントシステム認定センター（ISMS-AC）「ISMS適合性評価制度の概要」 https://isms.jp/isms/about.html SCS評価制度とISMSの違い 両者の最も大きな違いは、ISMSが「組織の情報セキュリティマネジメントの仕組み」を第三者が認証する制度であるのに対し、SCS評価制度は「サプライチェーンにおいて必要なサイバーセキュリティ対策の実施状況を可視化し、取引時の確認に活用しやすくする制度」である点です。 違い1：制度の目的 ISMSは、自社のリスクに基づいて情報セキュリティを継続的に管理し、マネジメントシステムとして機能させることを重視します。一方、SCS評価制度は、委託元から見て委託先の対策状況が分かりにくいことや、委託先が複数の取引先から異なるチェック項目を求められる負担を軽減することを背景に設計されています。 そのため、SCS評価制度は取引先管理、調達、外部委託、サプライチェーンリスクの文脈で利用される可能性が高い制度です。法律上の一律義務というより、発注条件や取引継続の判断材料として求められるケースに備える視点が重要になります。 違い2：評価の考え方 ISMSは、自社の事業環境、情報資産、脅威、脆弱性を踏まえてリスクを評価し、必要な管理策を選択して運用するリスクベースのアプローチです。これに対しSCS評価制度では、★3・★4ごとに要求事項・評価基準が用意され、取得にはそれぞれ定められた要求事項・評価基準を満たす必要があります。 したがって、「ISMSの審査で問題がなかったから、SCSでもそのまま適合する」とは限りません。逆に、ISMSで適切に運用できている領域については、SCS評価の根拠資料や証跡として活用できる可能性があります。 違い3：技術検証の位置付け ISMS審査では、マネジメントシステムが適切に構築・運用されているかが中心となります。技術的な脆弱性診断を毎回必須とする制度ではありません。 一方、SCS評価制度の★4では技術検証が明示されています。対象のIT基盤やシステムの構成によっては、Webアプリケーション診断、プラットフォーム診断、脆弱性診断、ペネトレーションテストなどを通じて、設定不備や既知の脆弱性、認証・権限管理上の問題、攻撃経路を確認することが重要になります。 例えば、ISMS上は「脆弱性管理の手順」が整備されていても、実際の公開サーバーに重大な既知脆弱性が残っている、管理画面がインターネットへ露出している、クラウドのアクセス制御に過剰権限がある、といった状態は別問題です。SCS対応では、管理プロセスと実際の技術状態の両方を見る必要があります。 違い4：取引先への説明材料としての使われ方 ISMS認証はすでに多くの企業で、委託先選定やセキュリティチェック時の信頼性を示す材料として利用されています。SCS評価制度はさらに、サプライチェーン上で求めるセキュリティ水準を共通化し、発注時等に対策状況を確認しやすくする目的を持っています。 今後、顧客企業が「重要な業務委託先には★3以上」「特に重要なシステムやデータを扱う委託先には★4」といった社内調達基準を設ける可能性があります。自社がISMS認証を取得していても、取引先がSCSの★取得を条件として設定すれば、別途対応が必要になります。 ISMS取得済み企業もSCS評価制度への対応が必要？ はい、必要になる可能性があります。特に、大企業や重要インフラ企業の取引先、顧客情報・機密情報を預かる事業者、クラウド・システム運用を担う事業者、製造業のサプライヤー、BPO・ITサービス事業者は、取引先から具体的な水準を求められる可能性を想定して準備しておくことが合理的です。 ただし、ISMS取得済み企業には大きな優位性があります。規程、情報資産台帳、リスクアセスメント、教育記録、委託先管理、アクセス管理、インシデント対応手順、内部監査、経営レビューなど、SCS対応に関連する文書や運用実績がすでに存在するためです。 したがって実務では、「ISMSとは別の制度だから全部作り直す」のではなく、SCS要求事項と既存ISMSの管理策・証跡をマッピングし、差分を埋める方法が効率的です。 ISMS取得済み企業が最初に確認すべき5つのポイント 1．ISMSの認証範囲とSCSで想定する対象範囲が一致しているか ISMS認証は、組織全体ではなく特定の部門・拠点・サービスを認証範囲としている場合があります。SCS評価制度で顧客から求められる対象が、ISMSの認証範囲外にあるシステムや子会社、拠点、クラウド環境であれば、既存認証だけでは十分な説明になりません。 最初に、取引先へ提供しているサービス、保存・処理している情報、利用しているシステム、外部委託先、ネットワーク境界を整理し、どこをSCS対応の対象とするかを明確にします。 2．規程だけでなく運用証跡が残っているか 規程が存在していても、アカウント棚卸しの記録、パッチ適用履歴、教育受講記録、インシデント訓練記録、バックアップ復元試験結果などが残っていなければ、実際に運用されていることを説明しにくくなります。 SCS対応を見据えるなら、既存のISMS運用を「監査で見せるための文書」ではなく、「現場で実施し、証跡を残す仕組み」として再確認することが重要です。 3．実システムの脆弱性を把握できているか 情報システム部門は、インターネット公開資産、Webアプリケーション、サーバー、ネットワーク機器、クラウド環境を一覧化し、脆弱性管理の対象漏れがないか確認します。 Webアプリケーションでは認証回避、アクセス制御不備、SQLインジェクション、クロスサイトスクリプティングなど、プラットフォームでは古いミドルウェア、不要ポート、脆弱な暗号設定、管理インターフェースの露出などが代表的な確認対象です。重要度の高い環境では、単純なスキャンだけでなく、攻撃者の視点で侵入可能性や横展開を確認するペネトレーションテストが有効な場合があります。 4．委託先・再委託先まで管理できているか サプライチェーンリスクは、自社だけで完結しません。クラウド事業者、開発会社、運用保守会社、コールセンター、物流会社など、自社の事業継続や機密情報に影響する委託先を整理し、契約上のセキュリティ要求、事故報告、再委託、アクセス権限、データ返却・消去などの管理状況を確認します。 5．経営層がリスクと投資判断に関与できているか SCS評価制度の★3では経営層による自己適合宣誓が想定されています。セキュリティを情報システム部門だけの作業にせず、どの取引を守るのか、どこまで投資するのか、未対応リスクを受容するのかを経営判断として整理する必要があります。 SCS評価制度への対応を進める具体的な手順 ステップ1：取引先から求められる水準を確認する まず、主要顧客や親会社、調達部門からSCS評価制度に関する要求が出ているかを確認します。現時点で明示されていなくても、取引更新、入札、監査、セキュリティチェックシート改定のタイミングで要求が追加される可能性があります。売上依存度や契約上の重要性を踏まえ、優先順位を付けます。 ステップ2：既存ISMSとSCS要求事項をマッピングする 情報セキュリティ方針、リスクアセスメント、適用宣言書、情報資産台帳、組織体制、教育記録、委託先管理、アクセス管理、ログ管理、バックアップ、脆弱性管理、インシデント対応、事業継続関連資料などを収集し、SCS要求事項との対応関係を整理します。 ここで「対応済み」「一部対応」「未対応」「証跡不足」に分類すると、追加対策の全体像が見えやすくなります。 ステップ3：技術面の現状を確認する 文書確認と並行して、IT資産の棚卸し、外部公開資産の確認、脆弱性診断などを実施します。対象範囲が広い企業では、全システムを一度に診断するのではなく、顧客データを扱う環境、インターネット公開システム、特権アクセスが集中する基盤など、リスクの高い領域から着手すると現実的です。 ステップ4：ギャップをリスクベースで改善する 未対応項目をすべて同じ優先度で処理すると、費用も期間も膨らみます。外部から侵入される可能性、扱う情報の重要性、事業停止時の影響、取引先への波及、是正コストを踏まえて優先順位を付けます。 例えば、インターネット公開システムの重大な脆弱性、特権IDの多要素認証未導入、バックアップからの復旧不能、インシデント時の連絡体制不備などは、単なる文書体裁より優先度が高くなることがあります。 ステップ5：評価に備えて証跡を整える 改善後は、規程だけでなく実施証跡を揃えます。成果物としては、対象範囲一覧、要求事項対応表、ギャップ分析結果、改善計画、診断報告書、是正記録、教育実績、インシデント対応訓練記録、経営層への報告資料などを整理しておくと、評価対応が進めやすくなります。 期間と費用を左右する要因 SCS評価制度への対応期間や費用は、企業規模だけでは決まりません。既存のISMS成熟度、対象範囲、拠点数、システム数、クラウド利用状況、外部公開資産、委託先数、必要な技術診断、現状の証跡整備状況などで大きく変わります。 ISMS取得済みで運用が定着している企業は、文書整備の工数を抑えやすい一方、技術検証で重大な課題が見つかれば、改修費や再診断費用が発生します。また、複数事業を一括で対象にするか、主要サービスから段階的に対象化するかでもプロジェクト規模は変わります。 社内稟議では「制度取得費用」だけを説明するのではなく、重要顧客との取引継続、入札要件への対応、委託先監査への回答工数削減、セキュリティ事故による事業停止リスクの低減といった事業上の目的を合わせて示すと、投資判断につながりやすくなります。 SCS評価制度の支援会社を選ぶポイント 支援会社を選ぶ際は、規程作成だけを行う会社か、技術診断だけを行う会社かではなく、制度要求と技術対策を横断して支援できるかを確認することが重要です。 RFPや見積依頼では、SCS要求事項とのギャップ分析、既存ISMS文書の活用範囲、対象範囲の決定支援、脆弱性診断・ペネトレーションテストの実施可否、改善計画の作成、再診断、証跡整備、経営層向け報告まで、どこまで含まれるのかを確認します。 また、診断で個人情報や機密情報に触れる可能性がある場合は、データの保存場所、アクセス権限、再委託、報告書の保管・廃棄、インシデント発生時の連絡方法について契約前に確認しておく必要があります。 よくある失敗と注意点 「ISMSがあるから大丈夫」と判断して差分確認をしない 最も避けたいのは、ISMS認証をSCS適合の証明と同一視することです。重複する領域は多くても、SCS独自の要求や技術検証を確認しなければ不足を見落とします。 評価直前に診断を実施し、改修期間が取れない 脆弱性診断で重大な問題が見つかる可能性を考えると、評価直前ではなく早めに技術確認を行う方が安全です。改修、テスト、再診断までを含めて計画します。 情報システム部門だけで進める 契約、調達、委託先管理、教育、事業継続、経営判断は複数部門にまたがります。管理部門、法務、調達、営業、事業部門、経営層を早期に巻き込むことで、後戻りを減らせます。 Librus株式会社が提供できるSCS評価制度対応支援 Librus株式会社では、SCS評価制度への対応を、チェックリストの作成だけで終わらせず、現状分析、技術検証、改善、運用まで一気通貫で支援します。 ISMS取得済み企業に対しては、既存の規程・リスクアセスメント・運用証跡を活かしながらSCS要求事項とのギャップを整理し、追加対応が必要な領域を明確化します。ISMSを未取得の企業についても、SCS取得に必要な体制・ルール・技術対策を企業規模や取引状況に応じて設計できます。 技術面では、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習などを組み合わせ、制度上の要求と実システムのリスクを結び付けて確認します。診断で課題が見つかった場合も、優先順位付け、改善方針、再診断、継続運用まで支援可能です。 さらに、経営層向けのリスク整理、情報システム部門と現場部門の役割整理、取引先監査への対応、SOC／CSIRT構築・運用支援、インシデントレスポンス、教育・訓練など、SCS評価制度の取得後を見据えた運用設計にも対応します。 よくある質問 Q1．ISMSを取得していればSCS評価制度の★3・★4も取得済み扱いになりますか？ いいえ。ISMS認証とSCS評価制度は別の制度です。ISMS取得済みであっても、SCSの要求事項・評価基準に沿った評価・申請が必要です。ただし、既存のISMS文書や運用証跡を活用できる領域は多くあります。 Q2．SCS評価制度に対応するためにISMSを取得する必要がありますか？ SCS評価制度の取得要件として、企業がISMS認証を事前取得しなければならないとは公表されていません。SCSの要求事項に適合する体制と対策を整備することが重要です。 Q3．ISMSとSCS評価制度はどちらを優先すべきですか？ 取引先要求と自社の経営目的によって異なります。取引先からSCSの★取得を求められる可能性が高い場合はSCS対応を優先しつつ、中長期的な情報セキュリティ管理の基盤としてISMSを活用する方法も考えられます。すでにISMS取得済みであれば、その仕組みをSCS対応の土台として利用するのが効率的です。 Q4．★4では脆弱性診断やペネトレーションテストが必須ですか？ ★4では技術検証が制度上明示されています。具体的な検証内容は対象環境や評価手順に従って決まります。IPAは技術検証事業者の業務として脆弱性診断を挙げており、対象によってはWebアプリケーション診断、プラットフォーム診断、ペネトレーションテスト等が関連します。 Q5．★3を取得してからでないと★4を取得できませんか？ いいえ。IPAは、上位段階が下位段階の事項を包含するものの、★3を事前取得していなければ★4を取得できない関係ではないと説明しています。自社の取引上の必要性と現状のセキュリティ水準を踏まえて検討します。 Q6．SCS評価制度への対応はいつから始めるべきですか？ ★3・★4は2027年3月頃の運用開始が予定されています。対象範囲整理、ギャップ分析、技術診断、改修、証跡整備には一定の期間が必要になるため、主要取引先から要求される可能性がある企業は、制度開始前から現状確認を進めることが望ましいでしょう。 Q7．まだ★3と★4のどちらを目指すか決まっていなくても相談できますか？ 可能です。まず取引先から想定される要求、自社の事業・システム・情報の重要度、現状のISMS運用や技術対策を整理することで、どの水準を目指すべきか判断しやすくなります。 まとめ：ISMS取得済みでも、SCS評価制度は「差分確認」が必要 SCS評価制度とISMS（ISO/IEC 27001）は、いずれも企業の情報セキュリティ向上に役立つ仕組みですが、目的と評価方法は同じではありません。ISMSは情報セキュリティマネジメントシステムを継続的に運用する枠組みであり、SCS評価制度はサプライチェーンにおけるセキュリティ対策状況を共通基準で可視化し、取引時に活用しやすくする制度です。 そのため、ISMS認証を取得済みでもSCSへの対応が不要になるわけではありません。一方で、ISMSで蓄積した規程、リスクアセスメント、運用証跡、内部監査などは大きな資産です。既存の仕組みをSCS要求事項へマッピングし、技術面を含む不足箇所だけを補強することで、効率的な準備が可能になります。 特に重要なのは、制度取得だけを目的にせず、主要取引先との関係、事業継続、顧客データの保護、実際のシステムリスクまで含めて対応計画を作ることです。 SCS評価制度と既存ISMSの整理からご相談いただけます 「ISMSを取得しているが、SCS評価制度で何が追加になるのか分からない」「★3と★4のどちらを目指すべきか判断できない」「取引先から求められる前に準備しておきたい」といった段階でもご相談いただけます。 Librus株式会社では、既存のISMS文書・運用状況を確認したうえで、SCS要求事項とのギャップ、追加で必要な技術対策、脆弱性診断やペネトレーションテストの対象、改善優先順位を整理します。対象範囲や実施方法がまだ決まっていない場合でも、事業上の重要度や取引先との関係を踏まえて、過不足のない進め方を検討できます。 制度対応を単なる認証取得の作業にせず、取引先への説明力向上と実際のセキュリティ強化を同時に進めたい場合は、現状整理の段階からご相談ください。 参考・出典 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 IPA「指定申請について（評価機関・技術検証事業者・研修事業者向け）」：https://www.ipa.go.jp/security/scs/security-experts-organization/shiteishinsei.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を取得してください」と言われる前に準備すべきこと

取引先からSCS★3の取得を求められた時点で、社内体制や規程、IT資産、証跡を一から整理し始めると、対応期限に間に合わない可能性があります。サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3は、単に申請書へチェックを付ければ取得できる制度ではありません。要求事項・評価基準を満たす対策を実際に行い、その状況を説明できる証拠をそろえ、セキュリティ専門家の確認を受けたうえで、経営層が自己適合を宣誓する仕組みです。 結論からいえば、取引先から正式な要請が来る前に着手すべきなのは「申請作業」ではなく、①適用範囲の整理、②IT資産とアカウントの棚卸し、③規程・運用・証跡の整備、④脆弱性や設定不備の是正、⑤インシデント対応とバックアップの実効性確認、⑥経営層を含む推進体制の構築です。これらはSCS★3への準備であると同時に、日常のサイバーリスク低減にもつながります。 SCS評価制度は2027年3月頃の★3・★4運用開始が予定されています。制度自体は任意ですが、委託元が取引契約等で委託先に必要な★を提示し、その対策状況を確認する利用が想定されています。そのため、法令上の義務ではなくても、取引継続・新規受注・調達要件の観点で対応が必要になる企業は今後増える可能性があります。 出典：IPA「SCS評価制度」 https://www.ipa.go.jp/security/scs/index.html 出典：IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html この記事で分かること SCS★3が取引先との関係でどのように使われる可能性があるか 正式な取得要請を受ける前に準備しておくべき項目 経営層・情報システム部門・現場部門それぞれの役割 規程だけでなく、運用証跡や技術対策まで必要になる理由 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストをどの場面で活用するか 社内稟議、予算化、外部支援会社の選定で確認すべきポイント SCS評価制度とSCS★3の基本を押さえる SCS評価制度はサプライチェーンの対策状況を可視化する制度 SCS評価制度は、委託元から見えにくい委託先のセキュリティ対策状況を共通の尺度で確認しやすくするとともに、委託先が複数の取引先から異なるチェックシートを求められる負担を軽減することを狙った制度です。IPAが制度を運営し、経済産業省と内閣官房国家サイバー統括室が監督する枠組みで構築されています。 対象は特定業種だけに限定されていません。IPAは全てのサプライチェーン企業を対象とし、とりわけ対策リソースが限られる中小企業にも活用効果が大きいとしています。従業員100～1,000名規模の企業では、取引先が大企業、重要インフラ事業者、製造業、金融業などである場合、自社が「委託先」「システム運用会社」「開発会社」「業務受託会社」などの立場で要求を受ける場面を想定しておくべきでしょう。 出典：IPA「SCS評価制度」 https://www.ipa.go.jp/security/scs/index.html ★3は「一般的なサイバー脅威に対処しうる水準」 ★3は、広く認知された脆弱性などを悪用する一般的なサイバー攻撃に対処しうることを水準としており、基礎的な組織対策とシステム防御策を中心に、サプライチェーン企業が最低限実装すべき対策として位置付けられています。★4はこれより広く、組織ガバナンス、取引先管理、検知、インシデント対応などを含む包括的な水準です。 ★3の評価方法は「専門家確認付き自己評価」です。取得希望組織が自己評価を行い、登録されたセキュリティ専門家が内容を確認・助言し、経営層の自己適合宣誓を含む評価結果を事務局へ提出します。IPAのFAQでは、★3取得には定められた全ての要求事項・評価基準を満たす必要があると示されています。したがって、「大部分はできているから申請する」というより、不足項目を事前に洗い出し、運用まで定着させる準備が重要です。 出典：IPA「よくある質問」 https://www.ipa.go.jp/security/scs/faq.html なぜ「取引先に言われてから」では遅れやすいのか 規程作成よりも、実際の運用と証跡づくりに時間がかかる セキュリティ評価では、方針や規程が存在することと、実際に運用されていることは別問題です。たとえばアカウント管理規程を作成していても、退職者アカウントが残っている、管理者権限の棚卸し履歴がない、アクセス権の承認記録を保存していないといった状態では、運用実態を説明しにくくなります。 同様に、バックアップを「実施している」だけでは、復元できるか、ランサムウェア感染時にも利用できるか、担当者不在でも復旧手順を実行できるかという実効性までは確認できません。取得要請を受けてから数週間で、規程・設定・記録・教育・訓練を同時に整備するのは現実的でない場合があります。 部門横断での調整が必要になる SCS★3準備を情報システム部門だけの仕事と考えると、途中で止まりやすくなります。人事部門は入退社や異動に伴う権限管理、総務・法務は委託契約や機密情報管理、購買部門は外部委託先の管理、経営層は方針と予算、人員配置に関与します。クラウドサービスを各部門が独自契約している企業では、SaaSの棚卸しだけでも時間を要します。 取引先から「1～2か月以内に取得方針を回答してほしい」といった相談が来たとき、社内責任者や対象範囲が決まっていなければ、技術対策以前に意思決定で時間を消費します。事前準備の価値は、対策そのものだけでなく、社内の判断速度を上げる点にもあります。 対応が遅れた場合に起こり得る経営上の問題 SCS評価制度自体は任意の制度であり、★3を取得していないことだけを理由に法律違反になるものではありません。一方、経済産業省のFAQでは、★の取得は委託元または委託先との取引契約で決められるものとされています。つまり、実務上重要なのは「制度上の義務か」だけではなく、「自社の主要顧客が調達条件として何を求めるか」です。 出典：経済産業省「SCS評価制度に関するよくあるお問い合わせ」 https://www.meti.go.jp/press/2025/03/20260327001/20260327001-gr.pdf 取得や準備が間に合わなければ、取引先から追加のセキュリティ説明を求められたり、是正計画の提出、契約条件の見直し、競合企業との比較で不利になる可能性があります。特に自社が顧客データを預かる、基幹システムへ接続する、システム開発・保守を担う、製造ラインや物流を支えるといった役割を持つ場合、サイバー事故は自社だけでなく取引先の事業継続に影響します。 経営層はSCS★3を「認証を取るためのコスト」とだけ捉えず、売上維持、調達要件への対応、信用毀損リスクの低減、事故時の復旧力向上に関係する経営課題として判断することが重要です。 取引先からSCS★3を求められる前に準備すべき7項目 1．適用範囲と重要業務を先に整理する 最初に決めるべきなのは、どの会社・拠点・業務・IT基盤を対象にするかです。対象範囲が曖昧なまま規程や診断を始めると、後から対象システムが増え、見積りやスケジュールが崩れます。主要取引先へ提供している業務、預かっている情報、外部接続、クラウド利用、重要な拠点を整理し、「停止すると取引先に影響する業務」から優先順位を付けます。 経営層は、主要顧客・売上・事業継続の観点から対象範囲を判断し、情報システム部門は対象に含まれるサーバ、ネットワーク、クラウド、端末、アプリケーションを具体化します。 2．IT資産・アカウント・外部公開資産を棚卸しする セキュリティ対策は、守る対象が分からなければ設計できません。PCやサーバだけでなく、VPN装置、ファイアウォール、ルーター、クラウド環境、SaaS、ドメイン、Webサイト、管理画面、開発環境、外部委託先が管理するシステムも含めて整理します。 特に見落としやすいのが、過去案件で作成したテスト環境、利用者の少ない管理画面、旧VPN装置、退職者や委託先のアカウントです。攻撃者は「重要な本番システム」だけを狙うとは限りません。古い機器や公開設定の不備を侵入口として利用し、内部へ移動するケースを想定する必要があります。 3．規程と運用証跡をセットで整備する 情報セキュリティ基本方針、アカウント管理、端末管理、脆弱性管理、バックアップ、ログ管理、インシデント対応、委託先管理などのルールは、実態に合わせて整備します。既存のISMS規程や社内規程がある企業は、ゼロから作り直すのではなく、SCS★3の要求事項との対応関係を確認する方が効率的です。 同時に、アカウント棚卸し記録、パッチ適用記録、教育受講記録、インシデント訓練記録、バックアップ確認記録、外部委託先の確認記録など、実施を示せる証跡を残す運用へ変えます。「やっているが記録がない」は、評価時の説明負担を増やします。 4．脆弱性と設定不備を把握し、優先順位を付けて是正する インターネットからアクセス可能なシステムや重要システムは、設定ミスや既知の脆弱性が放置されていないか確認します。プラットフォーム診断では、サーバ、ネットワーク機器、OS、ミドルウェアなどの脆弱性や不要ポート、危険な設定を確認できます。Webアプリケーション診断では、認証・認可、入力値処理、セッション管理など、Web固有の問題を確認します。 なお、★3の評価スキームは書類確認を中心とする専門家確認付き自己評価であり、★4のような第三者による技術検証そのものが評価スキームとして必須とされているわけではありません。それでも、自社の実装状況を客観的に把握し、重大な弱点を申請前に解消する目的で脆弱性診断を活用する価値があります。ペネトレーションテストは、個別の脆弱性だけでなく、複数の弱点を組み合わせた侵入可能性や影響を検証したい場合に有効です。 出典：IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html 5．インシデント対応とバックアップを「使える状態」にする ランサムウェア感染、不正アクセス、情報漏えいなどが発生した際の連絡先、初動責任者、判断基準、取引先への報告経路、外部専門会社への連絡方法を決めておきます。文書を作るだけでなく、机上訓練を行い、「休日に検知した場合」「担当者が不在の場合」などを想定すると実効性を確認できます。 バックアップについては、取得頻度、保存先、世代数、アクセス権、復元手順を確認し、定期的な復元テストを行います。攻撃者が本番環境と同じ権限でバックアップまで削除できる構成では、復旧手段として十分とはいえません。事業継続の観点から、重要システムごとに許容停止時間や復旧優先順位も整理しておくと、経営判断につながりやすくなります。 6．従業員教育と委託先管理を定常業務にする フィッシングメール、パスワードの使い回し、クラウド共有設定の誤りなど、人の行動を起点とするリスクは技術製品だけでは抑えられません。入社時教育だけでなく、定期教育、注意喚起、標的型メール訓練などを組み合わせ、受講記録も残します。 また、自社が再委託やクラウドサービスを利用している場合、自社だけの対策でサプライチェーンリスクを完結させることはできません。契約時のセキュリティ確認、アクセス権付与、事故時の連絡義務、契約終了時のデータ返却・削除など、外部委託先管理を購買・法務・情報システム部門で連携して運用する必要があります。 7．経営層が「取得方針・予算・責任者」を決める ★3では経営層による自己適合宣誓が評価プロセスに含まれます。したがって、情報システム担当者が最後に社長印をもらうだけのプロジェクトではありません。どの取引を守るために取得するのか、どの範囲を対象にするのか、是正にどこまで予算を使うのか、残るリスクを誰が受容するのかを経営レベルで判断する必要があります。 推進責任者を定め、情報システム、人事、総務・法務、購買、事業部門を含む体制を作っておくと、正式な取得要請を受けた後の意思決定が速くなります。 実施前に準備しておきたい資料 外部のセキュリティ専門家やコンサルティング会社へ相談する場合、最初から全資料を完璧にそろえる必要はありません。ただし、以下の情報があると現状把握と見積りが進みやすくなります。 会社・拠点・主要業務の概要と組織図 主要取引先との業務内容、預かる情報、接続関係 ネットワーク構成図、システム構成図、クラウド利用一覧 サーバ・端末・ネットワーク機器・SaaS等の資産一覧 既存の情報セキュリティ規程、ISMS文書、社内ルール アカウント管理、パッチ適用、バックアップ、ログ管理等の運用記録 過去の脆弱性診断・監査・セキュリティチェックシートの結果 インシデント対応手順、緊急連絡網、訓練記録 外部委託先・再委託先・主要クラウドサービスの一覧 資料が存在しない場合も、それ自体が現状把握の結果です。まず「何がないか」を明らかにし、要求事項とのギャップを優先順位順に埋めていく方が、形式的な文書を急いで大量に作るより有効です。 SCS★3取得までの進め方 ステップ1：現状評価とギャップ分析 IPAが公開する★3・★4要求事項・評価基準を基準に、自社の対策状況を確認します。各項目について「規程あり／運用あり／証跡あり」を分けて見ると、文書不足と実装不足を混同せずに整理できます。取得には全ての要求事項・評価基準への適合が求められるため、未対応項目を一覧化し、担当者と期限を決めます。 出典：IPA「要求事項・評価基準」 https://www.ipa.go.jp/security/scs/requirements-criteria.html ステップ2：是正計画と予算化 ギャップを、短期間で直せる項目、システム改修が必要な項目、社内ルール変更が必要な項目に分類します。緊急度は「攻撃されやすさ」だけでなく、漏えい時の影響、取引先への影響、復旧難易度も含めて判断します。MFA導入、古いVPN機器の更新、EDR導入、バックアップ分離、ログ保存基盤の整備などは費用や調整を要するため、早期に予算化することが重要です。 ステップ3：運用定着と証跡蓄積 是正した対策は、実施して終わりではありません。月次のアカウント棚卸し、定期的なパッチ管理、教育、バックアップ確認など、継続運用に組み込みます。担当者依存を避け、異動後も同じ水準で運用できるよう、手順と責任分担を明確にします。 ステップ4：自己評価とセキュリティ専門家による確認 ★3では、取得希望組織が要求事項・評価基準に沿って自己評価を記入し、SCS評価制度のセキュリティ専門家が内容を確認します。専門家は必要に応じて評価結果の修正を含む助言を行い、提出内容を了承した場合に署名します。制度上のセキュリティ専門家には資格・研修等の要件が定められているため、依頼先を選ぶ際は「一般的なセキュリティ資格者」ではなく、制度上登録された専門家かを確認する必要があります。 ステップ5：経営層の自己適合宣誓と申請 専門家確認後、経営層による自己適合宣誓を含む評価結果を事務局へ提出し、申請内容に問題がなければ台帳へ登録・公開される流れが示されています。運用開始時の申請方法、様式、料金などはIPAの最新案内を必ず確認してください。制度の詳細は運用開始に向けて更新される可能性があるため、古い資料だけで申請準備を完結させないことが重要です。 準備期間と費用を左右する要因 SCS★3準備に必要な期間は、従業員数だけでは決まりません。同じ300名規模でも、単一拠点でSaaS中心の企業と、複数拠点・オンプレミス・製造設備・多数の外部委託先を持つ企業では作業量が大きく異なります。 期間を左右する主な要因は、対象範囲の広さ、IT資産台帳の整備状況、既存規程の有無、ISMS等の既存認証、未是正の脆弱性、クラウド・SaaSの数、外部委託先の数、経営会議や稟議の頻度です。特に機器更改やシステム改修が必要になる場合は、調達期間を含めて計画する必要があります。 費用についても、制度への申請・登録に関する公的な料金だけでなく、専門家確認、コンサルティング、規程整備、脆弱性診断、製品導入、システム改修、教育・訓練などが発生し得ます。見積りでは「★3取得支援一式」という総額だけを見るのではなく、何が含まれるかを分解して確認しましょう。 社内稟議で説明すべきポイント 稟議では「SCS★3取得が必要だから費用がかかる」という説明だけでは、優先順位を上げにくいことがあります。経営者や財務部門には、①主要取引先から将来要求される可能性、②取得準備が遅れた場合の受注・更新への影響、③既存のセキュリティ課題も同時に改善できること、④事故時の停止・漏えい・復旧コストの低減につながること、⑤今回の投資が次回評価や他社チェックシートにも再利用できることを整理して説明すると判断しやすくなります。 また、取得期限が確定していない段階でも「現状評価だけ先に行い、改修費用はギャップ確認後に段階承認する」という進め方が可能です。最初から大規模投資を決裁するのではなく、フェーズを分けることで予算化の不確実性を下げられます。 支援会社を選ぶ際のチェックポイント SCS★3の支援会社を選ぶ際は、制度説明だけでなく、要求事項を実際のシステム・運用へ落とし込めるかを確認します。RFPや見積依頼では、現状評価、適用範囲設定、規程整備、技術対策、診断、証跡整備、専門家確認前のレビュー、取得後の運用支援のうち、どこまで対応するかを明示すると比較しやすくなります。 また、診断会社とコンサルティング会社を別々に利用する場合、診断結果が「脆弱性一覧」のままで終わり、SCS要求事項や経営リスクとの関係が整理されないことがあります。技術的な問題を、業務影響、是正優先度、必要予算まで翻訳できる支援会社を選ぶと、社内調整が進みやすくなります。 個人情報や機密情報を外部へ共有する可能性もあるため、秘密保持、データ保管場所、アクセス権、再委託、作業終了後のデータ削除、事故時の連絡体制も契約前に確認してください。 よくある失敗と注意点 取得直前に規程だけ大量に作る 規程を整えることは重要ですが、現場で運用できないルールを増やすと、評価後に形骸化します。現在の業務フローを確認し、実施可能な頻度・責任者・記録方法まで決めることが重要です。 対象範囲を広げすぎる、または狭めすぎる 全社の全システムを無条件で対象にすると負担が膨らみます。一方、取引先に影響する重要システムを外すと、取得の目的と合わなくなります。取引関係、情報、接続、業務継続への影響から対象範囲を説明できるようにします。 脆弱性診断を実施して満足する 診断は課題発見の手段です。重要なのは、発見事項をリスクに応じて是正し、再診断や設定確認で改善を確かめ、再発防止の運用へつなげることです。特に「高リスク」と判定された問題は、システム所有部門と経営層で対応期限を合意しておくと放置を防げます。 Librus株式会社が支援できること Librus株式会社では、SCS評価制度への対応を「申請書作成だけのプロジェクト」とせず、現状評価から技術対策、改善、運用まで一気通貫で支援します。企業ごとの業務、IT環境、主要取引先との関係を確認したうえで、必要な範囲と優先順位を個別に設計します。 具体的には、SCS★3要求事項とのギャップ分析、対象範囲の整理、規程・運用・証跡の整備、Webアプリケーション診断、プラットフォーム診断、必要に応じたペネトレーションテスト、インシデント対応体制やSOC／CSIRTの構築・運用、セキュリティ教育などを組み合わせられます。診断結果を提示して終えるのではなく、改善策の優先順位付け、経営層への説明、実施後の再確認まで支援できる点が特徴です。 また、SCS評価制度への対応だけでなく、M&A、IPO、取引先監査などの経営上の重要局面を踏まえて、技術と経営の両面から課題を整理します。情報システム部門と経営層、現場部門の間で認識がずれている場合にも、共通の判断材料を作ることで意思決定を進めやすくします。 よくある質問 Q1．SCS★3は法律上、必ず取得しなければなりませんか？ いいえ。SCS評価制度自体は任意の制度です。ただし、委託元と委託先の取引契約で取得が求められる場合は、実務上の取引条件になる可能性があります。自社の主要顧客や業界でどのように利用されるかを確認することが重要です。 Q2．取引先からまだ何も言われていません。それでも準備する必要がありますか？ 全ての企業が直ちに取得プロジェクトを開始する必要はありません。ただし、主要顧客からセキュリティチェックシートを頻繁に求められる企業、顧客情報を預かる企業、顧客システムに接続する企業は、少なくとも現状評価とギャップ把握を先に行うメリットがあります。 Q3．ISMSを取得していればSCS★3は自動的に取得できますか？ 自動的に取得できるわけではありません。既存のISMS規程や運用はSCS対応に活用できる可能性がありますが、SCS★3の要求事項・評価基準に照らして不足がないかを個別に確認する必要があります。 Q4．SCS★3取得に脆弱性診断は必須ですか？ ★3は専門家確認付き自己評価であり、★4の評価スキームで行われる第三者の技術検証と同じ仕組みではありません。ただし、外部公開資産や重要システムの実装上の弱点を客観的に把握するため、Webアプリケーション診断やプラットフォーム診断を実施することは有効です。 Q5．ペネトレーションテストまで実施した方がよいですか？ 全ての企業で一律に必要とは限りません。重要システムへの侵入経路や、複数の弱点を組み合わせた場合の事業影響を検証したい場合には有効です。まず資産とリスクを整理し、目的に応じて診断方法を選ぶことが重要です。 Q6．取得準備は情報システム部門だけで進められますか？ 難しいケースが多いです。人事、総務・法務、購買、事業部門、経営層も関係します。特に入退社管理、外部委託、教育、インシデント時の顧客報告、予算判断は部門横断での対応が必要です。 Q7．取引先から急に取得を求められた場合、最初に何をすべきですか？ まず期限、求められている★、対象となる契約・業務、適用範囲を取引先と確認します。そのうえで要求事項に対する現状評価を行い、短期で是正できる項目とシステム改修が必要な項目を分け、現実的な対応計画を作ります。 Q8．取得後は何もしなくてよいですか？ いいえ。セキュリティ対策は継続運用が前提です。資産や脅威、取引先要件は変化するため、アカウント棚卸し、パッチ管理、教育、バックアップ確認、診断、インシデント訓練などを定期的に見直す必要があります。 まとめ｜SCS★3は「要請を受けてから」ではなく、平時の準備が重要 サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3は、一般的なサイバー脅威に対処しうる基礎的なセキュリティ水準を可視化する仕組みです。制度自体は任意でも、取引先が調達・契約上の要件として★取得を求める場面は想定されています。 そのため、正式な依頼を受ける前に、適用範囲、IT資産、規程、運用証跡、脆弱性、バックアップ、インシデント対応、教育、委託先管理、経営責任を整理しておくことが重要です。早めに現状を把握しておけば、取引先から要請を受けた際も、必要な追加対策と費用、スケジュールを具体的に説明できます。 SCS★3対応を「認証取得のためだけの作業」にせず、自社の事業継続と取引先からの信頼を強化する機会として活用することが、結果として最も実務的な進め方です。 SCS★3対応の準備段階からご相談いただけます Librus株式会社では、「自社がSCS★3の対象になりそうか分からない」「取引先から求められる前に現状だけ確認したい」「要求事項と自社規程の差分を整理したい」「技術対策がどこまで必要か判断できない」といった初期段階からご相談いただけます。 対象範囲や実施方法が決まっていない段階でも、主要取引先との関係、IT環境、既存のセキュリティ対策を確認し、優先順位を整理することで、過剰な対策や重複投資を避けながら現実的な準備計画を作ることが可能です。制度対応に加えて、脆弱性診断、ペネトレーションテスト、インシデント対応、SOC／CSIRT支援、教育などを必要に応じて組み合わせ、改善・運用まで一貫して支援します。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE