コラム

COLUMN

取引先からSCS評価制度の★4を求められたら?まず受注側がとるべき対応

取引先(発注側)から突然「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)の★4で対応してほしい」と言われた。
でも、★4は重い。すぐ取れない。そもそも★3で十分では?——受注側がつまずくのは、ここです。

本制度の想定は、2社間の取引契約等で、委託元(発注側)が委託先(受注側)に適切な段階(★)を提示し、対策を促し、実施状況を確認するという運用です。
つまり受注側の勝ち筋は、「★を取れます/取れません」の二択ではなく、何を満たし、何をいつまでに、どう確認できるかを説明できる状態を作ることにあります。制度の目的も、発注者・受注者双方にとって、適切な対策の決定や対策状況の説明をしやすくすることにあります。

30秒でわかる、最初にやる3ステップ

  1. 求められているのが「★取得」なのか「チェックリスト回答」なのかを切り分ける
  2. 対象範囲(どのIT基盤/どこまで)を合わせる
  3. 対応は3択で検討する
    • 取得に向けて進める(ロードマップ)
    • 当面はチェックリスト運用(要求事項・評価基準を使う)
    • 範囲を絞って段階導入(重要領域から先に)
  1. なぜ取引先は★を求めてくるのか
  2. 取引先に最初に確認すべき3つの質問
  3. ★3と★4の違い
  4. ★3で済むケース、★4になりやすいケース
  5. 依頼を受けたときの対応
  6. 対応チェックリスト
  7. ★が間に合わないときの代替案
  8. 再委託がある場合は、どこまで見ればよいか
  9. つまずきやすい4つのポイント

発注側が★を求める背景には、単に形式として★が欲しいというより、取引先の対策状況を一定の基準で確認したいという事情があります。サプライチェーンを通じたインシデントが増える中で、発注側は委託先の対策状況が見えず、要求事項(チェックリスト等)の妥当性の担保も難しい。一方で受注側は委託元ごとに要求がバラバラで過度な負担になる。このような負担を軽減しようとしているのがSCS評価制度です。

ここで重要なのが

  • 本制度は「格付け制度」ではない(対策レベルを競わせる目的ではない)
  • ★取得は、完全なセキュリティを保証しない(取得・更新時点で水準を満たすことを示すだけ)

この2点を押さえると、発注側との会話が「★4を取れるか」から「取引リスクをどう下げ、どう説明するか」に戻ります。結果として、過剰要求の抑制にもつながります。

なお、制度の開始時期は、公表情報として2026年度末頃を目指すとされています。

SCS評価制度の開始時期や対象範囲、★3・★4に向けて何から準備すべきかを全体像から整理したい方は、「SCS評価制度はいつから?セキュリティ対策評価制度の対象と★3/★4の準備ロードマップ」もあわせてご覧ください。

Q1:求められているのは「★取得」か「チェックリスト回答」か

制度上、発注側は「対応が望ましい段階(★3・★4等)を提示したうえで、取引先の★取得有無を確認」する想定です。
一方で、取引先(受注側)が直ちに★を取得できない場合には、発注側が要求事項・評価基準をチェックリストとして活用することも考えられる、と明示されています。

→ まず「いま求められているのはどっちか」を確認します。

Q2:対象範囲はどこか(どのIT基盤/どこまで)

制度が対象とするのは「サプライチェーン企業等のIT基盤(クラウド環境含む)」で、OTや提供製品は直接対象としない整理です。
また適用範囲の考え方として、インターネット公開サーバは必ず含める、外部ネットワーク境界の機器も範囲定義の対象になる、など具体が出ています。

→ 「この取引で問題にしている範囲」を合意しないと、回答が全部“ズレた正解”になります。

Q3:期限と確認方法は何か

確認方法は、年次確認・台帳確認・訪問点検など、運用の想定が複数あります。再委託の例では、年1回以上の把握や、訪問/チェックシート等の方法例も示されています。

→ 期限と確認方法が決まると、「何を成果物として出すか」が決まります。

受注側がまず誤解しがちなのは、「★4=上位互換だから、とにかく重い」だけで止まることです。重いのは事実ですが、“どこが重いか”が見えると、交渉もしやすくなります。

★3:専門家確認付き自己評価

★3は、セキュリティ専門家による確認を経た自己評価(専門家確認付き自己評価)を求めるスキームです。

★4:第三者評価+技術検証

★4は、評価機関による第三者評価(ヒアリング・規程確認等)に加え、技術検証を求めるスキームです。
評価の実施内容として、文書確認に加え、実地審査(ヒアリング、規程、操作画面等の確認)、さらに技術検証(公開機器等への脆弱性検査)まで想定されています。

「★3を取っていないと★4が取れない」関係ではない

