取引先から「SCS評価制度の★3を取得してほしい」と伝えられたとき、社内で最初に出てくる反応はだいたい同じではないでしょうか。「うちはISMSを取っているから、その分は免除されるはずだ」。
そう考えるのは自然なことだと思います。ISMS(ISO/IEC 27001)もプライバシーマークも、情報セキュリティの水準を外部に示すための制度です。似た目的の制度が増えたのなら、どこかで相殺される仕組みがあってもよさそうに見えます。
ただ、2026年9月15日時点で、ISMSとSCS評価制度の関係について公式な整理は公表されていません。免除規定も確認できない状態が続いています。そのうえ、仮に今後なんらかの整理が出たとしても、ISMSの文書をそのまま提出して通る形にはなりにくい。理由は、2つの制度で基準の当て方そのものが違うからです。
この記事では、SCS評価制度・ISMS・プライバシーマーク・SECURITY ACTIONの4つを、目的・対象・評価方法・有効期間・第三者性・費用の有無という6つの軸で並べます。そのうえで、ISMSを取得している企業が何を流用できて何が足りないのかを、評価基準の側から整理しました。社内で「ISMSがあるから大丈夫」という説明が出たときに、どこが大丈夫でどこが大丈夫ではないのかを、根拠を持って示せる状態を目指します。
制度そのものの全体像はSCS評価制度とは|★3の81基準と満たし方3分類で解説しています。★の区分や運用開始の時期をまだ押さえていない場合は、そちらを先に読んでおくと本記事の比較が理解しやすくなります。
4つの制度は、守ろうとしているものも、評価のされ方も違います。まず全体を一枚の表にします。
| 比較軸 | SCS評価制度 ★3 | SCS評価制度 ★4 | ISMS(ISO/IEC 27001) | プライバシーマーク | SECURITY ACTION(★1・★2) |
|---|---|---|---|---|---|
| 目的 | サプライチェーンを構成する企業のセキュリティ対策状況を、取引の相手に示す | 同左。より高い水準を第三者が確認する | 情報セキュリティマネジメントシステムが自社で構築・運用されていることを示す | 個人情報の取扱いが適切であることを示す | 中小企業が情報セキュリティ対策に取り組むことを自ら宣言する |
| 対象 | 発注元・受注先・再委託先など、規模も立場も問わずサプライチェーンを構成するすべての企業 | 同左 | 適用範囲を自社で定める(全社・特定事業所・特定サービスなど) | 個人情報を取り扱う事業者 | 主に中小企業 |
| 評価の範囲 | インターネットに接続する自社IT基盤。OTシステムと提供製品そのものは対象外 | 同左 | 自社が定めた適用範囲 | 個人情報を取り扱う業務の範囲 | 自社の取り組み全般(宣言ベース) |
| 評価方法 | 専門家確認付きの自己評価 | 第三者評価+実地審査+技術検証 | 審査機関による認証審査 | 審査機関による審査 | 自己宣言 |
| 第三者性 | 一部あり(自己評価だが、SCSセキュリティ専門家の確認と署名が前提) | あり(評価機関が実地で確認) | あり | あり | なし |
| 有効期間 | 1年(毎年更新) | 3年更新。期間中も毎年の自己評価を評価機関へ提出 | 認証の有効期間があり、期間中の維持審査が前提 | 有効期間があり、更新審査が前提 | 該当なし |
| 費用の有無 | 2026年9月15日時点で未公表。IPAは今後公開するとしている | 同左 | 審査機関へ支払う費用が発生する | 審査機関へ支払う費用が発生する | 費用をかけずに着手できる |
表を縦に眺めると、4つが並列の選択肢ではないことが見えてきます。SECURITY ACTIONだけが第三者性を持たず、ISMSとプライバシーマークは審査機関が見る制度、SCS評価制度の★3は自己評価でありながら専門家の署名が前提という中間的な形をとっています。
★3は専門家確認付きの自己評価であり、審査機関が認証を与える仕組みではありません。ISMSやプライバシーマークと同じ感覚で「SCSの認証を取る」と言い換えてしまうと、社内で工数の見積もりを誤ります。
自己評価である以上、評価の内容をまとめる作業は自社で行います。外部に丸ごと委託して結果だけ受け取る形にはなりません。一方で、まとめた内容はSCSセキュリティ専門家の確認と署名を経る必要があるため、社内だけで完結もしません。この2つを同時に満たす体制を先に想定しておくと、後から慌てずに済みます。
なお★4は第三者評価で、実地審査と技術検証が加わります。ここはISMSやプライバシーマークの審査に近い運び方になります。
制度名で覚えようとすると混乱しやすいので、何を守る制度なのかで分けてみます。
プライバシーマークが守るのは個人情報です。顧客名簿や従業員情報の取扱いが適切かを見ます。ISMSが守るのは、自社が重要と定めた情報資産です。適用範囲も自社で決めます。
これに対してSCS評価制度が守ろうとしているのは、取引の相手です。自社の情報だけを守れていればよいわけではなく、自社が踏み台にされて取引先へ被害が伝わることを防ぐという視点が入っています。評価範囲がインターネットに接続する自社IT基盤と定められているのも、外から入られる経路を問題にしているためです。
この視点の違いが、後で見るベースライン型とリスクベース型の差につながっていきます。

4制度の中でもっとも混同されるのがSCS評価制度とISMSです。そして、この2つの違いはどちらが厳しいかではなく、基準の当て方にあります。
ISMSは、自社でリスクアセスメントを実施し、その結果に基づいて必要な管理策を選び、選ばなかったものについては理由を説明するという構造をとります。適用範囲も自社で定めます。
つまり、ある管理策を採用していないこと自体は、ISMSでは必ずしも不適合になりません。リスクアセスメントの結果として不要と判断し、その判断の過程が説明できていれば成立します。自社の事業特性に合わせて設計できる柔軟さが、ISMSの前提にあります。
リスクアセスメントの進め方そのものはセキュリティリスクアセスメントの手法とISMS対応の手順で扱っています。管理策をどう選び、どう実装まで落とすかはISO27001のIT管理策と実装ステップが参考になります。
SCS評価制度は逆の形をとります。★3であれば要求事項26・評価基準81が先に示されていて、そこに適合しているかどうかを見ます。自社でリスクを評価して「この基準は当社には不要」と外す設計にはなっていません。
こうした形をベースライン型と呼びます。全員が同じ最低線を満たしていることを、取引の相手が確認できる状態にするための作りです。取引の連鎖に入る企業の水準をそろえるという制度の目的から考えると、この形になるのは自然な帰結ではないでしょうか。
26の要求事項と81の評価基準が具体的に何を求めているかは、★3の要求事項26と評価基準81の全一覧で項目単位に整理しています。
参考:IPA SCS評価制度 ★3・★4 要求事項及び評価基準(Excel・2026年4月21日版/2026年9月15日取得)
| 観点 | ISMS(リスクベース型) | SCS評価制度(ベースライン型) |
|---|---|---|
| 基準の決まり方 | 自社のリスクアセスメント結果から必要な管理策を選ぶ | 制度側が要求事項と評価基準を先に提示する |
| 適用範囲 | 自社で定める | インターネットに接続する自社IT基盤 |
| 未実施の扱い | リスク評価の結果として説明できれば成立しうる | 原則として適合が求められる |
| 判断の主体 | 自社(審査機関が妥当性を確認) | 制度(自社は適合状況を示す) |
| 強み | 事業特性に合わせて設計できる | 企業間で水準を比較できる |
この2つの型の違いが、誤解の出どころです。
ISMSの運用に慣れていると、「必要性を説明できれば個別の対策は必須ではない」という感覚が身につきます。その感覚のままSCS評価制度を見ると、「うちのリスク評価では優先度が低いので対象外」と整理できるように思えてしまう。ところが制度の側は、示した評価基準への適合を確認する作りです。そこに自社判断で外す余地は想定されていません。
もう一つの出どころは、どちらも「セキュリティの制度」という一語でくくられてしまうことです。名前のレベルでは似て見えますが、ISMSが問うのは仕組みが回っているかどうか、SCS評価制度が問うのは示された線を越えているかどうか。問いの形が違います。
社内で説明するときは「ISMSは自社で線を引く制度、SCSは引かれた線に合わせる制度」と伝えると、誤解が生まれにくくなります。

