プライバシー設定
このサイトでは、第三者のウェブサイト追跡技術を使用して、当社のサービスを提供および継続的に改善し、ユーザーの興味に応じた広告を表示します。同意します。また、将来的に有効となる限り、いつでも同意を取り消したり、変更したりすることができます。
拒否
[すべて承認]
すべての記事

SCS評価制度とは|★3を求められた側が、最初に確かめておくこと

No items found.
共有
コピー

取引先から「SCS評価制度の★3を取得してほしい」と伝えられた。あるいは経営層から「新しい制度ができたようだから対応を検討してほしい」と言われた。そうした場面で最初に困るのは、制度の名前ではなく、自社が何をどこまで用意すればいいのかが見えないことではないでしょうか。

SCS評価制度とは、サプライチェーンを構成する企業のセキュリティ対策状況を評価し、その結果を★の段階で示す制度です。2026年に入って解説記事は一気に増えました。ところが、肝心の項目数が媒体によって違う。ある記事は「★3は25項目」と書き、別の記事は「評価基準83件」と書いています。どれを信じて社内に説明すればいいのか、判断がつかない状態が続いています。

この記事では、IPAが公開している要求事項・評価基準のデータを直接集計した実測値を示します。そのうえで、確定していること、予定にとどまること、あくまで想定であることを分けて整理しました。さらに、81ある評価基準を「証跡をどう集めるか」という軸で3つに分けています。この分け方は他の解説記事にはありません。読み終えたときに、自社が次に何から手をつけるかが決まっている状態を目指します。

SCS評価制度とは|制度の正式名称と対象

SCS評価制度とは、サプライチェーンを構成する企業のセキュリティ対策状況を評価し、その結果を★の段階で示す制度です。

「SCS」はSupply Chain Security の頭文字です。略称が先に広まったため、正式名称を知らないまま話が進んでいるケースも珍しくありません。

正式名称と、誰が作って誰が運営するのか

正式名称は「サプライチェーン強化に向けたセキュリティ対策評価制度」といいます。経済産業省と内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、運営はIPA(独立行政法人情報処理推進機構)が担います。

省庁が方針を決め、IPAが運用を担う。要求事項や評価基準、よくある質問といった実務に直結する情報はIPAのサイトに集約されています。

参考:IPA サプライチェーン強化に向けたセキュリティ対策評価制度

対象になるのはどの企業か

対象は、発注元・受注先・再委託先など、サプライチェーンを構成するすべての企業です。企業規模も立場も問いません。

「大企業向けの制度だろう」「うちは下請けだから関係ない」という反応をよく聞きますが、制度の想定はその逆に近い。攻撃者はいちばん守りの薄い取引先から入ってきます。だからこそ、取引の連鎖に入るすべての階層が対象になりました。

発注側は委託先に段階を提示する立場であると同時に、自社のIT環境の把握を問われる立場でもあります。受注側だけの話ではありません。

評価されるのはどこまでか

評価範囲は「インターネットに接続する自社IT基盤」と定められています。工場やプラントの制御システム、いわゆるOTシステムは対象外です。自社が提供している製品そのものも含まれません。

SCS評価制度の対象範囲

「工場の生産設備まで評価対象になるのか」という質問が繰り返し出ますが、現時点の制度構築方針では対象外です。準備は、社内のIT基盤のうちインターネットに接続している範囲を切り出すところから入るのが早道になります。

なぜ今この制度ができたのか

背景を知っておくと、要求事項の意図も読み取りやすくなります。この制度は抽象的な議論から生まれたものではなく、国内で実際に起きた2つの被害が直接のきっかけになりました。いずれも、攻撃を受けたのが自社ではなく取引先や委託先だったという共通点があります。個社で完結する対策では守りきれない。その認識が制度設計の出発点になっています。

トヨタ自動車の事例(2022年)

2022年3月1日、トヨタ自動車の国内14工場28ラインが終日停止しました。生産への影響は約1.3万台で、国内月産の5%程度に相当すると報じられています。

注目すべきなのは、攻撃を受けたのがトヨタ本体ではなかった点です。侵入口は一次仕入先である小島プレス工業の、さらに子会社が持っていたリモート接続機器の脆弱性でした。自社をどれだけ固めても、取引先の先にある一社の弱点が全体を止めてしまう。サプライチェーン・セキュリティという言葉がもっとも分かりやすく現れた事例です。

攻撃の手口や国内の被害事例をより詳しく知りたい場合は、サプライチェーン攻撃の対策と国内事例で整理しています。

アスクルの事例(2025年から2026年)

もう1件はアスクルの事例です。時系列で追うと、制度が何を問題視しているかがはっきりします。

時期何が起きたか
2025年6月5日委託先の管理者IDの認証情報が漏えい。多要素認証が適用されていなかった
2025年6月から10月約4か月にわたり潜伏。認証情報を収集して権限を昇格させた
2025年10月19日物流・社内システムを一斉に暗号化。バックアップも削除され、受注と出荷が停止
2026年1月21日全面復旧。出荷制限は約3か月に及んだ

被害額は2026年5月期の最終損益で221億円の赤字、個人情報の漏えいは約74万件と公表されています。影響は取引先のECサイトにも連鎖しました。

入口は委託先に渡していた管理者IDひとつ。そこに多要素認証がなく、4か月間気づけなかった。この2点がここまでの被害につながりました。

評価の単位が「個社」から「取引」へ変わった

これまでのセキュリティ対策は、各社が自社の判断で進めるものでした。取引先の実態は見えず、弱い一社が全体の入口になる構造が残っていた。

SCS評価制度が変えたのは評価の単位です。2社間の取引契約のなかで発注者が委託先に適切な★の段階を提示し、委託先が★を取得して実施状況を示す。この仕組みが取引の連鎖の全階層に波及していきます。

制度が想定するリスクは、供給が途絶える事業継続、データの漏えいや改ざん、踏み台にされる不正アクセスの3つです。トヨタの事例が1つ目、アスクルの事例が2つ目と3つ目に対応します。

どれくらいの経済規模が対象になるのか

この構造変化が、どの程度の範囲に及ぶのか。ジョーシスの独自試算では、対象となる企業間取引の規模はおよそ555兆円になります。

2025年度の名目GDPが約670兆円。そのうち企業間で取引される中間投入の割合が82.8%です。掛け合わせると約555兆円になります。中間投入とは、生産の過程で消費される原材料や部品、サービスなどの費用を指します。

一部の大企業だけの問題ではなく、日本の企業間取引のほぼ全体がこの制度変更の対象になる。そういう規模感です。

なお、この555兆円という数字はジョーシスが公開統計をもとに独自に試算したものであり、公的機関が公表している値ではありません。

★の区分は★3と★4|★1・★2は別制度

SCS評価制度が定めるのは★3と★4の2区分で、★1・★2はIPAが運用するSECURITY ACTION(自己宣言)です。

解説記事のあいだで最も食い違いが大きい箇所です。「★1から★5の5段階で評価される」と書く記事が複数ありますが、実際の構造は違います。

★1・★2はSECURITY ACTIONという別の枠組み

★1・★2はSCS評価制度が新しく作ったものではなく、IPAが以前から運用しているSECURITY ACTION、つまり中小企業が自ら情報セキュリティ対策に取り組むことを宣言する制度です。

★1は情報セキュリティ5か条への取り組み、★2は自社診断25項目の実施と対策方針の公開が求められます。いずれも第三者が評価するものではなく、自己宣言にとどまります。制度構築方針でも★1・★2は SECURITY ACTION を参照する形になっており、「本制度」という言葉は★3・★4を指しています。準備段階の別制度、と理解しておくのが正確です。

参考:IPA SCS評価制度 関連制度・施策

★3の中身

★3は、要求事項が26、評価基準が81です。評価の方法は専門家確認付きの自己評価で、有効期間は1年、毎年の更新が必要になります。

「自己評価」という言葉から社内だけで完結すると読まれがちですが、そうではありません。SCSセキュリティ専門家の確認と署名が前提になっています。自社で評価をまとめたあと、外部の専門家に見てもらう工程が必ず入ります。

26の要求事項と81の評価基準が具体的に何を求めているかは、★3の要求事項26と評価基準81の全一覧で項目単位に整理しています。

