自動車業界で情報システムを担当していると、ここ数年で取引先から届くセキュリティ関連の依頼が明らかに増えているのではないでしょうか。設問に答えて返送する形式のものもあれば、対策の実施状況を説明する場を設けてほしいという依頼もあります。そこへ2026年、SCS評価制度という新しい枠組みが加わりました。
現場で最初に出てくる問いは、制度の中身そのものではありません。「すでにガイドラインの対応をやっているのに、また別のものをやるのか」「両方やるとして、どちらを先に進めればいいのか」という順序の問題です。
この記事では、SCS評価制度の側でわかっていることを2026年9月15日時点の公表情報で押さえたうえで、自動車業界のTier構造のなかで要求がどう流れていくのかを整理します。自工会・部工会のサイバーセキュリティガイドラインとの関係については、公表資料での確認が必要な論点を明示する形にとどめています。断定できる範囲と、確認してから判断すべき範囲を分けて読めるようにしました。
SCS評価制度とは、サプライチェーンを構成する企業のセキュリティ対策状況を評価し、その結果を★の段階で示す制度です。
正式名称は「サプライチェーン強化に向けたセキュリティ対策評価制度」といいます。経済産業省と内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、運営はIPA(独立行政法人情報処理推進機構)が担います。制度の全体像はSCS評価制度とは何かで通しで解説しているため、ここでは自動車業界の判断に直結する部分だけを抜き出します。
対象は、発注元・受注先・再委託先など、サプライチェーンを構成するすべての企業です。企業規模も立場も問いません。完成車メーカーだけの話でも、Tier2以下だけの話でもない、という設計になっています。
評価範囲は「インターネットに接続する自社IT基盤」と定められています。工場やプラントの制御システム、いわゆるOTシステムは対象外です。自社が製造して供給している製品そのものも含まれません。
この線引きは自動車業界では特に重要になります。生産設備のセキュリティと、自社が供給する部品や車載ソフトウェアのセキュリティと、社内のIT基盤のセキュリティは、担当部門も対策の中身も別物です。SCS評価制度が見るのは3つ目の範囲だけになります。工場のネットワークをどう守るかという議論とは、ひとまず切り離して考えることになります。

