SCS評価制度★3取得実務自己評価から専門家確認まで

SCS評価制度★3取得は「証跡を先に設計する」と進めやすい サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3を目指す企業は、自己評価票に回答して終わりではありません。先に適用範囲を定め、要求事項ごとに実施状況を確認できる証跡をそろえ、不足を是正し、セキュリティ専門家の確認・助言・署名を受けます。そのうえで、経営層が自己適合を宣誓し、事務局へ申請するのが基本の流れです。 最も重要なのは、規程の有無ではなく、決めた対策が現場で継続運用されていることを説明できる状態にすることです。たとえば「多要素認証を導入している」という回答だけでは、対象アカウント、例外、設定状況、定期点検の記録が分かりません。自己評価票と証跡の対応関係を最初から台帳化すると、専門家確認での手戻りを減らせます。 この記事で分かること ★3の評価方式と、自己評価・専門家確認・経営層宣誓の関係 100～1,000名規模の企業が社内で組むべき体制と実務手順 自己評価票にひも付ける証跡、技術確認、是正計画の作り方 期間・費用を左右する要因と、支援会社への見積依頼項目 申請を目的化せず、取引継続と事業継続につなげる方法 SCS評価制度と★3の位置づけ 取引先の対策水準を共通の尺度で確認する制度 SCS評価制度は、委託元と委託先の間でセキュリティ対策水準を可視化し、サプライチェーン全体の底上げを図る制度です。IPAは、委託元にとっては委託先の対策が見えにくいこと、委託先にとっては発注者ごとに異なるチェックリストへの対応が負担になっていることを背景として挙げています。取引契約等において、委託元が委託先に適切な段階を提示し、対策の実施状況を確認する利用が想定されています。出典：IPA「SCS評価制度」https://www.ipa.go.jp/security/scs/index.html ★3は、一般的なサイバー脅威に対処し得る水準です。★4は初期侵入の防御に加え、侵入後の被害拡大防止やサプライチェーン上の役割に応じた強靭化まで求め、第三者評価と技術検証を伴います。上位段階が下位段階を包含する設計であり、★3を先に取得しなければ★4に進めないわけではありません。出典：IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html ★3は専門家確認付き自己評価 ★3では、取得希望組織が要求事項・評価基準に基づく自己評価を作成します。登録された社内外のセキュリティ専門家が内容を確認し、必要に応じて修正を含む助言を行い、提出内容を了承した場合に署名します。その後、取得希望組織は経営層の自己適合宣誓を含む評価結果を事務局へ提出し、申請内容に問題がなければ台帳に登録・公開されます。これは★4の第三者評価とは異なりますが、単なる無確認の自己宣言でもありません。 IPAによると、SCS評価制度のセキュリティ専門家は、所定の資格のいずれかを保有し、制度研修を受講したうえで事務局登録が必要です。資格保有者であれば誰でも直ちに署名できるとは限らない点に注意が必要です。出典：IPA「SCS評価制度の詳細情報」https://www.ipa.go.jp/security/scs/details.html なぜ今、★3取得の準備が必要なのか 制度対応の本質は、マークの取得よりも取引先に説明可能な統制を整えることです。製造、物流、IT、業務委託などの現場では、発注元の機密情報や接続権限を委託先が保有します。委託先のVPN装置が未更新で侵入される、保守アカウントの認証情報が窃取される、クラウド共有設定の誤りで設計資料が外部公開される、といった事態は、1社の問題にとどまりません。納品停止、顧客対応、調査費用、契約上の報告、信用毀損へ連鎖します。 特に従業員100～1,000名の企業では、IT環境が十分に複雑である一方、専任のセキュリティ人員が少ないことがあります。情報システム部門がツール運用を担い、総務が規程を管理し、各事業部がSaaSを契約し、開発部門がWebサービスを運用する構造では、全社としての証拠が一か所に集まりません。★3対応は、この分散を可視化し、責任者、対象、頻度、記録を結び直す機会になります。 対応しない場合に起こり得る問題 SCS評価制度が直ちにすべての企業へ法的義務を課すという意味ではありません。しかし、発注企業が調達条件や契約更新条件として一定段階を求める運用が広がれば、未対応は営業・調達上の説明負担につながります。個別質問票への回答が続く、商談時に改善計画の提出を求められる、重要業務への参画範囲が限定される、といった影響が考えられます。 より直接的な問題は、統制の空白が残ることです。退職者アカウントが停止されていない、バックアップから復旧できるか試していない、インシデント時の連絡先が更新されていない、外部公開資産を把握していない状態は、感染や侵入が発生したときの被害を大きくします。★3の自己評価を、取引のための書類作成ではなく、事業継続上の弱点を発見する仕組みとして使うべきです。 ★3の対象範囲はどう決めるか 最初に決めるべき事項は適用範囲です。法人全体を無条件に対象とすると、海外拠点、工場、子会社、レガシー環境まで確認が広がり、証跡収集が止まることがあります。一方、都合のよい一部システムだけに狭めると、取引先が期待する事業や情報処理を含まず、説明価値が下がります。対象となる契約、提供サービス、拠点、組織、情報資産、IT基盤、外部委託先を、サプライチェーン上の役割から逆算してください。 たとえば、大手メーカー向けに保守サービスを提供し、顧客環境へリモート接続する企業なら、当該サービス部門だけでなく、接続端末、ID基盤、VPN、ログ、端末管理、委託保守先、インシデント対応体制まで対象に含める必要があります。EC事業者なら、Webアプリケーション、クラウド基盤、決済・物流連携、顧客データ管理、開発委託先が重要です。 確認軸対象範囲の決め方残す資料事業取得目的となる取引・製品・サービスを特定契約、業務フロー、サービス一覧組織・拠点運用、開発、営業、管理部門と拠点をひも付け組織図、責任分担表、拠点一覧情報・システム扱う機密情報と処理するIT基盤を洗い出す資産台帳、データフロー、構成図外部委託再委託、クラウド、保守、開発先を含める委託先台帳、契約、評価記録 SCS評価制度★3取得の実務手順 1. 経営目的と責任者を決める 経営層は、取得理由を『取引先から言われたため』だけにせず、守るべき事業、許容できない停止時間、機密情報、予算枠、リスク受容者を決めます。プロジェクト責任者は情報システム部門に置く場合でも、経営企画、総務・法務、人事、調達、開発、営業を巻き込む必要があります。経営層の宣誓が最後にあるため、開始時と申請前の2回だけではなく、主要な不足事項が判明した時点で判断会議を設けると円滑です。 社内稟議では、制度概要、取得目的、対象範囲、予定時期、担当工数、外部費用、未達項目の改修費、専門家の役割、申請後の維持運用を説明します。診断費だけを予算化し、規程改定や設定変更、端末更新の費用が漏れるケースを避けてください。 2. 資料を収集し、現状を可視化する 自己評価の前に、規程、台帳、構成図、運用記録を集めます。規程が古い場合でも捨てず、現場との差分を確認する材料にします。準備資料の例は、情報セキュリティ方針、組織図、資産・アカウント・委託先台帳、ネットワーク構成図、アクセス権レビュー記録、パッチ適用記録、バックアップ・復旧試験記録、ログ監視記録、教育履歴、インシデント対応手順と訓練記録です。 この段階で証跡台帳を作ります。列には要求事項番号、評価結果、根拠文書、ファイルの保存先、対象範囲、責任部門、確認日、不足、是正担当、期限、専門家コメントを置きます。ファイル名だけでなく、規程の章番号や管理画面の確認箇所まで書くとレビューが速くなります。 3. 自己評価票を作成する 自己評価は、担当者の印象ではなく評価基準と証跡に基づいて行います。『実施済み』と判断する前に、①対象範囲全体へ適用されているか、②責任者と頻度が決まっているか、③例外が管理されているか、④実施記録が残っているか、⑤問題発生時に改善されるかを確認します。部分導入なら、その事実と残余リスクを明記し、適合を先取りしません。 複数部門の回答が食い違った場合は、文書上のルールではなく実運用を確認します。たとえば退職者IDを即日停止する規程があっても、SaaSごとに人事情報が連携されず手作業で漏れているなら、運用証跡と改善が必要です。自己評価票の文章は、第三者が読んでも『何を、誰が、どの範囲で、どの頻度で実施したか』を追えるようにします。 4. 不足事項をリスク順に是正する 不足を同じ優先度で並べると、規程の体裁調整に時間を使い、侵入につながる穴が残ります。優先順位は、インターネットからの悪用可能性、顧客情報・重要業務への影響、攻撃の起こりやすさ、代替策の有無、要求事項への影響、改修所要時間で決めます。外部公開VPNの重大な脆弱性、管理者IDの多要素認証未導入、公開サーバの不要ポート、復旧不能なバックアップは、早期対応候補です。 Webサービスを提供する企業では、Webアプリケーション診断によりSQLインジェクション、認可不備、セッション管理などを確認します。プラットフォーム診断ではOS、ミドルウェア、ネットワーク機器、クラウド設定の脆弱性を調べます。さらに、複数の弱点を組み合わせて重要資産へ到達できるかを検証する必要があれば、合意した範囲でペネトレーションテストを実施します。これらは★3申請のために機械的に全部行うのではなく、対象範囲とリスクに応じて選びます。診断結果は、深刻度だけでなく、事業影響、悪用条件、改修責任者、期限、代替策、再確認結果まで管理してください。 5. 証跡を整え、模擬レビューを行う 証跡は『存在する資料』ではなく『評価結果を裏付ける資料』です。規程は設計、設定画面は実装、ログやチケットは運用を示します。三者を組み合わせると説明力が上がります。スクリーンショットには取得日、対象システム、取得者を付け、機密情報や個人情報を必要以上に含めません。外部へ共有する前にマスキング、アクセス制御、保存期限、削除方法を合意します。 正式な専門家確認の前に、要求事項ごとに自己評価票から証跡をたどる模擬レビューを行います。リンク切れ、古い日付、対象範囲の不一致、責任者未承認、サンプル不足を洗い出します。専門家への提出パッケージは、適用範囲説明書、自己評価票、証跡台帳、主要証跡、不足事項と是正結果、未解消リスクの扱いで構成すると確認しやすくなります。 6. セキュリティ専門家の確認・助言を受ける 専門家は、自己評価の記載と証跡が評価基準に照らして妥当かを確認し、必要に応じて修正を助言します。署名だけを依頼するのではなく、範囲設定、判断根拠、例外、サンプリング、是正結果まで説明できるレビュー工程を確保してください。社内の専門家を起用する場合も、制度上の登録要件を満たすか、評価対象の運用に関与しすぎて確認の客観性を損なわないかを検討します。 初回打合せでは、専門家の登録状況、対応実績、確認方法、必要資料、レビュー回数、追加費用、機密情報の扱い、成果物、署名条件を確認します。専門家が問題を指摘した場合は、自己評価票を修正し、是正またはリスク判断を行い、差し替えた証跡を再提示します。 7. 経営層が自己適合を宣誓し、申請する 経営層の宣誓は、現場が作った回答への形式的な押印ではありません。経営層は、適用範囲、主要なリスク、未解消事項、例外、必要予算、維持体制を確認し、提出内容に責任を持てるか判断します。申請前の経営報告は、要求事項を一つずつ読み上げるより、重要リスク、是正完了状況、残余リスク、取引への影響、次年度の維持費を中心にまとめると判断しやすくなります。 事務局への提出内容、申請方法、公開項目は最新規程に従います。公開台帳に載ることを前提に、対象範囲の表現が取引先に誤解を与えないかも確認してください。基本規程等はIPAの制度ページから確認できます。出典：IPA「制度規程・委員会」https://www.ipa.go.jp/security/scs/regulation-advisory-committeess.html 期間と費用を左右する要因 公的資料で一律の取得期間や総費用が保証されているわけではありません。実務上は、現状把握、自己評価、是正、専門家確認、経営承認、申請準備を逆算します。規程と運用記録がそろう企業は短く、資産台帳がない、拠点が多い、ID管理が分散している、レガシー機器が残る、委託先管理が未整備といった企業は長くなります。数週間で書類を整える前提ではなく、技術改修や運用実績を作る期間を含めて計画してください。 費用は、対象範囲、拠点・システム数、自己評価の初期成熟度、規程整備量、診断の要否、是正支援、専門家確認の回数、現地確認、再レビュー、申請後の運用支援で変動します。見積では『コンサルティング一式』ではなく、ギャップ分析、文書作成、証跡整備、診断、是正支援、専門家確認、申請支援を分けて確認すると比較しやすくなります。制度上の申請費用等はIPAの最新案内で確認が必要です。 支援会社・専門家を選ぶ際のチェックポイント SCS評価制度の説明ができるだけでなく、規程、IT運用、技術検証、経営報告を横断できるかを確認します。自己評価票を埋める支援だけでは、脆弱性や運用不備の是正まで進みません。一方、診断だけでは経営層宣誓や委託先管理の仕組みを整えられません。★3の取得工程全体と、その後の運用を一貫して設計できることが重要です。 SCS評価制度の最新文書と評価基準を参照しているか 専門家確認を担う者の資格・研修・登録状況を明示できるか 自己評価の代筆ではなく、根拠と判断過程を残すか Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストをリスクに応じて提案できるか 機密情報の取扱い、再委託、保存場所、削除、事故時報告が契約で明確か 是正計画、再診断、教育、継続監視まで支援範囲を選べるか RFPまたは見積依頼には、取得目標、希望時期、対象事業・拠点・システム、従業員数、既存認証、利用クラウド、外部公開システム、過去の診断、希望成果物を記載します。成果物として、ギャップ分析報告書、自己評価票、証跡台帳、適用範囲説明書、是正計画、専門家コメント・署名、経営報告資料、申請書類一覧を確認すると、納品後に何が残るか明確になります。 よくある失敗と注意点 規程を作っただけで適合と判断する 規程は必要ですが、運用記録がなければ実効性を示せません。アクセス権棚卸し、教育、バックアップ復旧試験、脆弱性対応など、定期実施が必要な対策は早めに回し、記録を残します。 適用範囲を後から変える 自己評価の途中で対象システムが増えると、証跡や診断範囲が連鎖して変わります。営業が説明したい取引範囲と、情シスが管理できるIT範囲を開始時にすり合わせてください。 専門家を最後に探す 制度登録された専門家の確保やレビュー日程がボトルネックになり得ます。初期段階で候補を決め、正式確認の前に証跡の粒度や進め方を合意することが有効です。ただし、助言者と最終確認者の関係や客観性については制度規程に従います。 診断結果を申請資料から切り離す 技術診断を実施しても、発見事項の是正記録が自己評価票と結び付いていなければ説明が弱くなります。チケット番号、改修日、再診断結果、例外承認を証跡台帳に戻します。 取得後の維持担当を決めない 組織変更、システム追加、委託先変更、重大インシデントがあれば、評価時点の状態は変わります。月次の運用確認、四半期の証跡更新、年次の自己評価、教育、診断、経営報告を年間計画に組み込みます。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度★3に向けた現状分析から、適用範囲の設計、自己評価票、証跡台帳、規程・運用の整備、技術的な確認、是正計画、経営層向け説明、専門家との連携、申請準備まで一気通貫で支援します。企業ごとのIT環境、取引構造、予算、社内稟議を踏まえ、過剰な対策を一律に導入するのではなく、リスクと要求事項の双方から優先順位を整理します。 必要に応じて、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築、インシデントレスポンス、教育・訓練まで接続できます。診断結果を報告して終わらず、改善担当と期限を定め、再確認と継続運用までつなげることが特長です。経営層には取引・財務・事業継続の言葉で、情報システム部門には設定・運用・証跡の言葉で説明し、社内合意形成を支援します。 よくある質問 Q1. ★3は自己評価だけで取得できますか。 いいえ。取得希望組織が自己評価を作成しますが、セキュリティ専門家の確認・助言・署名と、経営層による自己適合宣誓を含む申請が必要です。 Q2. 社内の有資格者が専門家確認を担当できますか。 社内外の専門家が想定されていますが、所定資格の保有、制度研修、事務局登録などの要件があります。実際の起用時は登録状況と最新規程を確認してください。 Q3. ISMSを取得済みなら、そのまま★3を取得できますか。 既存の方針、リスク管理、監査記録は有力な証跡になり得ます。ただし、SCS評価制度の適用範囲と要求事項に照らした自己評価および所定手続は別途必要です。 Q4. 脆弱性診断やペネトレーションテストは必須ですか。 すべての企業に同じ検査を機械的に実施するものではありません。評価基準、対象システム、リスク、既存証跡に応じて必要性と範囲を判断します。 Q5. どの部門が主管すべきですか。 情報システム部門が実務主管となる例は多いものの、経営企画、総務・法務、人事、調達、開発、事業部門の参加が必要です。経営層は範囲、予算、残余リスクを判断します。 Q6. どのくらい前から準備すべきですか。 台帳、規程、ログ、復旧試験等がそろっているかで変わります。運用実績や技術改修が必要なら時間を要するため、希望申請日から逆算して早期にギャップ分析を始めるのが安全です。 Q7. ★3取得後は何をすべきですか。 証跡の更新、アカウント・資産・委託先の見直し、教育、脆弱性対応、訓練、経営報告を定常化します。対象事業のリスクが高い場合は★4も検討します。 Q8. 対象範囲が決まっていなくても相談できますか。 可能です。取引先からの要求、扱う情報、接続権限、重要業務を整理し、説明価値と実行可能性の両面から範囲を設計します。 まとめ：★3は書類作成ではなく、説明可能な運用を作る取り組み サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★3取得では、対象範囲を定め、要求事項に沿って自己評価し、規程・設定・運用記録を証跡としてそろえます。不足をリスク順に是正した後、登録されたセキュリティ専門家の確認・助言・署名を受け、経営層の自己適合宣誓を含めて申請します。 成功の鍵は、自己評価票を先に埋めることではなく、経営目的、適用範囲、証跡台帳、是正責任、維持運用を一つの計画にすることです。これにより、申請時の手戻りを抑えるだけでなく、取引先への説明、事故時の初動、事業継続の実効性も高められます。 取得後も機能するセキュリティ体制を作りたい企業へ SCS評価制度への対応を、取引条件を満たすための一度きりの作業で終わらせたくない企業には、改善・運用まで含む支援が適しています。Librus株式会社は、診断、ペネトレーションテスト、SOC／CSIRT、教育、インシデント対応を必要に応じて組み合わせます。対象範囲や実施方法が固まっていない段階から、事業リスクと予算に合うロードマップをご一緒に設計します。 監修者 鎌田光一郎：⻘山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度対応を経営課題として進めるべき理由

サプライチェーン強化に向けたセキュリティ対策評価制度（以下「SCS評価制度」）への対応は、情報システム部門だけに任せる認証取得作業ではない。取引先から選ばれ続けるための条件を整え、事故時の事業停止と信用毀損を抑え、経営陣が合理的な監督を行ったことを説明できる状態をつくる経営課題である。 とりわけ従業員100～1,000名規模の企業は、大企業の重要な委託先である一方、専任人材や予算が限られやすい。制度運用が始まってから一斉に規程、証跡、技術対策を整えるのでは間に合わない可能性がある。現時点で要求事項との差分を把握し、受注上の優先度と実際のリスクに沿って改善計画を組むことが重要だ。 結論SCS評価制度対応の本質は「星を取ること」ではなく、重要取引を守るために、経営判断・組織運用・技術対策を証拠とともに整えることにある。最初に目標段階と適用範囲を決め、ギャップ評価、改善、技術検証、申請準備を一つのプロジェクトとして管理したい。 この記事で分かること SCS評価制度の概要と、★3・★4で想定される評価の違い 受注維持、営業競争力、取締役の説明責任、企業信用との関係 経営層と情報システム部門が準備すべき事項、資料、進め方 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを使い分ける考え方 費用・期間を左右する要因、支援会社を選ぶ際の確認点 SCS評価制度とは何か SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策を共通の物差しで可視化する制度である。経済産業省と内閣官房国家サイバー統括室の監督の下、独立行政法人情報処理推進機構（IPA）が運営する。委託元が取引契約などで委託先に必要な段階（★）を示し、その実施状況を確認する利用場面が想定されている。 制度が解こうとしているのは、発注側には『委託先の対策を把握しにくい』、受注側には『顧客ごとに異なる質問票へ回答する負担が大きい』という双方の問題だ。共通基準が定着すれば、発注側は確認を標準化し、受注側は自社の対策を再利用可能な形で説明しやすくなる。 ★3と★4の違い 段階評価の考え方経営上の位置づけ★3セキュリティ専門家の確認を経た自己評価。経営層による自己適合宣誓を含む。すべてのサプライチェーン企業が最低限備えるべき基礎を整える起点。★4登録された評価機関による第三者評価。技術検証も組み込まれる。重要な機能・情報・接続を担う企業が、組織的かつ継続的な対策を外部に示す手段。★5要求事項、評価スキーム、開始時期を検討中。現時点で取得計画の前提にせず、公式情報の更新を確認する。 IPAの2026年5月29日更新FAQでは、★3・★4は2027年3月頃の運用開始予定とされ、取得には各段階で定められたすべての要求事項・評価基準を満たす必要がある。申請方法や解説書などは順次公開予定であり、公開時期や細部は変更され得るため、最新の公式情報を確認したい。 出典：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 なぜSCS評価制度対応を経営課題として進めるべきなのか 1．受注維持に影響し得るから SCS評価制度は法律によってすべての企業へ一律に取得を義務付ける制度ではない。しかし、取引契約などで委託元が委託先に必要な段階を示す利用が想定されている以上、実務上は調達条件、更新審査、取引先評価の一部になる可能性がある。重要顧客が★3または★4を要請したとき、準備がなければ回答期限に間に合わず、追加説明や是正計画を求められる。場合によっては新規案件への参加や契約更新で不利になり得る。 経営層が把握すべきなのは、どの顧客がいつ要請しそうか、対象売上と粗利はいくらか、代替困難なサービスを提供しているか、顧客システムへの接続や機密情報の取扱いがあるかである。取得費用だけを見るのではなく、『未対応によって影響を受ける売上・取引』と比較して投資判断する必要がある。 2．営業競争力と信用の共通言語になり得るから 法人営業では、セキュリティ質問票への回答、監査の受入れ、規程や診断報告書の提出が受注前のボトルネックになりやすい。営業担当が『対策しています』と説明しても、適用範囲、実施頻度、責任者、記録が曖昧なら信用にはつながらない。SCS評価制度に沿って対策と証跡を整理すれば、営業、法務、情報システム部門の回答が一致し、顧客説明の速度と再現性を高められる。 もっとも、星の取得だけで個別案件の安全性を保証できるわけではない。顧客のデータ、接続方式、委託範囲に応じて追加説明は必要だ。それでも、共通基準を土台にすれば、独自質問票への回答をゼロから作る負担を減らし、営業活動で『何を、どこまで実施しているか』を具体的に示せる。 3．取締役が合理的な判断と監督を説明する材料になるから サイバー事故が起きたという結果だけで、直ちに取締役の法的責任が確定するわけではない。責任は個別事情により判断される。一方、経済産業省のサイバーセキュリティ経営ガイドラインは、経営者が認識すべき原則と、責任者へ指示すべき事項を示しており、サプライチェーン全体の状況把握と対策も重要項目に含めている。 したがって取締役会では、制度対応の担当部署を決めるだけでなく、重要資産・重要取引、許容できる停止時間、投資額、未解消リスク、重大事故時の報告経路を定期的に確認したい。議事録、承認済み方針、リスク評価、改善計画、演習記録を残すことは、平時の実効性を高めるだけでなく、事故後に『どの情報を基に、何を判断し、どのように監督したか』を説明する基盤になる。 出典：経済産業省『サイバーセキュリティ経営ガイドライン Ver3.0』：https://www.meti.go.jp/policy/netsecurity/mng_guide.html 参考：IPA『指示9 ビジネスパートナーや委託先等を含めたサプライチェーン全体の状況把握及び対策』：https://www.ipa.go.jp/security/economics/practices_navi/practice236.html 4．事故対応と事業継続の準備を同時に進められるから サプライチェーン攻撃では、自社の端末感染だけで問題が終わらない。盗まれた認証情報が顧客環境への侵入に使われる、受発注システムが停止して供給が滞る、共有ファイルから設計情報が漏れる、改ざんされたソフトウェアや更新ファイルが顧客へ配布される、といった波及が起こり得る。 制度対応を経営課題として扱えば、予防策だけでなく、検知、封じ込め、復旧、顧客通知、証拠保全、代替業務まで含む事業継続の議論ができる。これはITの復旧手順にとどまらず、納期、売上、違約金、広報、個人情報保護、取引先への報告を横断するテーマである。 対応しなかった場合に起こり得る問題 未対応の影響は、制度開始日に突然発生するとは限らない。まず顧客調査への回答が遅れ、次に是正要求や追加監査が増え、最終的に入札・更新条件との不一致が顕在化するという段階的な形が考えられる。特に問題なのは、技術対策を導入していても、対象範囲や運用記録がなく『実施を証明できない』状態だ。 また、脆弱性を放置したインターネット公開機器、共有管理者ID、バックアップの同一ネットワーク保管、退職者アカウントの残存、委託先権限の未棚卸しなどは、ランサムウェアや不正侵入の被害を拡大させる。事故時に契約上の報告期限や連絡先が分からなければ、技術的復旧が進んでも顧客対応が遅れ、信用を損なうおそれがある。 対象となる企業・システム・場面 制度はサプライチェーンを構成する企業全体を対象としている。従業員数だけで対象可否を判断するのではなく、取引上の役割とリスクを見るべきだ。製造業の部品会社、物流会社、BPO、クラウド・SaaS事業者、システム開発・運用会社、保守会社、データ処理会社などは、顧客の事業継続や情報保護に直接影響しやすい。 優先度が高いのは、顧客ネットワークへの接続がある、個人情報・営業秘密・設計情報を預かる、停止すると顧客の生産やサービスが止まる、ソフトウェアや更新物を提供する、再委託先が多い、といった場面である。自社全体を無条件に対象とするのではなく、組織、拠点、業務、システム、クラウド、委託先の境界を明文化し、除外する範囲には合理的な理由を持たせる。 SCS評価制度対応の具体的な進め方 ステップ1：経営目的と目標段階を決める 最初に『顧客から求められたから』だけでなく、守る取引、改善したいリスク、目標時期、目指す★を経営会議で合意する。主要顧客の調達方針が未公表なら、営業部門がヒアリングし、契約更新月や次年度予算の時期を把握する。★3から始めるのか、重要サプライヤーとして★4を見据えるのかで、必要な体制と技術検証の深さが変わる。 ステップ2：適用範囲と責任体制を定める 対象は法人名だけでなく、拠点、部門、業務、情報資産、ネットワーク、クラウドサービス、顧客接続、再委託先まで具体化する。責任者には権限と予算を与え、経営層、情報システム、セキュリティ、法務、総務、人事、営業、事業部門の役割を決める。100～1,000名規模では専任組織がない場合も多いため、外部専門家を使う範囲も先に線引きしたい。 ステップ3：要求事項とのギャップを評価する 規程の有無だけでなく、実際の運用と証跡を確認する。例えばアカウント管理なら、規程があるかに加え、申請・承認、定期棚卸し、退職者停止、特権ID監視の記録を見る。脆弱性管理なら、資産台帳、情報収集、優先順位、修正期限、例外承認、再確認がつながっているかを確認する。 この段階で準備したい資料は、組織図、情報セキュリティ方針・規程、資産台帳、ネットワーク構成図、クラウド一覧、アカウント・権限一覧、委託先一覧と契約、インシデント対応計画、教育記録、バックアップ・復旧試験記録、脆弱性診断報告書、ログ監視記録、リスク台帳、取締役会・経営会議の承認記録などである。資料が存在しても更新日や対象が一致しなければ、証跡として弱い。 ステップ4：リスクと受注影響で改善順位を付ける 改善項目は件数順ではなく、①顧客・事業への影響、②攻撃される可能性、③外部公開や特権などの露出、④法令・契約・評価基準との不一致、⑤改善に要する期間で優先順位を付ける。重大な脆弱性、インターネット公開機器の多要素認証未導入、復旧不能なバックアップ、事故連絡網の欠落は、文書整備より先に暫定対策が必要な場合がある。 経営報告では、専門用語の一覧ではなく、『止まる業務』『影響する顧客』『想定損失』『暫定措置』『恒久対応の期限』『リスク受容者』へ翻訳する。未解消リスクを黙って残さず、誰がいつまで受容するかを明確にする。 ステップ5：技術的な実効性を検証する 文書と設定表だけでは、実際に攻撃経路を遮断できるか分からない。Webアプリケーション診断は、顧客向けWebシステムや管理画面に対し、認証不備、アクセス制御、SQLインジェクションなどの脆弱性を確認する。プラットフォーム診断は、サーバー、ネットワーク機器、OS、ミドルウェアの設定不備や既知脆弱性を確認する。 ペネトレーションテストは、合意したシナリオの下で複数の弱点を組み合わせ、重要資産へ到達できるかを検証する。単体の脆弱性一覧では見えにくい侵入後の横展開や権限昇格を確認できる一方、対象・時間・停止リスクの調整が必要だ。すべての企業に同じ検証を当てるのではなく、SCS評価の目標段階、顧客接続、重要資産、過去の診断結果に合わせて選ぶ。 ステップ6：証跡を整え、模擬評価を行う 改善後は、要求事項、社内ルール、実施記録、責任者、保存場所を対応付ける。規程だけを新設して運用開始前の状態で申請準備を終えないことが重要だ。サンプルを抽出し、承認記録、ログ、教育受講、パッチ適用、復旧試験、委託先確認が同じ説明と整合するかを模擬評価する。 ステップ7：申請後も継続運用する 評価はゴールではない。組織変更、新システム、M&A、クラウド移行、主要委託先変更があれば適用範囲とリスクを見直す。定期的な脆弱性診断、重大変更後の再診断、ログ監視、教育、インシデント対応演習、バックアップ復旧試験を年間計画へ組み込み、経営層へ指標と例外を報告する。 実施期間と費用を左右する要因 必要期間は、目標段階、適用範囲、既存のISMS等の運用成熟度、拠点・システム数、文書と証跡の整備状況、改修の難易度、評価機関等の日程によって変わる。初期診断だけなら数週間で整理できる場合があるが、規程改定、認証基盤刷新、ネットワーク分離、ログ基盤整備、復旧試験まで必要なら数か月以上を見込むべきだ。制度運用開始直前は専門家・評価機関への依頼集中も想定されるため、余裕を持って着手したい。 費用は『申請の支援費』だけでは決まらない。現状評価、プロジェクト管理、規程整備、教育、ツール導入、設定変更、診断・ペネトレーションテスト、是正支援、再検証、第三者評価などに分けて見積もる。複数拠点や多数のクラウド、海外子会社、OT環境、顧客ごとに分かれたネットワークがあると工数は増える。逆に、資産台帳と責任者が明確で、既存のISMSや監査証跡を再利用できれば効率化しやすい。 社内稟議で説明すべき内容 稟議では『制度対応が必要』という抽象的な説明では予算化しにくい。対象顧客と売上、要求される可能性のある段階、現在の不足、事故時の事業影響、対応しない場合の選択肢、対応期間、概算費用、社内工数を一枚で示す。費用はセキュリティ部門のコストではなく、受注維持、監査対応効率化、事業継続、顧客信用を支える投資として整理すると、営業・事業部門との合意を得やすい。 同時に、星の取得を売上増加の確約として扱わないことも大切だ。投資効果は、対象売上の防衛、質問票回答時間の短縮、重大脆弱性の解消率、復旧目標の達成、顧客監査の指摘減少など複数の指標で追う。 サービス提供会社の選び方 支援会社は、評価基準の読解だけでなく、組織・技術・経営の間をつなげられるかで選ぶ。RFPまたは見積依頼では、目標段階、適用範囲、成果物、社内外の役割、現地確認の有無、技術検証の方法、是正支援、再確認、制度変更時の追随、機密情報の管理、再委託、担当者の資格・経験を確認したい。 成果物には、適用範囲、要求事項別の判定と根拠、証跡一覧、リスク評価、改善優先順位、担当・期限を含むロードマップ、未解消事項、経営層向け要約を含める。『チェックリストを埋めて終わり』ではなく、発見事項を実装・運用へ落とし、再検証まで伴走できる会社が望ましい。★3の確認者や★4の評価機関には制度上の登録要件があるため、正式な評価を依頼する段階ではIPAの公表情報で登録状況を確認する。 よくある失敗と注意点 規程だけを短期間で増やす ひな形を自社名に置き換えても、実際の承認経路、ツール、担当者、記録と一致しなければ運用できない。現場へのヒアリングとサンプル確認を行い、守れる規程にする必要がある。 適用範囲を広げすぎる、または狭めすぎる 全社一括で始めて停滞する例もあれば、評価を通しやすくするために重要システムを不合理に除外する例もある。顧客へのサービス提供と情報の流れを起点に、境界と依存関係を説明できる範囲を設定する。 診断結果を件数だけで管理する 脆弱性の深刻度だけでなく、悪用可能性、外部公開、保有データ、業務影響、代替策を組み合わせて判断する。改修できない場合は、アクセス制限や監視強化などの代替策と受容期限を決める。 情報システム部門だけで進める 委託先契約は法務、顧客要求は営業、教育は人事、事業継続は各事業部門が関与する。部門横断の責任体制がなければ、文書と実態がずれ、顧客説明も統一されない。 評価対応と機密情報管理を切り離す 支援会社や評価者へ、構成図、脆弱性、ログ、顧客情報など高機密の資料を渡す場合がある。秘密保持、アクセス制御、保管場所、暗号化、再委託、保存期間、返却・削除、事故時報告を契約と運用の両面で確認する。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度への対応方針の整理から、現状評価、適用範囲の設計、規程・証跡の整備、改善計画、技術検証、運用定着まで一気通貫で支援する。制度の要求事項を満たすためだけでなく、企業ごとの事業、顧客、システム、予算、組織体制に合わせて実行可能な形へ落とし込む。 技術面では、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、レッドチーム演習、SOC／CSIRT構築、インシデントレスポンス、デジタルフォレンジックなどを組み合わせられる。経営面では、リスクアセスメント、取引先監査、M&A・IPOなどの重要局面を踏まえ、経営層、情報システム部門、現場部門の間で判断基準をそろえる。 既にISMSや社内規程がある企業には既存資産を生かした差分対応を、体制が未整備の企業には優先順位を絞った段階的な導入を提案する。診断結果を提出して終わるのではなく、改善の実装、再診断、継続監視、教育・演習まで支援できる点が特徴である。 よくある質問 Q1．SCS評価制度への対応は法律上の義務ですか？ すべての企業に一律の取得義務を課す制度ではありません。ただし、委託元が取引契約や調達条件で必要な★を示す利用が想定されているため、自社の主要顧客や業界の方針を確認する必要があります。 Q2．★3と★4のどちらを目指すべきですか？ 顧客から求められる段階、自社が扱う情報、顧客環境への接続、供給停止時の影響で判断します。まず★3の基礎を整え、重要サプライヤーとして★4を見据える段階計画も考えられます。 Q3．ISMSを取得済みなら追加対応は不要ですか？ 不要とは限りません。既存の規程や証跡を再利用できる可能性はありますが、SCS評価制度の要求事項、適用範囲、評価方法との対応関係を確認し、不足を補う必要があります。 Q4．SCS評価制度の運用開始はいつですか？ IPAの2026年5月29日更新FAQでは、★3・★4は2027年3月頃の運用開始予定です。申請方法などは順次公開予定のため、最新の公式情報を確認してください。 Q5．準備にはどのくらいの期間がかかりますか？ 初期のギャップ評価は数週間で整理できる場合があります。ただし、規程整備、システム改修、運用記録の蓄積、技術検証を含めると数か月以上かかることがあります。 Q6．脆弱性診断だけで対応できますか？ 脆弱性診断は重要ですが、それだけでは十分ではありません。ガバナンス、資産・権限管理、委託先管理、教育、ログ監視、インシデント対応、復旧など組織と運用の対策も必要です。 Q7．どのシステムを診断対象にすべきですか？ 顧客データを扱うシステム、インターネット公開システム、顧客ネットワークへ接続する端末・機器、認証基盤、事業停止の影響が大きい基盤を優先します。適用範囲とリスク評価から決めるのが基本です。 Q8．まだ対象範囲や予算が決まっていなくても相談できますか？ 可能です。主要顧客、提供サービス、情報・システムの流れを確認し、目標段階、優先範囲、概算スケジュールを整理するところから始められます。 まとめ：SCS評価制度対応は取引と事業を守る経営基盤 サプライチェーン強化に向けたセキュリティ対策評価制度、SCS評価制度への対応は、単なるチェックリスト対応ではない。受注維持と営業競争力を支え、事故による停止と信用毀損を抑え、取締役が合理的な判断と監督を説明できる状態をつくる取り組みである。 経営層は目標段階、対象取引、適用範囲、許容リスク、予算を判断し、情報システム部門は資産、設定、運用記録、診断結果を整える。営業、法務、人事、事業部門を巻き込み、要求事項との差分をリスクと受注影響で優先順位付けすることが、無理のない対応につながる。制度の細部は今後も更新されるため、公式情報を確認しながら早期に現状把握を始めたい。 SCS評価制度対応の進め方を整理したい企業へ Librus株式会社では、要求事項とのギャップ評価、目標段階と適用範囲の設計、経営層向け説明、規程・証跡整備、脆弱性診断やペネトレーションテスト、改善ロードマップの策定まで相談できる。対象システムや実施方法が決まっていない段階でも、主要取引と事業リスクから優先順位を整理することで、過不足のない計画を立てやすくなる。 CTA案1｜まずは現状と要求事項の差を可視化する 制度対応の全体像が見えない場合は、既存の規程、運用、システム対策を確認し、要求事項との差分を整理するところから相談できる。対応が必要な項目と既存資産を切り分けることで、予算と社内工数の見通しを持ちやすくなる。 CTA案2｜重要取引から対応範囲を絞り込む すべてを一度に進める必要があるか判断できない場合は、主要顧客、契約更新時期、取扱情報、顧客環境への接続状況を基に優先範囲を設計できる。受注維持とリスク低減の両面から、経営会議や稟議で説明しやすい計画へまとめる。 CTA案3｜技術対策から改善・運用定着まで相談する 診断の要否や対象が未確定でも相談可能である。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/policy/netsecurity/mng_guide.html IPA『サイバーセキュリティ経営ガイドライン Ver3.0実践のためのプラクティス集』：https://www.ipa.go.jp/security/economics/csm-practice.html 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 電話：03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度★⁠4の技術検証とは？調査項目と準備を解説

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の★⁠4では、書類を整えるだけではなく、第三者評価に加えて実地審査と技術検証が行われます。結論からいえば、技術検証で確かめるのは「規程に書かれた対策が、対象システム上で実際に機能しているか」です。脆弱性診断だけを受ければ足りるとは限りません。外部公開システムの弱点、サーバーやネットワーク機器の設定、認証・権限管理、ログの取得と監視、バックアップからの復旧可能性などを、証跡と技術的な確認によって立体的に検証する準備が必要です。 ただし、2026年9月3日時点で、制度は2026年度末頃の申請受付開始に向けて詳細化の途中です。実際の検証項目、サンプリング方法、工数、提出様式は今後公表される文書で確定する部分があります。本記事では、公表済みの制度構築方針、★⁠3・★⁠4要求事項・評価基準、IPAの制度説明を基礎に、取得希望企業が今から準備すべき実務を解説します。未公表の事項を確定要件として扱わないことが重要です。 この記事で分かること この記事を読むと、★⁠4における第三者評価と技術検証の違い、想定される確認領域、Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストの使い分け、社内で準備すべき資料、対象範囲の決め方、費用と期間を左右する要因が分かります。あわせて、経営層が決める事項と情報システム部門が進める作業を切り分け、評価直前の場当たり的な対応を避ける進め方を示します。 サプライチェーン強化に向けたセキュリティ対策評価制度と★⁠4の概要 SCS評価制度は、発注者と受注者の間で求めるセキュリティ対策の水準を分かりやすく示し、サプライチェーン全体の対策を底上げするための制度です。IPAによれば、委託元には取引先の対策状況を把握しにくい問題があり、委託先には取引先ごとに異なる質問票への対応が重なる問題があります。共通の評価軸を設けることで、双方の確認負担を減らしながら、事業停止、情報漏えい、改ざん、踏み台化などのリスクを抑えることが制度の狙いです。 公表済みの枠組みでは、★⁠3は一般的なサイバー脅威に対処できる基礎的な水準で、専門家確認付きの自己評価です。★⁠4は、初期侵入の防御だけでなく、侵入後の被害拡大防止、検知、インシデント対応、取引先のデータやシステムの保護、サプライチェーン上の役割に応じた強靱化までを対象とし、評価機関による第三者評価と技術検証が求められます。★⁠3を先に取得しなければ★⁠4を申請できない仕組みではありませんが、★⁠4は下位段階の要求を包含します。 なお、SCS評価制度は法令上の強制制度ではなく、二社間の契約などで活用される任意制度です。「取得しなければ直ちに取引が規制される」と断定する説明は正確ではありません。一方で、発注者が調達条件や取引先管理に用いる可能性はあるため、主要顧客の要請、入札方針、自社のサプライチェーン上の重要性を踏まえて取得方針を判断する必要があります。 出典：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.meti.go.jp/policy/netsecurity/scs.html 出典：IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html 出典：経済産業省・内閣官房国家サイバー統括室「SCS評価制度に関する注意喚起」 https://www.meti.go.jp/policy/netsecurity/20260427_scs.html ★⁠4の技術検証では何を調べられるのか ★⁠4の技術検証は、評価対象企業が説明した統制や対策が、対象となるIT基盤で有効に実装されているかを技術的に確かめる工程です。IPAは、★⁠4について文書確認に加え、実地審査と技術検証を行い、企業が定めた適用範囲から対象をサンプリングして評価する想定を示しています。したがって、すべての端末やサーバーを一律に検査する「全数点検」とも、外部公開サイトだけをスキャンする「脆弱性診断」とも同義ではありません。 技術検証の準備では、要求事項、評価証跡、技術的な確認方法を一対一で結び付けます。たとえば「多要素認証を導入している」という回答だけでなく、誰に、どのシステムで、どの認証方式を適用し、例外をどう承認し、退職者の権限をいつ削除するかまで説明できる状態が望まれます。以下は、公表資料の趣旨を踏まえて企業が想定しておくべき代表的な確認領域です。最終的な必須項目は、今後の評価ガイドや評価機関の正式な手順で確認してください。 1．脆弱性診断：攻撃の入口になり得る弱点を確認する 脆弱性診断では、既知の脆弱性、不要な公開ポート、古いソフトウェア、安全でない通信方式、Webアプリケーションの実装不備などを調べます。対象は、コーポレートサイトだけではありません。VPN装置、リモートアクセス基盤、メール関連システム、クラウド上の公開サーバー、取引先向けポータル、APIなど、攻撃者がインターネットから到達できる資産を漏れなく把握することが先決です。 Webアプリケーション診断では、SQLインジェクション、クロスサイトスクリプティング、認証・セッション管理の不備、アクセス制御の欠陥などを確認します。プラットフォーム診断では、OS、ミドルウェア、ネットワーク機器、暗号設定、公開サービスなどを確認します。同じ「診断」でも対象と観点が違うため、システム台帳とデータフローを基に組み合わせる必要があります。 診断結果は、危険度の点数だけで判断しないことが重要です。外部から悪用可能か、管理者権限に到達するか、顧客情報や設計情報に接続するか、代替統制があるか、事業停止につながるかを加味します。技術的な重大度が中程度でも、主要取引先とのファイル交換基盤に存在する弱点なら、経営上の優先度は高くなり得ます。 2．設定確認：安全な製品でも危険な使い方になっていないか 設定確認では、ファイアウォール、VPN、クラウド、サーバー、端末、メール、ID管理基盤などが、自社の基準に沿って構成されているかを確認します。管理画面のインターネット公開、初期アカウントの残存、過度に広い通信許可、暗号化されていない管理通信、クラウドストレージの公開設定、監査機能の無効化などは、製品自体に脆弱性がなくても事故の原因になります。 ここで問われるのは、一時点の画面表示だけではありません。安全な標準設定を定めているか、構成変更を申請・承認・記録しているか、例外設定に期限と責任者があるか、定期的に差分を確認しているかという運用も重要です。設定値のスクリーンショットを大量に集めるより、基準、実設定、例外台帳、変更履歴を突合できる状態を作る方が実務的です。 3．認証・権限：本人確認と最小権限が機能しているか 認証領域では、多要素認証、パスワード方針、特権IDの管理、共有アカウント、休眠アカウント、入社・異動・退職時の権限変更を確認します。特に、VPN、クラウド管理者、Microsoft 365やGoogle Workspace、サーバー管理、バックアップ管理など、侵害時の影響が大きいアカウントが焦点になります。 典型的な問題は「多要素認証を導入したが、一部の旧式認証や緊急用アカウントが除外されている」「退職者のSaaSアカウントが残っている」「委託先に管理者権限を恒常付与している」といった状態です。検証に備えるには、利用者一覧、権限一覧、承認記録、棚卸結果、例外と期限を整え、実際の設定と一致させます。 4．ログと監視：侵入後に気付けるか、説明できるか ログは、攻撃の兆候を発見し、事故発生後に事実関係を追跡するための記録です。認証、管理者操作、端末検知、ネットワーク通信、クラウド監査、重要データへのアクセスなどについて、必要なログを取得しているかを確認します。さらに、保存期間、時刻同期、改ざん防止、閲覧権限、監視ルール、アラート対応、エスカレーションの仕組みまで見なければ、単に「ログがある」だけで終わります。 たとえば深夜の国外ログインを検知しても、通知先が退職者のメールアドレスなら対策は機能しません。EDRやSIEMを導入していても、重要サーバーが監視対象から外れていたり、アラートが長期間未処理だったりすれば、実効性に課題があります。技術検証前には、代表的な検知シナリオを使い、通知、一次判断、封じ込め、記録までの流れを確認するとよいでしょう。 5．バックアップ：取得ではなく復旧可能性を確認する ランサムウェア対策では、バックアップの有無だけでなく、攻撃者から分離されているか、バックアップ管理権限が本番環境と分かれているか、必要な世代が保管されているか、復旧試験を実施しているかが重要です。本番の管理者アカウントでバックアップも削除できる構成では、同時に暗号化・消去されるおそれがあります。 復旧試験では、ファイルが一つ戻るかだけでなく、重要業務を所定の時間内に再開できるかを確かめます。復旧対象の優先順位、RTO（目標復旧時間）、RPO（許容できるデータ損失時間）、依存するID基盤やネットワーク、復旧担当者、連絡先を明確にします。テスト結果と発見事項、未達の場合の改善計画を残すことで、事業継続の説明資料にもなります。 6．ペネトレーションテスト：弱点を組み合わせた侵入可能性を確かめる ペネトレーションテストは、許可された範囲で攻撃者の手法を模擬し、複数の弱点を組み合わせて重要資産へ到達できるかを確認する試験です。個別の脆弱性を網羅的に洗い出す脆弱性診断とは目的が異なります。たとえば、外部公開VPNの設定不備、弱い認証、端末上の過剰権限、ネットワーク分離の不足を連鎖させ、取引先データを保管するサーバーまで到達できるかを検証します。 制度上、すべての企業に同じ規模のペネトレーションテストが一律に必要と断定することはできません。ただし、外部公開資産が多い企業、重要情報を大量に扱う企業、遠隔保守や多数の委託先接続がある企業では、統制の実効性を確認する有力な方法です。実施時は、対象、禁止事項、試験時間、緊急連絡、停止条件、取得データの扱いを事前に合意します。 技術検証の対象となる企業・システム・場面 ★⁠4は、従業員数だけで決まる制度ではありません。従業員100～1,000名規模でも、大手企業の業務を受託する、取引先の個人情報・設計情報を保管する、基幹業務をSaaSとして提供する、遠隔保守で顧客環境に接続する、物流・製造・決済など停止影響の大きい業務を担う企業は、早めの検討が有効です。 制度の主な対象はビジネス・ITサービスに関わるIT基盤です。一般にIT基盤に該当しない製造設備などのOTシステムや、取引先へ提供する製品そのものは直接の対象外とされ、他の制度・ガイドラインで対策する想定が示されています。ただし、社内ITと工場ネットワークの接続点、保守端末、認証基盤、バックアップなどは相互に影響します。形式的に「OTは対象外」と切り離さず、境界と依存関係を明示する必要があります。 ★⁠4技術検証に向けた実施手順 経営層が最初に決めること 最初に決めるのは製品ではなく、取得目的と適用範囲です。主要顧客の要請への対応、新規取引の条件整備、事故リスクの低減、監査回答の共通化など、投資目的を言語化します。その上で、対象法人、事業、拠点、システム、委託先、データを決め、対象外とする範囲には合理的な理由を持たせます。 経営会議では、評価取得だけをゴールにしないことが大切です。重大な不備が見つかった場合の改修予算、業務停止を伴う設定変更、例外リスクの受容、再検証まで含めて意思決定します。社内稟議には、制度の任意性、顧客・事業上の必要性、対象範囲、概算費用、担当部門、想定スケジュール、発見事項への対応費を記載すると、後工程の予算不足を防ぎやすくなります。 情報システム部門が準備する資料 実務の出発点は、現状を説明できる資料の整備です。組織図と責任分担、情報資産・システム台帳、ネットワーク構成図、データフロー、外部公開資産一覧、アカウント・権限一覧、委託先一覧、セキュリティ規程、設定基準、変更記録、脆弱性管理台帳、ログ設計、インシデント対応手順、バックアップ・復旧手順、教育記録などを集めます。 資料は「存在するか」だけでなく、更新日、責任者、実環境との一致を確認します。クラウドやSaaSが各部門で個別導入されている企業では、台帳にないサービスが評価範囲から漏れやすいため、経費データ、シングルサインオンの登録、ネットワーク通信、ヒアリングなどを組み合わせて棚卸しします。 ギャップ分析から改善、事前検証へ進む 次に、★⁠4要求事項・評価基準と現状を照合し、未対応、部分対応、証跡不足を分けます。未対応は仕組みそのものがない状態、部分対応は一部拠点や一部システムだけに適用されている状態、証跡不足は実施していても記録で説明できない状態です。この三つを混同すると、ツール導入に偏った改善計画になります。 優先順位は、攻撃可能性、影響、取引先との関係、是正に必要な時間で決めます。インターネット公開機器の重大な脆弱性や、退職者の管理者IDなどは早急に対処します。規程の改定や全社教育は承認・展開に時間がかかるため、年度計画に組み込みます。改善後は、脆弱性の再診断、設定の再確認、アカウント棚卸し、ログ検知テスト、バックアップ復旧試験を行い、対策が機能した証拠を残します。 実施期間と費用を左右する要因 制度上の標準費用・標準期間が一律に決まっているわけではありません。準備から改善までの期間は、適用範囲、拠点数、システム数、クラウド利用状況、台帳の精度、既存認証の有無、診断対象、是正の難易度、評価機関の予約状況で変わります。小さく整理された範囲なら短く進みますが、資産台帳の作成から始める場合や、基幹システムの改修を伴う場合は複数の予算期にまたがる可能性があります。 費用は、コンサルティング、第三者評価、技術検証、システム改修、製品・サービス、社内工数に分けて考えます。見積額だけを比較すると、診断対象のIP数やURL数、クラウドテナント数、拠点訪問、再検証、報告会、緊急対応、報告書の粒度が違い、適正な比較ができません。RFP（提案依頼書）では、対象範囲、前提資料、検証方式、成果物、再検証の条件、機密情報の保管・削除、事故時の責任分担を揃えて提示します。 技術検証・支援会社の選び方 ★⁠4の正式な評価や技術検証は、制度に基づき指定された機関・事業者へ依頼する必要があります。IPAは、評価機関を2026年12月末頃から公表する予定としています。取得準備のコンサルティング会社と正式な評価機関が同一になる場合には、中立性・公平性に関する制度上の条件を確認しなければなりません。 選定時は、指定の有無だけでなく、Webアプリケーション、ネットワーク、クラウド、ID、ログ、バックアップの知見を横断して持つかを確認します。診断結果を列挙するだけでなく、事業影響を踏まえた優先順位と改善案を示せるか、経営層向けと技術担当者向けの双方の報告があるか、再検証まで支援できるかも重要です。 個人情報や機密情報の扱いも確認してください。秘密保持、作業者の権限管理、取得データの暗号化、保存場所、国外移転、再委託、保管期限、消去証明、脆弱性情報の連絡方法を契約前に合意します。ペネトレーションテストでは実データへ接触する可能性があるため、証跡として何を残し、何を持ち出さないかまで決めておく必要があります。 よくある失敗と注意点 最も多い失敗は、評価直前に証跡を集め始めることです。ログの保存期間が短ければ過去の運用を示せず、アカウント棚卸しや復旧試験をその場で再現することもできません。少なくとも一回の運用サイクルを回し、承認、実施、例外、改善の記録を残すことが重要です。 次に、脆弱性診断だけで★⁠4に備えたつもりになることです。診断は重要ですが、設定、ID、ログ、バックアップ、インシデント対応、委託先管理などの統制を代替しません。逆に、規程だけを増やし、現場の設定や運用を確認しない対応も不十分です。 もう一つは、適用範囲を狭くすれば安く済むと考えることです。主要な顧客データや業務を支えるシステムを不自然に外せば、取得目的と整合しません。対象外の妥当性、依存関係、発注者が期待する範囲を説明できることが必要です。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度の★⁠4取得を見据えた現状整理、適用範囲の設計、要求事項とのギャップ分析、改善計画、証跡整備、事前の技術検証を一気通貫で支援します。制度対応を単なるチェックリスト作成にせず、経営リスク、取引先対応、事業継続、実装可能性を同じ計画に落とし込むことを重視しています。 技術面では、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、設定確認、ログ・監視設計、インシデントレスポンス、デジタルフォレンジック、SOC／CSIRT構築、SBOM導入などを組み合わせられます。診断で問題を見つけて終わるのではなく、改修の優先順位付け、運用定着、再診断まで支援できる点が特徴です。 また、経営層、情報システム部門、現場部門の間で、同じ課題を異なる言葉で説明できます。経営層には取引・財務・信用・事業継続への影響を、技術部門には具体的な設定と改善手順を示し、企業ごとの環境、既存投資、予算、稟議時期に合わせて現実的なロードマップを設計します。 よくある質問 Q1．★⁠4の技術検証は脆弱性診断と同じですか 同じではありません。脆弱性診断は技術検証に用いられる方法の一つです。★⁠4では、文書確認と実地審査に加え、設定、認証・権限、ログ、バックアップなど、要求事項が実環境で機能しているかを確認することが想定されます。 Q2．すべてのサーバーや端末が検査されますか IPAは、企業が決めた適用範囲から対象をサンプリングして評価する想定を示しています。具体的な抽出方法や件数は、正式な評価手順と評価機関の案内を確認する必要があります。重要資産の漏れを避けるため、全体の台帳整備は必要です。 Q3．ペネトレーションテストは必須ですか 現時点で、すべての取得希望企業に同一内容のペネトレーションテストが一律必須と断定できません。対象システムとリスクに応じ、脆弱性診断や設定確認などと組み合わせて検証方式を決めます。 Q4．クラウドサービスも対象になりますか 適用範囲内の事業や情報を支えるクラウドは対象となり得ます。利用企業が管理するID、アクセス権、ログ、データ保護、設定、委託先管理を整理します。クラウド事業者が担う責任との境界も確認が必要です。 Q5．★⁠3を取得してからでないと★⁠4を取得できませんか いいえ。IPAは、★⁠3を事前に取得しなければ★⁠4を取得できない関係ではないと説明しています。ただし、★⁠4は★⁠3相当の基礎的対策を含むため、現状把握では下位要求も併せて確認します。 Q6．SCS評価制度への対応は義務ですか 制度自体は任意です。ただし、発注者が契約や調達条件として一定の段階を求める可能性があります。主要顧客の方針や自社の事業上の必要性を確認して判断します。 Q7．技術検証前に最低限そろえるものは何ですか 適用範囲、システム・情報資産台帳、ネットワーク構成図、外部公開資産一覧、ID・権限一覧、設定基準、ログ設計、バックアップ・復旧記録、過去の診断と改善記録を優先してください。資料と実環境の不一致も解消します。 Q8．不備が見つかったら取得できませんか 正式な判定は制度文書と評価機関の手順によります。準備段階で不備が見つかること自体は、改善機会です。影響と悪用可能性で優先順位を付け、是正、代替統制、期限付き改善計画、再検証を進めます。 まとめ：★⁠4は「ある対策」から「機能する対策」への確認 サプライチェーン強化に向けたセキュリティ対策評価制度の★⁠4では、規程や自己申告だけでなく、第三者評価、実地審査、技術検証を通じて、対策が現場で機能しているかを確認します。想定される中心領域は、脆弱性診断、設定、認証・権限、ログ・監視、バックアップ・復旧です。必要に応じてペネトレーションテストを組み合わせ、個々の弱点が事業や取引先へどう波及するかを検証します。 準備の要点は、取得目的と適用範囲を経営層が決め、情報システム部門が資産・設定・運用証跡を整え、ギャップ分析、改善、再検証までを一つの計画として進めることです。制度の詳細は今後更新されるため、経済産業省とIPAの公表資料を継続的に確認し、未確定情報を前提に過剰な投資をしない姿勢も欠かせません。 出典：経済産業省「SCS評価制度に関する制度構築方針」 https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_supply_chain/20260327_report.html 出典：IPA「制度規程・委員会」 https://www.ipa.go.jp/security/scs/regulation-advisory-committeess.html 出典：IPA「SCSセキュリティ専門家・評価機関」 https://www.ipa.go.jp/security/scs/security-experts-organization.html SCS評価制度の対象範囲から整理したい企業へ 「主要顧客から将来の対応可能性を尋ねられたが、どこまでを対象にすべきか分からない」「診断は実施済みだが、★⁠4との差分が見えない」という段階でもご相談いただけます。Librus株式会社が、事業・取引・システムの関係を整理し、必要な準備と優先順位を可視化します。早期に論点を把握することで、予算化や社内稟議を進めやすくなります。 技術検証の事前準備を具体化したい企業へ Librus株式会社は、Webアプリケーション診断、プラットフォーム診断、設定確認、認証・権限、ログ、バックアップ、ペネトレーションテストの必要性を対象環境に応じて整理します。実施方法が決まっていなくても問題ありません。既存資料と現状を確認し、過不足のない検証計画と改善ロードマップの作成を支援します。 診断後の改善・運用まで一貫して進めたい企業へ 課題の発見後に、担当部門、期限、予算、再検証方法が決まらず止まるケースは少なくありません。Librus株式会社では、経営上の影響と技術的な重大度を結び付け、改修の優先順位、証跡整備、運用定着、再診断まで支援します。まずは現在の準備状況を共有いただくことで、次に着手すべき作業を明確にできます。 監修者： 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE