【2026年度末開始】SCS評価制度とは？概要から要求事項のポイントを解説

サプライチェーンを経由したサイバー攻撃が相次ぐなか、発注企業側は「委託先の対策状況を把握しにくい」、受注企業側は「取引先ごとに異なるチェックシートへの対応負担が大きい」という問題を抱えており、取引先のセキュリティを確認・担保する方法が双方の共通課題となっています。

こうした課題を踏まえて構築が進められているのが、SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）です。企業のセキュリティ対策を共通の要求事項で確認し、達成状況を段階（★）として可視化します。

2026年8月時点では、★3と★4の要求事項・評価基準が公表され、2026年度末（2027年1〜3月頃）の制度開始（申請の受付開始）を目標に運営基盤の整備が進んでいます。

本記事では、SCS評価制度の目的、対象範囲、★3・★4の要求事項のポイント、そして、制度開始に向けて企業が整理できることについて解説します。

国内唯一のISMAP登録済
SBOM・脆弱性管理ツール

SCS評価制度とは

SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策状況を、共通の要求事項と評価基準によって可視化する制度です。

経済産業省が制度方針を示し、同省の監督のもとでIPA（独立行政法人情報処理推進機構）がスキームオーナーとして運営します。

制度が想定しているのは、企業間取引における次のような活用です。

• 発注企業が、取引によるリスクに応じて委託先に望ましい段階（★3または★4など）を示す
• 委託先（受注企業）が、示された段階の要求事項に沿って対策を整備する
• 発注企業が、委託先（受注企業）による★の取得状況や対策状況を確認する
• 取得結果や評価結果を、取引当事者間のリスクコミュニケーションに活用する

★の取得は、取得・更新時点で各段階の水準を満たしていることを示します。ただし、サイバー攻撃を完全に防げることや、将来にわたって安全であることを保証するものではありません。

また、SCS評価制度は企業を優劣で並べる格付け制度ではありません。サプライチェーンにおける立ち位置や想定リスクに応じて必要な対策を示し、対応状況を可視化するための制度です。取得は任意であり、特定のセキュリティ製品の導入も取得条件ではありません。

SCS評価制度が作られる背景

発注企業と受注企業の双方に課題がある

経済産業省の制度構築方針では、サプライチェーンを通じたセキュリティインシデントの頻発を背景として、発注側と受注側の課題が整理されています。

発注企業側の課題

委託先のセキュリティ対策が外部から見えにくいことです。自社でチェックリストを作成しても、要求内容や水準が妥当かを判断するのは容易ではありません。取引先が多い企業ほど、回答の回収、内容の確認、改善依頼にも大きな負荷が生じます。

受注企業側の課題

複数の発注企業から異なる形式・水準の確認を求められることです。同じ対策について何度も説明する、似た質問に別々の様式で回答するといった重複対応が、人員の限られる中小企業の負担になっています。

SCS評価制度には、共通の要求事項を介して双方の認識をそろえ、確認にかかる社会的コストを減らす役割が期待されています。

対象となるサプライチェーンリスク

制度構築方針では、主に次の3種類のリスクが想定されています。

1. 事業・サービスの提供途絶
   取引先への攻撃やクラウドサービスの停止によって、部品供給やサービス提供が遅延・停止するリスクです。
2. 機密情報の漏えい・改ざん
   BPO事業者、ITベンダー、クラウド事業者などへの攻撃を起点として、発注企業の情報が漏えい・改ざんされるリスクです。
3. 取引先を踏み台とした不正侵入
   委託先やマネージドサービスの環境を経由し、発注企業のシステムへ侵入されるリスクです。

情報の機密性だけでなく、事業継続や取引ネットワークを介した侵入まで対象としている点が、制度を理解するうえで重要です。

SCS評価制度はいつから始まるのか

経済産業省の制度構築方針では、
2026年度末（2027年1〜3月頃）の制度開始（申請の受付開始）が目標として示されています。

2026年8月時点の主な経緯と今後の予定は次のとおりです。

ただし、開始時期は制度運営基盤の整備状況などによって変更される可能性があります。具体的な申請受付日や評価手続については、今後公表される運営規程、評価用ガイドなどで明らかになる予定です。

⚠️経済産業省は、「評価を取得していないと商取引が規制される」「今すぐ取得しなければ入札から除外される」などの説明を伴う勧誘について注意を呼びかけています。SCS評価制度は任意であり、特定製品の導入を必須とする制度でもありません。制度判断には経済産業省とIPAの公表情報が基準となります。

SCS評価制度の対象となる企業・組織

SCS評価制度でセキュリティ対策の実施主体として想定されているのは、サプライチェーン上の取引における受注者側です。ただし、発注者にも、取引先へ適切な段階を示したり、取得状況を確認したりする役割が想定されています。1社が取引によって発注者にも受注者にもなり得るため、サプライチェーンを構成する幅広い企業に関係します。

評価取得の申請主体は、原則として法人または個人事業主の単位です。★3では申請主体を問わずセキュリティ専門家による自己評価結果の確認・助言を、★4では評価機関による第三者評価と技術検証を受けます。なお法人は、設定した適用範囲の妥当性についてセキュリティ専門家（★3）または評価機関（★4）の確認を経ることで、法人全体ではなく事業部やグループなどを単位に申請することもできます。

直接の対象は企業のIT基盤

制度が直接の対象とするのは、サプライチェーンを構成する企業のIT基盤です。

対象に含まれる代表例は次のとおりです。

• 全社共通で利用するサーバーや認証基盤
• パソコン、スマートデバイスなどのエンドポイント
• Webサーバー、メールサーバーなどのインターネット公開サーバー
• ファイアウォール、ルーター、VPN装置などの外部ネットワーク境界
• IT基盤を構成するクラウドサービス
• 親会社が提供するグループ共通ネットワークなど、他社と責任を共有するIT環境

インターネット公開サーバーは適用範囲に必ず含めるとされています。クラウドサービスなどでは、責任共有モデルに基づき、自社が担う対策を実装するとともに、サービス提供者が担う対策の実施状況を確認します。確認方法の例として、ISMAP登録の有無やSOC2レポートの確認などが示されています。

一方、製造環境などの制御システム（OT）や、発注元などへ提供する製品は、原則として本制度の直接の対象外です。これらはIT基盤とは求められる対策が異なるため、他の制度やガイドラインなどに基づく対応が想定されています。ただし、対象内のIT基盤へ接続しているものを適用範囲外とする場合は、VLANやファイアウォールなどにより、適用範囲内外の通信を必要最小限に制限する必要があります。

★3・★4・★5の違い

2026年度末（2027年1〜3月頃）に制度開始（申請の受付開始）が予定されているのは★3と★4です。

★1・★2についてはIPAの「SECURITY ACTION」を参照する位置づけで、★5は2026年度以降に要求事項・評価基準や評価スキームが具体化される予定です。

★3：一般的なサイバー攻撃に備える水準

★3は、広く認知された脆弱性などを悪用する一般的なサイバー攻撃への対処を想定しています。

制度上は、基礎的な組織的対策とシステム防御策を中心とする、すべてのサプライチェーン企業が「最低限実装すべき水準」と位置づけられています。

評価方法は専門家確認付き自己評価です。取得希望組織が実施し作成した自己評価について、セキュリティ専門家による確認・助言を経て、評価結果を確定します。単なる自己申告ではなく、取得希望組織が作成した自己評価結果や、その判断根拠となる書類を専門家が確認する仕組みです。

⚠️「最低限」と記載されていますが、評価基準まで見ると、一定条件に該当するセキュリティアップデートのリリースから14日以内の適用、または期限内に適用できない場合の代替的なリスク低減策（評価基準4-4-4-2）や、不正通信をリアルタイムで検知・遮断する仕組み、ログ・アラートの分析、インシデント該当性の判断、速やかな発報・通知（評価基準5-1-1-1〜5-1-1-3）など、迅速かつ継続的な運用を要する統制も★3に含まれています。

規程や手順を作成するだけでなく、脆弱性情報やアラートを継続的に把握し、必要な場合に短期間で判断・対応できる体制が実務上必要になります。

★4：サプライチェーンで標準的に目指す包括的な水準

★4は、初期侵入の防御だけでなく、侵入後の内外への被害拡大防止、攻撃者による目的遂行のリスク低減、事業継続、重要な取引先のセキュリティ対策状況の把握まで含みます。

