SCS評価制度とPマーク・SOC 2・業界ガイドラインの関係

サプライチェーン強化に向けたセキュリティ対策評価制度（以下「SCS評価制度」）への準備で、PマークやSOC 2を取得済みなら、最初から仕組みを作り直す必要はありません。ただし、既存認証を持っているだけでSCS評価制度の要求を自動的に満たすわけでもありません。制度ごとに目的、対象範囲、評価方法が異なるためです。 実務上の結論は、既存の規程や証跡を制度別に管理するのではなく、「要求事項―社内統制―証跡―責任者」の対応表を一つ作り、共通利用できるものと不足部分を切り分けることです。例えば、アクセス権申請、ログ監視、インシデント対応訓練、委託先評価の記録は複数制度で活用できます。一方、Webアプリケーション診断やプラットフォーム診断、ペネトレーションテストなど、技術的な有効性を裏付ける追加検証が必要になる場合があります。 本記事では、従業員100～1,000名程度の企業を想定し、SCS評価制度とPマーク、SOC 2、金融・医療等の業界ガイドラインをどう整理し、監査・取引先回答・経営報告に使える証跡体系へまとめるかを解説します。なお、制度の詳細は今後更新され得るため、申請時点のIPA公式資料を必ず確認してください。 この記事で分かること この記事を読むと、各制度の目的と守備範囲の違い、既存認証をSCS評価制度へ流用できる範囲、証跡の共通化手順、技術検証の組み込み方、社内稟議や外部支援会社の選定で確認すべき点が分かります。特に重要なのは、「認証を何個持っているか」ではなく、「必要な統制が対象範囲で実際に機能し、その事実を再現可能な証跡で説明できるか」という視点です。 SCS評価制度とは何か SCS評価制度は、取引先を含むサプライチェーン全体のセキュリティ対策を段階別に可視化し、発注者と受注者の間で共通言語として使うことを想定した制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが運営します。委託元が取引先に適切な段階を示し、対策の実施状況を確認する利用場面が想定されています。 IPAの公表情報では、★3は一般的なサイバー脅威に対処し得る水準で、専門家確認付き自己評価です。★4は、初期侵入の防御だけでなく、被害拡大や攻撃目的の遂行を抑え、取引先のデータ・システム保護や自社の役割に応じたサプライチェーン強靱化策まで含む水準で、第三者評価と技術検証が予定されています。★5は高度な攻撃を想定したリスクマネジメントとベストプラクティスを念頭に、今後さらに具体化される位置付けです。上位段階の申請に、下位段階の事前取得が必須という関係ではありません。★3・★4は2027年3月頃の運用開始が予定されています。 出典：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度」https://www.meti.go.jp/policy/netsecurity/scs.htmlIPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.htmlIPA「よくある質問」https://www.ipa.go.jp/security/scs/faq.html 評価対象は会社全体とは限らない SCS評価制度では、取得希望組織が適用範囲を決め、その中から対象をサンプリングして評価することが想定されています。したがって、最初に決めるべきなのは「全社で取るか」ではなく、どの取引、拠点、業務、システム、クラウドサービス、委託先を評価対象にするかです。重要顧客へ提供するサービスだけを狭く切り出すと準備負担は下がりますが、共通基盤や本社機能が範囲外になり、実態と説明が合わないことがあります。契約上の責任範囲、ネットワーク境界、データフロー、運用責任者を基準に決めることが重要です。 SCS評価制度とPマーク・SOC 2・業界ガイドラインの違い 複数制度は競合するものではなく、異なるリスクを異なる方法で確かめる仕組みです。Pマークを持つ企業がSCS評価制度にも対応し、クラウドサービスについてSOC 2報告書を顧客へ提示し、さらに金融・医療の業界要求を満たすことは矛盾しません。むしろ、目的の違いを理解せず、一つの認証で全要求を代替できると考えることが問題になります。 制度・基準主な目的主な対象評価・確認の特徴SCSとの関係SCS評価制度サプライチェーン上のサイバー対策を段階評価組織が定めた取引・業務・システム等★3は専門家確認付き自己評価、★4は第三者評価・技術検証を予定比較の中心。取引要請への共通言語Pマーク個人情報保護マネジメントシステムの構築・運用原則として国内事業者の法人単位JIS Q 15001に基づく運用指針への適合を審査規程、教育、委託先管理、事故対応等を部分流用SOC 2サービス組織の統制について利用者等へ保証を提供対象サービスと、その提供に関係するシステム・統制独立した監査人がTrust Services Criteriaに照らして報告アクセス管理、変更管理、ログ、可用性等の証跡を部分流用業界ガイドライン業種固有の法規制・リスクへの対応金融、医療、重要インフラ等の対象事業・システム監督指針、契約、監査等と結び付く場合があるSCSを土台に固有要求を追加する Pマークは個人情報保護が中心 プライバシーマーク制度は、JIS Q 15001に基づく個人情報保護マネジメントシステム（PMS）を整備し、実際の事業活動で個人情報を適切に取り扱う体制を評価します。付与単位は原則として法人です。個人情報の特定、リスク分析、教育、委託先管理、事故対応、内部監査、マネジメントレビュー等はSCS評価制度の準備にも役立ちます。 ただし、Pマークはサイバー攻撃への技術的耐性だけを評価する制度ではありません。脆弱性管理、境界防御、侵害拡大防止、検知・対応能力などについては、Pマークの運用証跡だけでは説明が不足する可能性があります。Pマーク取得済み企業ほど、PMS文書を無批判に転用するのではなく、情報資産の範囲を「個人情報」から「取引先の重要情報、設計情報、認証情報、業務継続に必要なシステム」へ広げる作業が必要です。 出典：プライバシーマーク制度「制度の概要」https://privacymark.jp/system/about/outline_and_purpose.html SOC 2は対象サービスの統制を説明する保証報告 SOC 2は、AICPAのTrust Services Criteriaを用いて、サービス組織のシステムに関する統制を独立した監査人が検証する枠組みです。セキュリティを共通基準とし、契約やサービス特性に応じて可用性、処理のインテグリティ、機密保持、プライバシーを扱います。Type 1は特定時点の統制設計、Type 2は一定期間にわたる運用状況を対象とする点も、単純な認証マークとは異なります。 SOC 2報告書が対象とするサービス、システム境界、除外事項、サブサービス組織、対象期間を確認しなければ、SCS評価制度への利用可否は判断できません。例えば、クラウドサービスAのSOC 2報告書は、同じ法人が運営する受託開発部門Bや国内拠点全体を当然にはカバーしません。一方で、ID管理、特権アクセス、変更管理、バックアップ、ログレビュー、インシデント管理などの統制記述と運用証跡は、有力な基礎資料になります。 出典：AICPA & CIMA「SOC 2 - SOC for Service Organizations」https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2 業界ガイドラインは業種固有の上乗せ要件 金融機関向けのFISC安全対策基準、医療情報システムの安全管理に関するガイドラインなどは、事業停止時の社会的影響、取り扱う情報の機微性、システム構成、監督上の要請を踏まえた具体性を持ちます。SCS評価制度を取得しても、業界固有の責任分界、外部委託、クラウド利用、非常時運用等の要求が消えるわけではありません。 例えば金融機関向けサービスでは、顧客の外部委託先管理やシステムリスク管理に耐える説明が必要です。医療分野では、医療機関とサービス提供者の責任分界、認証・認可、保守接続、バックアップ、証跡レビュー等を具体化します。SCS評価制度は共通基盤、業界ガイドラインは追加レイヤーと考えると整理しやすくなります。 出典：FISC「安全対策」https://www.fisc.or.jp/publication/pubcat/sm/厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html なぜ今、複数制度を一体管理すべきなのか 取引先ごとの質問票、Pマーク更新、SOC 2監査、業界別監査を別々の担当者と文書で回すと、同じアクセス権一覧や教育記録を何度も収集することになります。回答内容が制度ごとに食い違えば、統制そのものより説明の不整合が問題になります。さらに、営業が顧客へ回答した内容と、情報システム部門の実運用が一致しないまま契約上の保証となることもあります。 一体管理の目的は、監査工数の削減だけではありません。経営者が重要取引の継続条件を把握し、投資の優先順位を決められる状態をつくることです。取引先から★4を求められる可能性があるのに、翌年度予算へ技術検証やEDR、ログ保管、復旧訓練の費用を織り込んでいなければ、運用開始直前の対応は難しくなります。制度対応を営業継続、受注資格、BCPの課題として扱う必要があります。 対応しない場合に起こり得る問題 SCS評価制度への未対応が直ちに法令違反や一律の取引停止を意味するわけではありません。しかし、発注者が調達条件として一定段階を求めるようになれば、評価未取得や説明不足が新規取引、契約更新、委託範囲の判断に影響する可能性があります。特に、自社が大企業の業務システムを運用する、機密設計情報を扱う、顧客ネットワークへ接続する、再委託先を多数利用するといった場合は優先度が高まります。 攻撃面では、VPN機器や公開サーバーの脆弱性から侵入され、認証情報を窃取され、委託元環境への接続口を踏み台にされるケースが考えられます。メールアカウント侵害による取引情報の流出、ランサムウェアによる納品停止、開発環境への侵入によるソースコード改ざんも、サプライチェーン上の影響が大きい事象です。Pマークの教育記録やSOC 2報告書があっても、未修正の公開脆弱性や過大な特権が残っていれば実害は防げません。 証跡と統制を共通利用する7つの手順 1．経営が目標段階と対象取引を決める 最初に、主要顧客の調達方針、扱う情報、停止時の売上影響、代替困難性を踏まえ、目標とする★と期限を仮決定します。経営会議では、認証取得費だけでなく、改善投資、運用人員、維持費を含めて判断します。顧客要請が未確定なら、売上上位顧客、重要インフラ関連、機密情報を扱う業務から優先順位を付けます。 2．適用範囲と責任分界を図にする 組織図だけでは不十分です。業務プロセス、情報の流れ、利用SaaS、クラウド、ネットワーク、拠点、再委託先、保守会社を一枚の構成図と台帳にします。自社が実施する統制、クラウド事業者に依存する統制、顧客側の責任を分けることで、証跡の所在が明確になります。 3．制度横断のコントロールマトリクスを作る 各制度の要求をそのまま横に並べるのではなく、アクセス管理、脆弱性管理、ログ監視、インシデント対応、事業継続、委託先管理、教育などの統制テーマへ正規化します。行には統制、列にはSCS、Pマーク、SOC 2、業界ガイドラインを置き、該当要求、実施部署、頻度、証跡、保管先、不備、改善期限を記録します。これが監査回答の基礎台帳になります。 4．証跡の品質を確認する 規程が存在するだけでは、運用の有効性は説明できません。アクセス権棚卸しなら、対象者一覧、承認記録、差異、是正結果、実施日、責任者まで必要です。教育なら受講率だけでなく、未受講者への督促や理解度確認も証跡になります。ログ監視では、ログを保存している事実に加え、アラートの判断基準、対応チケット、エスカレーション記録を確認します。個人情報や顧客機密を含む証跡は、閲覧権限、提出方法、マスキング、保管期限も定めます。 5．不足をリスクで優先順位付けする 不備は件数順ではなく、取引への影響、攻撃可能性、被害規模、外部公開の有無、代替策の有効性で評価します。インターネット公開機器の重大な脆弱性、共有管理者ID、多要素認証の欠如、バックアップ復元未検証などは、文書表現の不足より先に改善すべきです。改善計画には、恒久対応、期限、責任者、予算、完了条件、暫定措置を含めます。 6．技術検証で実装の有効性を確かめる Webアプリケーション診断は、認証・認可不備や入力処理等、Web固有の脆弱性を確認します。プラットフォーム診断は、OS、ミドルウェア、ネットワーク機器、クラウド設定などを調べます。ペネトレーションテストは、攻撃者の視点で複数の弱点を組み合わせ、重要資産へ到達できるかを検証します。目的が異なるため、単に「診断実施済み」とせず、対象資産、脅威、深度に応じて選びます。 RFPや見積依頼では、対象URL・IP・クラウド環境、認証後画面、API、実施時間、停止回避条件、再診断、報告会、機密情報の取扱い、再委託、事故時連絡、報告書サンプルを確認します。成果物には、経営向け要約、技術的根拠、再現条件、影響、リスク評価、推奨対策、優先順位、対象外範囲を含めるべきです。 7．運用サイクルへ組み込む 評価取得を一度きりのプロジェクトにしないことが重要です。月次の脆弱性管理、四半期のアクセス権棚卸し、年次の教育・訓練、委託先見直し、インシデント対応演習、経営レビューなど、既存会議へ統制確認を組み込みます。組織変更、M&A、新規クラウド導入、重要な再委託、重大インシデントがあれば、定例を待たず適用範囲とリスクを再評価します。 準備資料、期間、費用を左右する要因 準備では、情報セキュリティ規程、資産台帳、ネットワーク・データフロー図、アカウント一覧、権限棚卸し記録、脆弱性・パッチ管理記録、ログ監視記録、インシデント対応計画と訓練記録、バックアップ・復旧試験、教育記録、委託先台帳・契約、過去の診断報告書、PマークやSOC 2の審査資料などを集めます。資料名より、最新版か、対象範囲が一致するか、承認と実施記録が残るかが重要です。 期間は、適用範囲、目標段階、拠点・システム数、既存認証の成熟度、証跡の蓄積期間、技術改善の量、評価機関との調整で変わります。初期ギャップ分析だけなら比較的短期間でも可能ですが、ログ運用や権限棚卸しなど一定期間の実績が必要な統制は、文書作成だけでは埋まりません。余裕を持って年度予算と人員計画へ組み込むべきです。 費用も申請・評価費だけでなく、コンサルティング、ツール導入、診断、ペネトレーションテスト、規程改定、教育、運用工数、再評価まで含めて見積もります。全社一律に高額な製品を導入するより、重要資産へ優先配分し、既存ツールの設定改善や運用統合で代替できる部分を見極める方が合理的です。 社内稟議で説明すべき内容 稟議では「認証取得のため」だけでは投資効果が伝わりません。①主要取引先と売上への影響、②求められる可能性のある段階と期限、③現状との差分、④事故時の事業停止・復旧・信用への影響、⑤既存のPマーク・SOC 2・業界対応を共通利用できる範囲、⑥初年度と維持年度の費用、⑦社内責任者と外部支援範囲、⑧取得できない場合の代替説明を示します。 特に、情報システム部門だけに責任を寄せないことが重要です。営業は顧客要求の把握、法務・購買は契約と委託先管理、人事は教育、事業部門は業務継続、経営はリスク受容と予算判断を担います。制度対応を横断プロジェクトとして位置付けることで、監査直前の資料集めから、平時の統制運用へ移行できます。 支援会社を選ぶ際の確認ポイント 支援会社には、制度文書の作成能力だけでなく、技術と経営の両面を確認します。具体的には、SCS要求事項と既存制度をマッピングできるか、適用範囲を事業・契約から設計できるか、診断やペネトレーションテストを含む技術検証に対応できるか、改善後の運用設計まで支援するかを確認してください。 見積比較では、成果物の名称だけで判断せず、ヒアリング回数、現地確認、対象拠点・システム、証跡サンプル数、規程改定、技術検証、再確認、経営報告、申請支援が含まれるかを揃えます。また、評価を担う立場と改善支援を担う立場の独立性、利益相反、機密情報の保管・削除、再委託先も確認が必要です。制度開始前の段階では、公式に登録・指定されたかのような不適切な説明がないことも重要です。 出典：経済産業省「SCS評価制度に係る不適切な勧誘に御注意ください」https://www.meti.go.jp/policy/netsecurity/20260427_scs.html よくある失敗と注意点 既存認証があれば追加対応は不要と考える 制度間で目的と範囲が違うため、認証書だけでは代替できません。報告書、適用範囲、統制記述、例外事項、証跡を要求事項単位で照合します。 規程を増やしすぎる 制度ごとに似た規程を作ると、更新漏れと矛盾が生じます。共通の基本規程と手順を中心にし、業界固有事項は付則や管理基準で補完する方が運用しやすくなります。 対象範囲を曖昧にしたまま診断を発注する 公開Webだけを診断しても、取引先接続端末やクラウド管理面が重要なら目的を満たしません。情報資産と攻撃経路を整理してから、診断対象と手法を決めます。 評価直前に証跡を作る 後から整えた記録は、継続運用の証明になりにくく、実態との不一致も起きます。日常業務から自動的に証跡が残るチケット、承認フロー、ログ保管の仕組みを設計します。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度に向けた現状分析、適用範囲の設計、Pマーク・SOC 2・業界ガイドラインとの要求事項マッピング、規程・証跡整備、改善計画、経営報告、運用定着まで一気通貫で支援します。単にチェックリストを埋めるのではなく、取引上の重要性と実際の攻撃経路を踏まえ、優先順位を設計します。 技術面では、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築・運用、インシデントレスポンス、デジタルフォレンジックを組み合わせられます。経営面では、リスクアセスメント、情報セキュリティ体制構築、教育、SBOM、M&A・IPO・取引先監査等の重要局面にも対応します。既存の認証やツールを生かしながら、企業ごとの環境、予算、期限に合わせて支援範囲を個別設計できる点が特徴です。 よくある質問 Q1．PマークがあればSCS評価制度を取得できますか？ Pマークだけで自動的に取得できるわけではありません。ただし、個人情報管理、教育、委託先管理、事故対応、内部監査等の規程と証跡は活用できます。SCS固有の対象範囲とサイバー対策との差分確認が必要です。 Q2．SOC 2 Type 2報告書はSCS評価の代わりになりますか？ 原則として別の枠組みです。対象サービス、期間、統制、例外事項がSCSの適用範囲と一致する部分は有力な証跡候補になりますが、不足要求は別途対応します。 Q3．業界ガイドラインとSCSはどちらを優先すべきですか？ 法令、監督上の要請、契約上の義務を優先しつつ、SCSを共通基盤として統合します。片方を選ぶのではなく、業界固有要求を上乗せする考え方が実務的です。 Q4．★3を取らずに★4を目指せますか？ IPAの公表情報では、★3の事前取得が★4取得の条件という関係ではありません。ただし、★4は★3相当を包含するため、現状とのギャップと準備負担を確認して目標を決めます。 Q5．どの部署が主管になるべきですか？ 情報システムまたはセキュリティ部門が事務局を担う例が多いものの、経営、営業、法務、購買、人事、事業部門を含む横断体制が必要です。取引条件とリスク受容は経営判断です。 Q6．診断とペネトレーションテストのどちらが必要ですか？ 目的で選びます。個別資産の既知の弱点を網羅的に確認するなら脆弱性診断、攻撃経路を組み合わせて重要資産への到達可能性や検知・対応を確かめるならペネトレーションテストが適します。 Q7．準備はいつ始めるべきですか？ 対象範囲の整理とギャップ分析は早期に始めるのが合理的です。運用証跡の蓄積や予算化には時間がかかるため、顧客要請が確定してからでは選択肢が狭まる場合があります。 Q8．既存の取引先質問票は使えますか？ 利用できます。ただし、質問への回答だけでなく、対応する統制、証跡、対象範囲、責任者をひも付けてください。回答の根拠が明確になり、SCSや他の監査への再利用が容易になります。 まとめ：制度別対応から統制・証跡の一体管理へ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）、Pマーク、SOC 2、業界ガイドラインは、目的も対象範囲も評価方法も異なります。したがって、一つの認証ですべてを代替することはできません。一方、アクセス管理、教育、委託先管理、ログ監視、インシデント対応、事業継続など、共通利用できる統制と証跡は多くあります。 実務では、対象範囲を定め、制度横断のコントロールマトリクスを作り、証跡の品質を確認し、技術検証で実装の有効性を確かめます。制度取得そのものをゴールにせず、重要取引の継続と事故時の被害抑制につながる運用へ落とし込むことが、経営上の価値になります。 SCS評価制度の準備を、既存資産を生かして始めたい企業へ まず現状と不足項目を整理する PマークやSOC 2の資料をどこまで使えるか分からない場合は、既存の規程・証跡とSCS要求事項のギャップを整理するところから相談できます。Librus株式会社は、対象範囲や目標段階が未確定の段階でも、重要取引とリスクを踏まえ、優先して確認すべき項目と準備の進め方を可視化します。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F電話：03-6772-8015お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS取得までのロードマップ｜準備から登録までの全工程

