コラム

SCS対応を一過性にしない――取得後の継続運用モデル

SOC・CSIRT・脆弱性管理・教育・内部点検・更新管理を実務で回す方法 サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応で重要なのは、マーク取得をゴールにしないことです。取得時に整えた規程や証跡が、その後の組織変更、クラウド移行、新規取引、脆弱性の発見に追随しなければ、実際の防御力は低下します。 結論から言えば、SCS対応を継続させる鍵は、要求事項を「担当者が保管する審査資料」ではなく、「月次・四半期・年次で回る業務」に変換することです。SOCによる監視、CSIRTによる事故対応、脆弱性管理、従業員教育、内部点検、更新管理を一つの運用台帳と経営報告に接続すれば、更新前の慌ただしい再整備を避けやすくなります。 この記事で分かること SCS評価制度の取得後に必要となる継続運用の全体像 SOC・CSIRT・脆弱性管理・教育・内部点検を連動させる方法 ★3・★4の有効期間と、変更時に再評価を検討すべき場面 年間計画、証跡管理、経営報告、予算化の実務ポイント 継続運用を支援する会社を選ぶ際の確認事項 SCS評価制度は「取得時点の確認」であり、将来の安全を保証するものではない SCS評価制度は、サプライチェーンにおける企業の立ち位置や想定リスクに応じて必要な対策水準を示し、対応状況を可視化する制度です。経済産業省と内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、IPAが運営します。★3・★4は2027年3月頃の運用開始が予定されています。 出典：IPA「SCS評価制度の詳細情報」、IPA「よくある質問」 ★3と★4では、評価方法と有効期間が異なる 制度構築方針では、★3は一般的なサイバー脅威に対処できる水準とされ、セキュリティ専門家の確認を伴う自己評価が想定されています。有効期間は1年です。★4は、侵入防御だけでなく、被害拡大防止、インシデント対応、事業継続、取引先管理まで含む標準的・包括的な水準で、第三者評価と技術検証を伴います。有効期間は3年ですが、期間中も毎年の自己評価と評価機関への提出が想定されています。 また、取得時の適用範囲や基準の達成に大きな影響を与える変更があった場合は、有効期限前でも専門家または評価機関による確認・評価が必要になる想定です。大規模な端末・サーバ更改、クラウドへの大規模移行、ネットワーク構成の顕著な変更、規程や運用方法の大幅変更などが例示されています。 出典：経済産業省・国家サイバー統括室「SCS評価制度に関する制度構築方針」 継続運用が必要な理由 攻撃者は審査日程に合わせて待ってはくれません。公開サーバの既知脆弱性、盗まれた認証情報、取引先を装うメール、クラウド設定ミスは、日々発生します。例えばVPN装置の脆弱性が公表されたのに資産台帳が古く、対象機器の有無を判断できなければ、パッチ適用の意思決定が遅れます。退職者アカウントが残ったままなら、取得時にアクセス管理規程が整っていても実効性はありません。 制度上の更新だけを目的にすると、現場には「年に一度、証跡を集める仕事」と映ります。これを避けるには、通常業務の成果物がそのまま評価の証跡になる仕組みが必要です。 取得後に起こり得る問題――形骸化は取引と事業継続にも影響する 規程と実態がずれる 取得後に組織再編やシステム変更が進む一方、責任者一覧、ネットワーク図、クラウド利用台帳、委託先一覧が更新されないケースがあります。事故時の連絡先が旧担当者のままでは、初動が止まりかねません。更新審査では、文書の有無だけでなく、定めた手順が実際に運用されていることを説明する必要があります。 脆弱性対応が担当者の勘に依存する 脆弱性情報を受け取っても、対象資産、事業影響、悪用状況、代替策を結び付ける仕組みがなければ優先順位が定まりません。CVSSの点数だけで判断すると、外部公開された重要システムの脆弱性と、隔離された検証端末の脆弱性を同列に扱うおそれがあります。結果として、本当に急ぐべき対応が後回しになります。 取引先への説明力が低下する 委託元から「直近の教育実施率」「重大脆弱性の是正状況」「インシデント時の通知期限」を尋ねられた際、資料を即時に提示できなければ、対策自体を行っていても信頼を得にくくなります。SCS評価制度は取引契約等で委託元が委託先に段階を提示し、実施状況を確認する利用が想定されています。継続運用は、営業・調達・法務にとっても取引継続の基盤です。 経営判断が遅れる セキュリティ情報が情報システム部門内に閉じると、経営層は予算の必要性を判断できません。技術的な指摘件数だけでなく、停止し得る事業、影響する顧客、復旧時間、契約上の通知義務まで翻訳する必要があります。経済産業省の「サイバーセキュリティ経営ガイドライン Ver3.0」も、経営者のリーダーシップと継続的な改善を重視しています。 出典：経済産業省「サイバーセキュリティ経営ガイドラインと支援ツール」 SCS取得後の継続運用モデル――6つの機能を一つの管理サイクルにする 従業員100～1,000名規模の企業では、専任の大組織を新設するより、既存の情報システム、総務・人事、法務、事業部門、経営会議の役割を明確にし、不足部分を外部サービスで補う設計が現実的です。以下の6機能を別々に導入せず、共通のリスク台帳、改善計画、証跡保管ルールでつなぎます。 1．SOC：監視結果を改善につなげる SOC（Security Operation Center）は、ログやアラートを監視し、不審な挙動を検知・分析する機能です。導入後は、検知件数だけでなく、重大度、初動時間、誤検知率、同種アラートの再発、ログ未取得資産を月次で確認します。監視対象に入っていないクラウドや拠点があれば、リスク台帳に登録し、追加時期を決めます。 SOCを外部委託する場合も、社内の判断責任は残ります。「誰が遮断を承認するか」「夜間に誰へ連絡するか」「取引先への通知を誰が決めるか」を事前に定め、半年に一度は連絡テストを行うと実効性を確認できます。 2．CSIRT：事故対応手順を訓練で検証する CSIRT（Computer Security Incident Response Team）は、インシデント発生時の対応を統括する体制です。常設の専任部署でなくても、情報システム、法務、広報、人事、事業責任者、経営層から役割を指定できます。 年1回の机上訓練では、ランサムウェアで受発注システムが停止した、委託先から情報漏えいの連絡が来た、管理者アカウントが乗っ取られた、といった自社固有のシナリオを使います。連絡網、証拠保全、復旧優先順位、顧客・委託元への報告、経営判断を時系列で試し、訓練後に手順書を改訂します。 3．脆弱性管理：資産把握から是正確認まで閉じる 脆弱性管理は、単発の診断ではなく、①資産把握、②情報収集、③影響判定、④優先順位付け、⑤修正または緩和策、⑥再確認、⑦例外承認の一連のプロセスです。インターネット公開資産は継続的に把握し、重大な脆弱性は期限と責任者を設定します。期限内に修正できない場合は、アクセス制限、WAF、監視強化などの代替策と、残余リスクを承認者が記録します。 Webアプリケーション診断は、認証、入力処理、権限管理などアプリ固有の問題を確認します。プラットフォーム診断は、OS、ミドルウェア、ネットワーク機器などの設定や既知脆弱性を確認します。ペネトレーションテストは、複数の弱点を組み合わせて実際にどこまで侵入・権限拡大・情報到達が可能かを検証します。目的に応じて使い分け、重大改修や公開前、定期点検のタイミングに組み込みます。 4．教育：受講率ではなく行動変容を測る 全社員向け教育は、パスワード、フィッシング、情報持ち出し、事故報告を基本とし、入社時と年次で実施します。ただし受講率100％だけでは不十分です。標的型メール訓練の報告率、誤送信の再発、端末放置、委託先データの扱いなど、実際の行動指標を確認します。 管理者、開発者、営業、人事、調達には役割別教育が必要です。例えば開発者にはセキュアコーディングと依存ライブラリ管理、調達担当には委託先評価と契約条項、経営層には重大事故時の判断訓練を行います。 5．内部点検：証跡の有無と運用実態を確認する 内部点検では、要求事項ごとに規程、実施記録、システム設定、担当者ヒアリングを突き合わせます。「規程がある」だけで適合とせず、例えばアカウント棚卸しなら、対象一覧、実施日、差異、削除結果、承認記録まで確認します。点検担当者は可能な範囲で実施担当者と分け、自己確認の盲点を減らします。 指摘事項は、重大度、事業影響、期限、責任者、是正方法、再確認結果を一つの改善台帳で管理します。更新直前に資料を集めるのではなく、月次の運用記録を所定の場所へ保管するルールが有効です。 6．更新管理：変更をトリガーに再評価する 更新管理は、毎年のカレンダーだけでは不十分です。M&A、事業譲渡、新拠点、クラウド移行、基幹システム刷新、大規模なネットワーク変更、重要な委託先の変更、重大インシデントを「臨時評価のトリガー」として定義します。経営企画や購買部門から情報システム部門へ変更情報が届くワークフローを設けます。 ★3は1年ごとの更新、★4は毎年の自己評価と3年ごとの第三者評価が想定されています。正式な申請方法、費用、解説書などは公表予定の情報を必ず確認し、制度の具体化に応じて計画を更新してください。 月次・四半期・年次で回す実務スケジュール 月次：変化と未対応を把握する 月次では、重大アラート、インシデント、外部公開資産、重大脆弱性、パッチ未適用、入退社アカウント、バックアップ失敗、改善課題の期限超過を確認します。会議は60分程度でも構いません。件数の報告だけで終わらず、事業影響が大きい上位課題について、担当者と期限を決めます。 四半期：部門横断でリスクを見直す 四半期ごとに、システム変更、委託先変更、教育結果、アクセス権棚卸し、復旧テスト、SOCの検知ルール、例外承認の期限をレビューします。経営層には、重大リスクの残高、是正遅延、必要予算、取引への影響を簡潔に報告します。 年次：要求事項全体と経営方針を再確認する 年次では、適用範囲、資産・データ・取引先、規程、リスク評価、教育、訓練、診断、内部点検、経営者レビューを一巡させます。★3または★4の手続きに必要な自己評価へ接続し、前年との差分と未解決事項を明示します。年度予算の編成前にギャップを洗い出せば、診断費、監視費、ツール更改、人材育成費を稟議に載せやすくなります。 実施前に準備すべき資料と、成果物に含めるべき項目 継続運用の設計時には、情報セキュリティ規程、組織図、責任分担表、IT資産・クラウド・外部公開資産の一覧、ネットワーク図、データ分類、委託先一覧、契約上のセキュリティ条項、インシデント記録、教育記録、診断報告書、改善台帳、バックアップ・復旧記録を準備します。すべてが揃っていなくても、欠落自体を課題として管理すれば着手できます。 成果物には、適用範囲、現状評価、要求事項とのギャップ、リスク評価、優先順位、改善ロードマップ、責任者、期限、概算費用、代替策、残余リスク、必要な証跡、更新・臨時評価の条件を含めるべきです。技術部門向けの詳細版と、経営判断向けの要約版を分けると、稟議と実行の双方に使えます。 期間と費用を左右する要因 継続運用モデルの立ち上げ期間は、対象範囲、拠点数、システム数、既存規程の成熟度、委託先数、★3・★4のどちらを目指すかによって変わります。現状調査から運用開始まで数か月単位で設計し、重大な技術課題は別途改修計画を置くのが現実的です。制度申請そのものの費用は、2026年9月時点で今後公表予定とされています。 費用を左右する主な要因は、支援範囲、現地確認の要否、Webアプリケーション診断・プラットフォーム診断の対象数、ペネトレーションテストの範囲、SOCの監視対象と時間帯、ログ量、CSIRT訓練の複雑さ、文書作成支援の程度です。見積もりでは「適合支援」「技術対策」「運用代行」「評価・申請関連」を分けると比較しやすくなります。 社内稟議で説明すべき内容 稟議では、マーク取得だけを目的にすると投資対効果が伝わりにくくなります。対象となる重要取引、停止時の売上・顧客影響、機密情報の種類、既存契約上の義務、現状の不足、取得後の維持費、担当工数を示します。さらに、診断・監視・訓練で得られる成果を「更新対応」「事故低減」「取引先への説明」「復旧力向上」に分けて説明します。 経営層が判断すべきなのは、目標段階、適用範囲、許容する残余リスク、優先する事業、予算、責任者です。情報システム部門だけに取得責任を負わせず、経営企画、人事、法務、調達、現場部門の協力を経営判断として明確にすることが重要です。 支援会社の選び方とRFP・見積依頼時の確認事項 支援会社は、制度文書を作る能力だけでなく、技術検証と日常運用をつなげられるかで選びます。RFPや見積依頼では、制度の最新情報への追随方法、★3・★4ごとの経験・支援方針、ギャップ評価の手法、成果物、担当体制、秘密情報の保管・削除、再委託、事故時の連絡、診断後の再確認、SOC・CSIRT支援、更新時の支援範囲を確認してください。 評価とコンサルティングを同一法人が提供する場合の中立性・公平性に関する要件は、今後詳細化される予定です。評価機関の指定状況や利益相反管理を確認し、取得支援と正式評価の役割を契約上も明確にする必要があります。 よくある失敗と注意点 適用範囲を狭くしすぎる 審査負担を下げるために範囲を狭くすると、重要な受発注システム、クラウド、拠点、委託先が外れ、取引先が期待する説明と一致しない場合があります。法人単位だけでなく、部門、拠点、システム、データ、取引関係を図示して決めます。 ツール導入を対策完了と考える EDRやSIEMを導入しても、アラートを確認する人、遮断判断、例外管理、障害時の代替手順がなければ運用されません。製品の導入記録ではなく、検知から是正までの実績を確認します。 診断結果を放置する 診断報告書を受領しても、改修責任者と期限が決まらなければリスクは残ります。事業影響と悪用可能性で優先順位を付け、修正後は再診断または設定確認を行います。受容する課題は、理由と期限を経営または権限者が承認します。 証跡に個人情報や機密情報を残しすぎる 評価用証跡には、従業員情報、構成情報、脆弱性、ログなどの機密情報が含まれます。提出目的に必要な範囲へ限定し、マスキング、暗号化、アクセス制限、保管期限、削除確認を定めます。支援会社との秘密保持、再委託、国外保管の有無も確認が必要です。 Librus株式会社が提供できる支援 Librus株式会社は、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応を、現状把握から取得準備、技術対策、取得後の運用まで一気通貫で支援します。制度要求と現場の実装を分断せず、経営・財務・事業継続・取引先対応の観点を含めて設計します。 具体的には、適用範囲の整理、ギャップ評価、規程・手順の整備、改善ロードマップ、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用、インシデントレスポンス、デジタルフォレンジック、教育・訓練、SBOM導入・運用、内部点検、更新支援に対応可能です。企業ごとの環境や予算に合わせ、優先順位を付けて段階的に進めます。 よくある質問 Q1．SCS評価制度はいつ始まりますか。 IPAのFAQでは、★3・★4は2027年3月頃の運用開始予定です。申請方法や取得ガイドは2026年10月頃、評価機関は2026年12月末頃、セキュリティ専門家は2027年1月以降の公開予定とされています。最新情報はIPA公式サイトで確認してください。 Q2．★3を取得してからでないと★4を取得できませんか。 いいえ。IPAの制度説明では、上位段階は下位段階の事項を含みますが、★3の事前取得が★4取得の条件になる関係ではありません。自社の取引上の要請とリスクに応じて目標を選びます。 Q3．取得後は毎年何を行いますか。 ★3は有効期間1年で、年次点検と専門家の確認・助言を経た自己評価更新が想定されています。★4は有効期間3年ですが、毎年自己評価を実施し、評価機関へ提出する想定です。日常的には月次の監視・脆弱性管理と、四半期の横断レビューを行うと年次評価へ接続しやすくなります。 Q4．取得後にクラウド移行した場合、更新まで待ってよいですか。 大規模なクラウド移行やネットワーク変更など、適用範囲や基準達成に大きく影響する変更では、再度の確認・評価が必要になる想定です。変更計画の段階で影響評価を行い、専門家または評価機関へ確認してください。 Q5．SOCを必ず内製する必要がありますか。 内製に限定する必要はありません。外部SOCを活用する場合は、監視範囲、対応時間、重大度基準、連絡先、初動権限、ログ保管、再委託、サービス終了時のデータ返却を明確にします。社内には事業判断と連携を担う責任者が必要です。 Q6．脆弱性診断は毎年一度で十分ですか。 システムの重要性と変更頻度によります。重大な改修、公開範囲の変更、新機能追加、基盤更改があれば、その都度の診断を検討します。定期診断の間も資産把握、脆弱性情報収集、パッチ管理、外部公開面の監視を継続します。 Q7．ISMSを取得済みでもSCS対応は必要ですか。 制度構築方針ではSCSとISMSは相互補完的な位置付けです。ISMSの規程、リスク評価、内部監査などは活用できますが、SCS固有の要求事項、適用範囲、取引先管理、技術検証との差分を確認する必要があります。 Q8．何から相談すればよいですか。 目標段階や対象範囲が決まっていなくても、重要な取引、システム、データ、委託先、現状の対策を整理するところから始められます。最初に簡易ギャップ評価を行うと、必要な施策と予算の優先順位が見えやすくなります。 まとめ――SCS評価制度を経営と現場の改善サイクルに変える サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、取得時点の対策状況を可視化する仕組みです。取得後も安全が自動的に維持されるわけではありません。SOC、CSIRT、脆弱性管理、教育、内部点検、更新管理を月次・四半期・年次の業務へ落とし込み、システムや事業の変更時には臨時評価を行うことが重要です。 継続運用によって、更新準備の負担を抑えるだけでなく、事故の早期検知、復旧力、取引先への説明力、予算判断の質を高められます。規程と技術、経営と現場をつなぎ、通常業務の記録がそのまま適合の証跡になる状態を目指してください。 SCS取得後の運用設計から相談できます 「取得後に誰が運用を担うか決まっていない」「既存のISMSや社内規程を生かしたい」「診断、SOC、教育をどの順番で進めるべきか分からない」といった段階でもご相談いただけます。Librus株式会社は、対象範囲と現状の対策を整理し、事業影響と予算に応じた優先順位、年間運用計画、必要な証跡、技術的な改善策まで具体化します。取得準備だけでなく、その後も無理なく維持できる体制を設計することで、取引先への説明と実際のリスク低減を両立しやすくなります。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS審査で求められる証跡とは規程だけでは足りない理由

ログ・台帳・申請記録・教育記録・議事録を、審査で説明できる状態へ サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の準備では、規程を作るだけでは十分ではありません。審査や確認で問われるのは、定めたルールが対象範囲で実際に運用され、その結果を第三者が追跡できるかどうかです。規程は「何をするか」を示しますが、ログ、資産台帳、申請・承認記録、教育記録、会議議事録などの証跡は「実際にしたこと」を示します。 結論から言えば、証跡整備の要点は、要求事項ごとに「ルール・実施・結果・改善」を一本の線でつなぐことです。大量のスクリーンショットを直前に集めるのではなく、日常業務から証跡が自然に残る仕組みをつくる必要があります。本稿では、従業員100～1,000名規模の企業を想定し、証跡の種類、整理手順、審査で説明しやすい判断基準、技術検証との関係まで実務的に解説します。 この記事で分かること SCS評価制度で規程だけでは足りない理由 ログ、台帳、申請記録、教育記録、議事録を証跡として成立させる条件 ★3と★4を見据えた準備の違いと、証跡台帳の作り方 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを証跡につなげる方法 準備期間・費用を左右する要因と、支援会社を選ぶ際の確認事項 SCS評価制度と「証跡」の基本 SCS評価制度は何を評価する制度か SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策を共通の基準で評価・可視化し、委託元と委託先の双方が適切な対策水準を判断しやすくする制度です。IPAの公式説明では、委託先への攻撃に起因する事業・サービスの提供途絶、機密情報の漏えい・改ざん、委託先を踏み台とした不正侵入などのリスクを対象にしています。全てのサプライチェーン企業が対象とされ、特にリソースの限られる中小企業での活用効果が想定されています。 2026年9月時点の公表情報では、★3は一般的なサイバー脅威に対処できる水準、★4は初期侵入の防御だけでなく、被害拡大の防止や取引先のデータ・システム保護、サプライチェーン上の役割に応じた強靱化策まで含む水準です。★3はセキュリティ専門家の確認を伴う自己評価、★4は評価機関による第三者評価と技術検証が予定されています。★3・★4の運用開始は2027年3月頃の予定です。今後公開される解説書や申請要領によって実務詳細が更新される可能性があるため、申請前には最新版を確認してください。 出典：IPA「SCS評価制度」 出典：IPA「SCS評価制度の詳細情報」 出典：IPA「要求事項・評価基準」 証跡とは、運用の事実を再現できる記録 ここでいう証跡とは、ルールに沿った行為やシステム処理が、いつ、誰によって、何を対象に、どのような結果で行われたかを確認できる記録です。文書、システムログ、チケット、メール、ワークフロー履歴、診断報告書など形式は問いません。ただし、単にファイルが存在するだけでは弱く、対象範囲、期間、責任者、承認、結果、例外処理が読み取れることが重要です。 たとえば「退職者のアカウントは速やかに削除する」と規程に書いてあっても、退職者一覧とアカウント削除チケット、実施日時、確認者が結び付かなければ、運用実績を十分に説明できません。反対に、入退社ワークフローからID管理システムへ連携され、削除完了ログと月次照合記録が残るなら、ルールが継続的に機能していることを示しやすくなります。 なぜ規程だけでは足りないのか 規程は設計図であり、運用実績そのものではない 規程は統制の出発点です。しかし、審査対象は規程の文章力ではありません。担当者がルールを認識し、対象システムに対策を実装し、定期的に確認し、問題があれば是正しているかが焦点となります。規程の最終改定日が古い、実際のクラウド利用と記載内容が一致しない、例外承認の手続が形骸化しているといった状態では、文書と実態の不整合が生じます。 ★3では専門家が作成書類を確認し、★4では文書確認に加えて実地審査と技術検証が想定されています。また、適用範囲から対象をサンプリングして評価する考え方が示されています。つまり、代表的な一件だけを整えるのではなく、どの拠点・部署・システムが選ばれても、一定品質の証跡が提示できる状態が必要です。 証跡が弱いと、実効性と説明責任の両方が崩れる 証跡不足は審査対応の遅れだけでなく、実際のインシデント対応にも影響します。ログの保存期間が不明なら侵入経路を追えず、資産台帳が古ければ脆弱な機器の所在を特定できません。申請記録がなければ過剰権限の付与理由を検証できず、教育記録がなければ対象者の未受講を把握できません。議事録が残っていなければ、経営層がどのリスクを認識し、どの対策を承認したかを説明しにくくなります。 取引先から短期間でSCS評価制度への対応を求められた場合、証跡が分散している企業は収集と整合確認に時間を取られます。回答の遅れや説明のばらつきは、セキュリティ部門だけの問題にとどまらず、入札、契約更新、新規受注、事業継続にも影響し得ます。経営層はSCS対応を「認証の取得費」ではなく、取引維持と説明責任のための経営基盤整備として捉えることが重要です。 SCS審査に備えて整理すべき主な証跡 ログ：取得しているだけでなく、確認と対応まで示す 認証ログ、管理者操作ログ、EDRやアンチウイルスの検知ログ、ファイアウォール・VPNログ、クラウド監査ログ、バックアップジョブログなどは、技術対策の稼働状況を示す基礎資料です。ただし、ログが保存されているだけでは、異常を検知して対応する運用までは証明できません。監視ルール、アラートのトリアージ記録、インシデントチケット、月次レビュー結果まで関連付けておくと、検知から対応までを説明できます。 証跡としては、対象システム名、ログ種別、取得元、保存先、保存期間、時刻同期、閲覧権限、レビュー頻度、異常時の連絡先を一覧化します。スクリーンショットだけに依存すると改ざん防止や網羅性を説明しにくいため、可能であれば管理画面からのエクスポート、設定ファイル、チケット番号など原記録へたどれる情報を残します。機密情報や個人情報を含むログは、提出用にマスキングした写しと、原本の保管場所・閲覧手順を分けて管理します。 台帳：資産・アカウント・委託先を同じ範囲で管理する 資産台帳は、端末やサーバの一覧だけではありません。クラウドサービス、ネットワーク機器、業務アプリケーション、外部公開資産、ソフトウェア、重要データ、管理者アカウント、委託先との接続点まで含めて考えます。台帳の更新責任者と頻度を定め、購買・入社・異動・退職・廃棄などの業務イベントと連動させることが重要です。 審査で説明しやすい台帳には、識別子、所有部門、管理責任者、用途、重要度、設置・利用場所、OSやバージョン、サポート期限、外部公開の有無、バックアップ、最終確認日を持たせます。すべてを一つの台帳に詰め込む必要はありません。CMDB、端末管理、SaaS管理、契約管理など複数の仕組みを使う場合は、どれを正本とするか、相互の照合方法は何かを明確にします。 申請・承認記録：権限付与と例外の妥当性を示す アカウント発行、特権付与、外部接続、ソフトウェア導入、USBメモリ利用、データ持出し、設定変更などは、申請者、承認者、対象、理由、期限、実施者、完了確認が追跡できる記録を残します。特に期限付きの特権や例外は、失効処理までを一つの案件として管理する必要があります。 ありがちな失敗は、メールで承認を得た後に担当者の受信箱だけへ残るケースです。共有ワークフローやチケットへ集約し、検索可能な案件番号を付けます。緊急変更は事前承認が難しいこともあるため、事後承認の期限、影響確認、ロールバック結果を定めておくと、現実の運用と規程を両立できます。 教育記録：受講率だけでなく、対象と改善を説明する 教育記録では、教材名、実施日、対象者、受講結果、未受講者への督促、理解度テスト、追加教育、教材改定履歴を残します。全社員向け研修だけでなく、管理者、開発者、情報システム担当者、インシデント対応要員など役割別教育も整理すると、職務に応じた力量管理を示せます。 標的型メール訓練では、開封率など単一の数字を競うより、報告手順が機能したか、再教育が必要な部門はどこか、次回の改善策は何かを記録する方が実務的です。個人を責める運用にすると報告が遅れるため、教育の目的と個人データの利用範囲を明確にしてください。 議事録：経営判断と改善サイクルを残す 経営会議、リスク委員会、情報セキュリティ委員会、インシデント振り返り会議などの議事録は、セキュリティが経営課題として管理されていることを示します。日時と出席者だけでなく、報告されたリスク、判断の根拠、決定事項、予算、責任者、期限、継続課題を記載します。 経営層が判断すべき事項は、取得を目指す段階、適用範囲、受容する残余リスク、重大インシデント時の権限、改善予算、取引先への要求水準です。議事録とリスク台帳、改善計画、次回会議のフォロー結果がつながれば、PDCAが動いていることを説明できます。 証跡を審査で使える状態にする6つの手順 1．目標段階と適用範囲を決める 最初に★3または★4のどちらを目指すか、対象とする法人、拠点、部門、業務、システム、委託先を決めます。取引先のデータやシステムへのアクセス、サービス停止時の影響、機密情報の取扱いを基準に境界を引きます。範囲を狭めること自体が目的になると、実際のリスクや取引要件とずれるため、除外理由も記録します。 2．要求事項と証跡を対応付ける 要求事項ごとに、関連規程、実施部門、利用システム、証跡名、保存場所、対象期間、責任者、不足点を整理した証跡台帳を作ります。一つの証跡が複数要件を支える場合も、逆に一つの要件に複数証跡が必要な場合もあります。ファイル名の羅列ではなく、何を証明する資料かを一文で記載します。 3．サンプルで一連の流れを再現する 入社者のアカウント発行、重大脆弱性の対応、インシデント訓練など代表的な案件を選び、起点から完了確認まで追跡します。規程、申請、承認、システム反映、レビューの間に欠落があれば、証跡収集ではなく業務プロセスを修正します。 4．証跡の品質を確認する 良い証跡は、真正性、完全性、追跡可能性、期間整合性、再現性を備えます。作成者や日時が分からない、対象範囲が曖昧、編集可能なファイルだけ、別資料との数字が不一致といった問題を点検します。原本、提出用写し、機密情報のマスキングルールも定めます。 5．技術検証で実装を確かめる ★4を見据える場合、文書の整合だけでなく技術的な有効性も確認します。Webアプリケーション診断では認証・認可や入力処理、プラットフォーム診断ではOS・ミドルウェア・ネットワーク機器の設定や既知脆弱性を検証します。ペネトレーションテストでは、現実的な攻撃経路を用いて複数の弱点が連鎖した場合の到達可能性や影響を確認します。対象、前提、実施日、検出事項、リスク評価、是正責任者、再確認結果を報告書と改善台帳へ反映します。 6．定例運用へ組み込む 証跡は審査直前の特別作業にしないことが重要です。月次のアカウント棚卸し、四半期の資産照合、年次教育、変更時のリスク評価など、頻度とトリガーを業務カレンダーへ組み込みます。証跡台帳の更新状況をKPIとして確認し、未完了や例外を会議で扱います。 審査準備の期間と費用を左右する要因 準備期間は、従業員数だけでは決まりません。適用範囲の拠点・システム数、クラウドとオンプレミスの混在、委託先数、既存のISMS等の運用状況、台帳の精度、ログ保存期間、規程と実態の差、技術検証の範囲、是正に必要なシステム改修によって変わります。既に運用が定着していても、証跡の保管場所が部門ごとに分散していると収集に時間がかかります。反対に、規程が未整備でも対象範囲が限定され、意思決定が速ければ段階的に進められる場合があります。 実務では、現状把握、ギャップ分析、改善計画、規程・手順改定、ツール設定、運用実績の蓄積、模擬審査の順で進めます。短い準備期間では、設備投資だけを先行させず、取引上の重要度とリスクに基づいて優先順位を付けるべきです。緊急度の高い外部公開資産、多要素認証、特権管理、バックアップ復旧、脆弱性対応、インシデント連絡体制などから着手し、中長期項目は責任者と期限を伴う改善計画にします。 社内稟議では、制度対応そのものに加え、対象となる主要取引、未対応時に想定される契約・入札上の影響、対象範囲、現状ギャップ、必要な社内工数、外部費用、運用開始後の維持費、成果物を説明します。認証・登録取得だけを目的にすると、更新時に再び証跡が不足します。平時の運用品質向上と取引先への説明時間短縮も投資効果に含めると、経営判断につながりやすくなります。 支援会社の選び方とRFPで確認すべきこと SCS評価制度への対応支援会社を選ぶ際は、規程雛形の提供だけでなく、現場の実装、証跡設計、技術検証、改善運用まで支援できるかを確認します。制度要求をそのままチェックリスト化するだけでは、実態とのずれや過剰投資が生じやすいためです。経営層、情報システム部門、総務・人事、開発、営業、購買など複数部門の役割を整理し、現行の稟議やワークフローへ落とし込める会社が適しています。 見積依頼時には、目標段階、対象法人・拠点・システム、重要取引、既存認証、希望時期を共有します。そのうえで、ギャップ分析の方法、成果物、証跡台帳の有無、技術検証の範囲、是正支援、模擬審査、再確認、機密情報の取扱い、再委託、データ保存場所、削除方法、制度更新への対応を確認してください。支援と評価を同じ法人が担う場合の中立性・公平性については今後の制度詳細も確認する必要があります。 成果物には、適用範囲定義書、要求事項別ギャップ一覧、証跡台帳、規程・手順の改定案、技術検証報告書、リスク別の改善計画、経営報告資料、審査時の説明要領を含めると実務で使いやすくなります。報告書は問題点の列挙ではなく、事業影響、悪用可能性、対応難易度、依存関係を踏まえて優先順位を示すことが重要です。 よくある失敗と注意点 審査直前にスクリーンショットを集める 画面証跡は一時点の状態しか示さず、継続運用や母集団全体を説明できないことがあります。設定値のエクスポート、チケット履歴、定期レビュー記録などと組み合わせ、取得日と対象を明記してください。 規程と現場で使う手順が別物になっている 規程では情報システム部門の承認が必要でも、現場が独自にSaaSを契約していると、シャドーITが台帳から漏れます。購買・経費精算・SSOの情報を照合し、現実の業務フローに合わせて統制を設計します。 証跡の量を品質と取り違える 大量の資料は、かえって矛盾を生みます。要求事項ごとに主証跡と補助証跡を定め、審査者が短時間で結論へ到達できる索引を用意します。最新版、承認済み、対象期間内の資料を優先します。 診断を実施して終わる Webアプリケーション診断やプラットフォーム診断で問題を発見しても、改修、リスク受容、代替統制、再診断の記録がなければ改善サイクルを説明できません。診断結果をチケット化し、責任者と期限を割り当て、残課題を経営層へ報告します。 個人情報・機密情報を過剰に提出する 審査用証跡には従業員情報、顧客情報、IPアドレス、認証情報などが含まれ得ます。必要最小限の範囲に絞り、マスキング、暗号化、アクセス制御、受渡し方法、保管期限、返却・削除を事前に合意してください。秘密保持契約だけでなく、実際の取扱手順を確認することが大切です。 Librus株式会社が提供できるSCS評価制度対応支援 Librus株式会社は、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に向けた現状評価から、適用範囲の設計、要求事項とのギャップ分析、規程・手順整備、証跡台帳の構築、改善計画、模擬確認まで一気通貫で支援します。企業ごとのシステム構成、組織体制、取引先要求、予算策定と稟議プロセスを踏まえ、過不足のない進め方を個別に設計します。 特徴は、文書整備だけで終わらない点です。Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジック、教育・訓練などを組み合わせ、規程と技術実装、日常運用の整合を確認できます。経営上のリスクを整理しながら、情報システム部門と現場部門の実務へ落とし込むことが可能です。 大企業との取引継続、取引先監査、M&A、IPOなど重要局面では、限られた期間で優先順位を明確にする必要があります。Librus株式会社は、グローバルスタンダードを踏まえつつ、日本企業の意思決定や現場運用に合わせ、取得準備後の改善・継続運用まで見据えて支援します。 よくある質問 SCS評価制度では、規程があれば証跡として認められますか。 規程は重要な証跡の一つですが、それだけで運用実績を示すことは困難です。申請・承認記録、ログ、台帳、点検結果、是正記録などを組み合わせ、規程どおりに実施していることを説明します。 証跡は何か月分用意すればよいですか。 必要期間は要求事項、運用頻度、今後の申請要領によって異なります。現時点で一律の期間を断定せず、月次・四半期・年次など各統制が少なくとも一度は実施されたことを示せるよう、早めに記録を蓄積してください。 Excelの台帳でも問題ありませんか。 形式より、正確性、更新責任、変更履歴、アクセス制御、他の記録との整合性が重要です。Excelを使う場合も、正本の保存場所、更新者、承認方法、バックアップを明確にします。 ★3と★4では証跡準備がどう違いますか。 ★3は専門家確認付き自己評価、★4は第三者評価と技術検証が想定されています。★4では文書の整合に加え、実地での運用確認や技術的な有効性を説明できる準備がより重要です。 ISMSを取得していればSCS対応は不要ですか。 既存のマネジメントシステムや証跡は活用できますが、SCS評価制度の適用範囲と要求事項に照らした確認が必要です。自動的に代替できると決めつけず、差分を整理してください。 脆弱性診断は必ず必要ですか。 必要な技術検証は目標段階、対象範囲、システムの性質、最新の制度文書によって判断します。ただし、外部公開Webや基盤の弱点を客観的に把握し、是正まで追跡することは、実効性の説明に役立ちます。 証跡が不足している場合、申請を諦めるべきですか。 まず不足を要求事項別に整理し、短期で補える記録と、運用実績の蓄積が必要な項目を分けます。優先度、責任者、期限を設定すれば、段階的に準備できます。 対象範囲がまだ決まっていなくても相談できますか。 可能です。主要取引、扱う情報、停止時の影響、外部接続、委託関係を整理し、事業上合理的な範囲を設計するところから進められます。 まとめ：SCS評価制度対応は「残す運用」から始める サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）で重要なのは、規程を増やすことではなく、決めた対策が現場で実施され、その事実と改善結果を追跡できる状態をつくることです。ログ、台帳、申請記録、教育記録、議事録を要求事項と結び付け、規程・実施・結果・改善の連鎖を示せるようにします。 まずは目標段階と適用範囲を定め、代表的な業務を一件たどってください。途中で承認、実装、確認、是正の記録が途切れるなら、そこが改善の出発点です。制度の最新文書を確認しながら、審査のためだけではなく、取引先への説明、インシデント対応、事業継続に役立つ証跡管理を整えることが、持続的なセキュリティ向上につながります。 SCS評価制度の準備状況を、証跡から確認しませんか 「どの範囲を対象にすべきか分からない」「規程はあるが、どの記録を証跡として示せるか不安」「★3と★4のどちらを目指すべきか整理したい」といった段階でも相談可能です。Librus株式会社では、制度要求と現場運用の両面から現状を確認し、既存資料を活かせる部分、追加対策が必要な部分、優先順位を整理します。準備範囲や実施方法が固まっていなくても、主要取引やシステム構成を伺い、社内で判断しやすい進め方をご提案します。 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム

VIEW MORE

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評価制度の取引先管理は「対象・期限・支援」の設計から始める 結論から言えば、発注企業が構築すべき「取引先SCS管理」は、全取引先に同じ星を一律要求する仕組みではありません。自社事業への影響を基準に取引先を分類し、必要な★（段階）と期限を定め、証跡を確認し、未達先には改善支援またはリスク低減策を講じる継続的な管理プロセスです。 サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、委託元が委託先に適切な段階を提示し、対策を促し、実施状況を確認する利用を想定しています。したがって、発注企業に必要なのは「取得してください」という通知文だけではありません。誰を対象とし、どの水準を、いつまでに、誰が確認し、未達をどう扱うかを、調達・情報システム・法務・事業部の共通ルールとして定める必要があります。 この記事で分かること 取引先を事業影響で分類し、★3・★4の要請水準を決める方法 依頼、回答、証跡、期限、例外を管理する台帳と会議体の設計 未達企業を直ちに排除せず、改善計画と代替統制で支援する方法 Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを使い分ける考え方 予算、期間、稟議、RFP、ベンダー選定で押さえる実務ポイント SCS評価制度とは何か SCS評価制度は、取引先へのサイバー攻撃を起点とする情報漏えい、改ざん、サービス停止、踏み台化などのリスクに対し、必要な対策水準を段階別に示し、マーク取得を通じて対策状況を可視化する制度です。経済産業省と内閣官房国家サイバー統括室の監督のもと、IPAが運営します。 制度上、★3は一般的なサイバー脅威に対処し得る水準で、セキュリティ専門家の確認を経た自己評価が基本となります。★4は、初期侵入の防御だけでなく、被害拡大防止や取引先データ・システムの保護、サプライチェーン上の役割に応じた強靱化を求め、第三者評価と技術検証を伴います。★5は高度な攻撃への対応を想定するが、2026年9月時点では今後の具体化事項が残っています。上位段階は下位段階を包含するが、★4取得の前提として★3取得が必須という関係ではありません。 一次情報：IPA「SCS評価制度」／制度の詳細情報／要求事項・評価基準 なぜ今、発注企業に取引先SCS管理が必要なのか チェックシート配布だけでは、残存リスクが分からない 従来の取引先調査では、自社独自の質問票を年1回送付し、回答が返れば完了とする運用が少なくありません。しかし、回答が自己申告のまま検証されない、重要な取引先と軽微な取引先が同じ設問になる、再委託先が管理対象から漏れる、といった弱点があります。SCS評価制度は共通水準を利用できるため、発注企業ごとの質問のばらつきを減らし、取引先との会話を「回答したか」から「必要水準を満たしたか」へ移しやすくなります。 サイバーリスクは財務・供給・信用の問題でもある 取引先のVPN機器やクラウド管理者アカウントが侵害されれば、攻撃者が発注企業の接続環境へ侵入するおそれがあります。受発注システムや生産管理システムを担う委託先がランサムウェア被害を受ければ、納品停止や代替調達費用が発生する可能性もあります。個人情報や設計情報を預ける先で漏えいが生じた場合、顧客説明や規制対応は委託先だけの問題では済みません。経営層は、SCS対応を情報システム部門の認証取得施策ではなく、事業継続と取引信用を守る施策として判断すべきです。 参考：経済産業省「サイバーセキュリティ経営ガイドライン Ver 3.0」、IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」 対応しない場合に起こり得る問題 制度対応を先送りしただけで直ちに違法になるとは限りません。しかし、取引先管理が弱いままでは、事故後に「なぜ重要委託先を把握していなかったのか」「なぜ契約上の報告期限がなかったのか」「なぜ既知の未達を放置したのか」を説明できません。さらに、顧客や親会社からSCSマークを取引条件として求められた際、対象先の棚卸しから始めることになり、更新契約や新規案件に間に合わない可能性があります。 一方、要求水準を過度に高く設定すると、取引先の費用負担が増え、代替困難な技術・部材の供給者との関係を損なう可能性があります。重要なのは、事故ゼロを約束することではなく、リスクに比例した要求と、未達時の意思決定記録を残すことです。 対象となる取引先・システム・場面 管理対象は、ITベンダーだけに限定しません。個人情報・営業秘密・設計情報を扱う業務委託先、基幹システムやクラウドを運用する事業者、自社ネットワークに接続する保守会社、工場設備の遠隔保守先、物流・決済・コールセンターなど停止時の影響が大きい先が中心となります。再委託先や海外拠点を含めるかも、データフローと契約関係から判断します。 取引先SCS管理を構築する8つの手順 1. 経営方針と責任者を決める 取引先リスクの受容水準、★3・★4を求める基本方針、例外を承認できる役職を経営会議等で決めます。実務責任者は情報セキュリティ部門が担っても、取引継続の最終判断は事業責任者・調達責任者と共有します。 2. 取引先と委託内容を棚卸しする 契約台帳、支払先一覧、システム構成図、データフロー、外部接続一覧を照合します。取引先名だけでなく、提供サービス、委託データ、接続方式、再委託、代替可能性、契約更新月、インシデント連絡先を記録します。 3. 重要度を分類する 「機密性」「完全性」「可用性」「接続性」「代替困難性」の各観点で影響を評価します。取引金額が小さくても、管理者権限を持つ保守会社や単一供給源は高重要度となる可能性があります。 4. 必要な★と期限を設定する 一般的な脅威への基礎的対応を求める先には★3、高い事業影響、重要データ、特権接続、停止許容時間の短い先には★4を検討します。ただし制度文書、業界要請、契約責任を確認し、自社判断の基準として明文化します。 5. 取引先へ要請し、相談窓口を設ける 通知には、要請理由、対象範囲、求める★、期限、提出物、機密情報の送付方法、質問先、未達時の協議手順を記載します。一方的な通告では、誤解や形式対応を招きやすくなります。 6. 証跡と進捗を管理する ステータスは「未案内、説明済、ギャップ分析中、改善中、申請中、取得済、例外承認、再評価予定」程度に統一します。担当者の主観的な「対応中」だけでなく、次の行動、期限、責任者、根拠資料を残します。 7. 未達企業を支援し、残存リスクを扱う 不足対策を重大度と実現難度で分け、短期是正、中期計画、代替統制に整理します。例えば多要素認証の即時導入が難しい場合、接続元制限、権限縮小、監視強化、利用時間制限を暫定策として検討します。 8. 年次更新と変更時レビューを行う マーク取得だけで終了せず、契約更新、システム変更、再委託開始、M&A、重大インシデントの発生時に再評価します。取引先台帳とSCS台帳を分離すると更新漏れが起こるため、調達・契約のワークフローと連動させます。 重要度分類と★取得要請の判断基準 区分典型例基本方針追加確認重要度A基幹・生産・決済、特権接続、重要データ、大規模停止影響★4を軸に個別に判断します。取得までの移行計画を設定第三者評価、技術検証、BCP、事故連絡、再委託重要度B業務SaaS、個人情報取扱、重要業務の一部委託★3を基本に、影響が高ければ★4適用範囲、改善計画、脆弱性管理、バックアップ重要度C機密情報や接続が限定的で代替可能★要請の要否をリスクに基づき判断最低限の契約条項、連絡先、定期見直し ※上表はLibrus株式会社による実務上の分類例であり、制度が全取引先に一律の★を指定するものではありません。自社の業種、規制、顧客要求、事業影響に合わせて調整します。 進捗管理台帳に必要な項目 最低限、取引先ID、契約・サービス名、事業オーナー、重要度、要求する★、現在の取得状況、適用範囲、有効性を確認した日、証跡の保管先、ギャップ、改善責任者、期限、暫定措置、残存リスク、例外承認者、次回レビュー日を記録します。証跡には機密情報が含まれる可能性があるため、閲覧権限、保存期間、暗号化、外部共有方法も決めます。 月次会議では、取得率だけをKPIにはしません。重要度Aの未達件数、期限超過、重大ギャップの平均滞留日数、暫定措置未実施件数、インシデント連絡先の確認率など、リスクが減ったかを示す指標を用います。 未達企業への支援方法 「排除」か「放置」かの二択にしない 未達先が代替困難である場合、取引停止は自社の供給リスクを高めます。まず、要求事項との差分を確認し、経営承認が必要な規程・体制、ツール導入が必要な技術対策、運用定着が必要な教育・訓練に分解します。そのうえで90日、180日などの改善計画を合意し、重大項目から是正します。期限内に取得できない場合は、対象データの削減、接続分離、権限の最小化、監視強化、バックアップ確認などで残存リスクを下げます。 診断・テストを目的に応じて使い分ける Webアプリケーション診断は、取引先が提供するWebシステムの入力処理、認証、セッション、アクセス制御などを確認します。プラットフォーム診断は、サーバー、OS、ミドルウェア、ネットワーク機器の既知脆弱性や設定不備を確認します。ペネトレーションテストは、攻撃者の視点で複数の弱点を組み合わせ、重要資産へ到達できるかを検証します。SCSの証跡作成だけを目的に機械的に実施するのではなく、★4の技術検証や重大ギャップの有効性確認など、確認したいリスクから手法を選びます。 実施期間と費用を左右する要因 取引先管理の構築は、対象が数十社で台帳が整っていれば2〜3か月程度で初期設計できる場合があります。一方、数百社を超え、契約・システム・データの所在が分散している場合は、優先対象から段階導入する方が現実的です。制度側の審査期間や評価機関の稼働は別途考慮する必要があり、固定的な取得期間を約束することは適切ではありません。 費用は、対象取引先数、棚卸し精度、重要度評価の粒度、説明会や個別支援の回数、ギャップ分析の深さ、規程・契約改定、技術検証の範囲、複数拠点・海外対応、進捗管理ツール連携によって変わります。見積依頼では「SCS対応一式」ではなく、設計、展開、個社支援、診断、運用の各工程を分けると比較しやすくなります。 社内稟議とRFPで説明・確認すべき事項 稟議では事業損失と取引要請を起点にする 制度の概要だけでは予算判断につながりにくい傾向があります。重要委託先の停止許容時間、預託データ、外部接続、代替調達日数、顧客からの要求状況を示し、「どのリスクを、どの順番で、どこまで下げるか」を説明します。初年度に全社一斉導入せず、重要度Aから開始するロードマップも有効です。 RFP・見積依頼時の確認項目 制度文書と要求事項・評価基準を踏まえた支援範囲 発注企業側の取引先分類・管理プロセス設計の経験 ★3の専門家確認、★4の第三者評価・技術検証との役割分担 診断結果を改善計画と運用へ接続できる体制 機密情報・個人情報の保管場所、再委託、削除方法 成果物、会議体、レビュー回数、追加費用条件 制度変更時の更新支援と、取得後の継続管理 サービス提供会社の選び方 重要なのは、制度説明ができることだけではありません。発注企業側の調達管理、取得企業側のギャップ改善、技術診断の三つをつなげられるかを確認します。成果物のサンプルでは、台帳や規程の体裁より、重要度の根拠、未達時の判断、改善後の検証まで追えるかを確認します。経営層向け報告と現場向け是正指示を分けて作成できることも重要です。 よくある失敗と注意点 全社一律で★4を要求する リスクに比べ要求が過大となり、取引先の反発や形式対応を招きます。重要度分類と例外ルールを先に作ります。 取得マークだけで安全と判断する 評価には適用範囲があります。自社との取引に関係する拠点、システム、サービスが範囲内か確認します。 調達部門だけで運用する 技術的妥当性を判断できず、情シスだけでは取引継続を決められません。部門横断の責任分担が必要です。 未達先へ期限だけ通知する 原因が予算、人材、規程、技術のどこにあるか把握できず、改善が進みません。個社別のギャップと支援メニューを用意します。 診断を一度実施して終了する システム変更や新たな脆弱性で状態は変わります。再診断、継続監視、教育、インシデント演習へつなげます。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度に関する現状把握、適用範囲の整理、取引先重要度分類、★取得要請方針、管理台帳・会議体・例外承認の設計、個社説明、ギャップ分析、改善ロードマップまで一気通貫で支援します。制度対応だけでなく、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築、インシデントレスポンス、教育・訓練を組み合わせ、発見した課題を改善・運用までつなげます。 経営上の事業継続・取引信用と、現場のアクセス制御・脆弱性管理を同じリスク軸で整理できる点が特長です。大企業の統制要件と、中堅・中小取引先の人員・予算制約の双方を踏まえ、過不足のない個別設計を行います。 よくある質問 Q1. すべての取引先にSCSマーク取得を求めるべきですか？ 一律要請は推奨しません。委託情報、外部接続、事業停止影響、代替可能性などで重要度を分類し、対象と水準を決めます。 Q2. ★3と★4はどう使い分けますか？ ★3は一般的な脅威への対応水準、★4は被害拡大防止や第三者評価・技術検証まで含みます。重要データ、特権接続、停止影響が大きい取引先では★4を検討します。 Q3. 取引先が期限までに取得できない場合は？ 未達理由と重大ギャップを確認し、改善期限、暫定措置、責任者を合意します。例外は期限付きで承認し、残存リスクと再評価日を記録します。 Q4. ISO 27001を取得済みならSCS確認は不要ですか？ 制度や適用範囲、評価観点が同一とは限りません。既存認証を証跡として活用しつつ、自社取引に必要な範囲とSCS要求との差分を確認します。 Q5. Web診断やペネトレーションテストは必須ですか？ 対象となる段階、評価・技術検証の具体的な要件、およびリスクによって異なります。診断を先に決めず、守る資産と確認目的から手法を選びます。 Q6. 管理の主管部門はどこが適切ですか？ セキュリティ部門または情報システム部門が制度・技術を統括し、調達が契約・台帳、事業部が重要度と継続判断、法務が条項と事故対応を担う形が現実的です。 Q7. どの程度の期間を見込むべきですか？ 対象数と台帳整備状況に左右されます。重要先の選定、基準設計、試行、展開の順で進め、制度側の審査・評価期間は別に見込みます。 Q8. 制度の詳細が更新された場合はどうしますか？ IPAの公式ページ、基本規程、要求事項・評価基準を定期確認し、契約条項、社内基準、取引先案内を版管理します。 まとめ｜SCS評価制度を「取引先の継続管理」に変える サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）を実務で機能させる鍵は、★取得率ではなく、重要な取引先の残存リスクを把握し、改善を継続できることにあります。発注企業は、①棚卸し、②重要度分類、③★と期限の設定、④証跡・進捗管理、⑤未達支援、⑥例外承認、⑦定期見直しを一つの業務フローとして設計すべきです。 制度の詳細は今後も更新される可能性があります。最新の公式文書を確認しながら、最初から全取引先を完璧に管理しようとせず、事業影響の大きい委託先から段階的に始めることが、現実的かつ説明可能な進め方となります。 制度対応と技術対策を一体で進めたい企業へ SCS評価制度への対応に加え、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストなどの実施範囲が決まっていない場合もご相談いただけます。制度上の要求と実際の攻撃リスクを結び付けることで、過不足の少ない対策計画と予算化につなげることが可能となります。 主な参考資料 IPA「サプライチェーン強化に向けたセキュリティ対策評価制度」 IPA「SCS評価制度の詳細情報」 IPA「要求事項・評価基準」 IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」 経済産業省「サイバーセキュリティ経営ガイドライン」 監修者 鎌田光一郎：青山学院大学法学部を卒業しました。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍しました。金融機関に対するコンサルティング業務に従事しました。その後、Librus株式会社を設立、代表取締役に就任しました。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015 お問い合わせフォーム

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

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

SCS評価制度は大企業だけではない｜中堅・中小企業に対応が求められる理由

結論からいえば、サプライチェーン強化に向けたセキュリティ対策評価制度（以下「SCS評価制度」）は、大企業だけを対象とする制度ではありません。業種や企業規模を問わず、サプライチェーンを構成する企業が対象になり得ます。とりわけ、従業員100～1,000名規模で、大企業の業務、システム運用、製造、物流、ソフトウェア開発などを受託する企業は、早めに準備を始める意義が大きいといえます。 SCS評価制度そのものは任意制度であり、国がすべての企業に★の取得を一律に義務付けるものではありません。しかし制度は、委託元が取引契約などで委託先に適切な段階（★）を示し、対策の実施と確認を促す使い方を想定しています。そのため、法令上の義務ではなくても、入札、取引開始、契約更新、委託先審査の条件として対応を求められる可能性があります。 本稿では、元請・一次請けから取引先へ取得要請が波及する構造を整理し、中堅・中小企業が何を、どの順番で準備すべきかを解説します。制度開始前の現段階で重要なのは、製品を急いで買うことではありません。対象範囲を定め、現状と要求事項の差を把握し、経営判断を伴う改善計画を作ることです。 この記事で分かること この記事を読むと、SCS評価制度が中堅・中小企業にも関係する理由、★3と★4の基本的な違い、取引先から要請を受ける前に整えておくべき資料、Webアプリケーション診断やプラットフォーム診断、ペネトレーションテストの位置づけ、準備期間と費用を左右する要因が分かります。さらに、社内稟議、ベンダー選定、改善後の運用まで、実務上の進め方を把握できます。 SCS評価制度とは何か SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策状況を共通基準で評価し、可視化する仕組みです。経済産業省と内閣官房国家サイバー統括室が制度構築を進め、独立行政法人情報処理推進機構（IPA）が運営します。★3と★4は2027年3月頃の運用開始が予定されています。制度の詳細や様式は今後も更新され得るため、実際の申請時にはIPAの最新版を確認する必要があります。 背景には、委託元が取引先の対策状況を外部から判断しにくい一方、委託先は顧客ごとに異なるチェックシートへの回答を繰り返しているという双方の負担があります。共通の基準で対策状況を示せれば、発注側は取引リスクを判断しやすくなり、受注側も説明を標準化しやすくなります。 制度の直接的な対象は、クラウド環境を含む企業のIT基盤です。一般にIT基盤に該当しない製造設備などの制御システム（OT）や、取引先へ提供する製品自体は直接の対象外とされています。ただし、それらに関するリスク対策が不要になるわけではありません。OTや製品については、該当する別の制度やガイドラインと組み合わせて管理することが必要です。 ★3と★4の違いをどう理解するか ★3は、SCS評価制度の要求事項・評価基準に基づいて企業が自己評価を行い、所定の研修を受けたセキュリティ専門家の確認を経て申請する仕組みです。経営層による自己適合宣誓も求められる予定であり、情報システム部門だけで完結するチェック作業ではありません。 ★4は、★3より広い範囲と高度な対策を対象とし、登録された第三者評価機関による評価を受ける仕組みです。技術検証を伴うため、規程があるかだけでなく、設定や運用が実際に機能しているかを示す証拠が重要になります。どの★を目指すかは、会社の規模だけでなく、委託業務の重要性、扱う情報、システム接続、停止時の影響、発注者の要求によって判断します。 なお、SCS評価制度は企業の優劣を競う格付け制度ではなく、対策の実施状況を可視化する制度です。また、特定のEDRや資産管理製品の購入が一律に必須となるわけでもありません。自社の環境とリスクに照らし、要求事項を満たす手段を選ぶことが基本です。 なぜ中堅・中小企業にも対応が求められるのか 最も大きな理由は、攻撃者が企業規模ではなく、サプライチェーン上の到達経路を見ているからです。大企業の防御が強固でも、保守会社、開発委託先、物流会社、会計・人事業務の受託先などが持つ認証情報や接続経路が侵害されれば、そこから委託元へ影響が及ぶ可能性があります。 IPAの「情報セキュリティ10大脅威 2026」では、「サプライチェーンや委託先を狙った攻撃」が組織向け脅威の2位に挙げられ、8年連続で選出されています。また警察庁によれば、2025年に報告されたランサムウェア被害226件のうち143件は中小企業でした。これらはSCS評価制度の取得義務を示す数字ではありませんが、企業規模にかかわらず、侵害と事業停止のリスクが現実に存在することを示しています。 発注企業にとって、委託先の事故は『他社の問題』で終わりません。サービス停止、納期遅延、個人情報や営業秘密の漏えい、顧客への説明、代替調達、復旧費用などが自社へ波及します。経済産業省のサイバーセキュリティ経営ガイドラインVer.3.0も、経営者が認識すべき原則としてサプライチェーン全体への目配りを示し、委託先との契約で役割と責任範囲を明確にすることを求めています。発注企業がSCS評価制度を取引先管理に使う流れは、この経営責任と整合します。 元請・一次請けから取得要請が波及する構造 要請は、発注元からすべての取引先へ一斉に広がるとは限りません。まず、重要データを扱う企業、発注元のネットワークへ接続する企業、停止すると供給継続に大きな影響が出る企業などに、一定の★や同等水準の対策が示されると考えられます。一次請けが業務の一部を再委託している場合、一次請け自身も再委託先のリスクを管理しなければなりません。このため、要求は二次請け、三次請けへ連鎖します。 例えば、大手メーカーが生産管理システムの運用をA社へ委託し、A社が監視や保守の一部をB社へ再委託しているとします。B社の端末からA社の環境へリモート接続できるなら、B社の認証管理や端末管理は大手メーカーの事業継続にも関係します。大手メーカーがA社に★4相当を求め、A社がB社に★3または同等の対策を求める構造は十分に想定できます。 また、★取得そのものを契約条件にしない場合でも、SCS評価制度の要求事項を委託先チェックシートやRFPに取り込む運用が考えられます。したがって、自社が直接大企業と契約していない、あるいは現時点で取得要請を受けていないという理由だけで、影響がないとは判断できません。主要顧客の業界、再委託関係、接続権限、保有データを確認する必要があります。 一方、発注者が一方的に過大な費用負担を押し付けてよいわけではありません。経済産業省は、★取得の契約上の扱いは当事者間で合意し、独占禁止法や中小受託取引適正化法（取適法）上、適切に制度を活用する必要があると説明しています。受注側は、要求範囲、期限、費用分担、契約価格への反映、再委託先に求める水準を具体的に協議することが重要です。 対応しない場合に起こり得る問題 SCS評価制度を取得していないだけで、直ちに取引が停止するわけではありません。しかし、発注者が合理的な理由から一定水準を契約条件や選定基準に定めた場合、未対応は新規入札での不利、追加質問や監査の増加、契約更新の遅延、取り扱える情報や接続権限の制限につながる可能性があります。重要なのは『★がないこと』だけでなく、対策状況と改善計画を説明できないことです。 インシデントが発生すれば、売上の減少だけでなく、復旧・調査費用、顧客通知、代替業務、法務対応、再発防止、保険対応が同時に発生します。受託業務が止まれば委託元の生産やサービスにも影響し、信用毀損や損害賠償の論点に発展することもあります。SCS対応は、認証マークを取るための費用ではなく、重要顧客との取引継続と事業継続を支える投資として稟議に載せるべきです。 どの企業・システムから優先して考えるべきか 優先度が高いのは、大企業や重要インフラ企業から業務を受託している企業、顧客の個人情報・設計情報・営業秘密を保有する企業、顧客環境へリモート接続する企業、SaaSやシステム開発・運用を提供する企業、停止時に代替が難しい部品やサービスを供給する企業です。IPO、M&A、金融機関からの審査、重要な取引先監査を控える企業も、対策状況を説明できるようにしておく価値があります。 対象範囲を決める際は、法人全体を機械的に一括評価するのではなく、組織、拠点、ネットワーク、クラウド、端末、委託業務、データの流れを整理します。ただし、都合のよい狭い範囲だけを切り出すと、共通ID基盤、管理端末、バックアップ、委託先接続などの重要な依存関係を見落とします。『どこが侵害されると対象業務へ影響するか』を基準に境界を設定します。 SCS評価制度への具体的な対応手順 最初に経営層が、対応目的と責任者を決めます。目的は、主要顧客の要請への対応、取引継続、新規受注、事業継続、監査対応など、経営課題の言葉で定義します。同時に、★3と★4のどちらを想定するか、対象業務と拠点、予算、期限、許容できるリスクを仮決定します。顧客の要求が不明な場合は、調達部門や取引窓口を通じて、想定する★、適用時期、対象契約を確認します。 次に、情報システム部門と関係部門が証拠資料を集めます。最低限、組織図、情報セキュリティ規程、資産台帳、ネットワーク構成図、クラウド・SaaS一覧、アカウントと権限の管理手順、ログ管理、脆弱性・パッチ管理、バックアップと復旧手順、インシデント対応計画、教育記録、委託先一覧・契約、過去の診断結果と改善記録を準備します。規程だけでなく、申請、承認、設定画面、チケット、訓練記録など、運用の実態を示す証跡が必要です。 その後、要求事項とのギャップ分析を行います。各項目を『対応済み』『一部対応』『未対応』『非該当』に分け、根拠と責任者を明記します。非該当とする場合は理由を残します。未対応項目は、攻撃の起こりやすさ、影響の大きさ、顧客要求、是正に必要な期間を踏まえて優先順位を付けます。 技術面では、設定確認だけでなく、外部から到達できるWebサイトやAPIにはWebアプリケーション診断、サーバー・ネットワーク機器・クラウド設定にはプラットフォーム診断を検討します。Webアプリケーション診断は認証や入力処理などアプリ固有の弱点を、プラットフォーム診断はOS、ミドルウェア、ネットワーク、クラウド構成の弱点を確認するものです。 さらに、重要システムについて攻撃経路全体の実効性を確認したい場合は、ペネトレーションテストが有効です。これは、許可された範囲で攻撃者と同様の手法を用い、侵入や権限拡大、重要情報への到達可能性を検証する試験です。ただし、診断やペネトレーションテストを一度実施するだけでSCS対応が完了するわけではありません。制度は、ガバナンス、教育、委託先管理、検知、対応、復旧なども含む総合的な管理を扱います。 改善計画では、短期、中期、継続運用に分けます。初期設定の是正、多要素認証、不要アカウントの削除などは短期で進めやすい一方、ネットワーク分離、ログ基盤、バックアップ再設計、規程改定、委託先契約の見直しには時間がかかります。各施策に責任者、期限、予算、完了条件、確認方法を設定し、経営会議で残存リスクを承認します。最後に、想定する評価方式に合わせて自己評価、専門家確認または第三者評価へ進みます。 実施期間と費用を左右する要因 準備期間は企業ごとの差が大きく、一律の標準期間を示すことは適切ではありません。すでにISMSや顧客監査を運用し、資産台帳や証跡が整っている企業と、規程や担当者が未整備の企業では必要な作業が異なります。制度開始から逆算するなら、まず数週間程度で対象範囲と現状を把握し、その結果に基づいて改善工程を見積もる進め方が現実的です。システム改修や調達、規程承認を伴う場合は、半期または年度の予算策定を待たず、段階的に着手する必要があります。 費用を左右する主な要因は、対象拠点・システム・アカウント数、目指す★、既存規程と運用の成熟度、クラウドや海外拠点の有無、技術検証の範囲、診断対象の画面数・IP数、改善実装を外部へ委託する範囲です。見積りでは、評価支援費だけでなく、規程整備、技術対策、教育、診断、再確認、継続運用の費用を分けて示してもらうと、社内説明がしやすくなります。 社内稟議では、制度対応費を単独で示すのではなく、守るべき売上、主要顧客との契約更新時期、事故時の停止影響、既存施策との重複、翌年度以降の運用費を記載します。『なぜ今か』に対しては、制度開始直前に人材や評価枠が集中する可能性、改善に調達・承認期間を要すること、顧客からの要請後では期限を選びにくいことを説明するとよいでしょう。 成果物と改善の優先順位 支援会社から受け取る成果物には、対象範囲、前提条件、要求事項ごとの評価、根拠資料、発見事項、リスク、改善案、優先順位、責任部署、期限、概算負荷を含めるべきです。経営層向けには、取引・財務・事業継続への影響を要約した資料が必要です。現場向けには、具体的な設定変更や運用手順まで落とし込まれていることが望まれます。 優先順位は、単純に未対応項目の数で決めません。外部公開されている、特権権限がある、顧客環境に接続する、機密情報を大量に扱う、バックアップから復旧できない、といった重大な経路を先に是正します。診断で見つかった脆弱性も、深刻度スコアだけでなく、実際の攻撃可能性、情報価値、代替策、事業影響を合わせて判断します。改善後は再診断または設定再確認を行い、残存リスクを記録します。 SCS対応を支援する会社の選び方 支援会社を選ぶ際は、制度資料を説明できるだけでなく、要求事項を実際の規程、運用、技術対策へ落とし込めるかを確認します。RFPや見積依頼には、想定する★、対象組織、対象システム、希望時期、既存認証、顧客要求、必要な成果物、改善実装の要否、診断の要否を記載します。分からない項目は未定とし、スコーピング支援を依頼して構いません。 確認したい点は、SCS評価制度に関する支援範囲、担当者の資格と実務経験、評価と改善支援の役割分担、Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストの対応能力、再診断、緊急時支援、機密情報の保管と削除、再委託、報告書のサンプル、追加費用の条件です。★4の評価を依頼する場合は、IPAが公表する登録状況と、評価の独立性に関する条件も確認します。 秘密保持契約だけで安心せず、資料の受渡方法、アクセス権、保存場所、保存期間、作業端末、作業ログ、廃棄証明、事故時の連絡期限を合意します。特に構成図、脆弱性情報、認証方式は攻撃に悪用され得るため、閲覧者を必要最小限に限定します。 よくある失敗と注意点 第一の失敗は、チェックリストを埋めること自体を目的にすることです。規程上は実施することになっていても、退職者アカウントが残り、バックアップ復旧を試したことがなければ、実効性は十分とはいえません。担当者へのヒアリング、証跡確認、技術検証を組み合わせる必要があります。 第二の失敗は、情報システム部門へ丸投げすることです。予算、人員、取引条件、リスク受容、委託先契約は経営判断を伴います。経営層、情報システム部門、法務・調達、事業部門が責任を分担しなければ、申請直前に承認が止まります。 第三の失敗は、認証取得後の運用を設計しないことです。人事異動、クラウド追加、システム更新、脆弱性の公表によりリスクは変化します。資産台帳、権限棚卸し、教育、パッチ、ログ監視、バックアップ試験、インシデント訓練、委託先確認を年間計画に組み込みます。 第四の失敗は、制度開始前の不確かな説明をうのみにすることです。IPAは不適切な勧誘への注意喚起も行っています。現時点で評価機関やSCSセキュリティ専門家の公表は今後予定されているため、『必ず取得できる』『指定済み』といった説明は、公的情報で確認してください。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度への対応方針の整理から、対象範囲の設定、要求事項とのギャップ分析、規程・運用の整備、技術的な検証、改善計画、継続運用まで一気通貫で支援します。経営層には取引・財務・事業継続の観点で、情報システム部門には具体的な証跡と実装の観点で説明し、社内の合意形成を進めます。 必要に応じて、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築・運用支援、インシデントレスポンス、デジタルフォレンジック、教育・訓練などを組み合わせます。診断結果を報告して終えるのではなく、企業ごとのシステム、予算、人員、顧客要求に応じて改善の優先順位を設計し、運用へ定着させることを重視しています。 大企業向けの高負荷な仕組みをそのまま導入するのではなく、必要な水準を保ちながら、既存の規程、ツール、委託サービスをできるだけ活用します。SCS評価制度への対応だけでなく、M&A、IPO、取引先監査などの重要局面も見据え、技術と経営の両面から整理できる点がLibrus株式会社の強みです。 よくある質問 SCS評価制度は中小企業にも義務ですか？ 国がすべての中小企業へ取得を義務付ける制度ではなく、任意制度です。ただし、発注者が取引契約、入札、委託先審査などで一定の★または同等水準を求める可能性があります。主要顧客の方針を早めに確認してください。 取得しないと取引を停止されますか？ 未取得だけで自動的に取引停止になる制度ではありません。契約上の扱いは当事者間で合意されます。要請を受けた場合は、必要性、期限、費用負担、代替的な確認方法を協議し、改善計画を提示することが重要です。 ★3と★4のどちらを選ぶべきですか？ 会社規模だけでは決まりません。扱う情報、顧客環境への接続、停止時の影響、委託業務の重要性、顧客要求を基に判断します。顧客指定がなければ、リスク分析とギャップ分析を行って適切な段階を選びます。 ISMSを取得していればSCS対応は不要ですか？ 不要とは限りません。ISMSとSCS評価制度は相互補完的に位置づけられています。既存のISMS文書や運用証跡は活用できますが、SCSの要求事項・評価基準との差分確認が必要です。 SCS対応には特定のセキュリティ製品が必要ですか？ 制度は特定製品の導入を一律には求めていません。既存の仕組みで要求事項を満たせる場合もあります。製品選定より先に、対象範囲とリスク、現状の運用を確認してください。 脆弱性診断を受ければ取得できますか？ 診断だけで完了するものではありません。診断は技術的な弱点を確認する重要な手段ですが、ガバナンス、資産管理、権限管理、教育、委託先管理、インシデント対応、復旧なども整える必要があります。 準備はいつから始めるべきですか？ 顧客から正式要請を受ける前が望ましい時期です。まず対象範囲と現状を短期間で把握し、予算やシステム改修が必要な項目を早期に特定します。2027年3月頃の運用開始予定から逆算して計画してください。 対象範囲が決まっていなくても相談できますか？ 可能です。業務、取引関係、データ、システム接続、停止影響を整理し、合理的な対象範囲と想定する★を決める段階から専門家の支援を利用できます。 まとめ｜SCS評価制度は取引継続の共通言語になる サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、大企業だけの制度ではありません。任意制度であっても、元請・一次請けが契約や委託先審査で活用すれば、要求は二次請け以降へ波及します。中堅・中小企業に必要なのは、要請を待って製品を買うことではなく、主要顧客との関係、重要業務、データ、接続経路を把握し、要求事項とのギャップを計画的に埋めることです。 経営層は取引継続と事業継続の観点から目的、責任者、予算を決め、情報システム部門は資産・規程・運用証跡を整えます。必要に応じてWebアプリケーション診断、プラットフォーム診断、ペネトレーションテストを使い分け、改善後も再確認と継続監視を行います。早めの準備は、顧客からの照会に答える力を高めるとともに、自社の事故リスクを下げる機会になります。 Librus株式会社へのご相談 SCS評価制度の準備状況を一度整理しませんか 取引先から具体的な要請が届く前に、対象業務、システム、現状の対策、必要な改善を整理しておくと、予算化と顧客説明を進めやすくなります。Librus株式会社では、想定する★や対象範囲が決まっていない段階から、スコーピングとギャップ分析をご相談いただけます。 取引先からの要請に、実行可能な計画で応えるために SCS対応では、短期間にすべてを入れ替えるのではなく、重要なリスクから優先して改善することが大切です。Librus株式会社は、顧客要求の読み解き、社内稟議、規程整備、技術対策、診断、改善後の確認まで支援し、説明可能なロードマップづくりをお手伝いします。 制度対応と実効性のあるセキュリティを両立 ★の取得だけを目的にすると、運用負荷や形骸化が残りかねません。Librus株式会社は、既存の規程やツールを活かしながら、事業継続と取引先の信頼につながる対策を個別に設計します。まずは現状確認だけ、診断の要否だけといったご相談にも対応します。 参考資料・出典 制度の詳細は更新される可能性があります。公開・申請時には、以下の公的機関による最新版をご確認ください。 経済産業省：サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度） IPA：SCS評価制度 公式サイト IPA：SCS評価制度の詳細情報 IPA：要求事項・評価基準 IPA：SCS評価制度 よくある質問 経済産業省：サイバーセキュリティ経営ガイドラインVer.3.0 IPA：情報セキュリティ10大脅威 2026 警察庁：令和7年におけるサイバー空間をめぐる脅威の情勢等について 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度の★3と★4を徹底比較｜自社はどちらを目指すべきか

はじめに サプライチェーン強化に向けたセキュリティ対策評価制度（以下「SCS評価制度」）は、取引先との間で求めるサイバーセキュリティ対策の水準を共通化し、その実施状況を可視化する仕組みです。★3と★4では、単にチェック項目の数が違うだけではありません。守るべき範囲、侵入後を見据えた対策、評価の客観性、技術検証の有無が大きく異なります。 経済産業省と内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、IPAが制度を運営します。★3・★4は2027年3月頃の運用開始が予定されています。2026年9月3日現在、申請・登録費用や申請方法の詳細は未公表です。そのため、本記事では確定情報と実務上の見立てを明確に分けて説明します。 この記事で分かること ★3と★4の対象企業、要求水準、評価方式の違い 自社がどちらを目指すべきかを判断するための基準 準備期間と費用を左右する要因、社内稟議での説明ポイント Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストの位置付け 取得準備から改善・運用までの具体的な進め方 SCS評価制度とは SCS評価制度は、発注者が受注者に適切な対策段階を示し、受注者がその水準の対策を実施していることを評価・登録する制度です。対象の中心は、企業活動を支えるIT基盤です。 製造設備などのOTシステムや、顧客へ納入する製品そのものは、原則として直接の対象外です。OTとは、工場設備などを監視・制御する技術を指します。これらには別の制度やガイドラインによる対策が想定されています。 星3は、一般的なサイバー脅威へ対処できる水準です。星4は初期侵入を防ぐだけでなく、侵入後の被害拡大、攻撃目的の遂行、取引先への波及を抑える対策まで求めます。 上位段階は下位段階の内容を含みますが、星3を取得してからでなければ星4へ進めないという前提ではありません。 ★3と★4の違いを一覧で比較 比較項目★3★4位置付け一般的なサイバー脅威に対処し得る基礎水準侵入後の被害拡大や取引先への波及まで抑える標準的水準主な対象幅広い企業。まず共通的な対策基盤を整えたい企業重要な情報・接続・業務を担い、停止や漏えいの波及が大きい企業評価方式セキュリティ専門家の確認を受けた自己評価指定された評価機関による第三者評価確認方法作成書類を専門家が確認し、助言・署名文書確認に加え、実地審査と技術検証経営層の関与自己適合宣誓を含む組織的運用と客観的な証跡提示がより重要技術面基本的な防御、検知、対応、復旧を整備セグメント分離、監視、侵入・横展開耐性などをより深く検証費用・期間外部専門家の確認、文書整備、改善範囲に左右される第三者評価、実地審査、技術検証、対象拠点・システム数により増えやすい 出典：IPA「SCS評価制度の詳細情報」および経済産業省「SCS評価制度」よりLibrus株式会社作成（2026年9月3日確認） IPA / 経済産業省 対象企業の違い：規模ではなく、取引上の役割で判断する 従業員100人から1,000人という規模だけで、★3か★4かは決まりません。判断の中心は、サプライチェーンにおける自社の役割と、事故が起きた際の影響度です。取引先から預かった個人情報や設計情報を大量に扱う、取引先ネットワークへ常時接続する、基幹部品や重要サービスを代替困難な形で供給するといった企業は、★4の必要性が高まります。 一方、外部との接続が限定的で、重要情報の取扱いが比較的少なく、まず全社の基本対策と運用証跡を整える段階であれば、★3を目標にするのが現実的です。ただし、発注者が契約・調達条件として★4を求める場合は、自社判断だけで★3にとどめることはできません。営業、調達、法務、情報システム部門で主要取引先の要請を確認する必要があります。 ★3を目指すべき企業 ★3は「セキュリティ製品を一通り導入している企業」ではなく、基本対策がルール、責任者、実装、証跡までつながっている企業に適します。情報資産台帳が未整備、退職者アカウントの削除が部門任せ、バックアップの復元試験をしていないといった状態では、製品導入済みでも評価準備は不足しています。まず★3を通じて、全社共通の最低ラインを作る意義があります。 ★4を目指すべき企業 ★4は、侵入が起こり得ることを前提に、被害を局所化し、早期に検知し、事業と取引先への影響を抑える能力まで示したい企業に向きます。大手企業の重要委託先、クラウド・SaaS事業者、システム開発・運用会社、物流・決済・BPOなど停止時の影響が広い企業、M&AやIPOでセキュリティ管理の客観性を示したい企業が典型です。 要求水準の違い：★4は『侵入させない』から『広げない・止めない』へ ★3でも、ガバナンス、取引先管理、リスク特定、攻撃防御、検知、インシデント対応、復旧といった一連の管理が必要です。★4ではこれらをより深く実装し、第三者が追跡できる証跡として提示する必要があります。たとえば、多要素認証を導入したという事実だけでなく、どのアカウントを対象にし、例外を誰が承認し、設定が継続しているかまで説明できる状態が重要です。 攻撃例で考えると分かりやすくなります。VPN機器の脆弱性から侵入された場合、★3では機器の把握、更新、アクセス制御、ログ取得、連絡体制などの基本対策が焦点です。★4ではさらに、侵入された端末から基幹システムへ横展開できないネットワーク分離、特権IDの厳格管理、異常挙動の監視、封じ込め手順、取引先への連絡判断まで含めて実効性を確認します。 評価方式の違い：★3は専門家確認付き自己評価、★4は第三者評価 ★3の評価プロセス ★3では、取得希望組織が要求事項・評価基準に沿って自己評価を行い、登録された社内外のセキュリティ専門家が内容を確認します。専門家は必要に応じて評価結果の修正を助言し、提出内容を了承した場合に署名します。その後、経営層による自己適合宣誓を含む評価結果を事務局へ提出し、問題がなければ台帳へ登録されます。自己評価であっても、担当者の感覚だけで丸を付ける制度ではありません。 ★4の評価プロセス ★4では、自己評価を出発点に、指定された評価機関へ検証・評価を依頼します。評価機関と技術検証事業者は、文書確認、実地審査、技術検証を行い、評価報告書を作成します。取得希望組織はその結果をもとに事務局へ登録を申請します。評価対象は、組織が決めた適用範囲からサンプリングされる想定です。適用範囲を狭く見せるのではなく、取引リスクに照らして合理的に説明できることが重要です。 Webアプリケーション診断・プラットフォーム診断・ペネトレーションテストの位置付け ★4の技術検証では、書類上のルールだけでなく、実装上の弱点がないかを確かめます。Webアプリケーション診断は、認証、入力処理、セッション管理、アクセス制御などWeb特有の脆弱性を調べる手法です。プラットフォーム診断は、サーバー、ネットワーク機器、OS、ミドルウェアの設定不備や既知脆弱性を確認します。 ペネトレーションテストは、現実的な攻撃シナリオに沿って侵入可能性や侵入後の影響を検証する試験です。脆弱性診断が弱点を網羅的に見つけることを得意とするのに対し、ペネトレーションテストは弱点を組み合わせたときに、重要情報への到達や権限昇格が可能かを確かめます。両者は代替関係ではありません。対象資産、脅威シナリオ、制度上の技術検証仕様に応じて組み合わせる必要があります。 なぜ今、準備を始めるべきか 制度開始まで待ってから着手すると、台帳や規程は作れても、運用実績という証跡が不足しがちです。アクセス権棚卸し、教育、脆弱性対応、バックアップ復元試験、インシデント訓練は、一度実施して終わるものではありません。計画、実施、記録、改善のサイクルが回っていることを示すには時間がかかります。 また、日本企業では次年度予算の要求、相見積もり、稟議、契約、対象部門との日程調整に数か月を要することがあります。特に★4では、第三者評価の前に不足事項を直す期間と、技術検証の対象システム所有者との調整が必要です。2027年3月頃の運用開始を見据えるなら、現状評価と適用範囲の整理は早めに着手する価値があります。 対応しなかった場合に起こり得る問題 SCS評価制度は任意制度として設計されていますが、取引の現場では発注者の調達条件や取引先評価へ組み込まれる可能性があります。未取得が直ちに取引停止を意味するわけではありません。しかし、同等の品質・価格で競合が必要な段階を取得している場合、選定上の説明力で差がつくことは考えられます。 より本質的な問題は、取得できない背景にある管理不備です。資産が把握できていなければ、重大な脆弱性が公表されても影響範囲を判断できません。ネットワークが分離されていなければ、一台の端末感染が生産、受発注、会計へ広がる可能性があります。連絡基準がなければ、取引先への報告が遅れ、信用毀損や契約上の問題を拡大させます。評価対応は、取引資格のためだけでなく事業継続の整備として捉えるべきです。 ★3・★4取得に向けた具体的な進め方 1．経営層が目標段階と適用範囲を決める 最初に、主要取引先の要請、自社が保有する情報、システム停止時の影響、取引先ネットワークとの接続を整理します。そのうえで★3・★4のどちらを目指すか、全社か特定事業・拠点か、責任者と予算枠を決定します。適用範囲は評価工数と費用へ直結しますが、重要な業務を恣意的に除外すると制度の利用目的に合いません。 2．要求事項とのギャップを可視化する 規程の有無だけではなく、実装と運用証跡を確認します。必要資料は、組織図、情報セキュリティ方針・規程、情報資産台帳、ネットワーク構成図、クラウド利用一覧、アカウント・権限一覧、ログ管理方針、脆弱性管理記録、バックアップ設計、委託先一覧、教育記録、インシデント対応手順などです。資料が存在しても現状と一致しなければ、不備として扱って改善します。 3．リスクに応じて改善の優先順位を付ける すべてを同時に直すのではなく、悪用可能性と事業影響で優先順位を付けます。インターネットへ公開された既知脆弱性、管理者アカウントへの多要素認証未導入、バックアップの同一ネットワーク保管、退職者IDの残存などは優先度が高い典型です。規程改定だけで解決する項目と、製品導入・設計変更・教育が必要な項目を分けると、稟議と実行計画が組みやすくなります。 4．技術検証とリハーサルを行う ★4を目指す場合は、本番の第三者評価前にWebアプリケーション診断、プラットフォーム診断、必要に応じたペネトレーションテストを実施し、重大な不備を修正します。★3でも、自己評価の確度を高めるため診断は有効です。診断では対象IP、URL、アカウント、試験時間帯、禁止事項、障害時連絡先、個人情報・機密情報の取扱いを事前に合意します。 5．経営層の確認を経て申請し、取得後も運用する 評価直前だけ帳尻を合わせると、更新時や取引先監査で運用実態とのずれが表面化します。発見事項は、責任者、期限、暫定対策、恒久対策、再確認方法を付けて管理します。再診断、ログ監視、教育、インシデント訓練を年間計画へ組み込み、システムや組織の大きな変更時には適用範囲と評価への影響を見直します。 費用と期間を左右する要因 2026年9月3日現在、★3・★4の申請・登録費用は公表されていません。したがって、確定額として見積もれるのは制度料金ではなく、自社の準備・改善、専門家支援、診断・技術検証などの周辺費用です。★4は第三者評価、実地審査、技術検証を伴うため、一般に★3より工数が大きくなる構造ですが、正式価格は公表後に確認する必要があります。 費用と期間を左右する主な要因は、対象拠点・法人・システム数、クラウドとオンプレミスの混在、規程・台帳の整備度、ネットワーク構成の複雑さ、技術検証対象の数、重大不備の改修難易度、証跡の蓄積状況です。従業員数が同じでも、一拠点で標準化された企業と、買収した複数法人が別々のIT環境を持つ企業では大きく異なります。 実施期間の目安は、制度の正式な審査日数ではなく準備プロジェクトとして見積もるべきです。現状評価、改善計画、規程・実装の改修、運用証跡の蓄積、事前確認、本評価という工程へ分け、各工程に社内承認と調整期間を加えます。短期間の取得を約束する事業者より、前提条件とボトルネックを明示する事業者の方が信頼できます。 社内稟議で説明すべき内容 稟議では「制度対応が必要だから」だけでなく、売上防衛と事業継続の両面を示します。主要取引先の売上比率、求められる段階、未対応時の入札・更新への影響、事故時の停止業務、法務・広報・復旧費用への波及を整理します。そのうえで、取得支援費、改善費、評価費を分け、今年度と次年度の予算へ配置します。 経営層が判断すべき事項は、目標段階、適用範囲、許容する残余リスク、責任者、予算、重大不備の是正期限です。情報システム部門だけに丸投げせず、法務は契約・報告義務、人事は教育と入退社、調達は委託先管理、事業部門は重要業務と復旧目標を担う体制が必要です。 支援会社・評価関連事業者の選び方 制度取得支援と、★4の第三者評価は役割が異なります。支援会社を選ぶ際は、要求事項の説明だけでなく、技術面の検証と改善、経営層への説明、取得後の運用まで一貫して支援できるかを確認します。第三者評価を担う評価機関については、IPAが公表する指定状況と、中立性・公平性に関する最新要件を必ず確認してください。 RFPまたは見積依頼では、対象範囲、前提資料、現地訪問の有無、診断対象数、成果物、再確認の条件、追加費用、機密情報の保管場所と削除時期、再委託の有無、インシデント発生時の責任分界を明記します。成果物には、要求事項別の適合状況、根拠資料、ギャップ、リスク評価、優先順位、改善案、担当部門、期限、評価前に残る論点が含まれるかを確認しましょう。 よくある失敗と注意点 製品導入をそのまま適合と考える SCS評価制度は特定製品の導入を必須としていません。EDRやMFAを導入していても、対象漏れ、設定不備、アラート放置があれば実効性は不足します。製品名ではなく、要求事項に対してどの仕組みがどう機能し、誰が証跡を確認するかを説明できる状態にします。 適用範囲をIT部門だけで決める 重要な委託業務や取引先データの流れは、事業部門や営業部門にしか分からないことがあります。ネットワーク図だけで範囲を決めると、業務委託先、SaaS、個人端末、海外拠点が漏れます。業務フローとデータフローを重ねて判断してください。 診断を一度実施して終える 診断結果は、その時点の対象と設定に対するスナップショットです。新しい脆弱性、システム変更、アカウント追加で状況は変わります。重大度だけでなく、外部公開、保有データ、悪用経路、代替策を踏まえて期限を決め、修正後の再診断まで完了させる必要があります。 制度の未公表事項を確定情報として扱う 申請料金、申請手順、解説書などは順次公表予定です。古い検討資料や民間記事だけで稟議を確定すると、後で条件が変わる可能性があります。IPAと経済産業省の公式ページを基準日付きで確認し、見積書にも未確定事項を明記することが大切です。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度への対応を単なるチェックリスト作成で終わらせず、経営リスクと技術リスクを一つの改善計画へ落とし込みます。現状評価、適用範囲の整理、規程・台帳整備、リスクアセスメント、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、SOC／CSIRT構築、教育・訓練、インシデントレスポンスまで一気通貫で支援可能です。 企業ごとの業務、既存製品、予算、取引先要請を踏まえて個別設計するため、過剰な製品導入を前提にしません。経営層には事業継続・取引維持・投資優先順位の言葉で、情報システム部門には実装・証跡・運用の言葉で整理し、両者の意思決定をつなぎます。M&A、IPO、取引先監査など、短期間で説明責任が高まる局面にも対応します。 よくある質問 Q1．★3を取得してからでなければ★4を取得できませんか。 いいえ。★4は★3の内容を含みますが、★3の事前取得は必須ではありません。現状の成熟度と取引先要請が合えば、最初から★4を目指せます。 Q2．従業員数が多い企業は必ず★4ですか。 いいえ。規模だけでは決まりません。重要情報の取扱い、取引先との接続、供給停止の影響、発注者の要求で判断します。 Q3．★3は完全な自己評価ですか。 いいえ。取得希望組織が自己評価を行いますが、登録されたセキュリティ専門家の確認・助言・署名と、経営層の自己適合宣誓が必要です。 Q4．★4では何が追加されますか。 第三者評価に加え、文書確認、実地審査、技術検証が行われます。侵入後の被害拡大や取引先への波及を抑える対策も重要になります。 Q5．★4にはペネトレーションテストが必須ですか。 技術検証の具体的な対象・手法は制度の最新文書と評価機関の計画で確認が必要です。制度構築方針では、技術検証事業者の対象となる脆弱性診断サービスにペネトレーションテストを含む整理が示されています。 Q6．申請費用はいくらですか。 2026年9月3日現在、申請・登録費用は未公表です。準備支援、改善、診断、第三者評価などを分けて見積もり、制度料金は公表後に更新してください。 Q7．準備にはどのくらいかかりますか。 一律の期間はありません。対象範囲、資料整備、重大不備、技術検証対象、社内承認で変わります。まず短期間のギャップ分析を行い、工程別に見積もる方法が現実的です。 Q8．ISO/IEC 27001を取得済みなら対応不要ですか。 既存の管理策や証跡は活用できますが、自動的にSCS評価制度へ適合するとは限りません。SCSの要求事項・評価基準との対応関係を確認する必要があります。 まとめ：★3を基礎線、★4を取引・事業影響に応じた目標として判断する SCS評価制度の★3と★4の本質的な違いは、★3が一般的な脅威へ対処するための専門家確認付き自己評価であるのに対し、★4は侵入後の被害拡大と取引先への波及まで見据え、第三者評価・実地審査・技術検証で客観性を高める点にあります。 自社が目指す段階は、従業員数ではなく、取引先の要求、扱う情報、外部接続、供給停止の影響で決めます。迷う場合は、★3・★4の両方に対して現状ギャップを可視化し、必要な改善費と事業上の効果を比較するのが近道です。制度開始前から証跡を蓄積すれば、取得対応を一過性の作業ではなく、取引継続と事業継続を支える仕組みにできます。 ★3・★4の選択から整理したい企業さまへ 取引先から具体的な段階を指定されていない場合でも、主要業務、データ、接続先、停止影響を整理すれば、自社が目指す水準は見えてきます。Librus株式会社では、対象範囲や実施方法が決まっていない段階から、★3・★4それぞれのギャップと概算工程を整理します。社内説明に使える判断材料を先に作りたい場合もご相談いただけます。 出典・参考資料 経済産業省｜サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度） 経済産業省｜制度構築方針の公表 IPA｜SCS評価制度の詳細情報 IPA｜要求事項・評価基準 IPA｜よくある質問 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎） 〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F 03-6772-8015 お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE

SCS評価制度は義務なのか―取得しない企業に起こり得ること

SCS評価制度の★取得は、現時点で民間企業に一律に課された法的義務ではありません。ただし、発注者が取引条件・選定基準・契約更新条件として求めることは想定されており、未取得が受注機会や取引継続に影響する「事実上の要請」へ発展する可能性があります。したがって、法律上の強制の有無だけで判断せず、自社の取引構造と求められる★水準を確認し、取得準備と実質的な対策を並行して進めることが重要です。 サプライチェーン強化に向けたセキュリティ対策評価制度（以下「SCS評価制度」）は、企業のIT基盤におけるセキュリティ対策を共通の基準で評価し、星の段階で可視化する制度です。IPAの公表情報では、★3・★4は2027年3月頃の運用開始が予定されています。本稿は2026年9月3日時点の公表資料に基づき、法的義務と取引上の要請の違い、未取得時のリスク、実務的な準備方法を整理します。 この記事で分かること 未取得の場合に想定される取引・経営上の影響 ★3と★4の違いと、自社が目指す水準の考え方 経営層・情報システム部門が今から進める準備 SCS評価制度とは何か SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策状況を共通基準で評価・可視化し、委託元と委託先の双方が対策水準を確認しやすくする仕組みです。制度は経済産業省および内閣官房国家サイバー統括室の監督のもと、独立行政法人情報処理推進機構（IPA）が運営します。 制度が想定する中心的な場面は、二社間の取引です。発注者が受注者に適切な★水準を提示し、受注者が対策を実施したうえで、その状況を確認できるようにします。従来、発注者ごとに異なる質問票が送られ、受注者が似た質問へ何度も回答することがありました。共通の評価基準が普及すれば、発注者は取引先を評価しやすくなり、受注者も自社の対策状況を説明しやすくなります。 ★3と★4の違い ★3は「一般的なサイバー脅威に対処し得る水準」とされ、取得希望企業による自己評価に、登録されたSCSセキュリティ専門家の確認・署名と経営層の自己適合宣誓を組み合わせる仕組みです。★4は、初期侵入の防御だけでなく被害拡大防止や取引先のデータ・システム保護まで含む水準で、評価機関による第三者評価と技術検証が求められます。上位段階は下位段階を包括しますが、★4の取得に★3の先行取得が必須という関係ではありません。 対象は原則として、メールサーバー、Webサーバー、認証基盤、端末、ネットワーク、クラウド環境など企業のIT基盤です。製造設備を制御するOTシステムや、取引先へ提供する製品そのものは基本的に直接対象とせず、別の制度・ガイドラインによる対応が想定されています。ただし、ITとOTの接続点や製品開発環境が企業IT基盤と共通化している場合、境界の整理が欠かせません。 SCS評価制度は義務なのか 法律上、一律の取得義務ではない 2026年9月3日時点の公表資料を見る限り、すべての民間企業に★取得を直接命じ、未取得そのものに罰則を科す法律上の義務として設計されているわけではありません。対象業種や企業規模を限定せず、サプライチェーンに属する幅広い企業が活用できる制度ですが、「制度の対象になり得ること」と「取得が法的に強制されること」は別問題です。 また、個人情報保護法、業法上の安全管理措置、契約上の秘密保持義務など、企業が別途負う法令・契約上の責任はSCS評価制度の取得有無で消えるものではありません。★を取得していなくても必要な安全管理措置は実施しなければならず、反対に★を取得しても、あらゆる法令遵守や事故防止が自動的に保証されるわけではありません。 取引上は「対応必須」になる可能性がある 重要なのは、法的義務と取引上の要請を分けて考えることです。制度は、発注者が取引先に適切な★水準を提示する利用を想定しています。発注者がRFP（提案依頼書）、新規取引の審査、委託先選定、契約更新、重要業務への参画条件などに★取得を組み込めば、受注者にとっては事実上の必須条件となり得ます。 たとえば「★4取得済み、または期限までの取得計画を提出できること」が入札条件になれば、法律による強制がなくても、条件を満たさない企業は比較対象から外れる可能性があります。一方、発注者側も、取引上の立場を利用して一方的に過大な費用負担を押し付けてよいわけではありません。経済産業省と公正取引委員会は、セキュリティ対策の要請と価格交渉を円滑に行うための想定事例を示しています。要請内容、必要性、費用、期限を協議し、契約条件へ明確に落とし込む姿勢が双方に求められます。 SCS評価制度を取得しない企業に起こり得ること 新規案件の候補から外れる 最も現実的な影響は、新規取引の入口で評価されにくくなることです。大手企業が多数の委託先を短期間で選別する場合、共通マークは確認項目を標準化する材料になります。未取得企業が直ちに失格になるとは限りませんが、個別質問票への回答、追加監査、証憑提出が必要になり、営業提案のスピードと比較可能性で不利になるおそれがあります。 既存取引の更新条件が厳しくなる 基幹業務、顧客情報、設計情報、認証情報を扱う委託では、契約更新時にセキュリティ条項が見直されることがあります。未取得のままでは、改善計画の提出、現地監査、診断結果の提示、事故時報告期限の短縮、再委託先管理の強化など、個別条件が追加される可能性があります。対応できなければ、委託範囲の縮小や代替ベンダーへの切替が検討される場合もあります。 質問票・監査対応の負担が残る SCS評価制度を取得しない場合、自社の安全性を別の証拠で説明する必要があります。ISMS認証、SOC報告書、社内規程、資産台帳、教育記録、脆弱性診断報告書、インシデント対応訓練記録などを取引先ごとに組み直すと、情報システム部門だけでなく営業、法務、総務、内部監査にも作業が波及します。取得コストだけでなく、未取得のまま個別対応を続ける運用コストも比較すべきです。 事故発生時の説明が難しくなる 未取得そのものが事故原因になるわけではありません。しかし、ランサムウェア感染、委託先アカウントの不正利用、Webアプリケーションからの情報漏えいなどが起きた際、経営層は「どの基準で対策水準を判断したか」「既知の不足をなぜ放置したか」を説明する必要があります。公的な共通基準に照らしたギャップ分析や改善記録がなければ、顧客、株主、金融機関、監督官庁への説明が属人的になりやすく、復旧以外の対応負荷が増えます。 予算化が後手に回る 取引先から短い期限で取得を求められてから着手すると、年度予算外の対応になりやすくなります。規程の整備だけでなく、多要素認証、端末管理、バックアップ、ログ管理、脆弱性対応、委託先管理など技術・運用双方の改善が必要になる場合があります。複数部門やクラウド事業者との調整もあるため、単なる申請作業として扱うと期限と予算が合いません。 どの企業が優先して準備すべきか 従業員100名以上の規模では、IT環境が複雑化する一方、専任のセキュリティ人材が限られるケースがあります。特に、次のような企業は早めに発注者の意向と自社ギャップを確認する価値があります。 大企業、政府機関、重要インフラ事業者との取引が多い企業 顧客情報、設計情報、ソースコード、認証情報などを預かる企業 クラウドサービス、システム開発、運用保守、BPOを提供する企業 重要業務を再委託し、多層のサプライチェーンを構成する企業 M&A、IPO、大型提携、取引先監査を予定している企業 目標水準は「会社規模」だけで決めません。取扱情報の重要性、システム停止時の影響、外部接続、委託元から受ける権限、代替可能性、発注者の要求を踏まえます。一般的な脅威への備えを対外的に説明したい企業は★3が起点になり得ます。重要なデータやシステムへ深く関与し、技術検証を含む第三者評価が取引上重視される企業は★4を検討します。 取得に向けた具体的な対応手順 1．経営目的と責任者を決める 最初に「マークを取ること」ではなく、守る事業と取引を決めます。主要顧客からの要求、売上依存度、停止時の損失、機密情報の種類を整理し、目標★、対象組織、希望時期、予算枠を経営会議で合意します。CISOがいない場合でも、経営責任者、実務責任者、各部門の協力者を明確にしてください。★3では経営層による自己適合宣誓が想定されており、情報システム部門だけに任せ切る進め方は適しません。 2．評価範囲と資産を可視化する 組織、拠点、ネットワーク、クラウド、端末、アカウント、重要データ、委託先を一覧化し、評価範囲を定めます。必要資料の例は、情報セキュリティ方針、組織図、資産台帳、ネットワーク図、アカウント管理台帳、バックアップ設計、ログ保存方針、脆弱性管理記録、教育・訓練記録、インシデント対応手順、委託先管理基準です。文書が存在するだけでなく、実際の運用記録と一致していることが重要です。 3．要求事項との差分を評価する IPAが公開する★3・★4の要求事項・評価基準に照らし、「適合」「一部適合」「不適合」「対象外」に分類します。対象外とする場合は根拠を残します。優先順位は、単純な項目数ではなく、事業影響、攻撃可能性、取引期限、改善に要する時間、他施策への波及効果で決めます。認証基盤の多要素認証、外部公開資産、バックアップ復旧、特権IDなど、重大事故につながりやすい領域は先行させるのが実務的です。 4．技術検証で「実装されているか」を確認する 規程と自己評価だけでは、実装上の弱点を見落とすことがあります。Webアプリケーション診断は、SQLインジェクションや認可不備などアプリ固有の弱点を確認します。プラットフォーム診断は、サーバー、ネットワーク機器、クラウド設定などの既知の脆弱性や設定不備を確認します。ペネトレーションテストは、攻撃者の視点で複数の弱点を組み合わせ、実際にどこまで侵入・権限拡大・情報到達が可能かを検証します。 これらは同じ検査ではありません。評価対象、取引先のリスク、★水準に合わせて組み合わせ、発見事項を要求事項へ紐付けると、診断が単発の技術報告で終わらず、取得準備と経営判断に使える証拠になります。診断時には本番影響、試験時間、禁止事項、連絡体制、個人情報・機密情報の取扱い、ログ保存、再委託の有無を事前に合意します。 5．改善し、証跡を蓄積する 改善計画には、課題、リスク、担当部門、期限、費用、暫定対策、完了条件、証跡を記載します。技術的な修正が難しい場合でも、アクセス制限、監視強化、手作業の承認など代替策を検討し、残余リスクを経営層が承認します。規程改定、設定変更、教育実施、復旧訓練、委託先契約の見直しは、実施日と結果を残して初めて評価に耐える運用になります。 6．模擬評価・再診断を行う 申請前に、評価者の視点で証跡の不足、規程と実態の不一致、対象範囲の漏れを確認します。脆弱性を修正した箇所は再診断し、改善済みであることを確かめます。取得後も、組織変更、クラウド移行、新規拠点、M&A、新サービス開始などで前提が変わるため、継続監視、定期診断、教育、インシデント対応訓練へつなげる必要があります。 期間と費用を左右する要因 制度上の申請・登録費用は、2026年9月3日時点で今後公表予定とされています。そのため、現段階で一律の取得費用を断定することはできません。実務上の総費用は、制度への支払額だけでなく、現状調査、コンサルティング、規程整備、ツール導入、設定変更、診断・技術検証、教育、評価対応、再診断を含めて見積もります。 期間は、対象拠点・法人・クラウドの数、資産台帳の精度、既存認証の活用可否、要求事項とのギャップ、経営承認や購買手続、技術改修の難易度に左右されます。規程・証跡が整っていれば数か月単位で準備できる場合がありますが、認証基盤やネットワークの改修を伴えば半年以上の計画が必要になることもあります。正式な申請手順、評価機関、費用の公表時期を確認しつつ、まずギャップ分析と長納期項目の着手を進めるのが安全です。 社内稟議で説明すべきポイント 稟議では「制度対応費」だけを示すと、任意認証への投資と受け取られやすくなります。対象顧客の売上、更新時期、RFPで想定される水準、未対応時の追加監査工数、事故による停止・復旧費用、既存施策との重複を整理し、受注維持と事業継続の投資として説明します。 承認事項は、目標★、対象範囲、責任者、予算上限、実施期限、外部支援の利用範囲、残余リスクの承認方法です。費用は「必須改善」「推奨改善」「中長期改善」に分けると判断しやすくなります。制度要件が更新される可能性も踏まえ、段階的な発注や変更管理を契約に入れることも有効です。 支援会社を選ぶ際の確認事項 SCS評価制度への対応では、チェックリストを埋める能力だけでなく、実装と運用を改善する力が重要です。見積依頼やRFPでは、次の点を確認してください。 対象範囲と目標★を決めるギャップ分析に対応できるか 要求事項を規程、運用、技術設定、証跡へ具体化できるか Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト等を適切に使い分けられるか 重大度だけでなく事業影響と改修難易度で優先順位を提示できるか 改善支援、再診断、教育、継続運用まで一貫して支援できるか 評価支援と第三者評価を同一法人が担う場合の中立性・公平性を説明できるか 機密情報の保管場所、アクセス権、保存期間、削除、再委託を契約で明確にできるか 成果物には、適用範囲、前提・制約、要求事項別の評価、根拠証跡、技術検証結果、リスク評価、改善優先度、ロードマップ、担当部門、概算費用、残余リスクを含めると、その後の稟議・評価・運用へ転用しやすくなります。単に「未対応」の一覧を受け取るのではなく、経営判断と実装の双方に使えるかを確認しましょう。 よくある失敗と注意点 取得だけを目的にして実態が伴わない 審査直前に文書だけを整えても、設定や運用記録と食い違えば改善は定着しません。★は安全性の絶対保証ではなく、一定時点・一定範囲の対策状況を示すものです。取得プロジェクトを、資産管理や脆弱性管理を平常運用へ組み込む機会として設計する必要があります。 評価範囲を狭くし過ぎる、または広げ過ぎる 負担を減らすために重要システムを不自然に除外すると、取引先が確認したいリスクを説明できません。反対に全法人・全拠点を一度に対象とすると、準備が止まりやすくなります。データと権限の流れを起点に、取引上の説明力と実行可能性のバランスを取ります。 既存認証や診断結果をそのまま代用できると思う ISMSなどの既存認証や診断は有力な証拠になり得ますが、SCS評価制度の要求事項と評価範囲が同一とは限りません。既存資料を要求事項へマッピングし、不足分だけを追加することで、重複投資を抑えられます。 発注者からの要請を無条件で受ける 受注者は、求められる★水準、対象業務、期限、費用負担、代替的な証明方法を確認してください。発注者も、業務リスクに比して過大な要求とならないようにし、価格・納期を含む協議を行うことが望まれます。セキュリティを一方的な転嫁ではなく、サプライチェーン全体の共同課題として扱うことが継続的な改善につながります。 Librus株式会社が提供できる支援 Librus株式会社は、SCS評価制度に向けた現状評価から、対象範囲の設計、要求事項とのギャップ分析、規程・運用整備、技術検証、改善、再確認までを一気通貫で支援します。企業ごとのIT環境、取引先要請、予算、社内体制を踏まえて個別に設計し、経営層・情報システム部門・現場部門の間で論点を整理します。 制度対応の過程で技術的な確認が必要な場合は、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテストを目的に応じて組み合わせます。診断結果は改善優先度と事業影響に結び付け、必要に応じてSOC／CSIRT構築・運用、インシデントレスポンス、デジタルフォレンジック、教育・訓練、SBOM導入、M&A時のIT・サイバーセキュリティデューデリジェンスまで継続して支援可能です。 制度の詳細が更新される局面では、確定事項と検討中事項を分け、将来の変更に耐えられる準備を優先します。診断だけで終わらず、改善と運用まで伴走することで、★取得に加え、取引先へ説明できる実質的なセキュリティ体制の構築を目指します。 よくある質問 Q1．SCS評価制度の取得は法律上の義務ですか。 2026年9月3日時点では、すべての民間企業に一律の★取得を課す法律上の義務ではありません。ただし、発注者が取引条件として求めれば、受注のための事実上の要件になる可能性があります。 Q2．制度はいつ始まりますか。 IPAは★3・★4を2027年3月頃に運用開始する予定と公表しています。今後の正式情報をIPA公式サイトで確認してください。 Q3．未取得だと直ちに取引停止になりますか。 直ちに取引停止になる制度ではありません。実際の扱いは契約、調達基準、業務リスク、発注者の方針によります。追加監査や改善計画で対応できる場合もあるため、早めに取引先へ確認することが重要です。 Q4．★3と★4のどちらを目指すべきですか。 取扱情報、システム権限、停止時の影響、顧客要求で判断します。一般的な脅威への対策を示す場合は★3、重要業務に関与し第三者評価・技術検証が重視される場合は★4が候補です。 Q5．★4の前に★3を取得する必要がありますか。 ありません。上位段階は下位段階の要求を包括しますが、★3の先行取得が★4取得の条件ではないとされています。 Q6．ISMSを取得済みなら対応不要ですか。 対応不要とは限りません。既存の規程・証跡は活用できますが、SCS評価制度の要求事項と対象範囲へマッピングし、差分を確認する必要があります。 Q7．脆弱性診断だけで★を取得できますか。 脆弱性診断は技術対策を確かめる重要な手段ですが、制度はガバナンス、資産管理、教育、インシデント対応、委託先管理なども含みます。診断だけで全要求を満たすものではありません。 Q8．費用はいくらですか。 制度上の申請・登録費用は現時点で今後公表予定です。総費用は対象範囲、現状の成熟度、技術改修、診断や評価の内容によって変わります。まずギャップ分析で概算を作るのが適切です。 Q9．対象範囲が決まっていなくても相談できますか。 可能です。主要取引、重要データ、システム構成、顧客要求から対象候補を整理し、段階的な対応計画を作れます。 まとめ：取引上の必要性で判断する SCS評価制度は、現時点で全企業に一律の取得を強制する法律上の義務ではありません。しかし、発注者が調達・契約条件として★取得を求める使い方が想定されているため、未取得は新規受注、既存取引、監査対応、事故後の説明に影響し得ます。重要な結論は、「任意制度だから待つ」でも「すべて急いで取得する」でもなく、自社の取引先、扱う情報、事業停止の影響から必要水準と時期を決めることです。 まず主要取引先の意向を確認し、IPAの要求事項に基づくギャップ分析を行い、長納期の改善から着手してください。制度のための書類作成ではなく、実際の攻撃と事業継続に耐える仕組みへつなげることが、取得後も残る投資価値になります。 SCS評価制度への対応方針を整理したい企業の方へ 「自社は★3と★4のどちらを目指すべきか」「顧客から要請される前に何を準備するか」「既存のISMSや診断結果をどう活用するか」といった初期段階からご相談いただけます。Librus株式会社では、対象範囲や実施方法が決まっていない場合でも、取引構造と事業リスクを整理し、優先順位、概算期間、必要な技術検証を具体化します。社内稟議に使える説明材料まで整えることで、過不足のない投資判断につなげます。 診断から改善・継続運用まで一気通貫で支援 SCS評価制度への対応を、書類整備だけで終わらせたくない企業向けに、Webアプリケーション診断、プラットフォーム診断、ペネトレーションテスト、規程・運用改善、教育、継続監視まで支援します。技術と経営の両面から課題を整理し、取得準備と実際のリスク低減を同じロードマップで進められることがメリットです。 参考資料・出典 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 経済産業省「制度構築方針」（2026年3月27日） IPA「SCS評価制度」公式サイト IPA「SCS評価制度の詳細情報」 IPA「要求事項・評価基準」 IPA「よくある質問」 経済産業省・公正取引委員会「取引先とのパートナーシップ構築に向けて」関連資料 監修者 鎌田光一郎：青山学院大学法学部卒業。SMBC日興証券株式会社にて証券営業、経営管理業務に従事したのちPwCコンサルティング合同会社に転籍。金融機関に対するコンサルティング業務に従事。その後、Librus株式会社を設立、代表取締役に就任。 お問い合わせ先 Librus株式会社（代表取締役 鎌田光一郎）〒105-0004 東京都港区新橋6丁目13-12 VORT新橋Ⅱ 4F03-6772-8015お問い合わせフォーム：https://librus.co.jp/contact

VIEW MORE