サプライチェーン企業等が標準的に目指す水準で、特に、供給停止によってサプライチェーンへ大きな影響を及ぼす可能性がある企業や、漏えいした場合の影響が大きい機密情報などを扱う企業への適用が想定されています。

評価方法は第三者評価です。評価機関による評価に加え、実地審査や技術検証を含む対策実施状況の確認が想定されています。

★4の43件には、★3の26件が含まれます。上位段階が下位段階の要求事項を包含するため、★3の取得を経ずに★4を取得することも制度上は可能です。

★5：2026年度末以降に具体化

★5は、国際規格などのリスクベースの考え方に基づいて自組織に必要な改善プロセスを整備し、システムに対して現時点のベストプラクティスに基づく対策を実施する段階として検討されています。

ISMS適合性評価制度や★3・★4との整合も踏まえ、要求事項・評価基準や評価スキームが2026年度末以降に具体化される予定です。

★3・★4の要求事項のポイント

7つに分類された要求事項を把握する

2026年3月に公表された要求事項・評価基準では、43件の要求事項が7つの大分類で整理されています。

★3はそのうち26件、★4は43件すべてが対象です。

この7分類は、NIST Cybersecurity Framework（NIST CSF）の6機能である「統治（GV）」「識別（ID）」「防御（PR）」「検知（DE）」「対応（RS）」「復旧（RC）」を基礎に、SCS評価制度が重視する「取引先管理」を独立した分類として加えた構成です。

資産把握が複数の対策を支える基盤となる

「リスクの特定」では、★3・★4を通じて、情報機器・OS・ソフトウェアに関する情報の把握（評価基準3-1-1-1〜3-1-1-7）、ネットワークとネットワーク機器に関する情報の把握（評価基準3-1-2-1〜3-1-2-4）、外部情報サービスに関する情報の把握・管理（評価基準3-1-3-1〜3-1-3-2）が求められます。★3の基準を基礎として、★4では把握する情報や管理内容が追加・強化されます。

対象となる資産を把握できていなければ、アクセス権の管理、セキュリティパッチの適用、ログ取得、バックアップ、インシデント発生時の影響調査などを適切に行うことが難しくなります。そのため、台帳を一度作成して終えるのではなく、機器の追加・廃止、ソフトウェアの更新、クラウドサービスの利用変更などを継続的に反映できる運用が重要です。

★3の注意点①：重大な脆弱性は原則14日以内に対応

★3には「情報機器、OS及びソフトウェアの安全な構成を確立し、維持すること」（要求事項4-4-1、評価基準4-4-1-1〜4-4-1-3）と、「セキュリティパッチ及びアップデートの適用に係る手続を定めること」（要求事項4-4-4、評価基準4-4-4-1〜4-4-4-2）が含まれます。

なかでも、評価基準4-4-4-2では、利用中の機能・設定に関係するアップデートが次のいずれかに該当する場合、リリースから14日以内に適用することが求められます。

• ベンダーが「重大（Critical）」または「高リスク（High Risk）」と説明する脆弱性を修正する
• CVSSの基本スコアが7.0以上の脆弱性を修正する
• 修正対象となる脆弱性の深刻度がベンダーから示されていない

対象は、会社支給パソコンのOS・ブラウザ・Officeソフト、サーバーのOS・ミドルウェア、会社支給スマートデバイスのOS・アプリ、インターネット境界に設置するネットワーク機器のOS・ファームウェアです。

14日以内に適用できない場合は、対象機能の無効化、ベンダー推奨の回避策、機器のネットワーク分離、不正通信を監視・遮断する仕組みの導入など、適用までの代替的なリスク低減策を講じる必要があります。

したがって、★3であっても、アップデート情報の把握、影響を受ける資産の特定、対応要否の判断、検証、承認、展開、例外時の代替策までを期限内に進められる運用体制が実務上必要になります。

パッチ適用手順を文書化するだけでなく、実際に期限内で対応できる体制と処理能力を整えることが重要です。

★3の注意点②：不正通信のリアルタイム検知・遮断が必要

「攻撃等の検知」は、★3の要求事項数が1件であるため、対応負荷が小さいように見えるかもしれません。しかし、その配下にある評価基準5-1-1-1〜5-1-1-3では、次の検知・分析・通知に関する統制が求められます。