★4の中身

★4は、要求事項が43、評価基準が153です。★3の26要求事項を包括する構造になっています。評価の方法は第三者評価で、実地審査と技術検証が加わる点が★3との大きな違いです。

更新サイクルは3年ですが、ここに落とし穴があります。3年間なにもしなくてよいわけではなく、期間中も毎年の自己評価を評価機関へ提出しなければなりません。

★1から★5までを一覧にすると次のとおりです。

段階位置づけ要求事項評価基準評価スキーム更新サイクル
★1SECURITY ACTION(前段)情報セキュリティ5か条該当なし自己宣言該当なし
★2SECURITY ACTION(前段)自社診断25項目と方針公開該当なし自己宣言該当なし
★3SCS評価制度 本体2681専門家確認付き自己評価1年(毎年更新)
★4SCS評価制度 本体43(★3を包括)153第三者評価+実地審査+技術検証3年(期間中も毎年自己評価を提出)
★5検討中今後検討今後検討第三者評価未定
★の区分を正しく整理

要求事項が対策の大項目、評価基準がその達成を確認する判断基準にあたります。別の数え方なので「★3は26項目」と「★3は81項目」はどちらも誤りではなく、何を数えているかが違うだけです。記事によって数字が割れて見えるのは、この2つが混ざっていることも一因です。

★5は検討中

★5は要求事項も評価基準も評価スキームも、開始時期すら決まっていません。★3・★4と同列に扱う解説を見かけますが、現時点では検討段階です。

★3を取らないと★4は取れないのか

結論から書くと、そうした関係にはなりません。★4は★3の要求事項を包括していますが、★3を事前に取得していなければ★4を取得できないという順序は必須ではない、とIPAが明記しています。

取引先から★4を提示された場合に、まず★3を取ってから積み上げる必要はない、ということです。どちらを目指すかの判断材料は、★3と★4の違いを要件・評価方法・有効期間で比較した記事にまとめています。

参考:IPA SCS評価制度 詳細情報

★3の81評価基準は何を求めているのか

ここからは★3を前提に話を進めます。81ある評価基準が何を求めているのかは、数える軸を変えると見え方が変わります。ここでは制度が定めた大分類で見た場合と、内容で分け直した場合の2つの角度から確認します。前者は制度の公式な区分、後者はジョーシスが独自に分け直したものです。両者は数え直す対象が違うため、混同しないよう順に見ていきます。

制度が定めた大分類7つの内訳

SCS評価制度の要求事項・評価基準は、大分類7と中分類16という階層のもとに並んでいます。大分類が対策領域の大きなくくり、中分類がその下のテーマにあたります。IPAが公開している要求事項・評価基準のExcelを集計すると、★3の81評価基準は7つの大分類に次のように配分されています。

大分類★3★4
攻撃等の防御4882
リスクの特定1129
ガバナンスの整備819
インシデントへの対応66
取引先管理47
攻撃等の検知38
インシデントからの復旧12
合計81153

制度が定めた大分類で見ると、81件のうち48件が「攻撃等の防御」に集中しています。全体の59%です。★4でも153件中82件が同じ分類に入ります。

「SCS対応は規程や文書を整える話だ」という受け止め方をよく聞きますが、データを見るかぎり実際の山は技術的な実装側にあります。文書を整えるだけでは半分も埋まりません。

すでにNIST CSFで社内の対策状況を整理している場合は、NIST CSFの機能別に見た評価基準の偏りから読み替えると早く把握できます。

参考:IPA SCS評価制度 要求事項・評価基準

参考:IPA ★3・★4 要求事項及び評価基準(Excel・2026年4月21日版/2026年9月15日取得)

内容で分け直すと何が多いのか(ジョーシス独自の整理)

この内容別の分け方も、制度が定めたものではありません。IPAが公開している評価基準を、何について求めているかという観点でジョーシスが独自に分類したものです。

同じ81件を、制度の大分類ではなく「何について求めているか」という内容の軸で分け直すと、別の姿が見えてきます。

