SCS評価制度の対応範囲は？｜★3・★4の準備と更新時期を確認

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）への対応を取引先から求められると、★3・★4のどちらを目標にすべきか、社内の規程・台帳・ログをどの粒度で整えるべきかが実務上の論点になります。判断を先送りすると、調達審査や委託条件の見直しが迫った局面で、責任分界や証跡の不足により説明が詰まりやすくなります。制度の申請受付開始が二〇二六年度末頃予定とされる中、いつから何を着手するかを見積もれるようにしておくことが重要です。以下では、★3・★4の判断材料として制度の狙いと実務で詰まりやすい点を示します。

SCS評価制度の概要と背景

制度創設の目的と経済産業省の方針

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）は、企業間取引で求められるサイバーセキュリティ対策の状況を共通の物差しで可視化し、取引実務（調達・委託・外注管理）に乗る形で説明責任を果たしやすくすることを目的に整理が進められている制度です。近年は、セキュリティが強固な企業を直接狙うだけでなく、対策が相対的に薄い取引先・委託先を侵入経路として悪用するサプライチェーン攻撃が問題化しており、自社単体の最適化だけでは事業継続に必要な水準を担保しにくくなっています。

制度設計では、国際的に普及しているNIST Cybersecurity Framework（CSF）との整合が意識されており、成熟度の考え方として、場当たり的（Partial）→リスク情報共有（Risk Informed）→手順化対応（Repeatable）→変化への適応（Adaptive）といった段階概念が整理されています。これは「対策を導入しているか」だけでなく、経営承認・全社展開・継続改善まで含めて説明できる状態を目標にする、という実務上の方向付けになります。

サプライチェーンで評価制度が必要な理由

評価制度が必要とされる背景には、攻撃の増加に加え、取引実務における確認作業の非効率があります。発注元ごとに確認観点や書式が異なると、受注側は回答作業が膨らみ、発注側も比較・判断が難しくなります。統一的な枠組みによって、対策状況の説明が標準化されれば、取引先間での相互理解が進み、結果としてサプライチェーン全体の底上げにつながります。

また「サイバー対策」と「事業継続（BCP/BCM）」が分断されていると、災害・停電・通信断といった事象で重要業務が止まり、復旧にも影響します。例えば重要拠点・設備の分散化や遠隔地バックアップ、重要システムの耐震ラック等による耐震対策、被災時に調達困難となる事態を見据えた予備機器の確保、回線寸断に備えたネットワーク冗長化や代替通信手段（衛星電話・無線電話・PHS等）の確保、さらに停電・断水に備えた自家発電装置や冷却用水の確保といった観点が、実務のチェック項目として挙げられています。評価制度に合わせて、サイバーとBCMの両面で「止めない・止まっても戻す」説明ができる状態に寄せていくことが、発注側・受注側双方の合理的な目的になります。

SCS評価制度の対象範囲

評価対象となるIT基盤の考え方

本制度でいうIT基盤は、組織の事業活動を支える情報システム環境全般（サーバー、端末、ネットワーク境界機器、クラウド利用環境等）を前提に整理します。範囲を定める際は、資産の棚卸しだけでなく、「誰が・どこまで運用責任を負うか」を説明できることが重要です。

特に認証基盤（ID管理）は、SaaS利用が増えるほど運用不備が事故に直結します。例えばSSO（Single Sign On）は、1回のID・パスワード等の認証で複数のクラウドサービスを利用でき、利用者の利便性だけでなく、パスワード使い回しリスクの低減にもつながります。評価対応の実務では、SSO導入の有無そのものより、アカウント管理・権限付与・退職者の無効化・ログ管理が運用として回っていることを、台帳や記録で示せるかが論点になります。

制御システムなど対象外の具体例

工場等の設備制御を担う制御システム（OT）や、ネットワークから物理的に分離された独立機器は、情報システム（IT）と同一の基準で直接評価しにくいことから、制度上は直接スコープ外として整理される場面が想定されます。また、顧客へ納品する製品・ソフトウェア自体は、通常は本制度の「自組織のIT基盤」評価とは切り分けて考えます。

ただし、OT環境が社内ネットワークや外部ネットワークと接続されている場合、境界の防御・監視はIT側の管理事項として外れません。加えて、サイバーだけでなく災害時の継続性も境界領域に影響するため、重要業務システムについて、耐震対策（倒壊防止・耐震ラック設置等）や、回線寸断時に備えた代替通信手段（衛星電話・無線電話・PHS等）の準備状況が、運用上の説明材料になります。

クラウド・親会社共通基盤・委託先利用環境で責任分界をどう切り分けるか

クラウド、親会社の共通基盤、外部委託先の利用環境では、責任共有モデル（クラウド事業者が担う領域／利用者が設定・運用で担う領域）に沿って、評価対象を分解して整理します。自社で設定・運用できる部分（ID、権限、共有設定、ログ取得、端末管理等）については、自社の規程・手順・記録で説明し、事業者側の基盤対策は第三者評価資料や監査報告等で裏付けるのが基本です。

クラウド利用では、事業者側の堅牢性以前に、利用者側の設定ミスで事故が起きます。例えば、クラウドストレージの公開権限の設定ミスで機密情報が広く閲覧・ダウンロード可能になる、業務系SaaSの共有設定が非公開になっておらずゲストアカウント等から意図せず閲覧できる、URLを知っていれば第三者が閲覧できる状態で保管していた、といったパターンです。こうした人的ミスを前提に、設定・権限・共有状態を適宜監査する運用（いつ、誰が、何を確認したか）を組み込みます。

加えて、クラウドの利用実態把握と制御には、CASB（Cloud Access Security Broker）やSASEといったクラウドセキュリティサービスを使う選択肢があります。CASBは一般に、利用サービスの可視化、利用制御（許可・禁止）、データセキュリティ（アップロード制御・暗号化等）といった機能で、シャドーITや設定不備リスクを下げる方向で活用されます。

SCS評価制度の評価レベル

★1から★5の構成と既存制度との関係

SCS評価制度は、★1〜★5の段階で整理され、段階が上がるほど求められる統制（ルール化・運用・監査）が強まる設計が想定されています。制度理解の補助線として、NIST CSFで用いられる成熟度（ティア）の考え方を当てると、組織の状態を説明しやすくなります。

既存の自己宣言型の取り組み（例：IPAが運用する枠組み）を入口にしつつ、★3以上で第三者の確認を受ける設計により、取引で求められる説明責任を段階的に満たすことが狙いになります。

★3と★4の位置付けと評価スキーム

★3と★4は、取引実務で要求されやすい中心帯として、要求水準と確認の厳格性が分かれる整理がされています。★3は「最低限の基礎」として、自己評価書を作成し、登録専門家が内容確認・助言したうえで登録する枠組みが想定されます。★4は、サプライチェーンへの影響が大きい企業に対し、より高度な防御・検知・対応・復旧まで含めて確認する枠組みで、文書審査に加えて実地審査や技術的検証が含まれる整理がされています。

また、★3・★4のいずれでも、単に「製品を入れた」ではなく、成熟度でいえばティア3（手順化対応）以上に寄せて、組織全体で同じ手順と記録が回っていることを示すのが実務上の要点です。

★3で足りる会社と★4を前倒しで検討すべき会社の分かれ目

どちらを目指すかは、サプライチェーン上の役割と、情報・操業への影響度で決めます。判断では「事故時に何が止まるか」と「止まったときに代替が効くか」を具体化すると、社内合意が取りやすくなります。

一方で、影響範囲が限定的で、まずは「全社で同一手順と記録を回す」ことを優先したい場合は、★3から着手し、ティア2→ティア3へ確実に引き上げる設計が合理的です。

★3・★4の要求事項と実務対応

要求事項と評価基準の見方

要求事項は、ガバナンス整備、取引先管理、リスク特定、防御、検知、対応、復旧といった領域に分けて整理され、各領域で「何を実施し、何を証跡として示すか」が評価の焦点になります。実務では、要求事項を読んだ段階で「ツール導入」へ短絡せず、まず規程（ルール）→台帳（対象の特定）→ログ/記録（運用の立証）の順に落とし込むと、審査・確認に耐える形になります。

特にクラウドは、事業者の責任領域より、利用者の設定不備で事故が起きやすいため、共有設定や公開権限を誤設定しない仕組みと、誤設定が起きる前提での監査（定期チェック）が重要です。加えて、SSOのような認証統合は、利便性だけでなく、パスワード使い回しの低減により、運用統制の説明材料になります。

現状評価から体制整備までの進め方

制度対応は、現状把握と証跡整備に時間がかかるため、最初に「評価で問われる形に落とす」ことを目的に計画化します。

証跡不足で止まりやすい項目は何か｜規程・台帳・ログの準備順序

確認・審査で止まりやすいのは、「実施している」主張に対し、規程・台帳・ログが噛み合っていないケースです。証跡は、作った資料そのものだけでなく、運用の結果（履歴・ログ・点検記録）として出せる必要があります。

準備順序は、規程（何をするか）を作り、台帳（どれが対象か）を揃え、ログ/記録（実際にやったか）を積み上げる流れが基本です。運用記録は可能な範囲で自動化し、担当者変更があっても継続できる形にしておくことが重要です。

SCS評価制度の運用と活用

制度開始時期と有効期間・更新の考え方

制度の正式な申請受付開始は二〇二六年度末頃予定とされ、運用開始に向けたガイドラインや手続の整備が進む想定です。評価の有効期間は、★3が1年間、★4が3年間という整理で、更新を含む運用設計が前提になります。

更新を「申請手続き」ではなく「運用の平常業務」として回すには、成熟度でいうティア3（手順化対応）に寄せ、点検・改善が組織の定例業務として回っている状態を作る必要があります。特にクラウド利用では、設定ミスが起こりうることを前提に、共有設定・公開権限の定期監査を更新サイクルに組み込み、点検記録を残すことが実務上の要点になります。

申請から公開までの評価の流れ

申請から公開までの流れは、★3と★4で確認の深さが変わります。★3は自己評価書を作成し、登録専門家の確認・助言を受け、修正を反映したうえで登録・公開する流れが想定されます。★4は自己評価に加え、指定評価機関による文書審査、実地でのヒアリングや操作確認、外部公開機器に対する脆弱性検証など、より厳格な確認が含まれます。

どちらでも共通して重要なのは、クラウドの責任分界に沿って、利用者側の設定・運用（アクセス制御、共有設定監査、ログ取得、ID管理等）を証跡で示せることです。CASBのような仕組みを使って利用サービスの可視化や制御、データのアップロード制御・暗号化等を行っている場合は、運用ルールとログが説明材料になります。

更新切れを防ぐためにいつから動くか｜契約更新日と社内監査日程の合わせ方

更新切れを避けるには、取引先の契約更新や調達審査のタイミングと、社内点検・監査のタイミングを揃える必要があります。★3は有効期間が1年で、登録専門家の確認を含むため、期限前に「点検→証跡整理→自己評価更新」を回す設計が不可欠です。

また、更新対応を属人化させないためには、ログ収集・可視化を継続的に回す仕組みが有効です。例えば、Zabbix等のログ管理システムの活用により、平常時から監視・ログ保全を行い、必要時に提示できる状態を作れます。クラウド設定監査（公開権限・共有設定）も、年1回のイベントではなく、運用として定着させることが更新切れ防止に直結します。

発注側・受注側の対応方針

受注側のメリットと説明責任への備え

受注側にとっては、星の取得結果を提示することで、取引先ごとに異なる確認への個別対応負担を下げ、説明責任を果たしやすくする効果が見込まれます。特に、クラウド利用やリモートワークが前提になっている企業では、設定ミス由来の事故（公開権限の誤設定、共有設定の不備、URLを知っていれば閲覧できる状態など）をどう防ぎ、どう監査しているかが問われやすいため、日頃から監査記録を整えておくことが重要です。

また、SSOを含む認証統合は、利便性向上に加えてパスワード使い回しリスクを低減し、ID管理の統制を説明しやすくします。説明責任に備えるという意味では、規程の改定履歴、アカウント管理の履歴、ログ管理（Zabbix等での統合管理を含む）を、求められたときに出せる形で整備しておくことが実務上の肝になります。

中小企業支援とお助け隊サービスの使い方

中小企業では専門人材や運用の手が不足しがちなため、外部支援を組み合わせて「手順化と記録」を回す発想が重要です。支援サービスを検討する際は、単なる機器導入ではなく、クラウド利用の可視化・制御、ログ監視、規程整備、インシデント対応支援まで含めて運用を回せるかを見ます。

また、クラウドの可視化・制御という観点では、CASBが持つとされる、利用サービスの可視化、利用制御、データのアップロード制御や暗号化等の機能が、シャドーIT対策や設定不備の抑止に寄与します。自社の現状（SaaSの数、ID管理の統合状況、ログの収集状況）に合わせて、どこを外部に委ね、どこを社内手順として残すかを決めることが現実的です。

発注・情報システム・法務が社内で合意すべき事項と稟議資料のそろえ方

社内合意では、「どの★を目標にするか」だけでなく、評価対応が取引条件・委託条件にどう影響するかを、発注・情報システム・法務で揃える必要があります。特にクラウドやグループ共通基盤が絡む場合、責任分界が曖昧だと、審査や取引先説明で破綻しやすくなります。

稟議資料では、対策の要素を「製品購入」ではなく、ティア2からティア3へ上げるための手順化・記録化として説明すると、投資目的がぶれにくくなります。クラウド設定ミスを前提にした監査運用や、ログ管理の整備は、取引停止リスクの低減と説明責任の履行という観点で整理しやすい論点です。

よくある質問

SCS評価制度の★3と★4は同時に取得する必要がありますか？

同時に取得する必要はありません。制度設計上、上位レベル（★4）の要件が下位レベル（★3）の要求事項を包含する整理が想定されているため、★3を経由せずに★4の審査を目指すことも可能です。実務では、現状の成熟度がティア1〜2に近い場合は、まず★3相当の「手順と記録」を固めてから★4へ進む方が、証跡整備の手戻りが減ることがあります。

SCS評価制度の評価・取得にどのくらいの期間がかかる見込みですか？

準備期間は、体制整備（規程・台帳・ログの整備）に左右されます。特に、クラウドの公開権限・共有設定の監査手順を作って運用記録を積む、SSO等の認証統合を進めてアカウント管理の履歴を整える、Zabbix等でログを収集・提示できる形にする、といった「運用の形」を作る作業は、関係部署調整も含めて時間を要します。したがって、取引先から要求が来てから着手するのではなく、要求水準（★3か★4か）の見立てが付いた時点で現状棚卸しを開始するのが安全です。

SCS評価制度で要求されるIT基盤に、クラウドサービスは含まれますか？

評価対象に含まれる前提で整理するのが実務的です。クラウドでは責任共有モデルに沿って、利用者側の設定・運用（アクセス制御、共有設定の監査、ログ取得、ID管理など）を示す必要があります。事故原因として多いのは事業者側ではなく利用者側の設定不備であり、例えば公開権限の設定ミス、共有設定が非公開になっていない、URLを知っていれば第三者が閲覧できる状態、といったリスクを前提に、監査と記録で統制していることが重要です。

取引先に対してどの★を求めるか、どのように決めればよいですか？

取引先が担う業務の重要性と、事故時の影響度（操業停止・情報漏えい・復旧難易度）に基づいて決めます。例えば、重要業務の継続性まで踏み込んで説明が必要な場合には、拠点分散・遠隔地バックアップ、予備機器の確保、ネットワーク冗長化や代替通信手段（衛星電話・無線電話・PHS等）の準備、停電・断水への備え（自家発電装置等）といった観点が論点になります。これらの要求が取引先にとって過大にならないよう、発注側は「なぜその★が必要か」を業務影響度の言葉で説明できる形にしておくことが重要です。

まとめ：SCS評価制度への対応で次にすべきこと

SCS評価制度は、取引実務で求められるセキュリティ対策を共通の物差しで示すための枠組みで、★3・★4では「手順と記録が全社で回っているか」が中心の判断軸になります。★3は自己評価書を登録専門家が確認・助言する整理、★4は文書審査に加え実地審査や技術的検証まで含む整理であり、どこまでの説明責任が取引上必要かを業務影響度から決めることが重要です。制度の申請受付開始が二〇二六年度末頃予定とされるため、まずはIT資産・クラウド・委託先・親会社共通基盤の棚卸しと責任分界を固め、規程→台帳→ログ/記録の順で証跡を作る計画に落とし込みます。更新を見据えて、★3（1年間）・★4（3年間）の有効期間に合わせて点検・監査を定例化し、クラウドの共有設定監査やログ提示が止まらない運用に寄せていくことが実務上のポイントです。個別の取引条件や審査対応の進め方は状況で変わるため、必要に応じて情報システム・法務・調達の関係部署や外部支援も含めて相談体制を整えるのが安全です。

Baseconnect株式会社
サイト運営会社

本メディアは、「企業が経営リスクを正しく知り、素早く動けるように」という想いから、Baseconnect株式会社が運営しています。

当社は、日本最大級の法人データベース「Musubu」において国内1200万件超の企業情報を掲げ、企業の変化の兆しを捉える情報基盤を整備しています。

加えて、与信管理・コンプライアンスチェック・法人確認を支援する「Riskdog」では、年間20億件のリスク情報をAI処理、日々4000以上のニュース媒体を自動取得、1.8億件のデータベース等を活用し、取引先の倒産・不正等の兆候の早期把握を支援しています。

運営会社情報ページへ