• 5-1-1-1：社内外ネットワークの境界または端末で、インターネットから社内への通信と、社内から不正なサーバーへの通信の双方をリアルタイムで検知・遮断する
• 5-1-1-2：ネットワーク機器のログとアラートを分析し、不審な事象がセキュリティインシデントに該当するかを担当者または管理者が判断する
• 5-1-1-3：異常時にアラートを速やかに発報し、インシデントの速報レポートを作成・通知する

製品やサービスの導入だけでは、この基準への対応は完結しません。アラートの受信者、確認までの時間、誤検知の切り分け、インシデント該当性の判断、遮断後の復旧判断などを運用として定める必要があります。

監視業務を外部へ委託する場合も、自社と委託先の役割、連絡経路、判断権限の明確化が必要です。

★4で追加・強化される内容

★4では、★3の評価基準を前提として、管理対象や運用プロセスが次のように追加・強化されます。

脆弱性管理のプロセス化

脆弱性・脅威情報の収集から対応までの役割、情報源・ツール・頻度、対応要否の判断基準、脆弱性の残存状況、対応履歴の月次点検を含む管理体制が独立した要求事項になります（要求事項3-2-1、評価基準3-2-1-1〜3-2-1-5）。

また、インターネット境界のネットワーク機器では、OS・ファームウェアにCVSS基本値7.0以上の脆弱性がない状態が求められます（評価基準4-4-4-3）。サポート期限を迎えたOS・ソフトウェアについては、サポート中のものを利用するか、やむを得ず利用する場合に更改計画と代替的なリスク低減策が必要です（要求事項4-4-2、評価基準4-4-2-1）。

検知・分析対象の拡張

会社支給パソコンで利用を許可するソフトウェアの一覧化、許可されていないソフトウェアを自由にインストールできないようにする社内ルールの整備、インストール状況の年1回以上の点検、受領ファイルの安全性確認が加わります（評価基準5-1-2-1〜5-1-2-4）。さらに、セキュリティインシデントとして扱う事象の範囲とレベルを定め、アラート受信時にインシデント該当性やレベルを判断する運用も求められます（評価基準5-2-1-1〜5-2-1-2）。

取引先管理の拡張

★3では、接続先システムの把握と年1回以上の点検（評価基準2-1-1-1〜2-1-1-2）、機密情報の取扱いに関する事前合意（評価基準2-1-2-1）、インシデント時の役割・責任の明確化（評価基準2-1-4-1）が対象です。★4では、事業継続や情報管理の観点から重要な取引先を特定し、そのセキュリティ対策状況を年1回以上の頻度で把握する基準が追加されます（評価基準2-1-3-1）。

★3と★4のどちらを想定するか

すべての企業が一律に★4を目指す制度ではありません。

制度構築方針では、2社間の取引契約などにおいて、発注者が取引先に対応が望ましい段階を提示し、★の取得状況を確認することが想定されています。

★3は、すべてのサプライチェーン企業が最低限実装すべきセキュリティ対策として、一般的なサイバー攻撃への対処を想定した水準です。これに対して★4は、サプライチェーン企業等が標準的に目指すべき水準として、供給停止などによってサプライチェーンに大きな影響をもたらす企業への攻撃や、情報漏えいによって大きな影響をもたらす資産への攻撃を想定しています。

どの段階が求められるかは、自社だけで決めるのではなく、発注者・取引先との間で確認することが重要です。

実務上は、主要な取引先から求められる水準、自社が扱う情報、システム接続の有無、事業停止時の影響、代替可能性などを整理しておくと、適切な段階を検討する材料になります。

制度開始に向けて企業が整理できること

申請方法や評価用ガイドが未公表の段階でも、すでに公開されている要求事項をもとに現状を整理できます。

実務上は、次の順序で進めると全体像を把握しやすくなります。

1. 取引関係と想定リスクを整理する

主要取引先との関係、共有する機密情報、相互のシステム接続、事業停止時の影響、再委託の有無を一覧化します。この情報は、どの段階が想定されるか、どの取引先を重点管理するかを考える土台になります。

発注者の立場では、すべての取引先へ一律の水準を求めるのではなく、事業継続・情報管理・システム接続などの観点から取引先を分類する考え方が現実的です。受注者の立場では、主要顧客から想定される水準や確認事項を把握することが検討の起点になります。

2. 適用範囲となるIT基盤を可視化する

サーバー、パソコン、スマートデバイス、ネットワーク機器、公開サーバー、クラウドサービス、OS、ソフトウェアなどを整理し、所有者・管理者・設置場所・用途を対応づけます。

クラウドやグループ共通基盤では、自社と提供者の責任分界も整理します。対象内外の境界が曖昧な場合、評価対象の漏れだけでなく、誰が対策するのか不明確になるリスクがあります。

3. 26件または43件の要求事項と現状を照合する

目標とする段階の要求事項ごとに、対応状況、根拠資料、担当部門、課題を整理します。対応済みであっても、規程だけが存在して運用記録がない、ツールは導入済みでも責任者や手順が不明確といった状態では、評価時に説明が難しくなる可能性があります。

ギャップ分析では、「未対応」「一部対応」「対応済み」の区分に加えて、裏付けとなる証跡を記録すると進捗を管理しやすくなります。既存のISMS文書、資産台帳、教育記録、ログレビュー記録、パッチ適用履歴、インシデント訓練記録などが活用候補になります。

4. 優先度をつけて運用を整備する

改善項目は、事業への影響、攻撃される可能性、対策に必要な期間、他の要求事項への波及効果を踏まえて優先順位を設定します。

資産把握、ID・アクセス権管理、認証、セキュリティパッチ、バックアップ、インシデント対応などは、複数の要求事項や日常的なリスク低減に関係します。特に★3でも、重大なアップデートの原則14日以内の適用（評価基準4-4-4-2）や、不正通信のリアルタイム検知・遮断、ログ・アラート分析、速やかな通知（評価基準5-1-1-1〜5-1-1-3）が含まれます。現状確認では規程の有無だけでなく、アップデートのリリースからパッチ適用までの日数、例外時の代替策、アラート受信から判断・通知までの所要時間など、実際の処理能力を確認することが重要です。

5. 評価に用いる証跡を継続的に残す

制度では、要求事項に沿った運用が実施されていることを説明できる状態が必要になります。最新版の規程、承認記録、台帳、点検記録、教育・訓練記録、脆弱性対応履歴、例外承認、経営層への報告などを、担当者が変わっても追跡できる形で残す仕組みが有効です。

★3の有効期間は1年、★4は3年とされているため、取得時だけ帳尻を合わせるのではなく、更新や継続確認を見据えた運用設計が求められます。

脆弱性管理とSBOMが関係する要求事項

• 資産・ソフトウェア情報の把握（評価基準3-1-1-1〜3-1-1-7）

• 安全な構成の維持（評価基準4-4-1-1〜4-4-1-6）

• パッチ・アップデート（評価基準4-4-4-1〜4-4-4-3）

• 脆弱性管理プロセス（評価基準3-2-1-1〜3-2-1-5）

• サポート期限管理（評価基準4-4-2-1）

これらは、継続的な情報収集と判断が必要な領域です。対象資産が多い企業では、表計算ソフトを中心とした手作業だけでは更新や追跡が難しくなる場合があります。

SBOM（Software Bill of Materials）は、ソフトウェアを構成するコンポーネントを一覧化したものです。SBOMと脆弱性情報を対応づけることで、新しい脆弱性が公表された際に、影響を受けるソフトウェアやバージョンを特定しやすくなります。

SCS評価制度の要求事項・評価基準は、SBOMの作成や導入を一律の必須要件として明記しているわけではありませんが、ソフトウェア構成の把握や脆弱性管理を継続する手段の一つになります。

脆弱性管理クラウド「yamory（ヤモリー）」が支援できる範囲

脆弱性管理クラウド「yamory」は、インフラからアプリケーションレイヤーまでに潜む脆弱性を可視化し、対応の優先度付けまでを自動化する国産のクラウドサービスです。オンプレミス（閉域網）・クラウド環境問わず導入でき、脆弱性の他にも、EOL、OSSライセンス違反、クラウドの設定不備（CSPM）を一元管理できます。

SCS評価制度との関係では、主に次の領域で活用できます。

資産・ソフトウェア情報の把握

関連する評価基準：3-1-1-1〜3-1-1-7

• オンプレ・クラウド環境問わず、スキャン・連携したIT資産の構成情報を可視化
• SBOMを活用し、直接・間接的に利用されているソフトウェアコンポーネントを把握

脆弱性・アップデート情報の継続的な把握

関連する評価基準：3-2-1-1〜3-2-1-5、4-4-4-1〜4-4-4-3

• IT資産に影響する脆弱性や対策情報を継続的に収集・可視化
• 緊急に対応が必要なIT資産・ソフトウェアを特定

リスク対応の優先度判断

関連する評価基準：3-2-1-1〜3-2-1-5、4-4-4-1〜4-4-4-2

• CVSS、攻撃情報、資産の重要度などを踏まえ、優先的に対応すべき脆弱性を特定
• 評価基準4-4-4-2の対象となる脆弱性や、EOL期限を意識した対応管理を支援

対応状況の記録

関連する評価基準：3-2-1-1〜3-2-1-5、4-4-4-1〜4-4-4-2

• 脆弱性への対応状況や進捗、対応履歴を一元管理

これらは、SCS評価制度の「リスクの特定」「攻撃等の防御」に含まれるIT資産の把握、安全な構成、パッチ・アップデート、脆弱性管理などの運用を効率化する手段としてご活用いただけます。

yamoryを使って、SCS評価制度を見据えた脆弱性管理を始めませんか？

以下より、yamoryのサービス紹介資料をダウンロードできますので、ぜひご覧ください。

脆弱性管理クラウドyamoryの詳しい機能をご紹介しています。

■参考文献

• IPA「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」
• 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」
• 経済産業省「★3・★4要求事項・評価基準」
• 経済産業省「SCS評価制度に関する注意喚起」

SCS評価制度に関するよくある質問

Q. SCS評価制度への対応は義務ですか？

A. 法令によって一律に取得を義務づける制度ではなく、取得は任意です。一方で、企業間取引において発注企業が委託先へ望ましい段階を示し、取得状況を確認する利用が想定されています。そのため、個別の取引条件や調達方針のなかで対応を求められる可能性はあります。

Q. 制度はいつ始まりますか？

A. 経済産業省は、2026年度末（2027年1〜3月頃）の制度開始（申請の受付開始）を予定しています。★3・★4の申請方法は、2026年10月頃に公開予定とのことです。

Q. ★3と★4の要求事項はいくつありますか？

A. ★3は26件、★4は43件です。★4の43件には★3の26件が含まれます。各要求事項には、実施状況を確認するための複数の評価基準が設定されています。要求事項数と評価基準数は異なるため、資料を参照する際には区別が必要です。

Q. ★3を取得してからでなければ★4を取得できませんか？

A. そのような前提ではありません。上位段階は下位段階の要求事項を包含しますが、★3の事前取得を★4取得の条件とはしていません。

Q. ISMSを取得していればSCS評価制度への追加対応は不要ですか？

ISMSの仕組みや記録を活用できる領域はありますが、自動的にSCS評価制度の要求事項を満たすわけではありません。適用範囲や具体的対策、取引先管理などの差分を確認する必要があります。

Q. OTや自社製品も評価対象ですか？

製造環境などのOTシステムや、発注元へ提供する製品そのものは直接の対象としないとしています。企業のIT基盤が主な対象となります。ただし、適用範囲外としたOTシステムや製品環境が、適用範囲内のIT基盤へ接続している場合は、両者の通信を必要最小限に制限する必要があります。

Q. ★3は「最低限」なので対応しやすい水準ですか？

A. 必ずしも対応しやすいとは限りません。制度上は、すべてのサプライチェーン企業が最低限実装すべき水準とされていますが、一定条件に該当するアップデートのリリースから14日以内の適用、または期限内に適用できない場合の代替的なリスク低減策（評価基準4-4-4-2）が含まれます。また、不正通信のリアルタイム検知・遮断、ネットワーク機器のログ・アラート分析、インシデント該当性の判断、速やかな発報・通知（評価基準5-1-1-1〜5-1-1-3）も求められます。人員、運用時間、対象資産数、既存ツールによっては、体制整備に時間を要する可能性があります。

Q. 特定のセキュリティ製品が必要ですか？

特定製品の導入は取得条件ではありません。評価の対象は、各要求事項を満たす対策が実装・運用されているかどうかです。ツールは運用を効率化し、継続的な記録を支える手段として位置づけられます。