内容別の分類件数割合
アイデンティティ・認証(ID・アクセス権・パスワード)2733%
インシデント対応・復旧1417%
資産・脆弱性・マルウェア対策1215%
ネットワーク境界・リモート911%
ガバナンス・体制・教育810%
情報・データの管理45%
取引先・外部サービス管理45%
ログ・監視34%

最も多いのはアイデンティティと認証で27件、全体の33%になります。2位のインシデント対応・復旧14件のおよそ2倍です。★4の153件で見ても、ID・認証は33件で最多という結果になりました。

アスクルの事例が委託先の管理者ID一つから始まったことを思い出すと、納得のいく配分ではないでしょうか。制度の重心は、誰が何にアクセスできるかの管理にあります。

この内容別の分類は、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。前の表の大分類とは数え直す対象が違うため、2つの表を同じ軸で並べて読むことはできません。社内資料でも書き分けておくと混乱を避けられます。

81基準をどう満たすか|システム・文書・人手の3分類(ジョーシス独自の整理)

何を求めているのかが見えたら、次は満たし方です。同じ81の評価基準を、証跡をどう集めるかという軸で見ると、3つに分かれます。

この3つの分け方は、制度が定めたものではありません。IPAが公開している評価基準を、証跡をどう集めるかという観点でジョーシスが独自に整理したものです。

満たし方件数割合何をするのか
システムで取る4049%API連携で台帳や設定状況を自動取得する
文書で示す2531%規程・手順書を作り、評価基準の粒度に合わせる
人手で回す1620%周知・点検・承認を人が実施し、記録に残す

重要なのは、どれか一つでは終わらない点です。システムを入れれば文書が不要になるわけでも、規程を整えれば運用が免除されるわけでもありません。

なお、この3分類は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものです。制度が定めた区分ではありません。

システムで取る40件

40件はどの領域に散らばっているのか。内訳を見ると、どこから自動化に手をつけるべきかが具体的に見えてきます。台帳と設定状況をAPIで取り出せるかどうかが分かれ目になる領域が、件数の多い順に並びます。

分野件数内訳
アイデンティティ15管理者ID5/ユーザID4/認証強度4/ロック2
端末・脆弱性10資産把握3/マルウェア3/構成2/パッチ2
ネットワーク7境界防護5/構成把握1/通信監視1
SaaS・取引先3取引先の関係2/外部サービス管理1
教育・訓練3インシデント訓練の実施記録
バックアップ2取得記録/リストアテスト

条件そのものはシンプルで、ID・端末・ネットワーク・SaaSの台帳と設定状況を、APIで取り出せる状態にあるかどうかです。逆に言えば、台帳がExcelで手管理されていて最終更新が半年前、という状態だと40件のほとんどが証跡として成立しません。

台帳をどう設計し、どう更新し続けるかについては、IT資産台帳の作り方と運用ルールで具体的な項目設計まで整理しています。制度側が何を「把握できている状態」とみなすかは、SCS評価制度が求めるIT環境の把握で扱っています。

文書で示す25件

文書の側は、作る書類の種類そのものは11種類ほどにとどまります。25という件数を見て身構えられがちですが、1つの規程が複数の評価基準を受け持つためです。どの領域に何件が集まっているかを先に見ておくと、既存の文書のどこを厚くすべきかが判断しやすくなります。

文書の領域件数内容
パスワードのルール6設定4・管理2。文字数や変更条件まで規定
インシデント対応5対応手順4・役割責任1
推進体制・方針3対応方針1・推進部門2
情報の取扱い3機密区分2・取扱い1
ID・アクセス権2管理者IDの手続1・アクセス権1
その他6守秘義務・資産把握・ネットワーク把握・SaaS管理・BCP・バックアップ

難しいのは種類の数ではなく、粒度と整合性のほうです。

たとえばパスワードのルールは、評価基準では6つに分解されています。初期パスワードを変更すること、推測されやすい単語の設定を禁止すること、多要素認証を使うか一定回数の失敗でロックすること、機器やサービス間で使い回さないこと。「パスワードポリシーは策定済みです」と答えるだけでは、この6つのどれが記述されていてどれが抜けているかを示せません。