上位段階は下位段階を包括しますが、★3を事前取得していないと★4を取得できない、という関係ではないとされています。

つまり、「いきなり★4要求」が来ても、形式上は矛盾しません。だからこそ、受注側はどのリスク観点が理由で★4なのかを確認する必要があります。

なお、★4対応では「対策をしていること」だけでなく、それをどのように示し、確認してもらうかも重要になります。証跡や説明の考え方を詳しく知りたい方は、「セキュリティ対策評価制度『★4』獲得の鍵は『証明』にあり」も参考になります。

制度構築方針には、取引先を★3/★4に割り当てる考え方が示されています。軸は大きく2つです。

判断軸1:事業継続リスク(止まると困るか)

取引先の事業中断により、自社の事業継続上重要な業務に許容できない遅延が生じ得るか、代替調達できるか、在庫確保は可能か、といった観点です。

判断軸2:情報管理リスク(漏れる/踏み台になるか)

取引先が自社の重要な機密情報にアクセスできるか、取引先から自社システム・ネットワークへアクセスできるか、その範囲はどうか、といった観点です。

★3で不足があるなら、★4や上乗せ要求もあり得る

★3要求事項に不足がある場合、★4を求めたり、要求事項へ対策を上乗せすることも想定されています。受注側の現実解は、「全部★4」ではなく「不足観点だけ上乗せで合意」の提案です。

取引先からSCS評価制度への対応を求められたとき、受注側が最初にやるべきことは、いきなり「対応できます」「できません」と答えることではありません。
まずは、何について、どの水準で、いつまでに、どのように確認したいのかを整理し、会話の前提をそろえることが重要です。

依頼内容を整理し、前提をそろえる

最初に確認したいのは、今回の依頼がどの取引を対象にしているのか、そしてどのシステム範囲についての話なのかという点です。
ここが曖昧なままだと、受注側は自社全体の対策状況を説明しているつもりでも、発注側は特定業務に関わるIT基盤だけを確認したい、というすれ違いが起こります。

そのため、回答の前に、対象となる取引、業務、システム、ネットワーク範囲を受注側の理解として短く整理し、認識が合っているかを確認することが大切です。

★の意味を共有し、期待値を調整する

次に重要なのが、★の位置づけを共有することです。
SCS評価制度の★は、単なる格付けでも、完全な安全を保証するものでもありません。あくまで、取引に必要なセキュリティ対策の水準を整理し、確認しやすくするための共通言語です。

この前提を共有できていないと、発注側は「★4でなければ不十分」、受注側は「★4は重すぎて無理」という対立になりやすくなります。
先に制度の趣旨をそろえておくことで、会話を「取れるかどうか」ではなく、「どのリスクに対して、どの対応が必要か」という実務的な議論に戻しやすくなります。

現状を整理して伝える

そのうえで、自社の現状を整理します。
ここでは、詳細な構成情報や設定値まで最初から開示する必要はありません。まずは、取得済みなのか、取得予定なのか、未着手なのかといった現在地を示し、必要に応じて補足説明を加える形で十分です。

大切なのは、できていることを過大に見せることではなく、現状を誤解なく伝えることです。
現時点で不足がある場合も、曖昧にせず、どこまで対応済みで、どこからが今後の課題なのかを切り分けて伝えるほうが、結果として信頼につながります。

不足している観点を特定する

現状を示した後は、何が不足しているのかを整理します。
このとき、単に「まだ取れていません」と言うだけでは不十分です。ガバナンス、取引先管理、リスク把握、防御、検知、対応、復旧といった観点のうち、どこにギャップがあるのかを見える化することが重要です。

不足している観点が明確になると、発注側に対しても「なぜ現時点で★4が難しいのか」「どの部分なら先に対応できるのか」を説明しやすくなります。
逆にこの整理がないと、必要以上に広い要求をそのまま受け入れてしまったり、会話が抽象的なまま長引いたりしやすくなります。

選択肢を持って提案する

ギャップが見えたら、受注側から対応の選択肢を提示します。
現実的な進め方としては、主に次の3つがあります。

  • ★取得を目指して計画的に進める
  • 当面は要求事項・評価基準を使ったチェックリスト運用で対応する
  • 対象範囲を重要領域に絞って段階的に整備する

ここで重要なのは、「できる」「できない」の二択にしないことです。
たとえ直ちに★取得が難しくても、代替案や段階的な進め方を提示できれば、発注側との合意形成は進めやすくなります。

次のアクションを成果物ベースで示す

最後に、次に何をいつまでに出すのかを明確にします。
たとえば、チェックリスト回答を提出するのか、対象範囲を整理した回答書を出すのか、あるいは取得に向けたロードマップを提示するのかを決めておくと、発注側も判断しやすくなります。