参考:IPA サプライチェーン強化に向けたセキュリティ対策評価制度
制度が定めるのは★3と★4の2区分です。★1・★2はIPAが以前から運用しているSECURITY ACTION(自己宣言)であり、本制度の段階ではありません。★5は要求事項も評価基準も評価スキームも開始時期も検討中です。
| 段階 | 位置づけ | 要求事項 | 評価基準 | 評価スキーム | 更新サイクル |
|---|---|---|---|---|---|
| ★3 | SCS評価制度 本体 | 26 | 81 | 専門家確認付き自己評価 | 1年(毎年更新) |
| ★4 | SCS評価制度 本体 | 43(★3を包括) | 153 | 第三者評価+実地審査+技術検証 | 3年(期間中も毎年自己評価を提出) |
要求事項が対策の大項目、評価基準がその達成を確認する判断基準にあたります。数え方が違うため、★3について「26」と「81」のどちらの数字も出てきます。社内資料では、どちらを数えているのかを併記しておくと説明が早く済みます。
★3を取得していなくても★4を取得できる、という点もIPAが明記しています。取引先から★4を提示された場合に、まず★3を取ってから順番に積み上げる必要はありません。
参考:IPA ★3・★4 要求事項及び評価基準(Excel・2026年4月21日版/2026年9月15日取得)
2026年9月15日時点で申請はできません。確度ごとに分けると次のようになります。
| 時期 | 内容 | 確度 |
|---|---|---|
| 2026年3月 | 制度構築方針 公表 | 確定 |
| 2026年度下期 | 評価機関・評価用ガイド等 公表 | 予定 |
| 2026年12月末頃から | 研修事業者の公表 | 予定 |
| 2026年度末頃 | 運用開始。取得企業の公表もここから | 想定 |
| 2027年度以降 | ★の要求が本格化 | 当社想定 |
確定しているのは制度構築方針が公表されたことだけで、それ以降は予定または想定にとどまります。2027年度以降に★の要求が本格化するという見通しはジョーシスの想定であり、制度側が公表している事項ではありません。
費用と取得にかかる期間も、2026年9月15日時点では公表されていません。IPAは今後公開するとしています。予算化の判断は、評価機関の指定が公表される2026年度下期以降になる見込みです。
SCS評価制度の設計でいちばん大きな変更は、項目の中身ではなく評価の単位です。自動車業界の読者にとって、ここが最も理解しやすい部分になります。
これまでのセキュリティ対策は、各社が自社の判断で水準を決めて進めるものでした。取引先の実態は見えず、確認したいときは個別に質問票を送るしかない。回答の粒度も様式も相手ごとに違うため、比較もできませんでした。
SCS評価制度が想定しているのは、2社間の取引契約のなかで発注者が委託先に適切な★の段階を提示し、委託先が★を取得して実施状況を示す形です。そして、この仕組みが取引の連鎖の全階層に波及していきます。
つまり、ある企業にとっての「求められる側」の対応と、「求める側」の対応が同時に発生します。自動車業界のTier1・Tier2は、上からも下からもこの動きに関わることになります。
取得した企業は登録組織台帳で公開されます。制度そのものは任意で、取引に規制措置を設けるものではないと、経済産業省と内閣官房国家サイバー統括室が2026年4月27日に注意喚起しています。特定のセキュリティ対策製品の導入が必須とされているわけでもありません。
ただし、公開されるという事実は、取らないという選択も外から見えることを意味します。調達の場面で選択肢の一つとして参照される状態になる、という理解が実態に近いのではないでしょうか。
この構造変化がどの程度の範囲に及ぶのか。ジョーシスの独自試算では、対象となる企業間取引の規模はおよそ555兆円になります。
2025年度の名目GDPが約670兆円。そのうち企業間で取引される中間投入の割合が82.8%です。掛け合わせると約555兆円という規模になります。中間投入とは、生産の過程で消費される原材料や部品、サービスなどの費用を指します。
なお、この555兆円という数字はジョーシスが公開統計をもとに独自に試算したものであり、公的機関が公表している値ではありません。
自動車産業は、この中間投入の規模がとりわけ大きい産業です。一台の完成車に数万点の部品が使われ、その部品がさらに素材や加工の取引に分かれていく。取引の連鎖に沿って要求が伝わる制度設計と、産業の構造そのものが重なります。
自動車業界のサプライチェーンは、完成車メーカーを頂点にTier1・Tier2・Tier3と階層が明確に分かれています。この構造と、制度が想定する波及の形は重なります。
制度が想定するのは、業界全体に一斉に何かが適用される形ではありません。あくまで2社間の取引契約が単位になります。