ここで多いのが、ISMSやプライバシーマークを取得しているから大丈夫だろう、という見立てです。実際には、そのままでは通りません。評価基準の条文ごとに、どの文書のどこが対応しているかを示す必要があります。さらに、方針・規程・手順・記録という4階層がつながっていることも求められます。手順書だけがあって上位の方針と結びついていない状態は指摘の対象になります。

既存のISMS文書を出発点にする進め方については、ISMS対応で押さえる統制と実装ステップが参考になります。何がそのまま流用できて何が足りないのかは、SCS評価制度とISMS・Pマークの違いで制度ごとに突き合わせています。

そしてもう一つ。★3であってもSCSセキュリティ専門家の確認と署名が前提になるため、文書の整備は社内だけで完結しません。

人手で回す16件

3つ目は、システムにも文書にも寄せきれない領域です。人が実施し、実施したことを記録に残して初めて証跡になります。件数は16件と3分類のなかで最も少ないものの、更新のたびに必ず作り直しが発生するため、運用の負荷はむしろこの領域に集まります。

文書の領域件数内容
パスワードのルール6設定4・管理2。文字数や変更条件まで規定
インシデント対応5対応手順4・役割責任1
推進体制・方針3対応方針1・推進部門2
情報の取扱い3機密区分2・取扱い1
ID・アクセス権2管理者IDの手続1・アクセス権1
その他6守秘義務・資産把握・ネットワーク把握・SaaS管理・BCP・バックアップ

作業そのものは難しくありません。効いてくるのは条件のほうです。

まず対象範囲が広い。周知の対象には役員も、派遣社員も、受入出向者も含まれることが条文に明記されています。人の出入りがあるたびに説明の機会が必要になり、異動のタイミングで漏れが出やすい領域です。

次に、毎年やり直しになります。★3の有効期間は1年なので、周知も点検も更新のたびに新しい記録が要ります。去年やったから今年は省略、が通用しません。

そして最も見落とされやすいのが、評価されるのは実施したことではなく、実施を示す記録だという点です。日付・対象者・内容がそろって初めて証跡になります。どの基準にどんな記録が要るのかは、★3の自己評価で求められる証跡で領域別に例示しています。

権限の限定については、棚卸しの実務まで含めてアクセス権レビューの進め方と自動化で扱っています。

SCS評価制度への対応をどこから機械化できるか整理したい場合は、IT資産とアカウントの一元管理の考え方をまとめた資料が参考になります。

5分でわかるジョーシスの資料をダウンロードする

いつから始まるのか|2026年9月時点で決まっていること

満たし方の見当がついたら、次に確認したいのが時期です。日程については「2026年開始」「2027年開始」と表記が割れており、社内説明でつまずきやすいところです。確度ごとに分けて整理します。

確定・予定・想定を分けた日程

公表されている情報を、確定した事実・予定として示されているもの・当社の想定の3段階に分けて並べます。この3段階の分け方も、制度が定めた区分ではなくジョーシスが整理したものです。確度の違いを落として一本の日程表にしてしまうと、社内で「決まったこと」として独り歩きしやすくなります。日付を引用するときは、どの段階の情報かをセットで伝えるのが安全です。

時期内容確度
2026年3月制度構築方針 公表確定
2026年度下期評価機関・評価用ガイド等 公表予定
2026年12月末頃から研修事業者の公表予定
2026年度末頃運用開始。取得企業の公表もここから想定
2027年度以降★の要求が本格化当社想定
SCS評価制度のロードマップ

制度構築方針が公表されたことだけが確定事項で、それ以降はいずれも予定または想定にとどまります。社内に説明するときは「2026年度末頃に始まる想定」と幅を持たせた表現にしておくほうが、後で修正が入りにくくなります。

なお、2027年度以降に★の要求が本格化するという見通しはジョーシスの想定であり、制度側が公表している事項ではありません。

今はまだ申請できない

2026年9月時点で、申請はできません。評価機関の指定は2026年度下期、研修事業者の公表は2026年12月末頃からとされており、依頼先が決まるのは運用開始の直前になります。