「検討します」「社内で確認します」だけでは、相手にとっては進んでいるのかどうかが見えません。
そのため、期限と成果物をセットで示し、会話を前に進めることが大切です。

情報開示は段階的に進める

なお、やり取りの中では、どこまでの情報を開示するかにも注意が必要です。
取引先への説明は必要ですが、システムの詳細構成や設定内容など、過度に踏み込んだ情報を最初から広く共有するのは望ましくありません。

秘密保持契約の有無や確認方法も踏まえながら、まずは説明の骨組みを示し、必要な範囲で段階的に情報を開示する進め方が現実的です。

SCS評価制度では、対策の考え方が複数の観点に整理されています。
受注側としては、いきなりすべての証跡をそろえるのではなく、まず「どの観点について、どこまで説明できるか」を確認することが重要です。

ここでは、制度の整理に沿って、最低限確認しておきたいポイントをまとめます。
社内確認や取引先への初期回答を準備する際のたたき台として使える内容です。

A. ガバナンスの整備

まず確認したいのは、セキュリティ対策を誰が担当し、どのような方針で進めているかです。
担当部署や責任者が明確になっているか、セキュリティ方針や関連規程の名称を説明できるかを整理します。

ここで求められるのは、いきなり詳細な規程全文を見せることではなく、社内で一定の管理体制があることを説明できる状態です。

B. 取引先管理

次に確認したいのは、自社が関わる取引先や再委託先について、どの程度把握できているかです。
機密情報を共有している相手先が誰か、重要な委託先に対してどのような確認をしているか、といった考え方を整理します。

特に再委託がある場合は、すべてを同じ深さで管理しようとするのではなく、重要性に応じて対象を絞り、把握方法を決めておくことが現実的です。

C. リスクの特定

自社のどの情報資産やシステムが対象になり、どこにリスクがあるのかを把握しているかも重要です。
対象業務に関わるサーバ、ネットワーク、クラウド環境などが整理されているか、外部サービスを利用している場合には責任分界を理解しているかを確認します。

この整理ができていないと、発注側に対しても「どこまでが今回の回答対象なのか」を明確に示せません。

D. 攻撃等の防御

防御の観点では、ID管理やアクセス権限の設定、ネットワーク境界の保護、ソフトウェアや機器のアップデート運用などが基本になります。
ここで大切なのは、高度な対策を幅広く並べることではなく、対象範囲に対して最低限の統制が効いていることを説明できるかどうかです。

たとえば、誰がどの権限を持つのか、不要な権限を放置していないか、更新作業をどのようなルールで実施しているか、といった点が説明できる状態を目指します。

E. 攻撃等の検知

検知の観点では、ログや監視の有無だけでなく、何を、どの頻度で、どのように確認しているかが重要です。
「ログは取っています」で止まるのではなく、確認対象、確認頻度、記録の残し方まで整理しておく必要があります。

発注側が見たいのは、単にデータが存在することではなく、監視や確認の運用が回っているかどうかです。
そのため、まずは監視対象と確認方法の定義を説明できる状態を整えることが実務上有効です。

F. インシデントへの対応

万が一問題が発生した場合に、誰が、どのように対応し、どこへ報告するのかを整理しておくことも欠かせません。
高度なインシデントレスポンス体制がなくても、最低限の初動手順や報告ルールが決まっていれば、説明の土台になります。

特に、取引先へどのタイミングで連絡するのか、社内でどの部門にエスカレーションするのかは、あらかじめ整理しておきたいポイントです。

G. インシデントからの復旧

最後に、障害やインシデント発生後に、どのように業務を復旧させるかも確認します。
バックアップの有無だけでなく、どの程度の時間で、どの状態まで戻すことを想定しているかを整理しておくことが重要です。

ここでも、最初から完璧な文書化を目指す必要はありません。
まずは復旧の考え方と基本的な手順を説明できる状態をつくることが現実的です。

最初に整えるべきなのは「全部の証跡」ではなく「説明の骨組み」

取引先対応でつまずきやすいのは、最初から完璧な証跡一式をそろえようとしてしまうことです。
しかし実務では、最初に求められるのは、制度の観点に沿って自社の状況を説明できることです。

そのため、まずは各観点について、

  • 何を実施しているか
  • どこまで説明できるか
  • 不足しているなら何が不足しているか

を整理し、説明の骨組みをつくることが重要です。
証跡や詳細資料は、その後に発注側の確認方法と合意しながら段階的に出していくほうが、安全かつ現実的です。

制度としても、直ちに★取得が困難な場合に、発注側が要求事項・評価基準をチェックリストとして活用する考え方が示されています。受注側から提案できる代替案を紹介します。

代替案1:要求事項・評価基準を「取引先向けチェックリスト」として運用

  • 受注側が自己点検し、結果と根拠の所在(規程名・ログ種別など)だけを渡す
  • いきなり深い証跡を全面開示しない(開示範囲を段階化)

代替案2:範囲を絞って段階導入(重要領域から)

制度の対象範囲や適用範囲の考え方(公開サーバは必ず含める/外部境界機器等)を踏まえ、重要度の高い領域から先に整備する提案は理解を得られやすいです。

代替案3:不足観点だけ上乗せして合意(“全部★4”を避ける)

★3に不足がある場合に★4を求めたり、対策の上乗せも想定されています。
受注側から「不足している観点(例:取引先管理/検知/復旧)だけ上乗せ」を提案すると、合意が早いです。

再委託先への適用は、元の発注者ではなく、直接の取引先(委託先)による判断で実施する整理です。
ただし、直接の取引先が★4対象の場合、★4要求事項に「重要な取引先の対策状況把握」があるため、再委託先にも一定の影響が及ぶ可能性があります。

制度の例では、対象条件(重要機密の提供・共有/事業継続上重要/内部システムへのアクセス可能)に該当する子会社・取引先を対象に、年1回以上で把握する方法(★取得状況の確認、訪問点検、チェックシート回答)などが示されています。

受注側は「再委託先を全部管理する」ではなく、条件で絞って年1回以上の把握を提案すると現実的です。

取引先から★対応を求められたとき、話がこじれる原因の多くは「対策そのもの」ではなく、前提のすれ違いと説明材料(証跡)の不足です。制度の目的も、発注側・受注側双方が、適切な対策水準を決め、対策状況を説明・確認しやすくすることにあります。

ここでは、受注側が実務でつまずきやすい点を4つに絞って整理します。

★を“格付け”や“完全保証”だと思い込む

発注側が★を「取引の合否」や「安全の保証」と捉えると、会話がゼロイチになりがちです。しかし制度構築方針では、本制度は格付け目的ではなく、★取得は完全なセキュリティを保証するものではないことが明記されています。
この前提が共有できると、議論は「★を取れるか」から「取引リスクをどう下げ、どう確認するか」に戻ります。

  • まず伝えるのは「★は共通言語」
  • 次に「★取得=完全保証ではない」
  • そのうえで「確認したい範囲はどこか」を聞く

対象範囲がズレる

受注側は社内規程や教育の話をしているのに、発注側は委託業務に関わるシステム範囲を確認したい。
こうしたズレはよく起きます。制度では対象をIT基盤(クラウド含む)とし、適用範囲の考え方も整理されています。
だからこそ、回答の冒頭で「今回の回答範囲」を短く言語化するだけで、やり取りのコストが下がります。

  • 回答対象の取引・業務・システムを一言で
  • 含む範囲(公開サーバ/境界/認証など)を一言で
  • 範囲外(OT・提供製品など)があれば一言で触れる

「ログは取っている」で止まる

ログは“取っている”だけだと、発注側が確認したい「運用が回っているか」の説明になりません。★4では、文書確認に加え実地審査で証跡確認を含めた評価が想定され、運用の説明が重要になりやすい構造です。
細かな技術論に踏み込む前に、監視・確認の運用を「定義」と「記録」で示す方が、受注側の負担も抑えられます。

  • 何を見ているか(対象)
  • どの頻度で見ているか(頻度)
  • 実施記録が残るか(記録)

★4で求められやすいのは、対策の有無だけではなく、「どのように証明するか」です。証跡の考え方や、説明の進め方をさらに詳しく整理した記事として、「セキュリティ対策評価制度『★4』獲得の鍵は『証明』にあり」もあわせてご覧ください。

期限の現実を言えず、曖昧に引き延ばす

取得が難しいときに曖昧な返答を続けると、発注側の不信が増え、結局は要求が厳しくなることがあります。制度構築方針でも、直ちに★取得が困難な場合に要求事項・評価基準をチェックリストとして活用する考え方が示されています。
つまり「取れない=詰み」ではなく、代替案で合意形成する余地があります。受注側は、返答を“段階”に分解して提示するのが現実的です。

  • 直近:チェックリスト回答(現状の可視化)
  • 中期:提出パック(骨組みの提示)
  • 最終:ロードマップ(期限と範囲の合意)

まとめ:受注側がまず整えるべきなのは、★ではなく説明材料

制度が狙うのは、取引に必要なセキュリティ水準を決め、状況を説明・確認しやすくすることです。
受注側は「★4は無理です」で止めず、対象範囲/不足観点/代替案(チェックリスト運用)/ロードマップで会話を成立させるのが最短ルートです。

Writer 雫田 貴一
WEEDS SYSTEMSのWebマーケティング担当者。 マーケティングだけでなく、システムの導入からセールスのサポートに至るまで幅広く手掛けています。 情報セキュリティに不安を感じるユーザーの悩みや課題を解決すべく、日々情報発信に努めています。