ここまでを踏まえると、「ISMSは無駄になるのか」という疑問が出てきます。そうではありません。流用できる部分は確実にあります。ただし、そのまま出せるわけではない、というのが実際のところです。
この3つの分け方は、制度が定めたものではありません。IPAが公開している評価基準を、証跡をどう集めるかという観点でジョーシスが独自に整理したものです。
ジョーシスでは、IPAが公開している★3の評価基準81件を、証跡をどう集めるかという軸で3つに分けました。
| 満たし方 | 件数 | 割合 | 何をするのか |
|---|---|---|---|
| システムで取る | 40 | 49% | 台帳や設定状況をAPI連携で自動取得する |
| 文書で示す | 25 | 31% | 規程・手順書を作り、評価基準の粒度に合わせる |
| 人手で回す | 16 | 20% | 周知・点検・承認を人が実施し、記録に残す |
ISMSの文書資産がまっすぐ効いてくるのは、このうち「文書で示す」25件です。全体の31%にあたります。
逆に言えば、残る69%は文書だけでは埋まりません。システムで取る40件は台帳と設定状況の実態が問われますし、人手で回す16件は実施したことを示す記録が必要です。ISMSの規程一式を提出すれば手続きが済むという見立てだと、準備の総量を3分の1以下に見誤ることになります。

なお、この3分類は、IPAが公開している要求事項・評価基準の各基準に、想定される証跡の取得手段をジョーシスが割り当てて集計したものです。制度が定めた区分ではありません。
ここから下りていく内訳も、前述のとおり制度が定めた区分ではありません。ジョーシスが独自に整理したものです。
流用可能性を判断するには、25件の内訳まで下りる必要があります。
| 文書の領域 | 件数 | 内容 |
|---|---|---|
| パスワードのルール | 6 | 設定4・管理2。文字数や変更条件まで規定 |
| インシデント対応 | 5 | 対応手順4・役割責任1 |
| 推進体制・方針 | 3 | 対応方針1・推進部門2 |
| 情報の取扱い | 3 | 機密区分2・取扱い1 |
| ID・アクセス権 | 2 | 管理者IDの手続1・アクセス権1 |
| その他 | 6 | 守秘義務・資産把握・ネットワーク把握・SaaS管理・BCP・バックアップ |
ISMSを運用していれば、情報セキュリティ方針、情報資産の管理規程、インシデント対応手順、アクセス制御の規程あたりはすでに整備されているはずです。この表の領域と重なる部分は多く、新規に一から書き起こす文書はそれほど多くありません。作る文書自体は11種類ほどにとどまります。
この内訳も、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。
問題は、文書の有無ではなく粒度です。
ISMSの規程に「パスワードポリシーを定め、遵守させる」と一行で書いてあったとします。文書としては存在します。ところがSCS評価制度の側では、パスワードに関する基準が6件に分かれていて、初期値の変更、推測されやすい文字列の禁止、多要素認証またはロックアウト、使い回しの禁止といった論点がそれぞれ独立して問われます。規程の一行からは、6件のどれが書かれていてどれが抜けているかを示せません。
必要なのは、評価基準の条文ごとに「どの文書の、どの章の、どの記述が対応するか」を示す対応表です。既存文書を先に読み込んで足りないところを探す進め方より、評価基準の側から引き当てる進め方のほうが早く終わります。前者は網羅性を確認できないため、やり直しになりがちです。
SaaSやIT環境の統制まで含めて既存のISMS文書を出発点にする場合は、ISMS対応で押さえる統制と実装ステップが突き合わせの下地になります。
粒度に加えてもう一点、方針・規程・手順・記録という4階層がつながっていることも問われます。