ただし、申請できないことと準備できないことは別です。規程の整備と証跡の蓄積は、申請の直前にまとめて作れる性質の作業ではありません。とくに人手で回す16件は年1回の実施記録が求められるため、記録を取り始めた時点からしか積み上がりません。

参考:IPA SCS評価制度 よくある質問

取得したことは外から見える

取得した企業は登録組織台帳で公開されます。制度そのものは取引を規制しませんが、取得状況が公開されることで発注側は★を持つ委託先を確認できるようになります。取らないという選択をした場合、その状態も外から見えます。

取得したら終わりではない|回り続ける運用サイクル

運用開始の時期が見えたところで、もう一つ押さえておきたいのが取得したあとです。★3の有効期間は1年で、評価基準には常時・14日以内・月1回・年1回という頻度そのものが書かれています。つまり制度が見ているのは、対策を導入したかどうかではなく、決められた間隔で回し続けているかどうかです。頻度が明記されている主なものを整理すると、次のようになります。

頻度求められること
常時退職IDの速やかな削除/資産台帳の維持
14日以内重大な脆弱性(CVSS7.0以上)へのパッチ適用
月1回認証ログの監視/不審な認証試行の点検
年1回取引先の★確認/全アクセス権の棚卸/評価の更新提出

制度対応が「取得して終わり」にならない理由がはっきりします。★4でも3年更新のあいだ毎年の自己評価を提出します。

なかでも運用の負荷が高いのは、常時対応が求められる退職IDの削除です。退職の連絡が人事から届いてから手作業でアカウントを止めていく運用だと、どうしても数日から数週間のずれが生まれます。そのずれ自体が証跡に残ってしまう点が、従来の内部統制対応とは違うところです。手順の設計については退職者アカウントの削除手順で具体的に扱っています。

問いは「どう取得するか」ではなく「どう回し続けるか」に移ります。取得をゴールに置いた計画は、2年目の更新でつまずきやすくなります。

参考:IPA SCS評価制度 制度規程・委員会

2026年9月時点で着手できる3つのこと

決められた間隔で回し続ける前提が見えると、今から手をつけるべきことも絞れます。申請はまだできません。それでも準備として動けることは明確にあります。優先順位の高い順に3つ挙げます。すでに取引先から★3の提示を受けている場合は、取引先にSCS★3を求められたときの実務のほうが手順に沿って進められます。

自社のIT基盤を棚卸しする

まず、ID・端末・SaaS・ネットワークの台帳が、申請ベースではなく利用実態から出せる状態にあるかを確認します。システムで取る40件は、この棚卸しがすべての前提になります。なおこの3分類は、前述のとおりジョーシスが整理したもので、制度が定めた区分ではありません。

かつては年に一度の資産棚卸しで台帳を更新し、その間の変更を差分で追いかける運用が一般的でした。現在は各システムのAPI経由で利用実態を自動取得し、台帳を常に最新に保てます。制度が求める「常時の維持」に応えるには、この形に寄せるのが現実的です。

既存の規程を評価基準の側から突き合わせる

次に、ISMSやプライバシーマークで作ってきた文書を、評価基準の条文単位で突き合わせます。

既存文書を読み込んでから足りないところを探すのではなく、評価基準の側から「この条文に対応する記述はどこにあるか」を当てるほうが早く終わります。前者は網羅性を確認できず、やり直しになりがちです。

周知と点検の記録の取り方を先に決める

3つ目は、記録の様式を先に作ってしまうことです。人手で回す16件は毎年やり直しになるため、型がないと積み上がりません。誰が、いつ、誰に対して、何を実施したか。この4つが埋まる様式を決めておけば、実施のたびにそのまま証跡になります。実施はしていたのに形式がばらばらで証跡として使えない、という状態が最も惜しい結果です。

これら3つに共通するのは、点在しているツールや台帳を横断して可視化し、評価のときに出せる証跡へ変えていく作業だという点です。ファイアウォールやEDRといった個別の対策はすでに導入されている前提で、それらの状態をどう束ねて示すかが問われています。

よくある誤解

制度の理解でつまずきやすい点を整理します。社内説明の前に確認しておきたい内容です。とくに「義務なのかどうか」は社内で最初に問われる論点なので、SCS評価制度は義務かどうかの整理も併せて確認しておくと説明がぶれません。