サプライチェーン強化に向けたセキュリティ対策評価制度を、適用範囲の決定、自己評価、改善、専門家確認・第三者評価、登録まで時系列で解説します。 SCS評価制度の取得は、申請書を整えるだけの作業ではありません。最初に「どの組織・拠点・業務・情報システムを評価対象にするか」を決め、要求事項ごとに証拠を集め、不足を改善し、★3では登録されたセキュリティ専門家の確認、★4では指定評価機関による第三者評価と技術検証を経て、事務局へ登録を申請する流れです。 実務上の成否を分けるのは、評価直前の対症療法ではなく、適用範囲と責任者を早期に確定し、規程・設定・運用記録が一致する状態をつくることです。本稿では、従業員100～1,000名程度の企業を想定し、経営判断、社内稟議、情報システム部門の準備、Webアプリケーション診断やプラットフォーム診断、ペネトレーションテストの位置付けまで説明します。 この記事で分かること この記事を読むと、SCS評価制度の★3と★4の違い、自社に適した段階の考え方、準備から登録までの順序、各工程で必要になる資料、期間と費用を左右する要因、外部支援会社を選ぶ際の確認点が分かります。なお、IPAは★3・★4を2027年3月頃に運用開始する予定とし、申請方法や取得ガイドは2026年10月頃、申請・登録費用は今後公開予定と案内しています。以下のロードマップには、公表済みの制度要件と、企業が先行して進められる実務準備を区別して記載します。 出典：IPA「SCS評価制度の詳細情報」「よくある質問」制度詳細／FAQ SCS評価制度とは――★3と★4の違い サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、取引関係にある企業のセキュリティ対策を共通の「★」で可視化し、委託元と委託先の双方が適切な対策水準を判断しやすくする制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが運営します。 ★3は、一般的なサイバー脅威に対処し得る水準です。取得希望組織が自己評価し、SCS評価制度に登録されたセキュリティ専門家が内容を確認・助言して署名します。最後に経営層が自己適合宣誓を行い、事務局へ提出します。 ★4は、初期侵入の防御だけでなく、侵入後の被害拡大防止、取引先のデータ・システム保護、サプライチェーン上の役割に応じた強靭化までを求める水準です。指定評価機関による第三者評価と、指定技術検証事業者による技術検証が必要です。★3を先に取得しなければ★4を申請できない仕組みではありませんが、★4は★3以下の要求を包括します。 したがって、取引先から最低限の共通水準を求められる企業では★3が出発点になりやすく、重要情報や基幹業務を預かる受託事業者、広範な接続権限を持つIT事業者、事業停止時の波及が大きい企業では★4を検討する余地があります。最終判断は、取引先要求、扱う情報、接続形態、停止時の影響、投資可能額を合わせて行います。 なぜ今、取得準備が必要なのか SCS評価制度は、単なる情報システム部門の認証対応ではなく、取引継続と受注競争力に関わる経営課題になり得ます。発注者は、委託先ごとに異なる質問票を作り続けるより、共通評価を利用する方が確認負担を抑えやすくなります。委託先にとっても、複数顧客へ同じ説明を繰り返す負担を減らせる可能性があります。 一方、準備を後回しにすると、重要案件の入札や更新時に短期間で証拠提出を求められ、場当たり的な規程作成や高額な緊急対応につながります。さらに、ランサムウェアによる操業停止、委託先アカウントを踏み台にした侵入、Webアプリケーションの脆弱性を起点とする情報漏えいが起きれば、復旧費だけでなく、代替調達、顧客説明、契約上の責任、信用毀損まで影響が広がります。 今から着手すべき理由は、制度開始まで待たずとも、資産台帳、アカウント管理、バックアップ、ログ、インシデント対応、委託先管理などの基礎整備は無駄になりにくいからです。正式な様式が公開された後に差分を調整できるよう、証拠を残す運用を先行させることが合理的です。 対象となる企業・システム・場面 SCS評価制度は、特定業種だけを対象とする制度ではありません。特に検討優先度が高いのは、大手企業や公共分野のサプライチェーンに参加する企業、顧客データや設計情報を扱う企業、クラウド運用・システム保守・BPOを受託する企業、工場や物流を止めると取引先へ影響が波及する企業です。従業員100～1,000名規模では、複数拠点、子会社、SaaS、オンプレミス、外部委託が混在し、管理主体が曖昧になりやすいため、適用範囲の設計が重要です。 対象は「会社全体」と決め打ちする必要はありません。ただし、都合の悪いシステムだけを除外すると、事業や情報の流れと評価範囲が矛盾します。顧客へ提供するサービス、扱う重要情報、利用する端末・ネットワーク・クラウド、運用する部門と委託先を一本の業務フローとして捉え、境界と除外理由を説明できる状態にします。 SCS取得までのロードマップ――準備から登録まで 工程0：経営方針と目標段階を決める 最初に経営層が決めるのは、取得目的、目標段階、責任者、予算、期限です。「顧客から求められたから」だけでなく、どの取引の維持・拡大に効くのか、停止するとどの事業に損失が出るのかを明確にします。CISOや情報システム責任者だけに任せず、事業部門、法務、総務、人事、購買、内部監査を含む横断体制にすると、規程と現場運用の乖離を減らせます。 社内稟議では、制度の概要、対象取引、目標段階、適用範囲案、現状とのギャップ、概算費用、必要な社内工数、未対応時の受注・事業継続リスクを示します。制度の申請費用が未公表である点は、外部支援費・製品導入費・評価費と分け、「確定後に追加稟議」として扱うのが安全です。 工程1：適用範囲を決定する 適用範囲は、組織図だけでは決められません。対象サービス、顧客、契約、拠点、従業員、端末、ネットワーク、クラウド、アプリケーション、データ、委託先を関連付けます。たとえば顧客向けWebサービスを対象にするなら、公開Webアプリケーションだけでなく、認証基盤、運用端末、ソースコード管理、監視、バックアップ、保守委託先まで確認対象に含み得ます。 この段階で作るべき資料は、適用範囲記述書、組織図、業務フロー、ネットワーク構成図、システム・資産台帳、データフロー、クラウド／SaaS一覧、委託先一覧、責任分担表です。除外項目には「関係がない」という結論だけでなく、情報や接続が分離されている根拠を残します。 工程2：要求事項に沿って自己評価する 次に、★3または★4の要求事項・評価基準ごとに、適合・不適合・確認中を判定します。重要なのは、規程の存在だけで適合としないことです。たとえばアカウント棚卸しを年1回行う規程があっても、実施記録がなければ運用実態を説明できません。判定欄には、根拠資料名、保管場所、対象範囲、責任者、最終実施日を紐付けます。 確認資料には、情報セキュリティ方針、リスクアセスメント、アクセス権限一覧、パッチ適用記録、バックアップ・復元試験記録、ログ監視記録、教育・訓練記録、インシデント対応手順、BCP、委託先契約・評価記録などが含まれます。個人情報や機密情報を外部専門家・評価機関へ提示する場合は、秘密保持契約、閲覧権限、保存期間、返却・削除方法、再委託条件を事前に合意します。 工程3：ギャップを優先順位付けし、改善する 不適合を一律に処理すると、予算と人員が足りなくなります。優先順位は、①取得上の必須性、②攻撃される可能性、③影響の大きさ、④短期で実施できるか、⑤他の対策への波及効果で付けます。インターネット公開資産の重大な脆弱性、多要素認証がない特権アカウント、復元できるか未確認のバックアップ、連絡網のないインシデント対応は、一般に優先度が高い項目です。 改善は「製品導入」で終わりません。責任者、手順、例外承認、記録様式、確認頻度まで決め、一定期間の運用証跡を残します。経営層には、件数ではなく、重大リスクの残存状況、期限超過、追加予算、受注・停止リスクへの影響を報告します。 工程4：必要な技術検証を行う ★4では文書確認と実地審査に加え、技術検証が求められます。具体的な対象は適用範囲とリスクに応じて設計されます。公開WebサービスにはWebアプリケーション診断、サーバー・ネットワーク機器・クラウド基盤にはプラットフォーム診断が候補です。重要システムでは、攻撃者の視点で侵入可能性と到達範囲を確かめるペネトレーションテストが有効な場合があります。 脆弱性診断は既知の弱点を広く確認する手法、ペネトレーションテストは複数の弱点や設定を組み合わせ、現実にどこまで侵入・権限拡大できるかを検証する手法です。目的が異なるため、名称だけで選ばず、評価基準、資産の重要度、停止許容度に合わせます。実施前には対象IP・URL、環境、本番影響、禁止行為、実施時間、緊急連絡先、取得データの扱いを合意してください。 工程5：★3の専門家確認、または★4の第三者評価を受ける ★3では、自己評価結果をSCS評価制度の登録セキュリティ専門家が確認し、必要に応じて修正助言を行います。専門家が最終提出内容を了承した場合に署名し、経営層が自己適合宣誓を行います。支援を受けたコンサルタントが、そのまま制度上の確認者になれるとは限りません。登録要件と独立性の扱いを確認する必要があります。 ★4では、取得希望組織が指定評価機関へ検証・評価を依頼し、文書、実地、技術面の確認を受けます。評価機関から評価報告書が提供された後、取得希望組織が事務局へ登録を申請します。評価機関や技術検証事業者は公表された指定先から選定し、事前支援と正式評価の役割分担、利害関係、再評価条件を契約前に確認します。 工程6：是正、経営層の承認、登録申請を行う 確認・評価で指摘が出た場合は、原因、影響範囲、暫定措置、恒久措置、担当者、期限、再確認方法を是正計画にまとめます。単に設定を変更するだけでなく、同種システムへの横展開と手順改訂まで行うことが重要です。 ★3は、専門家署名を含む自己評価結果と経営層の自己適合宣誓を事務局へ提出します。★4は、評価機関の評価報告書を踏まえて登録を申請します。事務局は申請内容に問題がなければ台帳へ登録し、公表します。申請様式、提出方法、費用は最新のIPA公表資料で確認してください。 工程7：登録後の運用を定着させる 登録はゴールではありません。人事異動、システム更改、M&A、クラウド移行、新規委託先の追加で、評価時の状態は変わります。少なくとも、資産台帳と権限の定期見直し、脆弱性管理、バックアップ復元試験、インシデント対応訓練、委託先評価、経営報告を年間計画に組み込みます。重大な構成変更や新サービス開始時には、臨時のリスク評価と再診断を行います。 実施期間と費用を左右する要因 準備期間は一律ではありません。公的制度としての標準所要期間が公表されていない段階で、確定的な月数を示すのは適切ではありません。実務上は、限定された範囲で管理が整っている企業ほど短く、複数拠点・子会社・レガシーシステム・多数の委託先を含む企業ほど長くなります。正式評価の予約や是正期間も考慮し、取引先の期限から逆算して余裕を持たせます。 費用を左右する主な要因は、目標段階、適用範囲の広さ、拠点数、対象システム数、現状の成熟度、規程整備の量、技術検証の深さ、診断対象数、現地訪問、再評価の回数です。見積りでは、①現状評価、②改善支援、③製品・設定変更、④脆弱性診断等、⑤制度上の専門家確認または第三者評価、⑥申請・登録費用を分けると、比較しやすくなります。 支援会社・評価機関の選び方 支援会社には、SCSの要求事項を説明する力だけでなく、技術・規程・運用・経営報告をつなぐ実装力が必要です。RFPや見積依頼では、対象段階、適用範囲案、対象拠点・システム、希望時期、既存認証、成果物、会議頻度、機密情報の扱いを提示します。 確認すべき成果物は、適用範囲記述書、要求事項別ギャップ一覧、証拠台帳、改善ロードマップ、規程・手順案、技術検証報告書、是正管理表、経営報告資料です。さらに、担当者の資格・経験、診断とコンサルティングの連携、再診断条件、報告書の具体性、緊急時の対応力を確認します。★3の制度上の専門家確認、★4の正式な第三者評価については、IPAに登録・指定された主体かを必ず確認してください。 よくある失敗と注意点 適用範囲を狭くしすぎる 評価負担を減らすために範囲を狭めても、対象事業と認証基盤や運用端末がつながっていれば、説明が成立しません。最初にデータと接続の流れを可視化し、境界を技術的・契約的に裏付けます。 規程だけを短期間で作る テンプレートを整えても、アクセス権限の棚卸しや復元試験の記録がなければ、実施を証明できません。評価日から逆算して、運用記録が蓄積される期間を確保します。 診断を一度行えば十分と考える 診断は重要ですが、対象外資産、認証後の攻撃経路、運用ミス、委託先管理、初動対応までは自動的に解決しません。診断結果をリスク台帳と改善計画へ戻し、再診断と継続監視につなげます。 正式評価と取得支援を混同する 取得準備の支援者と、制度上の確認者・評価機関は役割が異なります。利益相反や独立性に関する制度規程、契約上の責任分界を確認し、誰が何を保証するのかを明文化します。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度への対応を、チェックリスト記入だけで終わらせず、適用範囲の設計、ギャップ分析、規程・体制整備、改善実装、技術検証、運用定着まで一気通貫で支援します。経営層には取引・財務・事業継続の観点で判断材料を整理し、情報システム部門には実装可能な優先順位と証拠管理の仕組みを提示します。 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築、インシデントレスポンス、デジタルフォレンジック、教育・訓練を組み合わせられるため、評価で見つかった課題を別々の会社へ引き継ぐ負担を抑えられます。大企業から中堅・中小企業まで、既存のISMS、顧客監査、M&A、IPO準備との重複も整理し、各社の環境に合わせたロードマップを設計します。 なお、正式な★3確認や★4評価が必要な場面では、制度上の登録・指定状況と独立性要件を確認したうえで、適切な役割分担をご案内します。 SCS評価制度についてよくある質問 SCS評価制度はいつ始まりますか？ IPAは、★3・★4を2027年3月頃に運用開始する予定と公表しています。申請方法は2026年10月頃に公開予定です。最新情報はIPA公式サイトで確認してください。 ★3を取らないと★4を取得できませんか？ いいえ。IPAは、★3を事前取得しなければ★4を取得できない関係ではないと説明しています。ただし、★4は下位段階の要求を包括します。 ★3は自己評価だけで取得できますか？ 自己評価だけではなく、登録セキュリティ専門家の確認・助言と署名、経営層による自己適合宣誓、事務局への提出が必要です。 ★4では何が行われますか？ 指定評価機関による文書確認・実地審査と、指定技術検証事業者による技術検証が行われます。その後、評価報告書を踏まえて事務局へ登録申請します。 Webアプリケーション診断は必ず必要ですか？ 一律に必須と断定できません。適用範囲、評価段階、対象システムとリスクに応じて、技術検証の内容を設計します。公開Webサービスが重要資産であれば有力な検証手段です。 取得準備では何から始めるべきですか？ 取得目的と目標段階を決め、対象サービス・拠点・システム・データ・委託先を含む適用範囲を整理します。その後、要求事項別の自己評価と証拠収集へ進みます。 申請・登録費用はいくらですか？ 2026年9月4日時点で、IPAは今後公開予定としています。準備支援、製品導入、診断、正式評価、申請・登録を分けて予算化してください。 ISMSを取得済みでも追加対応は必要ですか？ 既存の規程や監査記録を活用できる可能性はありますが、SCSの適用範囲と全要求事項への適合を別途確認する必要があります。認証保有だけで自動的にSCS登録となるわけではありません。 まとめ――SCS評価制度は「範囲・証拠・改善」の順で進める サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の取得準備は、目標段階を決め、適用範囲を定義し、要求事項に沿って自己評価し、不足を改善することから始まります。★3は専門家確認付き自己評価、★4は第三者評価と技術検証を経て、事務局への登録申請へ進みます。 最も重要なのは、評価書類と実際の運用を一致させることです。資産、権限、バックアップ、ログ、インシデント対応、委託先管理の記録を継続的に残せる体制を整えれば、SCS対応は取引先説明のためだけでなく、自社の事業継続力を高める活動になります。 SCS取得準備を、対象範囲の整理から相談したい企業へ 「★3と★4のどちらを目指すべきか」「どの拠点やシステムを含めるべきか」「顧客監査やISMSの資料をどこまで流用できるか」が未確定でもご相談いただけます。Librus株式会社では、初期ヒアリングと現状資料の確認を通じて、優先課題、必要な技術検証、社内体制、予算化の考え方を整理します。早い段階で論点を可視化することで、不要な製品導入や評価直前の手戻りを抑え、現実的な取得計画を立てやすくなります。 主な公的情報・一次情報 経済産業省「SCS評価制度に関する制度構築方針」 IPA「SCS評価制度」公式サイト IPA「SCS評価制度の詳細情報」 IPA「要求事項・評価基準」 IPA「よくある質問」 IPA「制度規程・委員会」 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015https://librus.co.jp/contact/ 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。