手順書だけが存在して上位の方針と結びついていない状態、あるいは方針は立派だが実際の手順書が古いまま更新されていない状態は、指摘の対象になります。ISMSでも同じ構造は求められますが、適用範囲を自社で定められる分、対象外にしていた領域の文書が薄いまま残っているケースは珍しくありません。SCS評価制度ではインターネットに接続する自社IT基盤が一律の範囲になるため、そこで差が出ます。
方針から手順、記録までを一本の線でつなぐ設計は情報セキュリティポリシーの作り方と運用設計で扱っています。
| 既存のISMS資産 | SCS評価制度での扱い |
|---|---|
| 情報セキュリティ方針・各種規程 | 証跡として使える場面がある。ただし評価基準の条文単位で対応箇所を示す必要がある |
| リスクアセスメントの結果 | 基準を外す根拠には使えない。優先順位づけの材料としては有効 |
| 適用宣言書 | そのままでは対応表にならない。評価基準との突き合わせを別途作る |
| 内部監査・マネジメントレビューの記録 | 年1回の点検を示す記録として活用できる場面がある |
| 是正処置の記録 | インシデント対応の実施記録として活用できる場面がある |
| 適用範囲外にしていた領域 | インターネットに接続する自社IT基盤であれば新たに対象になる |
流用できるものは、いずれも「そのまま提出できる」ではなく「出発点として使える」という位置づけになります。作業の総量は減りますが、突き合わせの工程は残ります。
自社のIT環境をどこまで機械的に把握できているかを確認したい場合は、ITデバイスとSaaS、アカウント情報の一元管理の考え方をまとめた資料が参考になります。
以下で使う分類は、前述のとおりジョーシスが独自に整理したものです。制度が定めた区分ではありません。
社内で最も知りたいのはここだと思います。結論を先に書きます。
ISMSとSCS評価制度の関係について、公式な整理は2026年9月15日時点で公表されていません。免除規定も確認できません。
「ISMSを取得していればSCSの一部項目が免除される」「Pマークがあれば評価基準の何割かが自動的に満たされる」といった説明を見かけることがありますが、その根拠となる公表資料は現時点で存在しません。社内の稟議や取引先への回答に使うと、後で訂正が必要になる可能性があります。
制度そのものがまだ運用開始前という事情があります。2026年9月時点で申請はできず、評価機関・評価用ガイド等の公表は2026年度下期、研修事業者の公表は2026年12月末頃からとされています。運用開始は2026年度末頃の想定です。
他制度との読み替えは、評価の実務が動き出さないと具体化しにくい部分でもあります。評価用ガイド等が公表される段階で、なんらかの整理が示される可能性はあります。ただ、それは現時点では予定でも確定でもなく、単に未公表という状態です。
免除規定がないことと、準備が二重になることは別の話です。
ISMSで整備した文書があるなら、文書で示す25件の下地はすでにあります。優先度を上げるべきなのは、システムで取る40件と人手で回す16件のほうです。とくに人手で回す16件は、年1回の実施記録が求められるものが含まれるため、記録を取り始めた時点からしか積み上がりません。免除の可否が判明するのを待って着手すると、その分だけ記録の蓄積が遅れます。
現時点で動かせるのは、記録の様式を先に決めてしまうことです。誰が、いつ、誰に対して、何を実施したか。この4つが埋まる型を作っておけば、実施のたびにそのまま証跡になります。
SECURITY ACTIONとは、中小企業が情報セキュリティ対策に取り組むことを自ら宣言する、IPAの制度です。
ここは表記の混乱がとくに多い箇所なので、先に整理しておきます。
SCS評価制度が定めるのは★3と★4の2区分です。★1・★2はSCS評価制度の下位段階として新設されたものではなく、IPAが以前から運用しているSECURITY ACTIONの一つ星・二つ星を指します。
★1は情報セキュリティ5か条への取り組み、★2は自社診断25項目の実施と対策方針の公開が求められます。いずれも第三者が評価するものではなく、自己宣言にとどまります。
「★1から★5の5段階で評価される」と書かれた解説を見かけますが、制度構築方針では★1・★2はSECURITY ACTIONを参照する形になっており、「本制度」という言葉は★3・★4を指しています。なお★5は要求事項も評価基準も評価スキームも、開始時期すら決まっていません。
制度としては別でも、実務上のつながりはあります。
SECURITY ACTIONは自己宣言の枠組みのため、費用をかけずに着手できます。いきなり★3の要求事項26・評価基準81に向き合うのが難しい規模の企業にとっては、取り組みの入口として使えます。二つ星の自社診断25項目には、ID管理やバックアップ、ウイルス対策といった基礎的な論点が含まれるため、そこを埋めていく過程が★3の準備と重なる部分もあります。
ただし、★2を宣言したから★3に近づいた、という数え方はできません。自己宣言と専門家確認付きの自己評価では、求められる証跡の水準が違います。段階を積み上げる制度ではなく、別の入口から始めてSCS評価制度に合流する、という理解が実態に近いのではないでしょうか。
中小企業がどの順序で進めるかは中小企業のSCS★3対応の進め方で詳しく扱っています。
プライバシーマークとSCS評価制度は、ISMSほど混同されません。守る対象がはっきり違うためです。ただ、取引先から複数の制度をまとめて問われる場面はあるので、整理しておきます。
プライバシーマークが見るのは、個人情報の取扱いが適切かどうかです。取得・利用・保管・提供・廃棄という一連の流れに管理体制が組まれているかを問います。
SCS評価制度が見るのは、インターネットに接続する自社IT基盤です。扱っている情報が個人情報かどうかは基準になりません。個人情報をほとんど扱わない製造業でも、インターネットに接続するIT基盤があれば評価の対象になります。
重なるのは、アクセス権の管理や記録の保管、教育といった運用面です。ここで作った記録は、SCS評価制度でも実施の証跡として活用できる場面があります。
ここで使う内容別の分け方も、制度が定めたものではありません。IPAが公開している評価基準を、何について求めているかという観点でジョーシスが独自に分類したものです。
その集計では、★3の81評価基準を内容の軸で分け直すと、アイデンティティ・認証に関するものが27件で最多となり、全体の33%を占めます。ID、アクセス権、パスワードをどう管理しているかが制度の重心にあります。
続くのはインシデント対応・復旧14件(17%)、資産・脆弱性・マルウェア対策12件(15%)、ネットワーク境界・リモート9件(11%)です。★4の153件で見ても、ID・認証は33件で最多という結果になりました。
プライバシーマークの体制整備で個人情報に関するアクセス管理を作り込んでいたとしても、この27件が問うているのは個人情報を扱うシステムに限りません。全社のIDと権限が対象です。SaaSの管理者ID、退職者のアカウント、外部委託先に渡した権限まで含めて、把握できている状態が前提になります。
この内容別の分類は、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものであり、制度が定めた区分ではありません。制度が定めた大分類とは数え直す対象が違うため、2つを同じ軸で並べて読むことはできません。
以下で使う分類は、前述のとおりジョーシスが独自に整理したものです。制度が定めた区分ではありません。
制度の違いがわかったところで、実際にどう動くかを現在地ごとに整理します。
出発点としては恵まれた状態です。ただ、着手の順序を間違えると時間を使います。
最初にやるべきは、既存文書の棚卸しではなく、評価基準81件と手元の文書の突き合わせです。評価基準の条文を左の列に置き、対応する文書名と章番号を右の列に埋めていく形の表を作ります。埋まらない行が、そのまま不足分になります。
次に、システムで取る40件に着手します。ID・端末・SaaS・ネットワークの台帳が、申請ベースではなく利用実態から出せる状態にあるかを確認するところからです。ISMSの運用では台帳を年1回の棚卸しで更新している企業が多いのですが、SCS評価制度の評価基準には資産台帳の維持が常時求められる項目が含まれます。更新の頻度そのものが問われる形になります。
個人情報を扱う業務の範囲で作った体制が土台になります。教育の記録、アクセス管理の手続き、委託先管理の枠組みは、対象範囲を全社に広げれば流用できる場面があります。
一方で、インターネット境界の防護、脆弱性のパッチ適用、認証ログの監視といった技術側の論点は、新たに向き合うことになります。★3の評価基準では、重大な脆弱性への対応が14日以内、認証ログの監視が月1回といった具合に、頻度まで書かれています。まず現状の運用がどの頻度で回っているかを確認するところから入ります。
文書も体制もこれから、という状態であれば、順序は3つです。
1つ目は、IT基盤の棚卸しです。ID・端末・SaaS・ネットワークで何を使っているかを、利用実態から出せるようにします。ここが固まらないと、システムで取る40件のほとんどが証跡として成立しません。
2つ目は、記録の様式づくりです。人手で回す16件は年1回の実施記録が求められるため、型を先に作るほど後の蓄積が効きます。
3つ目が文書です。作る文書自体は11種類ほどですが、評価基準の粒度に合わせる工程に時間がかかります。1つ目と2つ目を進めながら並行して着手するのが現実的でしょう。
企業規模によっては、SECURITY ACTIONの一つ星・二つ星から入る選択肢もあります。
3つのケースに共通するのは、台帳の鮮度が制度対応の土台になるという点です。
かつては年に一度の資産棚卸しで台帳を更新し、その間の変更を差分で追いかける運用が一般的でした。現在は各システムのAPI経由で利用実態を自動取得し、台帳を常に最新に保てるようになっています。退職者のIDが残っていないか、把握していないSaaSが使われていないか。こうした問いに即答できる状態が、制度の求める「常時の維持」に近い形です。
ジョーシスでは、ITデバイスとSaaS、アカウント情報を一元管理し、評価のときに出せる証跡として蓄積する仕組みを提供しています。ISMSやプライバシーマークで作ってきた文書資産に、実態側の裏付けを足す使い方ができます。
免除されません。ISMSとSCS評価制度の関係について、公式な整理は2026年9月15日時点で公表されておらず、免除規定も確認できない状態です。ただしISMSで整備した規程や記録が証跡として使える場面はあります。評価基準の条文ごとに、どの文書のどこが対応するかを示す作業が必要になります。
基準の当て方が違います。ISMSは自社でリスクを評価して必要な管理策を選ぶリスクベース型、SCS評価制度は示された評価基準に原則すべて適合するベースライン型です。ISMSでは未実施の管理策も理由を説明できれば成立しうるのに対し、SCS評価制度では自社判断で基準を外す設計になっていません。
守る対象が違うため、どちらかで代替する関係にはありません。プライバシーマークは個人情報の取扱い、SCS評価制度はインターネットに接続する自社IT基盤を対象とします。取引先から★3を提示されているのであればSCS評価制度への対応が先になりますが、プライバシーマークで作った教育記録やアクセス管理の手続きは証跡として活用できる場面があります。
段階として接続する制度ではありません。★1・★2はIPAのSECURITY ACTION(自己宣言)であり、SCS評価制度が定めるのは★3と★4です。ただし二つ星の自社診断25項目にはID管理やバックアップなど基礎的な論点が含まれるため、取り組む過程が★3の準備と重なる部分はあります。費用をかけずに着手できる点も入口として有効です。
ありません。取引先から提示された制度に応じて優先順位をつけます。SCS評価制度は任意の制度であり、取引に規制措置を設けるものではないと経済産業省と内閣官房国家サイバー統括室が2026年4月27日に注意喚起しています。ただし取得企業は登録組織台帳で公開されるため、発注側は★を持つ委託先を確認できるようになります。
SCS評価制度とISMS・プライバシーマーク・SECURITY ACTIONの関係について、2026年9月15日時点で押さえておきたい点は3つです。
1つ目は、ISMSとSCS評価制度は基準の当て方が違うということ。ISMSは自社でリスクを評価して統制を選ぶリスクベース型、SCS評価制度は示された評価基準に原則すべて適合するベースライン型です。「ISMSがあれば通る」という受け止めは、この違いを踏まえていない見立てになります。
2つ目は、免除規定は確認できないということ。公式な整理そのものが2026年9月15日時点で公表されていません。免除を前提にした計画は立てないほうが安全です。
3つ目は、それでもISMS資産は出発点として使えるということ。★3の81評価基準のうち文書で示す25件は既存文書と重なりますが、条文単位の対応表と、方針・規程・手順・記録の4階層の整合は別途必要になります。残る56件はシステムと運用記録の領域です。
なお、ここで触れた証跡の取り方の3分類は、制度が定めた区分ではありません。ジョーシスが独自に整理したものです。
★1・★2は別制度のSECURITY ACTIONであり、SCS評価制度の段階ではありません。取引先との会話で段階の話が出たときは、この前提を先にそろえておくと話が噛み合います。
制度が増えたと捉えるより、問われる軸が増えたと捉えるほうが実務に近いのではないでしょうか。文書は整っているか、実態は台帳に出せるか、運用は記録に残っているか。3つの軸で自社の現在地を見ておくと、どの制度への対応でも土台が共通します。
Sign-up for a 14-day free trial and transform your IT operations.