| 階層 | 求められる側としての動き | 求める側としての動き |
|---|---|---|
| 完成車メーカー | 出資元や海外の取引先から水準を問われる場面がある | Tier1に段階を提示し、実施状況を確認する |
| Tier1 | 完成車メーカーから提示された段階を取得し、実施状況を示す | Tier2に段階を提示し、実施状況を確認する |
| Tier2 | Tier1から提示された段階を取得し、実施状況を示す | Tier3や外部委託先に段階を提示する |
| Tier3以下・外部委託先 | Tier2から提示された段階を取得し、実施状況を示す | 再委託先がいれば同様に提示する |
表の右側に注目すると、完成車メーカーとTier3を除くすべての階層が、求められる側と求める側の両方に立つことがわかります。SCS評価制度の要求事項にも「取引先管理」という大分類があり、★3で4件、★4で7件の評価基準が置かれています。自社の対策だけでなく、取引先の状況をどう確認しているかも評価の対象になる、という設計です。
Tier2以下で繰り返し聞くのが、「うちのような規模の会社にまで話は来ないだろう」という反応です。制度の構造を見ると、その前提は成り立ちません。
要求は各階層で受け渡されるため、階層が深いほど到達が遅れるだけで、到達しないわけではありません。むしろ、攻撃者の視点で見れば守りの薄い階層のほうが入口として使いやすい。制度が全階層を対象にしたのは、この非対称性があるからです。
サプライチェーンを狙った攻撃の手口と国内の被害事例は、サプライチェーン攻撃の対策と国内事例で業界を横断して整理しています。
要求が流れてきたとき、実務としてまず発生するのは説明責任です。取引先から段階を提示され、自社の現在地を示すことになります。
ここで、対応がセキュリティ部門だけの仕事にならない点が難しいところです。ID・端末・SaaS・ネットワークの実態を出すのは情報システム部門、規程の整備は総務や品質保証、周知や教育は人事と現場、という具合に担当が分かれます。取引先から一通の依頼が来た時点で、社内の複数部門を横断する調整が始まります。
取引先から★3を提示された場面の具体的な進め方は、取引先にSCS★3を求められたときの実務で手順に沿って扱っています。
Tier構造で要求が流れるという話は抽象的に聞こえるかもしれません。ところが、この構造がそのまま被害の経路になった事例が、すでに国内で起きています。
国内の完成車生産が丸一日止まった日があります。2022年3月1日、トヨタ自動車の国内14工場28ラインが終日停止し、生産への影響は約1.3万台に及びました。国内月産の5%程度に相当すると報じられています。
この停止を招いたのは、トヨタ自動車のIT基盤で起きた出来事ではありません。侵入口になったのは、一次仕入先である小島プレス工業の、さらに子会社が保有していたリモート接続機器の脆弱性でした。
被害の経路を先ほどの階層表に当てはめると、構造がはっきりします。
| 階層 | この事例での立場 | 何が起きたか |
|---|---|---|
| 完成車メーカー | トヨタ自動車 | 自社は直接攻撃されていないが、国内14工場28ラインが終日停止 |
| Tier1 | 小島プレス工業 | 自社も直接の侵入口ではない |
| Tier1の子会社 | リモート接続機器を保有 | 機器の脆弱性が侵入口になった |
侵入が起きたのは階層で見て3段目です。そこから2段目、1段目へと影響が及びました。攻撃された企業と、生産が止まった企業が違う。取引の連鎖をたどって影響だけが上流へ伝わっていく、この非対称性が事例の核心になります。
3点あります。
1つ目は、自社のIT基盤を固めきっても、対策の手が届かない範囲が残るという点です。完成車メーカーから見て二段先にあたる会社の一点の弱さが、国内の生産計画を動かしました。
2つ目は、侵入口が「子会社が持つリモート接続機器」だった点です。管理の対象として台帳に載っていたのか、載っていたとして最終更新はいつだったのか。ここが実務の核心になります。SCS評価制度の評価基準でも、資産台帳の維持は常時の対応として求められています。
3つ目は、階層が深いほど見えにくいという点です。完成車メーカーからTier1は見えても、Tier1の子会社まではふつう見えません。制度が取引の連鎖の全階層に波及する設計になっているのは、この見えなさを、各階層が自分の直下を確認する形で埋めようとしているからだと読めます。
ここからが、自動車業界の読者にとっての本題になります。
自動車業界には、一般社団法人日本自動車工業会(自工会)と一般社団法人日本自動車部品工業会(部工会)が公表しているサイバーセキュリティガイドラインという既存の枠組みがあります。取引先からの依頼を受けて自己点検を実施した経験を持つ企業も少なくないはずです。
本記事では、ガイドラインの版数、レベル区分の名称、項目数、改訂の時期といった具体的な内容を書いていません。SCS評価制度の側はIPAが公表している情報で確認できますが、ガイドライン側の内容は同じ確度で確認できていないためです。
社内説明や取引先への回答で数字を使う場面では、必ず自工会・部工会が公表している最新の資料を直接確認してください。解説記事の孫引きで版数や項目数を扱うと、改訂のたびにずれが生じます。
確認が必要な点を残したうえで、枠組みとしての違いを整理すると次のようになります。SCS評価制度側の欄は2026年9月15日時点の公表情報にもとづく確定事項です。ガイドライン側の欄は、一次資料で確認したうえで社内資料に落とす前提の項目になります。
| 論点 | SCS評価制度(確定事項) | 自工会・部工会ガイドライン |
|---|---|---|
| 策定・運営 | 経済産業省・内閣官房国家サイバー統括室が制度構築方針を公表。運営はIPA | 業界団体が策定。詳細は要確認 |
| 対象範囲 | 業種を問わず、サプライチェーンを構成するすべての企業 | 自動車業界が対象。適用の範囲は要確認 |
| 評価の対象 | インターネットに接続する自社IT基盤。OTシステムと提供製品そのものは対象外 | 要確認 |
| 評価の主体 | ★3は専門家確認付き自己評価、★4は第三者評価 | 要確認 |
| 結果の公開 | 取得企業は登録組織台帳で公開される | 要確認 |
| 有効期間 | ★3は1年、★4は3年(期間中も毎年自己評価を提出) | 要確認 |
SCS評価制度と既存の業界ガイドラインの関係について、公式な整理が公表されているかどうかも確認が必要な論点です。参考までに、ISMS(ISO/IEC 27001)との関係については、2026年9月15日時点で公式な整理が公表されておらず、免除規定も確認できないというのがIPAの公開情報から読み取れる状況になります。
業界ガイドラインについても同様の整理がなされているのか、それとも別の扱いになるのかは、評価用ガイド等が公表される2026年度下期以降に明らかになる可能性があります。現時点で「ガイドライン対応済みだからSCSも問題ない」と社内に説明するのは、根拠が確認できていない状態での断定になります。
「両方やるのか、どちらを先にやるのか」という問いに、業界一律の答えはありません。ただし、判断の材料は整理できます。
最優先の材料は、取引先から実際に何を求められているかです。
締切のある依頼が来ているなら、それが先になります。制度の理屈で順序を決める前に、契約上の求めがあるほうを処理する。当たり前のようですが、社内で「どちらが本質的か」という議論に時間を使ってしまう例をよく見ます。
SCS評価制度については、2026年9月15日時点で申請自体ができません。取引先から★の提示を受けたとしても、いま取得はできない状態です。したがって、現時点で締切があるのはガイドライン側の依頼である可能性が高い、という時間軸の整理になります。
2つ目は、それぞれの対応で作る成果物がどの程度重なるかです。
一般論として、セキュリティ対策の枠組みは、規程を整えること、技術的な対策を実装すること、運用の記録を残すことの3要素で構成されます。この3要素の水準が近ければ、片方の対応で作った文書や記録がもう片方でも使える場面が出てきます。
ただし「使える場面がある」と「そのまま通る」は別です。ここは後述します。
3つ目は、それぞれの有効期間と更新の頻度です。
SCS評価制度の★3は有効期間1年で、毎年の更新が必要になります。★4は3年更新ですが、期間中も毎年の自己評価を評価機関へ提出します。つまり、どちらの段階でも年次の作業が発生します。
評価基準には頻度そのものが書かれています。
| 頻度 | 求められること |
|---|---|
| 常時 | 退職IDの速やかな削除/資産台帳の維持 |
| 14日以内 | 重大な脆弱性(CVSS7.0以上)へのパッチ適用 |
| 月1回 | 認証ログの監視/不審な認証試行の点検 |
| 年1回 | 取引先の★確認/全アクセス権の棚卸/評価の更新提出 |
既存のガイドライン対応にも更新や再点検のサイクルがあるはずです。2つのサイクルがどの月に重なるかを先に並べておくと、年間の負荷が読めるようになります。
判断材料2で保留した点に戻ります。
既存の枠組みへの対応で作成した規程、手順書、実施記録は、SCS評価制度の評価基準に対する証跡として使える場面があります。これは業界ガイドラインに限らず、ISMSやプライバシーマークについても同じです。
一方で、そのままでは通りません。SCS評価制度では、評価基準の条文ごとに、どの文書のどこが対応しているかを示す必要があります。「すでに規程は整備済みです」という回答では、81ある評価基準のどれが埋まっていてどれが抜けているかを示せません。
たとえばパスワードに関する要求は、★3の評価基準では6つに分解されています。初期パスワードを変更すること、推測されやすい単語の設定を禁止すること、多要素認証を使うか一定回数の失敗でロックすること、機器やサービス間で使い回さないこと。既存の規程に「パスワードポリシーを定める」と書いてあるだけでは、この6つのうちどれに対応しているかを説明できません。
さらに、方針・規程・手順・記録という4階層がつながっていることも求められます。手順書だけがあって上位の方針と結びついていない状態は、指摘の対象になります。
既存のISMS文書を出発点にする進め方は、ISMS対応で押さえる統制と実装ステップで扱っています。考え方は業界ガイドラインからの読み替えでも同じです。
以上をまとめると、順序の判断は次の形に落ちます。

| 状況 | 現実的な順序 |
|---|---|
| 取引先から締切のある依頼が来ている | その依頼を先に処理する。SCSは並行して準備 |
| 依頼はまだ来ていないが、Tier1・Tier2に位置している | 既存の対応を維持しつつ、SCSの評価基準の側から現状を突き合わせておく |
| 既存の対応を一度も実施していない | まず社内のIT基盤の棚卸しから入る。どちらの枠組みでも前提になる |
3つの状況に共通するのは、どれも「棚卸しと文書の突き合わせ」が最初の作業になるという点です。順序の議論に結論が出なくても、この作業は着手できます。
順序の議論と並行して、SCS側で何が求められるのかを具体的に把握しておくと判断が速くなります。ここでジョーシスが独自に集計したデータを2つ示します。
この3つの分け方は、制度が定めたものではありません。IPAが公開している評価基準を、証跡をどう集めるかという観点でジョーシスが独自に整理したものです。
★3の81ある評価基準を、証跡をどう集めるかという軸で分けると次のようになります。
| 満たし方 | 件数 | 割合 | 何をするのか |
|---|---|---|---|
| システムで取る | 40 | 49% | API連携で台帳や設定状況を自動取得する |
| 文書で示す | 25 | 31% | 規程・手順書を作り、評価基準の粒度に合わせる |
| 人手で回す | 16 | 20% | 周知・点検・承認を人が実施し、記録に残す |
なお、この3分類は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものです。制度が定めた区分ではありません。
重要なのは、どれか一つでは終わらない点です。規程を整えれば技術的な対策が免除されるわけでも、ツールを入れれば運用の記録が不要になるわけでもありません。
既存のガイドライン対応が質問票への回答を中心に進んできた企業では、文書で示す25件の部分は比較的埋まりやすい一方、システムで取る40件が手つかずというケースが出てきます。逆に、製造現場のネットワーク分離などの技術対策を先行して進めてきた企業では、記録の様式が定まっていないことが多い。自社がどちらの傾向にあるかを見ておくと、残りの作業量が読めます。
この内容別の分け方も、制度が定めたものではありません。IPAが公開している評価基準を、何について求めているかという観点でジョーシスが独自に分類したものです。
同じ81件を、制度の大分類ではなく「何について求めているか」という内容の軸で分け直すと、別の姿が見えてきます。
| 内容別の分類 | 件数 | 割合 |
|---|---|---|
| アイデンティティ・認証(ID・アクセス権・パスワード) | 27 | 33% |
| インシデント対応・復旧 | 14 | 17% |
| 資産・脆弱性・マルウェア対策 | 12 | 15% |
| ネットワーク境界・リモート | 9 | 11% |
| ガバナンス・体制・教育 | 8 | 10% |
| 情報・データの管理 | 4 | 5% |
| 取引先・外部サービス管理 | 4 | 5% |
| ログ・監視 | 3 | 4% |
最も多いのはアイデンティティと認証で27件、全体の33%になります。★4の153件で見ても、ID・認証は33件で最多という結果になりました。
この内容別の分類は、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。制度側が定めた大分類とは数え直す対象が違うため、2つを同じ表に並べて読むことはできません。
自動車業界の文脈で考えると、この配分は示唆的です。トヨタの事例で侵入口になったのはリモート接続機器でした。アスクルの事例では、委託先に渡していた管理者IDに多要素認証が適用されていなかったことが起点になっています。誰が何にアクセスできるかの管理が、制度の重心に置かれている理由がここにあります。
SCS評価制度への対応をどこから機械化できるか整理したい場合は、IT資産とアカウントの一元管理の考え方をまとめた資料が参考になります。
以下で使う分類は、前述のとおりジョーシスが独自に整理したものです。制度が定めた区分ではありません。
順序の結論が出ていなくても着手できる作業を、優先順位の高い順に3つ挙げます。

まず、ID・端末・SaaS・ネットワークの台帳が、申請ベースではなく利用実態から出せる状態にあるかを確認します。システムで取る40件は、この棚卸しがすべての前提になります。
かつては年に一度の資産棚卸しで台帳を更新し、その間の変更を差分で追いかける運用が一般的でした。現在は各システムのAPI経由で利用実態を自動取得し、台帳を常に最新に保てるようになっています。評価基準が資産台帳の維持を常時の対応として求めている以上、この形に寄せるのが現実的です。
自動車業界の場合、拠点が国内外に分散し、工場と本社でIT環境の管理主体が異なることも珍しくありません。棚卸しの範囲をどこまで取るかを先に決めておかないと、作業が終わらなくなります。評価範囲がインターネットに接続する自社IT基盤である以上、生産設備側は範囲外として切り分けられます。
台帳の項目設計と運用ルールはIT資産台帳の作り方と運用ルールで具体的に扱っています。制度側が何を「把握できている状態」とみなすかは、SCS評価制度が求めるIT環境の把握で整理しました。
2つ目は、既存の対応で作った文書を、評価基準の条文単位で突き合わせることです。
進め方には2通りあります。既存文書を読み込んでから足りないところを探す方法と、評価基準の側から「この条文に対応する記述はどこにあるか」を当てる方法です。後者のほうが早く終わります。前者は網羅性を確認できないため、あとからやり直しになりがちです。
この作業は、SCS評価制度と既存ガイドラインのどちらを先に進めることになっても無駄になりません。自社の文書がどの要求に対応しているかという対応表は、相手が変わっても使えます。
3つ目は、記録の様式を先に作ってしまうことです。
人手で回す16件は、毎年やり直しになります。★3の有効期間が1年である以上、去年やったから今年は省略、が通用しません。型がないと積み上がらない領域です。
誰が、いつ、誰に対して、何を実施したか。この4つが埋まる様式を決めておけば、実施のたびにそのまま証跡になります。実施はしていたのに形式がばらばらで証跡として使えない、という状態が最も惜しい結果になります。
周知の対象には役員も、派遣社員も、受入出向者も含まれることが条文に明記されています。製造業では構内協力会社や出向者の出入りが多く、この範囲の広さが実務の負荷に直結します。
ここまでは求められる側の話が中心でした。Tier1以上の企業は、同時に求める側にも立ちます。
制度が想定しているのは、発注者が委託先に「適切な★の段階」を提示する形です。全取引先に一律の段階を求める設計ではありません。
どの取引にどの段階を求めるかは、委託する業務の内容とリスクに応じて判断することになります。設計データを預ける委託先と、汎用部品を納入する取引先で、同じ水準を求めるのが妥当かどうか。この整理を先にしておかないと、提示した段階の根拠を説明できなくなります。
評価基準には、年1回の頻度で取引先の★を確認することが含まれています。
一度提示して終わりではありません。取引先の★には有効期間があり、★3は1年で更新されます。更新されているかどうかを確認する運用が、発注側に発生します。取引先の数が多い企業ほど、この確認をどう回すかが課題になります。
見落とされやすいのが、発注側自身も評価の対象になるという点です。
取引先管理は★3で4件、★4で7件の評価基準が置かれた大分類の一つにすぎません。残りの大部分は、自社のIT基盤に関する要求です。委託先に段階を提示する立場であっても、自社のID管理や資産台帳の状態は同じように問われます。
取引先への依頼を進めながら、自社の棚卸しが手つかずという状態にならないよう、社内側の準備と並行して進めるのが実務的です。
自動車業界で耳にすることの多い受け止め方を整理します。
| よくある誤解 | 正しい理解 |
|---|---|
| 業界ガイドラインに対応していればSCSは不要 | 2つの枠組みの関係について、確認できている公式な整理はない。既存の文書や記録が証跡として使える場面はあるが、評価基準の条文ごとに対応を示す必要がある |
| 工場の生産設備も評価対象になる | 評価範囲はインターネットに接続する自社IT基盤。OTシステムと提供製品そのものは対象外 |
| 自社が供給する部品や車載ソフトの安全性が評価される | 提供製品そのものは評価範囲に含まれない |
| 取得しないと取引から外される | 任意の制度であり、取引に規制措置を設けるものではないと経済産業省と内閣官房国家サイバー統括室が2026年4月27日に注意喚起している。ただし取得状況は公開される |
| ★1から順番に取っていく | ★1・★2は別制度のSECURITY ACTION。★3を取得していなくても★4を取得できるとIPAが明記している |
| ★3は社内だけで完結する自己評価 | ★3も専門家の確認と署名が前提であり、社内で完結しない |
| 完成車メーカーが決めれば業界一斉に適用される | 制度の単位は2社間の取引契約。階層ごとに受け渡される形で波及する |
済んでいるとは言えません。2つの枠組みの関係について確認できている公式な整理はなく、免除の扱いも確認できていません。既存の対応で作った規程や記録が証跡として使える場面はありますが、SCS評価制度では評価基準の条文ごとに、どの文書のどこが対応しているかを示す必要があります。
評価されません。SCS評価制度の評価範囲は「インターネットに接続する自社IT基盤」と定められており、工場やプラントの制御システム、いわゆるOTシステムは対象外です。自社が提供している製品そのものも含まれません。生産設備のセキュリティとは切り分けて準備を進められます。
対象になります。発注元・受注先・再委託先など、企業規模も立場も問わずサプライチェーンを構成するすべての企業が対象です。要求は階層ごとに受け渡されるため、階層が深いほど到達が遅れるだけで、到達しないわけではありません。
制度が想定しているのは、2社間の取引契約のなかで発注者が委託先に適切な★の段階を提示し、実施状況を確認する形です。評価基準には年1回の頻度で取引先の★を確認することも含まれています。一律の段階を求める設計ではないため、委託する業務の内容とリスクに応じた整理が必要になります。
2026年9月15日時点で申請はできません。評価機関・評価用ガイド等の公表が2026年度下期、運用開始は2026年度末頃の想定です。ただし年1回の実施記録は、記録を取り始めた時点からしか積み上がりません。棚卸しと記録の様式づくりは、申請可否と関係なく進められます。
自動車業界でSCS評価制度をどう扱うかについて、2026年9月15日時点で押さえておきたい点は3つです。
1つ目は、SCS評価制度の単位が2社間の取引契約であり、要求が階層ごとに受け渡されるという点です。この形は自動車業界のTier構造とそのまま重なります。完成車メーカーからTier1へ、Tier1からTier2へと要求が連鎖し、Tier3を除く各階層が求められる側と求める側の両方に立ちます。
2つ目は、トヨタの2022年の事例が、まさにこの構造で起きたという点です。侵入口は一次仕入先の子会社が持つリモート接続機器でした。攻撃された企業と生産が止まった企業が違う。自社完結の対策では届かない範囲があることを示した事例になります。
3つ目は、既存の業界ガイドラインとの関係について、確認できている公式な整理がないという点です。既存の対応で作った文書や記録が証跡として使える場面はありますが、SCS評価制度では評価基準の条文ごとに対応を示す必要があります。ここはISMSと同じ構造です。
順序の結論が出ていなくても、IT基盤の棚卸し、既存文書と評価基準の突き合わせ、記録の様式づくりの3つは着手できます。どの枠組みが先になっても無駄にならない作業です。
ジョーシスでは、ITデバイスとSaaS、アカウント情報を一元管理し、評価のときに出せる証跡として蓄積する仕組みを提供しています。自社の現状をどこまで機械的に把握できるか確認したい場合は、資料をご覧ください。
関連記事:ITコンプライアンスとは|関連法規と50項目チェックリスト
関連記事:退職者アカウントの削除手順
Sign-up for a 14-day free trial and transform your IT operations.