VIEW MORE

SCS評価制度★4取得実務｜第三者評価・技術検証の備え方

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★4取得では、規程を整えるだけでは足りません。評価機関による第三者評価に加え、実地審査と技術検証を通じて、定めた対策が現場とシステムで実際に機能していることを示す必要があります。準備の要点は、①適用範囲を経営判断として確定する、②要求事項と証跡を対応付ける、③サンプリングされても説明できる運用を全社に定着させる、④Webアプリケーション診断やプラットフォーム診断等を是正・再確認まで完結させる、の4点です。 本稿は2026年9月4日時点の公表情報を基にしています。IPAによれば、★3・★4は2027年3月頃の運用開始予定です。申請方法、解説書、取得ガイド、申請・登録費用など、公表前または更新予定の事項があります。実際の申請時には必ず最新版の制度文書をご確認ください。 この記事で分かること ★4の評価スキーム、実地審査で確認され得る内容、サンプリングへの備え、技術検証の対象範囲、指摘後の是正対応を一連の実務として理解できます。また、従業員100～1,000名規模の企業が、どの部署を巻き込み、どの資料を揃え、どのように予算とスケジュールを組むべきかを整理します。 SCS評価制度と★4の位置付け SCS評価制度は、委託元が委託先の対策状況を把握しにくいこと、委託先が取引先ごとに異なる質問票へ回答する負担が大きいことを背景として、サプライチェーンに必要な対策水準を段階別に示す制度です。IPAは、取引契約等において委託元が委託先に適切な段階を提示し、その実施状況を確認する利用場面を想定しています。制度の対象はサプライチェーンを構成する企業全般です。 ★4は、一般的なサイバー脅威への対処を水準とする★3より一段深く、初期侵入後の被害拡大防止、攻撃目的の遂行リスク低減、取引先データ・システムの保護、自社の役割に応じたサプライチェーン強靭化を求める水準です。★3を先に取得しなければ★4を申請できない、という順序関係ではありません。 ★4は「書類審査＋現場確認＋技術的な確認」 IPAの公表スキームでは、取得希望組織が自己評価を行い、指定された評価機関に検証・評価を依頼します。評価機関は第三者評価を行い、技術検証は評価機関自身または委託を受けた指定技術検証事業者が実施します。評価報告書を受領後、取得希望組織が事務局へ登録申請し、問題がなければ台帳に登録・公開されます。★4では文書確認だけでなく実地審査と技術検証が行われ、適用範囲内から対象をサンプリングする想定です。 なぜ今、★4取得の準備が必要なのか 制度開始後に要求事項を読み始めても、日々の運用実績は短期間では作れません。アクセス権の棚卸し、脆弱性対応、バックアップ復旧試験、教育、インシデント訓練などは、規程の制定日ではなく実施記録によって有効性を説明します。取引先から取得予定や対応状況を尋ねられたとき、ギャップ、責任者、改善期限、予算を示せる状態にしておくことが重要です。 経営上も、★4対応は単なる認証費用ではありません。取引継続条件、入札・調達要件、秘密情報の取扱条件に影響する可能性があり、対応の遅れは営業機会の損失や個別監査の増加につながり得ます。他方、制度マークだけを目的に過剰投資をすると、維持できない仕組みが残ります。守るべき取引、情報、サービス停止時の損失を起点に優先順位を決めるべきです。 対応しなかった場合に起こり得る問題 第一は、取引先への説明力の低下です。委託元から対策水準を求められた際、計画も証跡もなければ、追加質問票、個別監査、契約条件の厳格化を招く可能性があります。第二は、攻撃を受けた際の被害拡大です。例えば、VPN機器の未修正脆弱性から侵入され、共通の管理者権限を使ってファイルサーバやバックアップ領域まで暗号化されるケースでは、境界防御だけでは事業停止を抑えられません。 第三は、委託先を経由した信用毀損です。開発環境の認証情報が漏えいし、顧客環境への接続に悪用されれば、自社の復旧費用だけでなく、顧客調査、契約上の報告、損害対応が発生します。★4の準備では、こうした連鎖を想定し、権限分離、ログ監視、インシデント対応、再委託先管理を一つの仕組みとして確認します。 対象範囲はどう決めるか 適用範囲は「審査を通りやすい最小範囲」ではなく、取引先へ約束したい業務と、その業務を支える人・拠点・システム・委託先から逆算します。たとえば顧客向けSaaSを対象とするなら、本番環境だけでなく、開発・保守端末、ソースコード管理、ID基盤、監視、バックアップ、クラウド運用、外部委託を含めるべきかを判断します。除外する対象には、業務上の依存関係がないかを確認し、理由を文書化します。 経営層が決める事項 経営層は、対象とする事業・契約、許容する停止時間と情報漏えいリスク、改善投資の上限、責任役員を決めます。情報システム部門だけに任せると、営業が締結した顧客契約、開発部門の例外運用、総務が管理する入退室、購買部門の再委託先管理が評価範囲から漏れやすくなります。 情報システム部門が準備する事項 情報システム部門は、ネットワーク構成図、資産台帳、アカウント・権限一覧、脆弱性管理台帳、ログ管理方針、バックアップ構成、インシデント対応手順を現状と一致させます。台帳上は廃止済みでも実機が稼働している、退職者アカウントが残っている、規程とクラウド設定が異なる、といった差異は技術検証で表面化しやすい点です。 ★4取得に向けた具体的な実施手順 1．経営目的と適用範囲を確定する まず、主要顧客から求められる水準、売上への影響、守る情報、重要サービスを整理します。適用範囲記述書には、法人・部門、拠点、業務、システム、ネットワーク、クラウド、委託・再委託、除外理由を記載します。評価中に範囲が変わると、証跡収集や技術検証のやり直しが生じるため、経営会議等で合意を得ておくことが有効です。 2．要求事項と現状のギャップを評価する IPAが公開する★3・★4要求事項・評価基準を基準に、適合、部分適合、不適合、対象外を判定します。自己評価の点数を埋めることよりも、判定根拠を一行で説明できることが重要です。各項目に、統制責任者、規程、実施手順、証跡、対象システム、残課題、是正期限を紐付けます。IPA FAQでは、★4取得には定められたすべての要求事項・評価基準を満たす必要があるとされています。 3．規程と実運用を一致させる 規程は現場で守れる粒度にします。「定期的に確認する」では、頻度、実施者、承認者、記録先が分かりません。「四半期ごとにシステム責任者が特権IDを棚卸しし、部門長が承認、結果をチケットに保存する」まで具体化すると、運用と証跡が結び付きます。既存のISMS文書があっても、対象範囲や実態が異なる場合は流用だけで済ませないことが肝要です。 4．証跡パッケージを作る 実施前には、組織図、責任分担表、適用範囲、情報資産・システム台帳、ネットワーク図、リスクアセスメント、各種規程、教育記録、アクセスレビュー、パッチ適用記録、脆弱性診断報告書、インシデント訓練・復旧試験結果、委託先評価、例外承認記録などを準備します。文書名を並べるだけでなく、要求事項ごとに参照ページと証跡保管場所を示す索引を用意すると、評価対応を効率化できます。 5．実地審査とサンプリングに備える 実地審査では、責任者へのインタビュー、管理画面や設定の確認、記録の突合、拠点の物理的対策の確認などが想定されます。サンプリングは、適用範囲内の一部の拠点、端末、アカウント、変更記録、教育記録等を選んで運用状況を確かめる考え方です。どのサンプルが選ばれるかを予測して一部だけ整えるのではなく、母集団を明確にし、同じ手順が全件に適用されていることを示します。 有効な事前演習は、評価者役が無作為に「直近3件の入社者」「管理者ID5件」「重大パッチ3件」「委託先2社」などを選び、申請内容、承認、設定、記録が一貫しているかを追跡することです。説明担当者だけでなく、実際の運用担当者が自分の業務を説明できる状態を目指します。 6．技術検証を実施する 技術検証の具体的方法と範囲は、最新の制度文書および評価機関との調整に従う必要があります。実務上は、インターネット公開資産、Webアプリケーション、サーバ・ネットワーク機器、クラウド設定、端末、認証・権限、ネットワーク分離、ログ等について、要求事項への適合を裏付ける検証計画を作ります。無断で本番環境を試験せず、対象、時間帯、試験元IP、禁止事項、停止判断、連絡網、データ取扱いを事前合意します。 Webアプリケーション診断は、SQLインジェクション、認証・認可不備、セッション管理、設定不備等を確認します。プラットフォーム診断は、OS、ミドルウェア、ネットワーク機器の既知脆弱性や不要サービス、暗号・設定の問題を確認します。ペネトレーションテストは、複数の弱点を組み合わせて重要資産へ到達できるかを、合意したシナリオと安全管理の下で検証するものです。自動スキャンだけでは、権限設計や業務ロジック、侵入後の横展開まで十分に確認できない場合があります。 7．指摘を是正し、再確認する 指摘はCVSS等の技術的深刻度だけでなく、悪用可能性、公開範囲、保有情報、権限、事業停止影響、代替統制を合わせて優先順位付けします。重大な認証回避や外部公開機器の既知脆弱性は迅速に封じ込め、恒久対応へ移行します。一方、直ちに改修できない基幹システムは、アクセス制限、監視強化、ネットワーク分離などの代替策を経営が期限付きで承認します。 是正管理票には、指摘、根本原因、影響範囲、暫定対応、恒久対応、責任者、期限、完了証跡、残余リスク、再確認結果を残します。設定変更の画面だけでなく、同種資産への横展開確認と、運用手順の修正まで完了させることが再発防止につながります。 成果物・報告書に含めるべき内容 社内準備の成果物には、適用範囲記述書、要求事項別ギャップ一覧、証跡索引、技術検証計画、診断報告書、是正管理票、経営報告資料を含めます。診断報告書には、対象・除外、実施日時、手法、制約、発見事項、再現条件、影響、リスク評価、推奨対策を記載し、経営向け要約と技術担当者向け詳細を分けると活用しやすくなります。 経営報告では、未解決件数だけでなく、重要事業への影響、必要投資、期限、リスク受容の要否を示します。評価報告書を取得すること自体ではなく、その後も統制を維持できる責任分担と予算を承認することが経営層の役割です。 期間と費用を左右する要因 IPAが示す申請・登録費用は2026年9月4日時点で公表待ちです。したがって、総費用は「制度上の申請・登録費用」と「評価機関・技術検証の費用」と「不足対策の改修費」を分けて見積もる必要があります。期間も一律ではなく、適用範囲、拠点数、システム数、クラウド数、文書整備度、既存認証の活用可否、技術検証の深さ、重大指摘の件数、繁忙期や変更凍結期間で変わります。 準備計画は、短期間の書類作成ではなく、予備診断、是正、運用実績の蓄積、模擬審査、本評価を逆算して組みます。予算稟議では、取得目的、対象取引、適用範囲、制度関連費、診断費、改修予備費、社内工数、取得後の維持費を分けて示すと、追加費用の理由を説明しやすくなります。 評価・支援ベンダーの選び方 評価機関と技術検証事業者は、制度上の指定状況を必ず確認します。取得支援を依頼する場合は、制度要求の解釈だけでなく、Web、プラットフォーム、クラウド、認証基盤の技術検証から是正支援、運用設計まで対応できるかが重要です。第三者評価とコンサルティングを同一法人が行う場合の中立性・公平性要件は制度文書で確認し、役割分離を契約と体制図で明確にします。 RFP・見積依頼で確認したい項目 見積依頼では、対象組織・拠点・システム、希望時期、既存認証、技術検証の対象と方式、報告書言語、再診断回数、出張、緊急連絡、機密情報の保管・削除、再委託、賠償・責任分界を明記します。価格だけでなく、前提条件と除外事項、追加費用が発生する条件を比較してください。診断データには構成情報、アカウント、脆弱性など機密性の高い情報が含まれるため、暗号化、アクセス制御、保管地域、保持期間、廃棄証明も確認します。 よくある失敗と注意点 よくある失敗は、①申請直前に規程だけ作る、②適用範囲と資産台帳が一致しない、③一部の模範的な拠点・端末だけ整える、④自動スキャン結果を技術検証の全てと考える、⑤診断指摘を修正したが再確認しない、⑥情報システム部門だけで対応する、⑦制度上の確定事項と支援会社の推奨事項を混同する、というものです。 また、診断のために本番データを複製した結果、管理外の環境へ個人情報が残る事態も避けなければなりません。テストデータの匿名化、最小権限の試験アカウント、ログ取得、データ削除の確認を計画に含めます。制度文書は更新されるため、申請時点の版番号と参照日も証跡に残してください。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度の要求事項整理から適用範囲設計、ギャップ分析、規程・運用整備、証跡作成、模擬審査、技術検証に向けた準備、是正計画、継続運用まで一気通貫で支援します。Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築、インシデントレスポンス、教育を組み合わせ、企業ごとの事業・IT環境・予算に合わせて設計します。 特徴は、診断結果を渡して終わらず、経営リスクと技術課題を接続し、改善の実行と運用定着まで伴走する点です。経営層には取引・事業継続・投資判断の言葉で、情報システム部門には設定・手順・証跡の言葉で、現場部門には日常業務の変更点として説明し、社内の橋渡しを行います。 よくある質問 Q1．★3を取得してからでないと★4を取得できませんか。 いいえ。IPAは、上位段階が下位段階の事項を包括するものの、★3の事前取得を★4取得の条件とはしていません。自社の取引要件とリスクに応じて選択します。 Q2．★4は自己評価だけで取得できますか。 できません。★4は評価機関による第三者評価と技術検証が必要で、文書確認に加えて実地審査が行われる想定です。 Q3．サンプリング対策として何をすべきですか。 母集団を明確にし、全件に同じ統制が適用されている状態を作ります。アカウント、端末、拠点、変更記録等を無作為に選ぶ模擬確認が有効です。 Q4．脆弱性診断とペネトレーションテストは同じですか。 目的が異なります。脆弱性診断は個々の弱点を網羅的に確認するのに適し、ペネトレーションテストは弱点を組み合わせて重要資産へ到達できるかを攻撃シナリオに沿って確認します。必要性は対象とリスクに基づいて決めます。 Q5．既にISMSを取得していれば準備は不要ですか。 既存の管理体系や証跡は活用できますが、自動的に★4適合になるわけではありません。SCS評価制度の要求事項、適用範囲、技術検証に照らした差分確認が必要です。 Q6．申請費用はいくらですか。 2026年9月4日時点で、IPAは★3・★4の申請・登録費用を今後公開予定としています。評価、技術検証、改修等の費用は別に見込み、範囲を明確にして見積もります。 Q7．準備にはどれくらいかかりますか。 一律の期間はありません。対象規模、現状の成熟度、技術的な不備、運用記録の有無に左右されます。制度開始や顧客期限から逆算し、予備診断と是正期間を確保してください。 Q8．対象範囲がまだ決まっていなくても相談できますか。 可能です。主要取引、重要情報、業務依存関係を整理する初期段階から支援を受けることで、過不足のある範囲設定や見積もりの手戻りを減らせます。 まとめ｜★4は「説明できる運用」と「技術的な裏付け」で備える サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★4取得準備では、要求事項を満たす規程、実際の運用、客観的な証跡、技術検証の結果が一貫していなければなりません。実地審査やサンプリングを直前対策として捉えず、どの拠点・端末・担当者が選ばれても同じ仕組みを説明できる状態を作ることが本質です。 まずは、取引と事業継続の観点から適用範囲を決め、ギャップ評価、予備診断、是正、模擬審査を進めてください。制度の最新情報を追いながら、未公表事項を仮定で埋めず、変更に対応できる計画を持つことが重要です。 SCS評価制度★4の準備を、現状整理から相談したい企業様へ Librus株式会社では、対象範囲や実施方法が決まっていない段階でもご相談いただけます。主要取引、重要システム、既存規程・診断の状況を整理し、取得に向けた課題、優先順位、必要な技術検証、概算スケジュールを可視化します。社内稟議に必要な論点も整理できるため、まず何から着手すべきかを明確にしたい企業様に適しています。 参考情報 IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 IPA「SCS評価制度の詳細情報」 IPA「要求事項・評価基準」 IPA「よくある質問」 経済産業省「SCS評価制度」特設サイト ※制度の名称、評価方法、日程、費用等は今後変更・更新される可能性があります。申請・契約時はIPAおよび経済産業省の最新版をご確認ください。 監修者 鎌田光一郎：⻘山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE