1 概念

日本におけるサプライチェーン・セキュリティ評価制度というのは、ビジネス・ITサービスサプライチェーンにおける、委託先へのサイバー攻撃等を起因とした自社事業・サービスの提供途絶／機密情報の漏えい、改ざんや委託先等を踏み台とした不正侵入等のリスクに対する適切なセキュリティ対策の実施を促し、サプライチェーン全体でのセキュリティ対策水準の向上を図ることを目的として構築された

満たすべき各企業の対策を段階ごとに区分し、それぞれについて要求事項・評価基準に基づき、自己評価（専門家の確認を経たもの）や第三者評価機関による評価を行い、各段階ごとに表示をなすことによって、それらのレベルを可視化する仕組み

をいいます。

これについては、経済産業省「産業サイバーセキュリティ研究会」ワーキンググループ1（制度・技術・標準化／現「実効性強化・国際連携」）の下に置かれた「サプライチェーン強化に向けたセキュリティ対策評価制度に関するサブワーキンググループ」（SWG）が構築を提唱していたものです。このSWGのリンクは、これです。https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_supply_chain/index.html

2024年7月に同研究会の下に設置され、第1回2024年7月12日、第2回9月9日、第3回12月24日、第4回2025年2月28日、第5回4月7日と開催。この場で制度の目的・位置付け、要求項目・評価基準、普及施策等を有識者・産業界と継続的に議論し、2025年4月に「中間取りまとめ」を公表、第6回（2025年12月）で実証報告書と制度構築方針案・要求事項及び評価基準案を審議し、12月26日公表の方針案に対する意見募集（2026年1月24日まで、93者から569件）を踏まえて修正されて、第7回（2026年3月）でパブリックコメントへの対応と方針案の確定を審議しました。

経済産業省及び内閣官房国家サイバー統括室が、2026年3月27日に「制度構築方針」を公表しています。

仕組みについては、ＭＥＴＩの「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」のページがあります。また、IPAの詳細な情報については、こちらにﾘﾝｸがあります。

これ制度を維持管理するスキームオーナーは、経産省の監督下で運営を行う独立行政法人情報処理推進機構（IPA）とされています。IPAは、運営方針や制度文書を審議する「運営審議委員会」、登録・普及promotionを担う「事務局」、評価機関・技術検証事業者・研修事業者の指定監督を行う「指定委員会」を運営します。

(https://www.meti.go.jp/policy/netsecurity/scs.html)より

運営審議委員会は第1回が2026年6月12日、第2回が7月13日に開催され、配付資料が公開されています。本制度は明示的に「任意の制度」と位置づけられ、★の取得は委託元・委託先間の取引契約において決められるもので、制度として規制を課すものではありません。また、事業者のセキュリティ水準を競わせる格付け制度ではないことも明記されています(IPAのﾎｰﾑﾍﾟｰｼﾞ)。

具体的には、2社間の取引契約等において、委託元が、委託先に適切な段階（★）を提示し、示された対策を促すとともに実施状況を確認することを想定しています。

したがって法的拘束力は制度自体からは生じず、契約条項を通じた私法上の義務としてのみ機能する構造です（いわゆるソフトロー型の可視化スキーム）。 以下のようなイメージでしょうか。

(お断り)高橋は、指定委員会の委員ですが、このブログは、その立場とは一切関係のない個人的なものです。この評価制度に関する公的な見解とは、一切、関係がありません。

 

2 評価の仕組み

2.1 構築される評価制度

評価制度の概要は、以下のようになっています。

METIホームページから(https://www.meti.go.jp/policy/netsecurity/scs.html)

2.2 評価の対象

評価の対象は、「取得希望組織の情報処理システム」ということになるかと思います。経済産業省は、制度の対象範囲として

サプライチェーンを構成する企業等のIT基盤（クラウド環境で運用するものも含む。）を対象としています。なお、一般的にIT基盤に該当しないと考えられる製造環境等の制御（OT）システムや委託元等に提供する製品等については、サプライチェーン全体での共通化が難しいことから直接の対象とはせず、他の制度・ガイドライン等に基づき対策を行うことを想定しています。

と記述しています(METIホームページ)。具体的な制度は、IPAによります。

もっとも、後述の英国のCyber Essentials / Cyber Essentials Plus と比較するときに、企業等のIT基盤（クラウド環境で運用するものも含む。）とは、どこまでをいうのか、という問題があります。

2.3 要求事項の構成

大分類が7つ（1 ガバナンスの整備、2 取引先管理、3 リスクの特定、4 攻撃等の防御、5 攻撃等の検知、6 インシデントへの対応、7 インシデントからの復旧）、その下に中分類が16、さらに要求事項が43件、最下層に評価基準が153件置かれます。番号体系は「大分類-中分類-要求事項-評価基準」の四桁連番（例：1-2-1-4）で特定されます。

具体的には、このようなかんじです(セル結合解除して表示)。

★3欄と★4欄に「○」で該当段階を示す列があるので、契約条項で「★3を取得・維持すること」と書けば要求事項としては、26件、評価基準としては、実質的に81件のへの適合を義務づけたことになります。

2.4 分野ごとの分析

大分類ごとに概観していきます

「攻撃等の防御」（大分類4）だけで要求事項21件・評価基準82件を占め、全体の過半（153件中82件、約54%）がここに集中します。中分類は、アイデンティティ管理・認証・アクセス制御、意識向上とトレーニング、データセキュリティ、プラットフォームセキュリティ、技術インフラのレジリエンスの五つに分かれ、ユーザID・管理者IDの管理手続、認証強度、アカウントロック、パスワード設定・管理、アクセス権管理といったアクセス統制系が★3の中核を成しています。

これに次ぐのが「リスクの特定」（大分類3）（要求事項6件・評価基準29件）で、資産管理とリスクアセスメントの二中分類からなります。資産管理には情報機器・OS・ソフトウェアの把握、ネットワーク情報の把握、外部情報サービスの管理、機密区分に応じた情報の管理が並び、★4でリモートワークのルールが加わります。脆弱性の管理体制は丸ごと★4のみで、★3では脆弱性管理プロセスの整備は要求されません。

「ガバナンスの整備」（大分類1）は要求事項6件・評価基準19件ながら、★3該当はうち3件にとどまり、★4の比重が高い領域（★3が8件、★4が11件）です。社内ルールの策定・周知（1-1-1）、サイバー攻撃の監視・分析体制（1-2-2）、セキュリティ対策推進計画（1-4-1）はいずれも★4限定です。

「インシデントへの対応」（大分類6）は要求事項1件（インシデント対応手順）・評価基準6件で、そのすべてが★3、★4での追加はゼロ。「インシデントからの復旧」（大分類7）に至っては要求事項1件（事業継続要件に沿った復旧準備）・評価基準2件のみです。

2.5 評価方法の違い

★3と★4との違いを表にしてみました。

出典：制度構築方針 p.13・p.18・p.19・p.20・p.21・p.23／IPA「SCS評価制度の詳細情報」

項目	★3専門家確認付き自己評価評価主体は取得希望組織	★4第三者評価評価主体は評価機関
評価主体	取得希望組織自身	評価機関（「評価主体である」と明記）
専門家の役割	自己評価結果の確認・助言、署名	評価機関における評価責任者
独立性	社内専門家でも可（制度的担保なし）	指定を受けた外部評価機関
手続の段階	4段階自己評価記入 → 専門家の確認・署名 → 経営層の自己適合宣誓を付して事務局提出 → 台帳登録・公開	7段階指定委員会による機関指定 → 自己評価記入 → 評価機関へ依頼 → 検証・評価 → 評価報告書受領 → 登録申請 → 台帳登録・公開
文書確認	あり（1〜2日程度）	あり（1〜2日程度）
実地審査	実施なし	あり（1〜2日程度、リモート可）脆弱性の管理体制・管理プロセス、インシデント対応手順、事業継続要件に沿った復旧準備等を証跡確認
技術検証	実施なし	あり（1〜2日程度）インターネット公開機器（VPN装置、ルータ等）への脆弱性検査。対象は評価基準4-4-4-3の1項目。過去の検査結果による代替も検討中
検証範囲	—	適用範囲からのサンプリング（全数ではない）
合格基準	原則としてすべての評価基準への適合	原則としてすべての評価基準への適合
不適合時	是正し専門家の了承を得れば取得可（期限の定めなし）	指摘通知から一定期間内（例：1か月以内）に是正報告し、了承を得れば取得可
要求事項数	26件（評価基準81件）	43件（評価基準153件）
有効期間	1年	3年
制裁	虚偽・不正発覚時は★の取消し等	同左に加え、評価手続に重大な瑕疵があれば評価機関の指定取消し等
要件の公表状況	専門家要件は公表済（資格＋研修＋事務局登録）。研修事業者は2026年12月末頃	評価機関・技術検証事業者の要件詳細 (詳細公開済み(制度規程))

3 英国制度との比較

英国の当該制度としては、①基礎認証制度（Cyber Essentials）、②公共調達ポリシーによる事実上の義務化、③防衛分野の契約条件、④規制法という四層構造で運用されています。SCS評価制度が①と②の機能を一つの枠組みに束ねようとしているのに対し、英国は各層が別々の法的性質を持つ点が構造的な違いです。

---

3.1. 中核：Cyber Essentials / Cyber Essentials Plus

NCSC（国家サイバーセキュリティセンター）が策定し、公式デリバリーパートナーであるIASMEが運用する政府後援スキームで、ファイアウォール、セキュア設定、ユーザーアクセス制御、マルウェア対策、セキュリティ更新管理の5つの技術的統制(5 Cyber Essentials Technical Controls)を検証するものです。(NCSCのページ  日本語での紹介(アムティーボ・ジャパン))

3.1.1 自己評価質問

自己評価質問表(バージョンVersion 16.3（2026年5月）)をみてみます(リンク)。イメージとしては、こんな感じです。

カテゴリーの部分には項目として

• 組織
• インシュアランス
• ユーザーアクセスコントロール
• 管理アカウント

があり、サブカテゴリの列には

• 組織
• 証明書
• 評価の範囲
• ファイアウォール
• デバイス解除手法
• セキュリティ更新管理
• パスワード認証
• マルウエア防御

などの記載があります。もっとも、これらがきちんと上の５つの技術的統制に対応しているわけではないです。

大きく見ていくと

層	セクション	性質	適合判定への影響
I. 主体・客体の特定	Your Company（Certificates含む）／Scope of Assessment	誰が、何について認証を受けるかを画定する条項。義務の名宛人と客体の定義	直接の合否要件ではないが、義務の射程そのものを決定
II. 付随的商品	Insurance	認証に付帯する保険の申込情報。ブローカーへ転送される	冊子が明示的に「これらの設問への回答はCyber Essentials評価の結果に影響しない」と述べる

の部分については、要求事項という形では評価さない事項ということになります。これに対して、その余の部分については、CE Requirementという太字が見えます。このCEの要求事項のところを抜き出した上に要旨にして５つの項目ごとに整理することができますが、「NCSC — Requirements for IT Infrastructure v3.3 / April 2026」という冊子(リンク)があり、そこでは、データのバックアップや範囲に加えて、技術的コントロールテーマが、5つの項目にわけて記述されています。

3.1.2 範囲について

NCSC — Requirements for IT Infrastructure v3.3 / April 2026 は、

• 技術的統制の紹介
• 定義
• データのバックアップ
• 範囲(scope)
• 技術的統制ごとの要求事項

からできています。個人的に興味深いのは、範囲のところです。

3.1.2 Cyber Essentials 5つの技術的統制　要件一覧

NCSC — Requirements for IT Infrastructure v3.3 / April 2026 の13ページ以降の要件記述を統制別に整理し要旨訳したもの(以下、claudeによります)は、

1. Firewalls

適用対象：境界ファイアウォール、デスクトップ、ラップトップ、ルータ、サーバー、IaaS、PaaS、SaaS

目的 ── 安全かつ必要なネットワークサービスのみがインターネットからアクセス可能な状態を確保すること。

No.	要件（要旨）	強度
1-1	適用範囲内のすべての機器を、適正に構成されたファイアウォール（またはファイアウォール機能を備えたネットワーク機器）で保護すること。クラウドサービスについてはデータフローポリシーによる実現が可能。多くのOSにソフトウェアファイアウォールが標準搭載されており、第三者製品より標準機能の有効化が推奨される。	MUST
1-2	既定の管理者用パスワードを強固かつ固有のものに変更すること。または遠隔管理アクセスを完全に無効化すること。	MUST
1-3	ファイアウォール構成の管理インターフェースへのインターネット経由アクセスを遮断すること。明確かつ文書化された業務上の必要性があり、かつ次のいずれかで保護される場合を除く。 多要素認証 信頼できる狭いIP範囲に限定した許可リスト＋適切に管理されたパスワード認証	MUST
1-4	未認証の受信接続を既定で遮断すること。	MUST
1-5	受信ファイアウォールルールについて、権限を有する者による承認と文書化を行い、業務上の必要性を文書に含めること。	MUST
1-6	不要となったファイアウォールルールを、必要でなくなった時点で削除または無効化すること。	MUST
1-7	公衆Wi-Fiホットスポット等の非信頼ネットワークで使用する機器には、ソフトウェアファイアウォールを使用すること。接続先ネットワークを組織が管理していない場合は、機器側での構成が必須。	MUST

2. Secure Configuration

適用対象：サーバー、デスクトップ、ラップトップ、タブレット、携帯電話、シンクライアント、IaaS、PaaS、SaaS

目的 ── コンピュータ及びネットワーク機器を適切に構成し、脆弱性を低減するとともに、その役割の遂行に必要なサービスのみを提供させること。

No.	要件（要旨）	強度
2-1	不要なユーザーアカウント（ゲストアカウント、使用しない管理者アカウント等）を定期的に削除および無効化すること。	MUST
2-2	既定または推測可能なアカウントパスワードを定期的に変更すること。	MUST
2-3	不要なソフトウェア（アプリケーション、システムユーティリティ、ネットワークサービスを含む）を定期的に削除または無効化すること。	MUST
2-4	利用者の許可なくファイルを実行する自動実行機能を無効化すること（ダウンロード時等）。	MUST
2-5	組織のデータまたはサービスへのアクセスを許す前に、利用者を認証すること。	MUST
2-6	物理的に在席する利用者に対し、適切なデバイスロック統制を確保すること。	MUST
2-7	機器のサービス利用に利用者の物理的存在を要する場合（ラップトップへのログオン、携帯電話のロック解除等）、生体認証・パスワード・PIN等の認証情報を経なければアクセスできないようにすること。	MUST
2-8	選択した認証方式（生体認証、パスワードまたはPIN）をブルートフォース攻撃から保護すること。設定可能な場合は次のいずれかを適用する。 試行間隔を漸増させるスロットリング（5分間に10回を超える推測を許さない） 10回を超えない失敗回数での機器ロック ベンダーが設定を許さない場合はベンダー既定値を用いる。	MUST SHOULD
2-9	認証情報の品質管理に技術的統制を用いること。機器のロック解除のみに用いる認証情報は、パスワードまたはPINで6文字以上とする。	MUST
2-10	デバイスロック解除用の認証情報が認証にも用いられる場合は、User Access Control に定めるパスワード要件（4-8〜4-10）を全面的に適用すること。	MUST

3. Security Update Management

適用対象：サーバー、デスクトップ、ラップトップ、タブレット、携帯電話、ファイアウォール、ルータ、IaaS、PaaS、SaaS※v3.3ではSaaSも適用対象に含まれる（質問セット冊子の記載とは異なる）。

目的 ── 修正が提供されている既知のセキュリティ上の問題について、機器及びソフトウェアが脆弱でない状態を確保すること。

No.	要件（要旨）	強度
3-1	適用範囲内のすべてのソフトウェアを最新の状態に保つこと。	MUST
3-2	対象機器上のすべてのソフトウェアが、ライセンスを有し、かつサポートされていること。「ライセンスを有しサポートされたソフトウェア」とは、使用する法的権利を有し、ベンダーが定期的な脆弱性修正の提供によりサポートを約束しているものをいう。ベンダーは提供終了の将来日を明示しなければならない。原開発者である必要はないが、修正を作成するために原ソフトウェアを改変できる立場になければならない。	MUST
3-3	サポートが終了した時点で当該ソフトウェアを機器から削除すること。または、インターネットとの送受信を一切遮断する定義済みサブセットを用いて適用範囲外へ移すこと。	MUST
3-4	可能な限り自動更新を有効化すること。	MUST
3-5	公開から14日以内の適用。脆弱性修正を含む更新を、次のいずれかに該当する場合に公開から14日以内に適用すること。 ベンダーが「critical」または「high risk」と記述する脆弱性を修正するもの CVSS v3 基本値 7 以上の脆弱性に対応するもの ベンダーが修正対象脆弱性の深刻度を示していないもの ベンダーが異なる深刻度表現を用いる場合はCVSSの定義による。深刻度の異なる複数の問題が単一の更新にまとめられている場合、そこに critical または high risk の問題が含まれていれば14日以内の適用が必須。なお、すべての更新を14日以内に適用することは強く推奨されるが義務ではない。	MUST

4. User Access Control

適用対象：サーバー、デスクトップ、ラップトップ、タブレット、携帯電話、IaaS、PaaS、SaaS

目的 ── ユーザーアカウントが、権限を与えられた個人にのみ割り当てられ、かつ当該利用者が職務を遂行するために必要なアプリケーション・コンピュータ・ネットワークにのみアクセスを与えるものであることを確保すること。

No.	要件（要旨）	強度
4-0	総則　組織のデータ・サービスへのアクセスを与えるユーザーアカウントとアクセス権限を、組織が管理下に置くこと。これにはサポートサービスが用いるアカウント等、第三者のアカウントも含まれる。あわせて、ユーザーアカウントがどのように認証されるかを理解し、当該認証を相応に管理すること。	MUST
4-1	ユーザーアカウントを作成・承認する手続を備えること。	MUST
4-2	アプリケーションまたは機器へのアクセスを許す前に、固有の認証情報により利用者を認証すること。	MUST
4-3	不要となったユーザーアカウントを削除または無効化すること（利用者の退職時のほか、一定期間アカウントが使用されていない場合を含む）。	MUST
4-4	利用可能な場合はMFAを実装すること。クラウドサービスへの認証には常にMFAを用いなければならない。MFAにおけるパスワード要素は8文字以上、上限設定なし。追加要素として、管理された企業端末、信頼できる端末上のアプリ、物理的に分離されたトークン、既知または信頼されたアカウントの4類型が示される。SMSは最も安全なMFAではないが、MFAを用いないことに比べれば大きな利点があるとされる。	MUST
4-5	管理作業専用の別アカウントを用いること。当該アカウントでメール送受信、Web閲覧その他、管理者権限を回避可能なリスクに晒す通常業務を行わないこと。	MUST
4-6	特別なアクセス権限が不要となったとき（担当者の役割変更時等）に、これを削除または無効化すること。	MUST
4-7	管理者アカウント、及びインターネットからアクセス可能なアカウントには、常にMFAを用いて追加のセキュリティを与えること。	SHOULD
4-8	パスワードを推測型総当たり攻撃から保護すること。次の少なくとも一つを実装する。 多要素認証 試行間隔を漸増させるスロットリング（5分間に10回を超える推測を許さない） 10回を超えない失敗回数での機器ロック	SHOULD
4-9	パスワード品質を管理する技術的統制として、次のいずれかを用いること。 多要素認証 12文字以上（上限設定なし） 8文字以上（上限設定なし）＋拒否リストによる一般的パスワードの自動ブロック	SHOULD
4-10	業務用アカウントについて固有のパスワードを選択できるよう利用者を支援すること。 ペットの名前、キーボード配列、他所での使い回し等、一般的なパスワードを避けるよう教育すること 3語以上の複数単語による長いパスワードを推奨すること パスワードマネージャーまたは施錠可能な保管庫等、実用的で安全な保管手段を、利用方法の明示とともに提供すること 定期的なパスワード有効期限を強制しないこと パスワードの複雑性要件を強制しないこと	SHOULD
4-11	パスワードまたはアカウントの侵害を認知・推知した場合に、速やかにパスワードを変更する確立された手続を備えること。	SHOULD

5. Malware Protection

適用対象：サーバー、デスクトップ、ラップトップ、タブレット、携帯電話、IaaS、PaaS、SaaS

目的 ── 既知のマルウェア及び信頼できないソフトウェアの実行を制限し、損害の発生又はデータへのアクセスを防ぐこと。

No.	要件（要旨）	強度
5-1	適用範囲内のすべての機器でマルウェア対策機構を有効にすること。機器ごとに、次の少なくとも一方を用いる。いずれの場合も、当該ソフトウェアは有効化され、ベンダーの指示に従って最新に保たれ、下記のとおり構成されていなければならない。 選択肢A　アンチマルウェアソフトウェア（Windows または macOS が稼働する対象機器＝サーバー、デスクトップ、ラップトップ向け） 選択肢B　アプリケーション許可リスト（すべての対象機器で選択可）	MUST
5-2	選択肢Aを用いる場合、アンチマルウェアを次のとおり構成すること。 ベンダーの推奨に沿って更新されること マルウェアの実行を防止すること 悪意あるコードの実行を防止すること インターネット上の悪意あるウェブサイトへの接続を防止すること	MUST
5-3	選択肢Bを用いる場合、コード署名により制限された承認済みアプリケーションのみが機器上で実行されるようにすること。あわせて次の各点を満たすこと。 機器への配備前に、当該アプリケーションを能動的に承認すること 承認済みアプリケーションの最新リストを維持し、利用者が未署名または無効な署名のアプリケーションを一切インストールできないようにすること	MUST

3.1.3　Cyber Essential Plusとの関係

認証は英国政府契約、サプライチェーン保証、多くの民間顧客から要求されており、全社を対象に認証を取得した売上高2,000万ポンド未満の組織には無償のサイバー賠償責任保険が付帯します(リンク)。この保険付帯というインセンティブ設計は、日本の制度には現時点で対応物がありません。

ちなみに、認証機関の要件については、IASME「How to become a Certification Body for Cyber Essentials」（2025年7月29日）https://iasme.co.uk/articles/how-to-become-a-certification-body-for-cyber-essentials/に明らかにされています。

---

Cyber Essentials / Cyber Essentials Plusについては、公共調達・防衛調達・法的規制との関係もみていきます。

3.2. 公共調達経由の義務化：PPN 014

PPN(Procurement Policy Note) は、対象となる組織が特定の種類の契約においてサイバー脅威を特定し、軽減するために講じるべき措置と、その実施を支援するためのリソースについて定めていますが、その014(PPN 014)は、中央政府省庁・その執行機関・非省庁公的機関及びNHS団体を「in-scope organisations」とし、特別規制契約を除く物品・役務・工事の公契約発注時に適用されるものであり、対象類型の契約に入札する供給者は、契約締結前にCEまたはCE+を保有していること（あるいは同等の統制を有することの証明）を示さなければならないとしています(同ノート 11項)(リンク ,NET SEC Groupの記事)。

11. 対象組織（in-scope organisations）は、サプライチェーンリスクを軽減するため、契約に対して効果的かつリスクに見合ったサイバーセキュリティ管理策（controls）が適用されることを確保しなければならない。

対象となるのは、市民の個人データ（氏名、住所、国民保険番号、銀行情報、医療記録等）や政府職員データ（人事記録、給与、セキュリティクリアランス情報）を取り扱う契約、OFFICIAL以上の分類のICTシステム・サービス、その他サイバー脅威リスクが高いと評価された契約で、認証は契約期間中毎年更新しなければならず、一回限りの要件ではありません(Cyber Essentials)  (同 ノートの12項)

12. サイバーセキュリティ上の脅威のリスクが高いと考えられる契約には、いくつかの重要な特性があります。対象となる組織（in-scope organisations）は、以下の特性を含む契約またはサービスについて、すべてのサプライヤーが一定の技術的要件を満たしていることを確認しなければなりません。

• 国民の個人情報（自宅住所、銀行口座情報、支払情報など）をサプライヤーが取り扱う場合。
• 政府職員、大臣、および特別顧問（Special Advisers）の個人情報（給与計算情報、出張手配情報、経費精算情報など）をサプライヤーが取り扱う場合。
• Government Security Classifications Policy（政府セキュリティ分類方針） における OFFICIAL レベルのデータを保存または処理することを目的として設計されたICTシステムまたはICTサービスを供給する場合。
• 政府の日常業務、公共サービスの提供、または公的財政に関連する情報を取り扱う契約である場合。

 総務省の入札とかで応募するときがありますが、このごろ、セキュリティの要件が厳しく求められるようになってきたりしています。法律調査とかで、オープンソースからのインテリジェンスとでもいうべきものまで、サプライチェーン評価的なものを要求されるようなことになったら、なんなんだろうなあと思うことになるかと考えていたりします。

法的に留意すべき事項

法的に留意すべき事項としては

• PPNは法令ではなく政府内部の調達方針であり、発注官庁を拘束する形で機能します。供給者に対する義務は、調達文書中の技術仕様（technical requirement）を通じて発生する構造です。この点、SCS評価制度が二社間契約という純粋な私法経路のみを想定するのに対し、PPN 014はCrownが発注者側から一律に押し込むという点で強度がまったく異なります。
• 英国法固有の重要な制約ですが、公契約についてはProcurement Act 2023第56条（技術仕様）に適合させるため、in-scope organisationsは同等物（equivalents）を受け入れなければならないとされています。すなわち個別フレームワークにも波及しており、G-Cloud 15では全供給者にCEが要求され、NHS供給者にはCE/CE+が必須化されています。NHS Supply Chainは、NHSデータを取り扱うか、IT・デジタルサービスを提供する供給者に対し、PPN 014の下でCyber Essentials Plusを要求しています。

---

3.3.民間への波及と自主的枠組み

NCSCは2026年初頭にCyber Essentials supply chain playbookを公表しています(リンク)。同書は、英国NCSCが2025年12月12日に公表した、主に大企業の経営層に向けた手引きです。構成は、

導入部

1. Ministerial foreword(サイバーセキュリティ担当大臣 Liz Lloyd による序文。主要企業宛の大臣書簡へのリンク付き)
2. Executive summary(脅威の現状と、CEをサプライヤーの標準要件にするよう求めるNCSCの呼びかけ)
3. Time to act(経営層への2つの要請-CEをサプライチェーンにすること.技術的要件を実装すること-と、本書が示す手順の予告)

問題と解決策の提示

4. Businesses are not managing cyber risk effectively(サプライヤーのリスク審査が進んでいない現状)
5. Cyber Essentials can help secure your business(CE制度の説明)
6. How you can use Cyber Essentials to secure your supply chain(保証ツールとしての利点6点と、St James’s Place の Case study)

これについては、具体的には、

• 一般のサイバー攻撃に効果的であること
• 保証ツールとして重要な役割を果たしうること
• サプライヤー・チェックツールが早急な検証を可能にすること
• サプライヤーが効果的に技術的要件をみたしていることについての自身を得ることができること
• 時間の節約および複雑さの減少
• 保険の付帯と専門的インシデントレスポンスの提供

が上げられています。

手順の本体

Steps to embed Cyber Essentials in your Supply Chain(7ステップの一覧)

導入のステップとして以下のステップが上げられています。

サプライチェーンリスクの理解

1. リスク評価:守るべき対象、サプライヤーの顔ぶれ、サプライチェーンがもたらすリスクを把握します。侵害時の影響は、業務、評判、財務・法的・規制・契約上の帰結、従業員や顧客の安全の観点で検討します。
2. サプライヤーのプロファイリング:規模や種類ごとに要件を分け、リスクに比例した現実的な要求にします。これには、リスクの理解を確認するこめにサプライチェーン原則(リンク)を利用すること、セキュリティプロファイルを作成するためにガイダンスを利用することがあります(サプライチェーンセキュリティガイダンス)。

サイバーエッセンシャル採用を増加するためにアプローチを定義せよ

1. 要件設定:CE認証を最低要件とするか、質問票をCEの統制に合わせて認証をその充足の証明として受け入れます(併用も可)。
2. 期待の伝達:サプライヤー宛書簡や会合での周知、インセンティブ、RfP・RfQへの反映、契約更新時の要求といった手段があります。

サプライチェーンの意識交渉のためのツール

伝達のための方法(reources)として、アカウントマネージャー、供給者レター、供給者イベント資料、ソーシャルメディア資料、サイバーエッセンシャル知識ハブ、サイバーエッセンシャル準備ツールが紹介されています。

サイバーエッセンシャル採用の動機付け

1. 導入の動機づけ:30分の無料相談、認証取得に付帯する2万5,000ポンドのサイバー保険、発注者負担の追加アドバイザー時間(1時間120ポンド)、CE Plus取得まで伴走する20時間のパッケージ、認証費用に充てるバウチャーがあります。

調達決定への影響および契約へのおとし込み

• 調達プロセスへの組み込み:リスクの高い取引先には認証の保有(または他の手段による統制実装の証明)を受注条件とし、標準契約条項で求めます。代替として、RfP・RfQで加重評価基準とする方法もあります。

具体的には、調達・第三者リスク部門と連携して、次の点を検討するよう求めています。

• 要件の導入時期
• 監査権の契約への組み込みと行使方法
• 不遵守時のペナルティ(契約期間中の認証失効など)
• 再委託契約にも同じ要件を課すか
• サプライチェーン管理の実効性を測るKPI

サプライチェーンにおけるサイバーエッセンシャルの採用の確認

• モニタリング:IASMEのSupplier Check Toolで最大5,000社を一括照合し、CEまたはCE Plusの認証状況を確認できます。

大規模組織が最低限のセキュリティ基準として供給者に認証取得を求めるよう促しています。

またNCSC等はFTSE 350の全企業に対し、Cyber Essentialsをサプライチェーンに組み込むよう促す書簡を送付しています(書簡本文(GOV.UK、HTML版):Ministerial letter on cyber security、告知ブログ)。

2026年には、こうした既存の制度基盤の上に構築される形でSupply Chain Pledgeが導入されています(Guidance-Cyber Resilience Pledge declaration )。

3.4 防衛分野：DEFCON 658 / CSM v4 / DCC

防衛分野においては、また、よりレベルの高い仕組みが導入されています。

2025年12月3日以降、DEFCON 658を含む新規・既存のすべてのMOD契約は、Cyber Security Model version 4及びDefence Standard 05-138 Issue 4への適合が必要です。

Cyber Security Model version 4というのは、英国国防省(MOD)が防衛サプライチェーンに課すサイバーセキュリティの枠組みの現行版です。旧版がMODの情報の保護を目的としていたのに対し、v4はサプライヤーの組織全体のセキュリティとレジリエンスに焦点を移しています(リンク)。

サイバーセキュリティモデル(CSM)は、国防省がサプライチェーンにサイバーセキュリティを組み込むための仕組みである。これはリスクに基づく比例的なアプローチであり、以下を含む。

• CSMリスク評価:国防省(MOD)のデリバリーチームが初期リスク評価を実施する。これによりサイバーリスクプロファイルが決定される。
• 防衛サプライヤー向けサイバーセキュリティ規格:防衛規格05-138(Def Stan 05-138)は、各サイバーリスクプロファイルについて求められるサイバーセキュリティ統制を列挙している。サプライヤーは、Def Stan 05-138の統制を満たすことを契約上義務づけられる。
• サプライヤー保証質問票(SAQ):サプライヤーは、サプライヤー保証質問票を用いて、CSMの要件に照らした自己評価を行う。
• フローダウン:サプライヤーが下請に出す場合、当該サプライヤーがリスク評価を実施し、新たなサイバーリスクプロファイルを生成する。下請業者は、該当するサプライヤー保証質問票に回答する。

CSMバージョン4は、CSMに対する重要な変更であり、国防省の防衛サイバーレジリエンス戦略を支えるもので、CSMv4は、

• CSMの焦点を「MOD識別可能情報」から組織のセキュリティおよびレジリエンスへと変更する
• 4つの新たなサイバーリスクプロファイル(「レベル0」「レベル1」「レベル2」「レベル3」)を導入する
• 防衛規格05-138 第4版に定める統制を用いる
• 新たなCSMリスク評価およびSAQを完了するための、新しいオンラインのサプライヤーサイバー保護サービスを提供する

とされています。手続面では、CSMv4のプロセスは、入札前の要件提示から契約後の年次更新まで、次の7段階で進みます。

1. 案件の提示:発注機関(MOD)が、市場との最初の接触の段階でリスク評価参照番号(RAR)と要求されるCRPレベル(0〜3)を示します。通常は入札招請書に記載されます。
2. SAQへの回答:入札を予定するサプライヤーは、Supplier Cyber Protection Service上でSAQに回答し、CRPに照らして自己評価します。
3. 評価:SAQは自動採点され、適合・不適合が即時に通知されます。
4. CIPの作成:不適合の場合はCyber Improvement Plan(CIP)の作成が必須で、入札書類に含めて提出します。CIPは契約書の一部を構成し、サプライヤーが改善を約束することで、発注機関は適合に向けた途上での履行を認めることができます。
5. 選定:発注機関は、適合状況またはCIPの提案内容を選定で考慮します。
6. 契約締結:合意されたCIPがあれば、それを含めて契約が締結されます。
7. 契約の維持:サプライヤーは毎年、契約締結日の応当日から1か月以内に新たなSAQに回答し、適合の継続を確認します。不適合となった場合はCIPが検討されます。

不適合は直ちに失格を意味せず、CIPによる是正の約束が契約上の義務として取り込まれます。また適合性は契約時の一度きりではなく、年次で再確認されます。

既存契約の移行については、Industry Security Notice(ISN)を参照するよう案内されています。

防衛サイバー認証（Defence Cyber Certification（DCC））

さらにMODとIASME(Information Assurance for Small and Medium Enterprises.)は第三者認証制度を導入しています。

Defence Cyber Certification（DCC）（リンク）は

Defence Cyber Certification（DCC）は、英国の防衛サプライヤーを対象とする包括的なサイバーセキュリティ認証フレームワークである。本制度は、英国国防省（MOD）とIASMEが共同で策定したものであり、英国防衛分野のサプライチェーン全体のサイバーレジリエンス強化を目的とする施策の一環として位置付けられている。

4つの認証レベル（0〜3）で利用可能です。

レベル0・1ではCyber Essentials、レベル2・3ではCyber Essentials Plusが要求され、また、そのレベルごとに対応策が異なっています。具体的には、レベル0は3項目、レベル1は101項目、レベル2は139項目、レベル3は144項目の対応策が定められており、上位レベルほど求められる対応策が多くなります。具体的には、Defence Standard 05-138　Issue 4 Date: 14 May 2024　Cyber Security Standard for　Suppliers（リンク）の表で示されています。（イメージ）は、以下のとおりてす。

各レベルは、英国国防省(MOD)のサプライチェーンにおいて当該サプライヤーが担う役割に伴うサイバーリスクの程度に対応しており、レベル0は非常に低いリスク、レベル1は低〜中程度のリスク（良好な実務を伴う包括的なサイバーセキュリティプログラムの実証が求められる)、レベル2は高いリスク（高度なサイバーセキュリティの監督と計画の実証が求められます。レベル1に比べ、経営層の関与と、計画を実際に試す要求(テスト、演習)が加わる）、レベル3は重大なリスクが評価された場合に割り当てられます（多層防御を全面的に活用した専門的な能力の実証が求められます。レベル2との差は5項目と小さく、自動化と常時監視が中心）。概要として、

	レベル0	レベル１	レベル2	レベル3
呼称	Basic	Foundational	Advanced	Expert
想定リスク	非常に低い	低〜中程度	高い	重大
前提認証	Cyber Essentials	Cyber Essentials	Cyber Essentials Plus	Cyber Essentials Plus
認証に関する統制(0001、0002)	1	1	2	2
A:セキュリティリスクの管理	0	12	18	19
B:サイバー攻撃からの防護	2	75	95	98
C:セキュリティ事象の検知	0	9	15	15
D:インシデントの影響の最小化	0	4	9	10
合計	3	101	139	144
そのレベルで加わる主な要求	Cyber Essentials認証、UK GDPR遵守、レジリエントなシステム	ガバナンスとリスク管理、アクセス制御、月次の脆弱性スキャン、年次の侵入テスト、ログの12か月保管、採用時の身元確認	取締役会主導のセキュリティ管理、重要システムへの多要素認証、データ損失防止(DLP)、復旧計画の年次テスト、インシデント対応計画と年次演習、年次のデータ持ち出しテスト	脅威インテリジェンス能力、24時間365日の監視、設定不備や未承認機器の自動検出、完全性検証ツール、通信系統の冗長化の検討

認証の審査は、IASMEの認定を受けた認証機関(Certification Body)が、防衛規格Def Stan 05-138に照らして一時点の評価として実施します。申請者は、各対応策をどのように満たしているかを説明し、その証拠を提出する責任を負います。取得した認証は、組織全体を対象とする単一の保証として英国の防衛調達で提示できますが、毎年の適合確認(annual attestation)と3年ごとの再認証が条件となります。

普遍的な義務化に先立ち、個別のMOD契約が既にDCC認証を要求し始めています。ISO 27001、NIST CSF、CAFへの既存の整合は準備負担を軽減し得ますが、DCCは技術的統制のみならず組織全体の証跡を重視するため、方針文書のみでは合格しません。

---

3.5. サイバーセキュリティ・レジリエンス法案(Cyber Security and Resilience)

日本のSCS評価制度が任意てあり、私的当事者間においてソフトロー型の可視化スキームにとどまるのに対し、英国は、制定法によって採用のためのインセンティブが準備されつつあります。

Cyber Security and Resilience (Network and Information Systems) Bill は2025年11月12日に庶民院へ提出され（Bill 329）、2026年1月6日の第二読会、2月3日〜24日の委員会段階を経て、6月16日の報告段階・第三読会を無投票で通過しました。2026年6月17日に貴族院へ送付され（HL Bill 32）、7月14日に第二読会を超党派の原則的支持を得て終え、委員会段階は2026年9月1日に予定されています。国王裁可は2026年後半が見込まれ、政府の2026年実施協議を経た二次立法により、完全な効力発生は2028年頃と予想されています。改正対象はNetwork and Information Systems Regulations 2018（EU NISディレクティブの英国残存版）です。(法案ページ(審議状況・関連文書):Cyber Security and Resilience (Network and Information Systems) Bill)

法案の構成・内容については、最新版の法案テキスト:HL Bill 49からみることができます。法案は5部61条2附則からなります。具体的には、

• 第1部「序」(Introduction、1〜2条)は、「NIS規則」の定義と法案全体の概要を定めています。
• 第2部「NIS規則」(The NIS Regulations、3〜23条)は、2018年ネットワーク・情報システム規則を改正する部分で、法案の中心をなします。データセンター、負荷制御、マネージドサービスの事業者への適用拡大や、重要サプライヤーの指定、インシデント報告、費用回収・情報共有・執行に関する改正が盛り込まれています。
• 第3部「システムのセキュリティおよびレジリエンス:主務大臣の権能」(Security and resilience of systems: functions of the Secretary of State、24〜42条)は、主務大臣に対し、規制対象となる活動の指定、戦略的優先事項に関する声明の指定、規則の制定、行為規範の発出といった権限を与えています。
• 第4部「国家安全保障目的の指示」(Directions for national security purposes、43〜58条)は、ネットワーク・情報システムへの脅威が国家安全保障上のリスクとなる場合に、主務大臣が規制対象者や規制当局に指示を出す権限を定めています。
• 第5部「総則」(General、59〜61条)は、適用地域、施行、略称を定めています。

このほか、附則1「執行および不服申立て」(Enforcement and appeals)と、附則2「軽微な改正および付随的改正等」(Minor and consequential amendments etc)が置かれています。

サプライチェーンとの関係でいうと「第12条:重要サプライヤー」において、NIS規則に第4B部(規則14H〜14L)が挿入されます。指定の要件(規則14H)において、規制当局は、

• 基幹サービス事業者(OES)に、物品またはサービスを直接供給している。
• その供給のために、ネットワーク・情報システムに依存している。
• そのシステムに影響するインシデントが、供給先によるサービス提供に混乱をもたらし得る。かつ、その混乱が英国の経済または社会の日常的な機能に重大な影響を与える見込みがある。

上のすべてを満たす者を指定できます。情報コミッション(Information Commission)が同様の要件でデジタルサービス事業者(RDSP)やマネージドサービス事業者(RMSP)への供給者については、指定できます。

---

4 法的な論点

4.1 取引の公正性について

優越的地位の濫用・買いたたき等の規律が正面から問題になります。 従前、「サイバーセキュリティ構築宣言と「競争の番人」-グレイゾーンの解消への提言」を検討したのですが、それと同様の問題状況ということになります。

経産省と公正取引委員会は、2022年10月にうえでふれたパートナーシップ文書を公表しています(「サプライチェーン全体のサイバーセキュリティ向上のための 取引先とのパートナーシップの構築に向けて」)が、今回、これを補足するものとして、独占禁止法及び中小受託取引適正化法（取適法）との関係を整理し、「問題とならない」ケースの想定事例と解説文書を2025年12月26日に公表しています。

これは、

具体的には、発注者側が取引先に対し、サプライチェーン強化に向けたセキュリティ対策評価制度に基づく対策の要請を行うケースを想定し、発注者側・取引の相手方がパートナーシップを構築してセキュリティ対策と価格交渉を実施し、円満に合意するに至るための想定事例及び解説としています。
○サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップ構築促進に向けた想定事例及び解説（概要）
○【想定事例】発注側企業からの「サプライチェーン強化に向けたセキュリティ対策評価制度」４つ星相当の対策の実施要請を踏まえ、発注側企業と取引の相手方とが円満に価格交渉を行うためのプラクティス
○サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて（令和４年10月28日　経済産業省・公正取引委員会）を踏まえた想定事例について（解説）

です。

サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップ構築促進に向けた想定事例及び解説（概要）は、一枚のスライドで、想定事例(発注側企業からの「サプライチェーン強化に向けたセキュリティ対策評価制度」４つ星相当の対策の実施要請を踏まえ、発注側企業と取引の相手方とが円満に価格交渉を行うためのプラクティス )自体についての方向性を説明しています。

また、その補足事項(具体的には)として

• ① SC対策評価制度に基づいたセキュリティ対策要請が合理的範囲を超えた負担を課すものではないこと。
• ②発注者・相⼿⽅双⽅でパートナーシップを構築することの必要性や重要性。
• ③セキュリティの経費が物件費や⼈件費などの間接経費として計上されること。
• ④価格交渉の考え⽅や、要請をしていない発注者側企業に対する価格交渉に当たって⽀援機関を活⽤すること。
• ⑤取引かけこみ寺や公正取引委員会の事前相談制度・⼀般相談・事例集の紹介。

を説明しています。

想定事例については、

A 大企業は、サイバーセキュリティ対策の実施要請に当たっては取引の相手方と協力関係を構築することが重要であると考え、B中堅企業を支援するため以下の取組を実施した。また、C中小企業も同じサプライチェーンに属するため、支援の対象とした。

となっていて、しかも、B中堅企業に対しとおり標準的なサイバーセキュリティ対策の実施要請を行ったA 大企業は、その際に、費用負担の考え方やセキュリティ対策に要した費用も価格交渉の対象となることを説明し、価格交渉の要請があれば積極的に対応することを周知したとなっています。

解説においては、「サプライチェーン強化に向けたセキュリティ対策評価制度との関係」が念頭におかれて議論されています。

国において検討中のサプライチェーンにおけるレジリエンス強化のための評価基準に基づいた対策を実施することは、サプライチェーンに属する企業にとって必要性かつ合理性のあるものと考えられますので、取引の相手方に合理的範囲を超えた負担を課しているものではないと考えられます

とされています。

4.2 日英比較の要点

日本の制度と英国の制度を比較します。

4.3  その他の留意事項

その他、注意しておくべき事項としては、以下のような事項があると思われます。

有効期間1年と継続契約

★3の有効期間1年と長期継続契約の期間ミスマッチです。経産省は、契約満了までは必要な★の評価を維持し続けることを求める運用が考えられるとしていますが、更新失敗時の効果（是正期間、解除権の発生要件）は個別に規定を置く必要があります。

不適切な勧誘について注意喚起

経産省は本制度に係る不適切な勧誘について注意喚起を出しています。「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）に関する注意喚起」になります。

令和８年度末頃の制度開始を予定している「サプライチェーン強化に向けたセキュリティ対策評価制度」（SCS評価制度）を引き合いに、「評価を取得していないと商取引が規制される」「今すぐ評価を取得しないと入札から除外される」といった営業活動による、製品・サービスの勧誘が報告されています。

ということを前提に

両者で実施状況を確認することを想定した 任意の制度 であって、上記のような営業活動は、本制度の趣旨・目的とは異なるものです。

ということを強調しています。