よくある誤解正しい理解
取得しないと取引ができなくなる任意の制度であり、取引に規制措置を設けるものではないと経済産業省と内閣官房国家サイバー統括室が2026年4月27日に注意喚起している。ただし取得状況は公開され、発注側は選べるようになる
特定の製品を入れないと★は取れない特定のセキュリティ対策製品の導入が必須とされているものではない(同注意喚起)
ISMSがあればSCSは免除されるISMSとの関係について公式な整理は2026年9月15日時点で公表されておらず、免除規定も確認できない。ただしISMSで作った規程や記録が証跡として使える場面はある
★1から順番に取っていく制度だ★1・★2は別制度のSECURITY ACTION。★3から★4への順序も必須ではない
工場の制御システムも評価される評価範囲はインターネットに接続する自社IT基盤。OTシステムと提供製品そのものは対象外
★3は社内だけで完結する自己評価だ★3も専門家の確認と署名が前提であり、社内で完結しない

よくある質問

SCS評価制度は義務ですか

任意の制度です。経済産業省と内閣官房国家サイバー統括室は2026年4月27日に、取引へ規制措置を設けるものではないと注意喚起しています。ただし委託元が委託先に段階を提示し実施状況を確認することは制度の想定に含まれており、取引先から現在地の説明を求められる場面は想定しておく必要があります。

費用はいくらかかりますか

評価そのものにかかる費用と、取得にかかる期間は、2026年9月15日時点で公表されていません。IPAは今後公開するとしています。金額を前提にした社内試算は、確定情報が出てから行うほうが確実です。評価機関の指定が2026年度下期とされているため、費用感が見えるのもその前後になる見込みです。現時点でわかっている範囲はSCS評価制度への対応費用でわかっていることに整理しています。

中小企業も対象になりますか

対象になります。発注元・受注先・再委託先など、企業規模も立場も問わずサプライチェーンを構成するすべての企業が対象です。いきなり★3を目指すのが難しい場合は、IPAのSECURITY ACTION(★1・★2)が準備段階として使えます。自己宣言の枠組みのため、費用をかけずに着手できます。進め方は中小企業のSCS★3対応の進め方で詳しく扱っています。

★3と★4のどちらを目指すべきですか

取引先から提示された段階によります。★3は要求事項26・評価基準81で有効期間1年、★4は43・153で3年更新です。★4には実地審査と技術検証が加わるため難易度が上がります。★3を取得していなくても★4を取得できるとIPAが明記しているため、提示された段階を直接目指す選択も可能です。

まとめ

SCS評価制度について、2026年9月15日時点で押さえておきたい点は3つです。

1つ目は、制度が定めるのは★3と★4だということ。★3は要求事項26・評価基準81で、有効期間は1年です。★1・★2は別制度のSECURITY ACTIONであり、「★1から★5の5段階」という理解は正確ではありません。

2つ目は、81の評価基準が証跡の取り方でシステム40件・文書25件・人手16件に分かれ、どれか一つでは終わらないということ。文書だけを整えても、システムだけを入れても、片側が残ります。

なお、ここで触れた証跡の取り方の3分類は、制度が定めた区分ではありません。ジョーシスが独自に整理したものです。

3つ目は、運用開始が2026年度末頃の想定で、申請はまだできないということ。それでも台帳の棚卸し、既存規程と評価基準の突き合わせ、記録の型づくりは今日から始められます。とくに年1回の実施記録は、始めた時点からしか積み上がりません。

制度に合わせて動くのではなく、回し続けられる運用として設計する。そこが出発点になります。

ジョーシスでは、ITデバイスとSaaS、アカウント情報を一元管理し、評価のときに出せる証跡として蓄積する仕組みを提供しています。自社の現状をどこまで機械的に把握できるか確認したい場合は、資料をご覧ください。

5分でわかるジョーシスの資料をダウンロードする

関連記事:IT内部統制とは|基礎知識とJ-SOX対応の実務

関連記事:情報セキュリティポリシーの作り方|策定ステップと運用設計

‍

Questions? Answers.

No items found.
No items found.