評価制度 - セキュリティコミュニティ「WEST-SEC」

1.自工会／部工会サイバーセキュリティガイドライン
2.SCS評価制度
3.ISMS
- 3.1 ISMSとは
- 3.2 ISMS認証とは

1.自工会／部工会サイバーセキュリティガイドライン

1.1 ガイドラインについて

(1)概要

・正式には「自工会/部工会・サイバーセキュリティガイドライン」です。JAMA（日本自動車工業会）とJAPIA（日本自動車部品工業会）が2020年3月に初版を策定し、現在のエンタープライズ領域版はV2.3です。V2.3では「37の要求事項・153の達成条件」が定められています。
・2026年4月には、工場・OT向けの「工場領域版V1.0」も追加されています。
・JAMAのページはこちら。
https://www.jama.or.jp/operation/it/cyb_sec/cyb_sec_guideline.html

(2)対象

・公式には「自動車産業に関係する全ての会社」です。
・完成車メーカーや部品メーカーだけでなく、加工、物流、設備、IT・設計受託なども想定されています。

(3) 評価対象となるIT環境

・公式資料では、少なくとも、以下が対象になります。

・インターネット公開サーバ（Web、メール等）
・PC・スマートデバイス等のエンドポイント
・FW、ルータ、VPN装置等のネットワーク境界
・IT基盤を構成するクラウドサービス等

(4)「認定を取得する制度」ではない

・JAMA/JAPIAガイドラインには、ISMSのような合格・不合格の第三者認証はありません。
・企業自身がチェックシートでセルフチェックし、その結果をJAMAへ提出します。2026年度もJAMA/JAPIAは、自動車産業サプライチェーンに関わる全企業に自己評価を依頼し、さらに「商流に沿って取引先にも展開してください」と要請しています。

1.2 この制度の意義は？

(1)対応しなくてもいいのでは？

取引先、特に完成車メーカーやTier1などから、「チェックシートを提出してください」「Lv2まで対応してください」などと要求された場合、取引上は実質的に対応せざるを得ない場合があります。

(2)制度の意義は？

・従来は、自動車メーカーや取引先ごとに異なるセキュリティチェックを求められる場合があり、サプライヤー側の負担となっていました。自工会・部工会が業界共通のチェックシートを策定したことで、共通部分について同じ基準で自己評価できるようになりました。
・こうした制度ができる以前から、発注企業が取引先のセキュリティ対策を独自のチェックリストなどで確認するケースはありました。ただし、すべての企業が何らかのチェックシートを提出していた、とまでは言えません。
・ただし、取引先独自の追加チェックまでなくなったわけではありません。
→ 「チェック項目を完全統一した」というより、「業界共通の物差しを作った」ことに大きな意義があると思われます。

1.3 レベルと点数

(1)点数はどう付けるのか

・153個の「達成条件」について、次の4択です。

回答	点数
対策完了	2点
該当なし	2点
対策中	1点
未実施	0点

※「該当なし」も満点扱いです。

(2)3つのレベル

レベル	位置付け	主に想定される会社	そのレベルの項目数	追加分の満点	累積満点
Lv1	自動車業界として最低限実装すべき	自動車産業に関係する全会社	50項目	100点	100点
Lv2	自動車業界として標準的に目指す	他社の機密情報を扱う、重要技術を持つ、供給停止するとサプライチェーンへの影響が大きい会社など	（Lv1）＋74項目	148点	248点
Lv3	現時点で自動車業界が到達点として目指す	規模・技術力等で自動車業界を代表・牽引する会社、またはそれを目指す会社	（Lv2）＋29項目	58点	306点

(3)目指すべきレベル

・2025年度は完成車メーカー14社すべてがLv3を目標にしていますが、部品メーカーなどにも多数のLv3目標企業があります。

(4)レベル別企業数

2025年度分（2026年3月31日公表）の有効回答は4,032社です。

Q.それって自動車業界のどれくらいの割合？

A.母数を公開していないのでわからないですが、実際の母数はもうちょっと多い気がします。参考になるか不明ですが、2020年版中小企業白書が紹介した2018年の自動車産業エコシステムでは、Tier1～Tier6以下を合計すると約2.6万社でした。内訳はTier1 4,446社、Tier2 8,533社、Tier3 6,267社などです。

各社が設定した目標レベル	企業数	4,032社に占める割合	そのグループの平均得点
Lv1	989社	24.5%	63.32 / 100点＝63.3%
Lv2	1,704社	42.3%	208.45 / 248点＝84.1%
Lv3	1,339社	33.2%	266.18 / 306点＝87.0%
合計	4,032社	100%	―

※あくまで「自社の目標レベルとして選んだ会社数」

(5)「達成した」とは何を意味する？

Q.8割など、一定の項目数を満たせば達成なのでしょうか？

→A.いえ、全項目です。
・ガイドライン上は、Lv1なら「Lv1の全項目」、Lv2なら「Lv1・Lv2の全項目」、Lv3なら「Lv1～Lv3の全項目」の達成を目指します。
・したがって、完全達成を点数で表せば、Lv1＝100/100、Lv2＝248/248、Lv3＝306/306です。
・ただし、その満点企業数をJAMAは集計資料で公表していません。

(6)結果の公表

・実際に各レベルごとの全項目達成した会社が何社かは、JAMAの公開資料からは分かりません。
・結果の公表の流れは、以下です。

・JAMAへ自己評価を提出
・JAMAは集計・匿名化して業界全体の統計を公表
・提出した企業が希望すれば、指定した取引先にもチェックシートを共有

1.4 チェック項目

(1)全体像

・全153項目ですが、V2.3では次の24分野に整理されています。

	ラベル	目的	要求事項
1	方針	会社としてセキュリティの基本的な考え方・方針を示し、社内の情報セキュリティ意識を高める	自社の情報セキュリティ方針を策定し、組織内に周知する
2	機密情報を扱うルール	機密情報を扱うルールを定めて周知し、情報漏えいを防止する	機密情報のセキュリティに関する社内ルールを定める
3	法令順守	情報セキュリティに関係する法令を順守する	個人情報保護法、不正競争防止法などを考慮して社内ルールを定める
4	体制（平時）	情報セキュリティの体制・役割を明確にし、情報保護とセキュリティ対策を強化する	平時のセキュリティリスクを管理する体制を整え、情報収集・共有を行う
5	体制（事故時）	事故発生時の体制・役割を明確にし、被害を最小化して速やかに復旧する	情報セキュリティ事故発生時の対応体制、責任者、役割を明確にする
6	事故時の手順	5「体制（事故時）」と同じ	①情報セキュリティ事故をBCPや緊急時対応計画に組み込む ②事故発生後に早期対応するための手順を明確にする
7	日常の教育	①マルウェアや機密情報のリスク、正しい取扱いを理解させ、事故を予防する ②事故に迅速・適切に対応できるよう事前に備え、被害拡大防止・早期復旧を図る	①従業員が注意すべき事項を教育する ②組織内・組織間で発生するセキュリティ事故を想定した教育・訓練を行う
8	他社との情報セキュリティ要件	サプライチェーンでの機密情報漏えいを防ぎ、事故発生時に迅速に対応できるようにする	サプライチェーン上で必要となる情報セキュリティ要件を明確にする
9	アクセス権	権限設定の不備による機密エリア・システムへの不正アクセスを防止する	入室権限やシステムのアクセス権を適切に管理する
10	情報資産の管理（情報）	情報資産を適切に管理し、機密情報の漏えいを防止する	情報資産を機密度で分類・把握し、区分に応じて管理する
11	情報資産の管理（機器）	IT資産を適切に管理してリスクを低減し、事故発生時の対応を迅速化する	情報機器、OS、ソフトウェアについて、バージョン、管理者、設置場所などを把握・管理する
12	リスク対応	情報資産のセキュリティリスクを特定し、組織的に対策して業務影響を最小化する	業務委託を含む自組織の情報セキュリティリスクに対して対策を行う
13	取引内容・手段の把握	どの取引先と、どの情報を、どの手段でやり取りしているかを明確にし、情報漏えい等を防ぐ	①取引先ごとに授受する情報資産と利用手段を把握する ②IT機器の調達に伴う情報セキュリティリスクを管理する
14	外部への接続状況の把握	外部システム利用時の安全性・信頼性を確保し、事故発生時の対応を迅速化する	①サプライヤー等とのネットワーク構成、接続状態、データの流れを把握・監視する ②クラウド等を含む外部情報システムを把握し、利用状況を管理する
15	社内接続ルール	社内ネットワークを適切に管理し、情報漏えいやマルウェア感染の被害を最小化する	①社内ネットワーク接続時の情報システム・機器の不正利用を防止する ②リモートワークにおける情報漏えい、なりすまし等を防止する
16	物理セキュリティ	サーバー等の重要機器への不正操作による情報漏えい、改ざん、システム停止を防止する	①サーバー等の設置場所を物理的に保護する ②入退場時の不正侵入、情報持出し、不審行動等を防止する ③機器や情報の持込み・持出しを制限する ④社内での撮影・録音による情報漏えいを防止する ⑤脆弱性発見時の対象把握や外部記憶媒体による情報漏えい等を防止する ⑥重要情報を扱うシステムについて、設定ミスによる被害を防止する
17	通信制御	※原文の「目的」欄には記載なし	サイバー攻撃や内部情報漏えいを防止するため、情報システム・機器や不正Webサイトへの通信を制御する
18	認証・認可	システムの不正利用・不正操作を防止し、情報漏えい・改ざん・停止を防ぐとともに、事故原因を調査できるようにする	情報システム・情報機器に適切な認証・認可対策を行う
19	パッチやアップデート適用	不正アクセスやマルウェア感染のリスクを低減する	①サポート期限切れの機器、OS、ソフトウェアを利用しない ②脆弱性を悪用した不正アクセスを防ぐための対策を行う
20	データ保護	不正アクセスやマルウェア感染のリスクを低減する	情報システム・情報機器のデータを保護する
21	オフィスツール関連	不正アクセスやマルウェア感染のリスクを低減する	情報システム・情報機器のデータを保護する
22	マルウェア対策	マルウェア感染による情報漏えい、改ざん、システム停止を防止する	セキュリティ上の異常を早期検知できるマルウェア対策を実施する
23	不正アクセスの検知	不正アクセス・不正侵入による情報漏えい、改ざん、システム停止を防止する	①ネットワークへの不正アクセスを常時監視する ②事故発生時に侵入経路・漏えい経路を調査できるようログを取得する ③標的型攻撃等を速やかに検知・遮断する
24	バックアップ・復元（リストア）	システム停止やデータ消失による業務影響を最小化し、早期復旧を実現する	①サイバー攻撃による重要情報やシステム稼働への影響を最小限に抑える ②セキュリティ事故を想定し、事業継続に必要なデータを復旧できるよう準備する

(2)具体的な達成条件

（出典： https://www.jama.or.jp/operation/it/cyb_sec/docs/cyb_sec_guideline_V02_03.pdf ）

1.5効果は？

(1)対策レベルは上がったのか

・自己評価スコア上は明確な改善が見えます。

年度	Lv1項目	Lv2項目	Lv3項目
2022	77.0%	74.7%	64.4%
2023	81.8%	81.1%	74.0%
2024	82.8%	83.4%	67.8%
2025	83.1%	85.2%	71.1%

JAMA/JAPIA自身も、2025年度について「全ての目標レベルで平均点が向上し、全体的なセキュリティレベルの底上げが図れている」と評価しています。
（出典： https://www.jama.or.jp/operation/it/cyb_sec/docs/cyb_sec_supply_chain_CS_guide_2025.pdf ）

(2)所感

・セキュリティレベルの実体まではこの制度では評価できないので、「この制度によってランサムウェア事故が○％減った」「工場停止が○％減った」といったことまでは、わかりません。
・ISMSと同様、ISMSを取得した大企業でも、情報漏えいは起きていますし。

2.SCS評価制度

2.1 概要

(1)制度の概要

・SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）は、サプライチェーンを構成する企業のセキュリティ対策状況を、共通の「★」で可視化する制度です。
・近年、セキュリティが比較的脆弱な取引先（中小企業など）を踏み台にして侵入する「サプライチェーン攻撃」が増えています。

・実際、IPAの情報セキュリティ10大脅威 2026（https://www.ipa.go.jp/security/10threats/10threats2026.html ）においても、「組織」向け脅威では、「サプライチェーンや委託先を狙った攻撃」が第2位です。

(2)背景と目的

・背景として、以下の問題がありました。

・発注企業：取引先のセキュリティ対策が見えにくい
・受注企業：取引先ごとに異なるチェックシートへの回答を求められる　→大きな負担

・この制度は、こうした非効率なチェックシートのやり取りを削減し、日本全体のセキュリティ水準を底上げすることを目的としています。・・・が、本当に意味あるかは不明

(3)主なスケジュール

時期	内容
2026年3月	制度構築方針を公表
2026年4月	★3・★4の要求事項・評価基準を公開
2026年8月頃	制度規程、評価機関等の詳細を順次公表予定
2026年10月頃	IPAより、解説書・取得ガイド・申請方法等を公表予定
2026年12月末頃	★4評価機関を公表予定
2027年1月以降	★3セキュリティ専門家を公表予定
2027年3月頃	★3・★4運用開始予定

※2026年8月現在、正式な★3・★4取得企業はまだ存在しません。

(4)誰が取得する？

・中小企業や下請けだけの制度ではありません。全サプライチェーン企業が対象です。
・発注企業自身も適切な★を取得し、そのうえでリスクの高い取引先に★3・★4を求める、という運用が自然だと考えます。

(5)取得単位

・原則は法人または個人事業主単位です。
・ただし、★3ではセキュリティ専門家、★4では評価機関が適用範囲を妥当と判断すれば、事業部単位やグループ単位で取得することもできます。
・ここでいうグループ単位とは、単に「資本関係がある会社をすべてまとめられる」という意味ではありません。共通のIT基盤やセキュリティ管理体制など、一つの責任範囲として合理的に説明できることが重要です。
・例えば巨大企業グループの場合、全グループ会社を一括取得するより、共通のIT・セキュリティ管理下にある会社や事業単位ごとに取得することが現実的と考えられます。
・たとえば、グループ会社が1000社を超えるような巨大企業の場合

申請範囲の例	可能性	考え方
巨大企業の1社として	◎ 原則形	法人単位
巨大企業の1社の特定事業部	○	範囲の妥当性確認が必要
共通IT基盤・共通セキュリティ管理下にある複数グループ会社	○	グループ単位として合理的なら可能
国内外1000社すべてを単純に「巨大企業グループ」として一括	△	制度上グループ申請は可能だが、その巨大範囲を1つの責任単位として説明できる必要がある

(6)SCS評価制度を理解するための主要資料

資料	何が分かるか	位置付け
★3・★4 要求事項・評価基準	実際に企業が満たすべき要求事項。153項目・7分野の具体的な評価基準	制度の中身そのもの。企業が何を対策すべきかを確認する最重要資料
SCS評価制度の詳細情報	★3・★4・★5の違い、★3の自己評価、★4の第三者評価、評価機関・技術検証事業者など制度全体の仕組み	制度全体を理解するために最初に読む資料
SCS-100 基本規程	SCS評価制度全体の正式な基本ルール。評価機関、技術検証事業者、研修事業者、SCSセキュリティ専門家などの位置付け	制度上の正式なルールを確認する資料
SCS-210 評価機関指定規則	評価機関の申請、審査、指定、更新、取消しなど	評価機関について確認する資料
SCS-220 技術検証事業者指定規則	技術検証事業者の申請、審査、指定、更新、取消しなど	技術検証事業者について確認する資料
SCS-230 研修事業者指定規則	研修事業者の申請、審査、指定、更新、取消しなど	研修事業者について確認する資料
指定基準・研修実施基準・指定手順	どのような会社が指定されるか、必要な体制・人員・講師要件、研修内容、申請方法など	事業者指定の具体的な条件を定める資料。正式な単独資料は現時点では未公開
第2回指定委員会配付資料	指定基準、研修内容、修了試験、講師要件、公募スケジュールなど	正式な指定基準等が公開されるまで、具体的な要件を確認するための参考資料
★3・★4 要求事項・評価基準解説書	153項目について、具体的に何を実施すればよいかを解説する資料	2026年10月頃公開予定

2.2 他のガイドライン等との比較

(1)自工会ガイドラインとの比較

・経産省・IPAのSCS評価制度は業界横断の新制度で、2026年度末ごろの運用開始予定です。現時点ではまだ取得実績が出る段階ではありません。
・両者にはかなり強い関係があります。経産省資料では、
　・SCS ★3 → 自工会/部工会ガイドラインLv1をベンチマーク
　・SCS ★4 → 自工会/部工会ガイドラインLv2をベンチマーク
　・SCS ★5 → ISO/IEC 27001、Lv3などの高度な対策も参考に今後具体化
という位置付けです。

■注意点
自工会Lv2を「満たした」というのは自己申告でしかないので、第三者の評価がある★４と同じとは考えない方がいいでしょう。うがった見方をすると、「Lv2を満たした」と考えている（または提出済の）会社さんは、★４を取るモチベーションが少ない可能性があります

（出典：https://www.ipa.go.jp/security/scs/rcu1hd0000007ajp-att/20260327001-br.pdf ）
・自工会方式を全国・全産業向けに発展させた制度にかなり近いのですが、「JAMA制度をSCSへ統合して廃止する」と決まっているわけではありません。2026年8月現在、JAMA/JAPIAは自動車業界ガイドラインを廃止しておらず、むしろ2026年度も自己評価を継続し、2026年4月には工場領域版まで新設しています。
・自工会・部工会ガイドラインは、「認証を取らせる制度」ではなく、「自動車サプライチェーン全体を同じ153項目で自己採点させ、取引先にも展開する仕組み」であった。
・自己評価なので客観的なセキュリティ保証にはならない。この部分を補うような形で、今後SCSの★3・★4という専門家確認・第三者評価型の仕組みが始まる、という流れです。

(2)ISMSとの違い

・ざっくりですが、以下のような整理ができます。

ISMS	自社のリスクを分析して、適切なセキュリティ管理を継続的に行っているか
SCS	サプライチェーン企業として共通して必要とされる具体的な対策を実装しているか

・とはいえ、２つの制度は相互補完的なものと考え、両方の取得をしていく企業が多くなっていくでしょう。

項目	ISMS	SCS ★3・★4
基本思想	リスクベース	ベースライン
対策の決め方	自社のリスクアセスメントに基づき、必要な管理策を選定（適用宣言書／SoA）	★ごとに共通の要求事項・評価基準をあらかじめ規定
審査・評価の焦点	選定した管理策をPDCAで継続的に運用・評価・改善できているか	共通要求事項に沿った具体的な対策が実施されているか

※SoAは Statement of Applicability

(3)JC-STARとの違い

どちらも★で評価するが、主な違いは、「何を評価するのか（対象）」で、会社を見るのがSCS、製品を見るのがJC-STARと言えるでしょう。

	SCS	JC-STAR
評価対象	企業・組織のIT基盤	IoT製品
目的	サプライチェーン企業の対策状況を可視化	製品自体のセキュリティを可視化
主な段階	★3・★4、★5検討中	★1～★4
例	会社のMFA、バックアップ、取引先管理等	ルータ、IoT機器等

・IoT製品メーカーなら、企業としてSCSを求められ、製品についてJC-STARを求められる、という両方のケースもあります。

2.3 サプライチェーンじゃなく、自社のセキュリティチェックに使える？

(1)経済産業省のサイトを見ると、使えると評価できそう

以下の記載を見ると、サプライチェーンに属する中小企業に限らず、幅広い会社で利用できそうです。
https://www.meti.go.jp/policy/netsecurity/scs.html

Q6　SCS評価制度は、どのような業種や企業規模に適用されるのですか？

→業種や事業規模を問わず、幅広い事業者が対象となり得ます。サプライチェーンを構成する企業等を対象としていますが、取引先からの要請が無くても、各企業が自らのサイバーセキュリティ対策状況を可視化するために、マーク（★）を自主的に取得することも考えられます。

Q18　中小企業だけが対象ですか？　大企業も評価対象になりますか？

→制度構築方針に記載の通り、業種や事業規模を問わず、幅広い事業者が対象となり得ます。中小企業だけでなく、大企業も評価対象とすることが可能なように制度を設計しています。

(2)どのレベルを使うべきか

以下に記載がありますが、★は段階なので、★３→★４→★５と、順に目指していくといいでしょう。
https://www.meti.go.jp/press/2025/12/20251226001/20251226001.html

レベル	内容	備考
★3	全てのサプライチェーン企業が最低限実装すべきセキュリティ対策として、基礎的なシステム防御策と体制整備を中心に実施する段階	専門家確認付き自己評価
★4	サプライチェーン企業等が標準的に目指すべきセキュリティ対策として、組織ガバナンス・取引先管理、システム防御・検知及びインシデント対応等包括的な対策を実施する段階	第三者評価
★5	サプライチェーン企業等が到達点として目指すべき対策として、国際規格等におけるリスクベースの考え方に基づき、自組織に必要な改善プロセスを整備した上で、システムに対しては現時点でのベストプラクティスに基づく対策を実施する段階	第三者評価（令和8年度以降具体化の検討）

(3)ただし、SCSだけでは不十分

注意点は、主に企業のIT基盤を対象としていることです。
例えば、以下は別途確認する必要があります。

・WebアプリケーションやAPI固有の脆弱性（BOLA/IDORなど）
・製造設備のOTセキュリティ
・自社製品・サービス固有のセキュリティ
・個々の重要システムに特有のリスク

よって、SCSを「共通チェックシート」として使い、それに「自社固有のリスクアセスメント」を組み合わせるといいでしょう。

2.4 評価について

(1)概要

・企業の対策成熟度に応じて5つの段階（星の数）で評価
・★1と★2は既存のIPA（情報処理推進機構）の制度を活用し、今回の新制度で新たに★3〜★5が創設される。※メインは★３と４

(2)評価の5段階

評価段階	位置付け・対象企業	想定する脅威・対策水準	要求事項	評価基準	評価スキーム	有効期間
★5	サプライチェーン企業が到達点として目指す高度な対策	未知の攻撃を含む高度なサイバー攻撃にも対応。国際規格等を踏まえたリスクベースの対策	未定	未定	第三者評価を想定。詳細は今後検討	未定
★4	事業停止や情報漏えいなど、サプライチェーンに大きな影響をもたらし得る企業が標準的に目指す対策	重大な事業停止・機密情報漏えい等につながる攻撃を想定。多層防御など包括的な対策	43件	153項目（★3の81項目＋追加72項目）	第三者評価＋実地審査＋技術検証	3年
★3	すべてのサプライチェーン企業が最低限実装すべき対策	広く認知された脆弱性の悪用など、一般的なサイバー攻撃を想定。基礎的な防御策と体制を整備	26件	81項目	自己評価＋登録されたセキュリティ専門家による確認 ※ただし、自己評価がメイン	1年
★2	基本的なセキュリティ対策を自主的に進める段階	自社診断を実施し、「情報セキュリティ基本方針」を策定・公開	－	－	IPA「SECURITY ACTION」二つ星の自己宣言	－
★1	最低限の情報セキュリティ対策に着手する段階	IPA「情報セキュリティ5か条」に取り組む	－	－	IPA「SECURITY ACTION」一つ星の自己宣言	－

Q.なぜ★3は自己評価がメインといえるのか？

A.★4のように評価機関による第三者評価・実地審査・技術検証を受ける必要はなく、自社で記入した自己評価をセキュリティ専門家が確認・署名し、経営層の自己適合宣誓を添えて事務局に提出すれば取得できます。確認するセキュリティ専門家は社外である必要がなく、社内の有資格者でも構いません。つまり、外部の第三者による客観的な検証を必須としない設計になっています。

(3)具体的なチェック項目

・公開された153項目は7分野です。
・IPA「要求事項・評価基準」に公開されています。
https://www.ipa.go.jp/security/scs/requirements-criteria.html
・IPAのExcelを分類すると次のようになります。

分野	★3	★4で追加	★4（合計）
ガバナンスの整備	8	11	19
取引先管理	4	3	7
リスクの特定	11	18	29
攻撃等の防御	48	34	82
攻撃等の検知	3	5	8
インシデントへの対応	6	0	6
インシデントからの復旧	1	1	2
合計	81	72	153

(4)各分類の概要

大分類No.	大分類	中分類No.	中分類	要求事項No.	★3	★4	要求事項名
1	ガバナンスの整備	1-1	組織の状況	1-1-1		○	社内ルール
〃	〃	1-2	役割、責任、権限	1-2-1	○	○	セキュリティ推進活動部門
〃	〃	〃	〃	1-2-2		○	サイバー攻撃の監視・分析体制
〃	〃	〃	〃	1-2-3	○	○	守秘義務のルール
〃	〃	1-3	ポリシー	1-3-1	○	○	セキュリティ対応方針の策定
〃	〃	1-4	監督	1-4-1		○	セキュリティ対策推進計画
2	取引先管理	2-1	サイバーセキュリティサプライチェーンリスクマネジメント	2-1-1	○	○	取引先とのビジネス又はシステム上の関係
〃	〃	〃	〃	2-1-2	○	○	機密情報の取扱い
〃	〃	〃	〃	2-1-3		○	取引先のセキュリティ対策状況
〃	〃	〃	〃	2-1-4	○	○	セキュリティインシデント発生時の役割・責任
〃	〃	〃	〃	2-1-5		○	機密情報の回収・破棄
3	リスクの特定	3-1	資産管理	3-1-1	○	○	情報機器、OS及びソフトウェアに関する情報の把握
〃	〃	〃	〃	3-1-2	○	○	ネットワークに関する情報の把握
〃	〃	〃	〃	3-1-3	○	○	外部情報サービスの管理
〃	〃	〃	〃	3-1-4	○	○	機密区分に応じた情報の管理
〃	〃	〃	〃	3-1-5		○	リモートワークにおけるルール
〃	〃	3-2	リスクアセスメント	3-2-1		○	脆弱性の管理体制
4	攻撃等の防御	4-1	アイデンティティ管理、認証、アクセス制御	4-1-1	○	○	ユーザIDの管理手続
〃	〃	〃	〃	4-1-2	○	○	管理者IDの管理手続
〃	〃	〃	〃	4-1-3	○	○	認証の強度・実装方法の決定
〃	〃	〃	〃	4-1-4	○	○	アカウントロック制御
〃	〃	〃	〃	4-1-5	○	○	パスワード設定ルール
〃	〃	〃	〃	4-1-6	○	○	パスワード管理ルール
〃	〃	〃	〃	4-1-7	○	○	アクセス権の管理ルール
〃	〃	〃	〃	4-1-8		○	サーバ設置エリアへの入退室管理
〃	〃	〃	〃	4-1-9		○	可搬媒体の制限
〃	〃	4-2	意識向上とトレーニング	4-2-1		○	セキュリティの意識向上のための教育・研修
〃	〃	〃	〃	4-2-2	○	○	セキュリティインシデント発生時の教育・訓練
〃	〃	4-3	データセキュリティ	4-3-1		○	データの暗号化
〃	〃	〃	〃	4-3-2		○	データの保管ルール
〃	〃	〃	〃	4-3-3		○	取引先との情報共有ルール
〃	〃	〃	〃	4-3-4	○	○	適切なバックアップ
〃	〃	4-4	プラットフォームセキュリティ	4-4-1	○	○	情報機器、OS及びソフトウェアの安全な構成
〃	〃	〃	〃	4-4-2		○	サポート期限の切れたOS及びソフトウェアへの対策
〃	〃	〃	〃	4-4-3		○	ログの取得
〃	〃	〃	〃	4-4-4	○	○	セキュリティパッチ・アップデートの手続
〃	〃	〃	〃	4-4-5	○	○	マルウェア感染からの保護
〃	〃	4-5	技術インフラのレジリエンス	4-5-1	○	○	ネットワーク境界防護
5	攻撃等の検知	5-1	継続的監視	5-1-1	○	○	ネットワーク接続・データの監視
〃	〃	〃	〃	5-1-2		○	情報機器及びソフトウェアの挙動監視
〃	〃	5-2	有害事象の分析	5-2-1		○	セキュリティインシデントのレベルごとの対象範囲
6	インシデントへの対応	6-1	インシデント管理	6-1-1	○	○	インシデント対応手順
7	インシデントからの復旧	7-1	インシデント復旧計画の実行	7-1-1	○	○	事業継続要件に沿った復旧準備

(5)評価基準の例

要求事項No.	★3	★4	要求事項名	要求事項	評価段階	評価基準No.	評価基準
4-1-6	○	○	パスワード管理ルール	パスワードの管理に関するルールを定め、周知すること。	★3	4-1-6-1	紙媒体への記載及び施錠保管、パスワード管理アプリの利用等により、パスワードを安全に保管するよう社内ルールを定めること。
〃	〃	〃	〃	〃	★3	4-1-6-2	パスワードの漏洩が判明した場合、又はその疑いがある場合に速やかにパスワードを変更するための手順を定めること。
〃	〃	〃	〃	〃	★3	4-1-6-3	No.4-1-6-1及びNo.4-1-6-2で定めたパスワードの管理に関するルールについて、役員、従業員、派遣社員及び受入出向者を対象に周知すること。
4-1-7	○	○	アクセス権の管理ルール	アクセス権の管理ルールを定めること。	★3	4-1-7-1	業務で利用するシステム及びパソコンへのログオン時のユーザのアクセス権並びに機密上の配慮が必要な場所及び部屋への入室について、以下の内容の管理ルールを定めること。・アクセス権の発行・変更・削除は申請・承認制であること。・与える入室許可・アクセス権の範囲は必要な範囲に限定すること。・入室権限及びアクセス権の棚卸について定めていること。・与えた入室許可・アクセス権の申請書又は台帳を管理していること。
〃		○	〃	〃	★4	4-1-7-2	年1回以上の頻度で役員、従業員、派遣社員及び受入出向者に付与したアクセス権の棚卸を実施すること。
〃		○	〃	〃	★4	4-1-7-3	重要な機密情報を扱うシステムは、アクセス権を付与するための条件を定めること。
〃		○	〃	〃	★4	4-1-7-4	重要な機密情報を扱うシステムにおけるアクセス権の設定に当たっては、システム管理者の要件及び設定手順を定めること。
〃		○	〃	〃	★4	4-1-7-5	重要な機密情報を扱うシステムは、ユーザ及び管理者ごとに必要最小限の権限を付与し、個人に権限が集中しない環境とすること。
〃		○	〃	〃	★4	4-1-7-6	重要な機密情報を扱うシステムは、付与したアクセス権の運用・利用状況を監視する仕組みを整備すること。

・特定製品であったり、具体的な技術としてEDRを導入せよ、ゼロトラスト製品を導入せよ、とは書かれていません。
・製品名ではなく、「不正通信を検知・遮断できる」「端末等の状態・挙動を監視できる」といった「達成すべき状態」を規定しています。

(6)「合格点」はなく、基準を全て満たす必要あり

・SCSは、「81項目の80％を満たせば★3」という点数制ではありません。
・★3・★4とも定められたすべての要求事項・評価基準を満たす必要があります。

2.4 ★3の取得方法

(1)取得プロセス

・★3は、企業自身が自己評価を行い、その内容を登録されたセキュリティ専門家が確認する方式です。第三者認証ではありませんが、単なる自己申告だけでもありません。
・取得プロセスは、概ね次のようになります。
❶要求事項への対応
★3では、26の要求事項、81の評価基準を満たす必要があります。
主な対策には、次のようなものがあります。

分野	主な対策例
IT資産管理	PC、サーバ、ネットワーク機器、ソフトウェアなどを把握・管理する
認証・アクセス制御	ID・アクセス権を適切に管理し、重要なシステム等では多要素認証（MFA）を利用する
脆弱性対策	OS、ソフトウェア、ネットワーク機器などの脆弱性情報を確認し、必要なアップデートを実施する
マルウェア対策	PCやサーバなどにマルウェア対策を実施する
ネットワーク防御	ファイアウォール等を利用し、不正通信を検知・遮断する
バックアップ	重要データをバックアップし、遠隔地等にも保管する
インシデント対応	事故発生時の連絡先、対応体制、初動手順などを定める
教育・訓練	セキュリティ事故を想定した教育・訓練を実施する

※EDRなど特定の製品を導入すること自体が必須なのではなく、評価基準で求められる状態を実現する必要があります。

❷自己評価
・IPAが公開する評価基準に基づき、自社が81項目を満たしているか自己評価します。
・単に「○」を付けるだけではなく、社内規程、資産台帳、設定内容、ログ、教育記録など、実施していることを確認できる証跡を準備します。

❸セキュリティ専門家による確認・助言
・自己評価結果を、SCS評価制度に登録されたセキュリティ専門家に確認してもらいます。
・専門家は誰でもよいわけではなく、情報処理安全確保支援士、CISSP、CISA、CISM、ISO/IEC 27001主任審査員など、制度で定められた資格等を持ち、所定の研修を受講して登録された者が想定されています。

Q.必ず外部のコンサルタントに依頼する必要がある？

A.社内に条件を満たす登録専門家がいれば、社内で対応できる可能性があります。

❹経営層による自己適合宣誓
専門家による確認を受けた後、経営層が要求事項を満たしていることを自己適合宣誓します。

❺IPAへの申請・登録
必要書類をIPAの事務局へ提出し、認められれば★3取得企業として登録・公表されます。

★3の有効期間は1年間です。
継続する場合は、毎年評価・更新する必要があります。

(2)専門家は社内でもいいの？

Q. ★3の確認は、社内の担当者がやってもいいのか？

→A. はい。ただし、情報処理安全確保支援士・公認情報セキュリティ監査人・CISSP・CISA・CISM・ISO27001主任審査員のいずれかを保持し、制度指定の研修を受講したうえで事務局に登録している必要があります。

Q. 費用や期間はどれくらいかかる？

→A.指定研修費について2026年7月時点では「未公表」です。2026年度末の制度開始までに指定研修機関から案内される予定。ただ、すでに対象資格を持っている社員がいるなら、そこまで大きな負担にはならない可能性があります。

2.5 ★4の取得方法

(1)取得プロセス

・★4では43の要求事項、153の評価基準を満たす必要があります。
・なお、★4を取得するために、事前に★3を取得する必要はありません。
・取得プロセスは概ね次のようになります。
❶要求事項への対応
↓
❷自己評価
↓
❸評価機関による文書確認
↓
❹実地審査
↓
❺技術検証
↓
❻評価報告書の受領
↓
❼IPAへの登録申請
↓
❽★4として登録・公表

・★4では、★3の81項目に加えて72項目が追加され、合計153項目になります。
・追加される対策には、例えば次のようなものがあります。

主な対策	内容例
脆弱性管理	脆弱性情報を継続的に収集し、対応状況を管理する
ログ管理	FW、Proxy、認証システムなどのログを保存・監視する
ネットワーク分離	重要なシステムを適切なネットワークに分離する
端末等の挙動監視	情報機器やソフトウェアの異常な挙動を監視する
取引先管理	重要な取引先のセキュリティ対策状況を定期的に確認する
復旧確認	バックアップから目標時間内に復旧できることを確認する

(2)実地審査

評価機関が実際の運用状況や証跡を確認します。

例えば、以下を確認します。

・規程どおりに運用されているか
・資産台帳が実態と一致しているか
・脆弱性管理が実施されているか
・インシデント対応手順が整備・運用されているか

(3)技術検証

・★4では技術的な検証も行われます。
・例えば、インターネットに公開されているVPN装置やルータなどについて、脆弱性が存在しないかを検査することが想定されています。全面的なペネトレーションテストを行うという意味ではなく、制度で定められた範囲について技術的な確認を行います。

(4)審査にかかる時間

・制度資料で示されている目安は次のとおりです。

工程	想定時間
文書確認	1～2日程度
実地審査	1～2日程度
技術検証	1～2日程度

・ただし、これは審査そのものに必要な時間です。
・81項目・153項目のギャップ調査、規程作成、システム改修、証跡準備、未達項目の是正などに必要な期間は含まれていません。したがって、実際の取得準備には、企業の現在の対策状況によって数か月以上かかる可能性があります。

(5)★4の取得で難しそうないところ

例えば、以下の項目が難所になると考えられます。

評価基準No.	項目	主な内容
4-4-3-1、4-4-3-3	ログ管理	FW、Proxy、認証サーバ等のログを6か月保存し、認証ログは月1回以上監視する
4-5-1-9	ネットワーク分離	社外公開サーバや重要な機密情報を扱うサーバを専用セグメントに設置し、アクセスを必要最小限に限定する
4-1-3-5、4-1-7-2	アクセス制御	社内環境へのリモート接続等にMFAを適用し、アクセス権を年1回以上棚卸しする
4-4-4-3	脆弱性対策	インターネット境界のネットワーク機器について、CVSS基本値7.0以上の脆弱性が残存していないこと
1-2-2-1～2、5-1-2	監視体制	サイバー攻撃の監視・分析体制を整備し、情報機器やソフトウェアの状態・挙動を監視する
2-1-3-1	取引先管理	重要な取引先のセキュリティ対策状況を年1回以上確認する
7-1-1-2	復旧確認	リストア手順書どおりに、目標復旧時間内にバックアップから復元できることを確認する

さらに、★4の難しさは、第三者による実地審査や技術検証が行われる点にもあります。
例えば、資産台帳と実際の機器構成が一致しているか、規程どおりに運用されているかなどを確認されます。インターネットに公開されたVPN装置やルータ等については、脆弱性検査も実施されます。

2.6 ★5について

★5の位置づけ

（出典：https://www.ipa.go.jp/security/scs/rcu1hd0000007ajp-att/20260327001-br.pdf ）

2.7 SCS評価制度を支える指定委員会と3つの事業者

SCS評価制度では、IPAなどの制度運営機関だけでなく、「指定委員会」と、指定を受けた3種類の事業者が重要な役割を担います。

種類	何をする組織？	主な役割
指定委員会	評価機関、技術検証事業者、研修事業者の指定などについて審議する	制度運営機関からの委託に基づき、各事業者の指定・指定取消しや、指定基準・手順などについて審議・決定する
評価機関	★4取得希望組織を第三者の立場で評価する	自己評価結果を確認し、実地審査や技術検証を実施して、評価報告書を作成する
技術検証事業者	★4で必要となる技術検証を行う	システムに対する技術的な検証を行い、技術検証結果報告書を作成する
研修事業者	SCS評価制度の評価・確認を担当する人材を育成する	★3の確認責任者・確認従事者、★4の評価責任者・評価従事者などに必要な研修を実施する

ポイントは、★4の「技術検証」は必ず別会社が行うわけではないことです。

評価機関自身が技術検証を行う場合と、評価機関が指定を受けた技術検証事業者へ委託する場合の両方があります。

2.8 取得費用

(1)公開されている登録費用など

「サプライチェーン強化に向けたセキュリティ対策評価制度料金設定のお知らせ」
https://www.ipa.go.jp/security/scs/rcu1hd00000075om-att/pricelist.pdf

ただ、この表はわかりづらく、3種類の立場の人に対する料金が混在しています。たとえば、1に書かれている15万円や30万円は、企業が評価機関に支払う審査費用ではなく、評価機関がIPAに登録するための料金です。

(2)必要な費用

費用の種類	費用項目	★3	★4
①評価・申請にかかる費用	IPAへの登録料	1万円（1年分）	6万円（3年分）
	評価費用（専門家確認・第三者評価）	専門家による確認費用	第三者評価費用
	技術検証費用（脆弱性診断等）	－	個別見積もり
②対策にかかる費用	対策・運用費用（製品導入、システム改修、規程整備、監視・保守等）	個別見積もり	個別見積もり
	取得支援コンサルティング（現状調査・ギャップ分析等）	必要に応じて	必要に応じて

・実際には、審査そのものよりも、81項目の未対応部分を改善するための費用の方が大きくなる場合があります。

2.9「取得すれば安全か」「意味があるのか」

(1)完全なセキュリティを保証するものではない

・経産省の制度構築方針には、★取得は取得・更新時点で必要水準を満たしたことを示すものであり、「完全なセキュリティを保証するものではない」と明記されています。

また、否定的な話をあえてすると
・大企業であれば、このチェックシートの大部分を実装しているでしょう。でも、大企業でも大規模なランサムウェアの被害にあっています。その原因は何だったのか。ここにあるようなベースラインアプローチで記載された内容が100%じゃなかったからなのか。
・中小企業が★４を全て実行できるか。特に運用面で可能か。

(2)構造的な限界

観点	内容
一般的かつベースライン評価	★3・★4は全企業共通で効果の高い対策を選んだものです。その会社固有のリスクを完全に分析する制度ではありません。経産省自身も、「本制度は、包括的なリスク分析に基づき共通して求められる対策を示すもの。将来的には、こうした企業もより自社のリスク分析に基づいた更なる対策の強化をしていくことが望ましい」としています。（出典：https://www.meti.go.jp/files/900017305.pdf ）
評価はサンプリング	★4でも、適用範囲にある全PC・全サーバ・全設定を一件ずつ検査するのではなく、対象をサンプリングして評価する予定
技術検証にも範囲がある	★4の技術検証は、VPN装置やルータ等に対する既知脆弱性を悪用した一般的な攻撃パターン等が中心です。全面的なペネトレーションテストではない
OTや製品そのものは対象外	工場制御システムや販売製品そのものまでSCS★4で安全性が保証されるわけでない
時点評価である	★3は1年、★4は3年の有効期間があります。★4も毎年の確認が想定されています。昨日安全だったシステムが、新しい脆弱性の発見で今日も安全とは限らない
★3は自己評価を含む	専門家の確認はありますが主体は自己評価。虚偽その他の不正が発覚した場合は★の取消し等の措置という事後的な担保しかない

(3)チェックシートの限界

※これは、この制度に限ったことではなく、チェックシートによるセキュリティ対策の限界についてです。

・たとえば、以下、セキュリティ対策として、とても大事な記載があります。

4-1-7-5	・重要な機密情報を扱うシステムは、ユーザ及び管理者ごとに必要最小限の権限を付与し、個人に権限が集中しない環境とすること。
4-5-1-9	・社外公開サーバ及び重要な機密情報を扱うサーバについて、それぞれ専用のネットワークセグメントに設置し、セグメント内外のアクセスを必要最小限に限定すること。

・でも、「必要最小限の権限」というのは、チェックする人の主観にならないでしょうか。たとえば、ベンダにリモートアクセスの権限を与えていて、ベンダが「必要だから」という理由で付与した権限というのは、必要最低限以上になっているときがあります。ときに、管理者権限が付与されていることがよくあります。でも、チェックした人は「必要最低限にしている」と考えて「〇」と判断することでしょう。

(4)ISMSを相互補完として活用する

・この制度が認めているように、ISMSの概念はとても大事だと思っています。
・この制度のサイト（https://www.meti.go.jp/press/2025/04/20250414002/20250414002.html）にも、「国際標準である「ISMS適合性評価制度」等とは相互補完的な制度として発展することを目指す。」と記載されています。
・ISMSはリスクベースアプローチだと思っていて、ようはどこにどんな情報があって、何を守るか。どこまで許容できるのか。そして、リスクベースの考え方で、リスクが高いところを中心に対策をする。
・セキュリティ対策は実効性があって初めて効果がでるもの。セキュリティと業務の利便性はトレードオフ。すべてを守ろうとして、ガチガチのセキュリティにして、本当に業務が成り立つか。機密性が高い重要資産はやりすぎるぐらいにガチガチにすべきだが、そうでないところとのメリハリがないと、特に中小企業では運用が持たないのではないか。

(5)制度の意義を理解して活用する

この制度の意義は、「攻撃を100%防ぐ」ことではなく、次の3点だと思われます。
①最低ラインを引き上げる
MFA、脆弱性対応、バックアップ、不正通信検知、ログ、インシデント対応など、「少なくともこれはやっておこう」という対策をサプライチェーン全体に要求できます。
②取引先の状況を外から判断しやすくする
③各社バラバラのチェックシートを減らせる
・発注者ごとに異なる要求事項を出し、受注者が何度も似たようなチェックシートに回答しているという無駄が減る
・ただし、各社ごとに追加のチェックシートは存在すると思われるので、ゼロにはならないでしょう。

なので、繰り返しですが、この制度の趣旨を再度理解してもらい、★を取得すればセキュリティ対策が万全というものではなく、上記の目的を満たすためのものだと考えて活用するのがいいと思います。

(6)どこまで広がる？

2026.8時点ではまだ始まってないので何とも言えないですが、広がった方がいいと思っています。懸念点としては、以下でしょうか。（個人的感想です）
・取適法（※注）との関係から、親会社が取引先に★取得を一方的に求め、必要な費用まで負担させることは難しい。追加費用が発生する場合には、価格や費用負担について協議する必要がある。
・親会社からすれば、従来からやっているチェックシートでも十分ではないか。わざわざ変えるメリットはないと考えるかも。そうであれば、進まない可能性がある。
・Lv2が★４相当になるのですが、自動車業界で言うと、自工会の場合は自己申告でした。Lv2を満たしている提出している企業もあるでしょう。それが、★４になると第三者の審査が入るので、（まず間違いなく）厳しくなる。であれば、「私の会社はL2を満たしている」と宣言しておく方がいいという気持ちになる可能性があるのではないか

※注：取適法
旧「下請法」が2026年1月から「中小受託取引適正化法（取適法）」に改称・改正されたもの。発注側企業がセキュリティ対策を求めること自体は禁止されていないが、それによって取引先に追加費用が生じる場合、価格交渉の申出には応じ、費用負担について適切に協議する必要がある

2.10 企業のアクション

(1)取らないとどうなる？

・SCSは法律上の強制制度ではありません。取得しなくても罰則はありません。
・とはいえ、制度自体は「発注者が取引先へ必要な★を提示し、取得状況を確認する」ことを想定しています。将来的に特定の取引で★取得が契約・調達条件となる可能性は十分あります。政府調達や重要インフラでの活用も検討されているようです。

(2)SCS取得に向けて現段階で企業がまずやること

❶2026年度
・IPAが公開している81/153項目のExcelを自社でチェックする
　→ 未達項目を洗い出す
・自社および取引先を★不要／★3／★4に分類

観点	確認する内容	リスクが高い場合
事業継続リスク	その取引先が停止すると、自社の重要業務や製品供給が止まるか	★4を検討
情報管理リスク	重要な設計情報、個人情報、認証情報などを預けているか	★4を検討

・必要なシステム・規程・運用を整備

❷2027年度以降
★3と★4の必要性に応じて取得を進める

(3)取引先にはどう要求する？

・一律に「全取引先、★4取得」とするのは適切ではないでしょう。
・取引先ごとに、どのレベルを求めるのか、★不要なのか、★3なのか、★4なのかを判断
・また、取得を依頼する場合、以下も整理する

①なぜその会社に★4が必要なのか
②いつまでに求めるのか
③取得できなかった場合どうするのか（取引継続の可否、猶予、代替措置）
④費用は誰が負担するのか　※「独禁法・取適法」の問題で、発注者が「★4を取れ。費用は全部そちらで」という運用を無条件にしてよいわけではなく、対策費用を踏まえて取引先と協議する必要があります。
など

・また、再委託先については原則として直接の取引先が判断します。

2.11 システムごとの具体的な対策

極度に管理面に寄った内容は省きました。そういう意味では、主に技術面の対策になると思います。

(1)サーバのセキュリティ対策

No.	SCSが求めるサーバの基本セキュリティ対策	具体的な内容
1	サーバ・OS等を資産管理する	・サーバ、仮想サーバ、ハイパーバイザの製造元・OS・台数を把握（★3：3-1-1-2）・情報機器、OS、ソフトウェアの導入・設置・NW接続・パッチ適用に関する管理ルールを策定（★3：3-1-1-3）・ルール遵守状況を年1回以上点検（3-1-1-4）・重要システムは設定情報も把握（★4：3-1-1-6）・把握した情報を年1回以上点検（3-1-1-7）
2	不要なユーザID・管理者IDを削除する	・IDの付与・変更・削除は申請・承認制（4-1-1-1、4-1-2-7）・原則として共有IDは禁止。共有時は利用者を特定可能にする（4-1-1-2、4-1-2-2）・退職者や一定期間未使用のIDを速やかに削除・無効化（4-1-1-3、4-1-2-6）・異動等で不要になったアクセス権も速やかに削除（4-1-1-4）
3	管理者権限・アクセス権を必要最小限にする	・すべてのサーバ・NW機器に管理者・責任者を設定（★3：4-1-2-1）・管理者権限を付与する人を限定（4-1-2-2）・管理者IDは必要最小限の権限（4-1-2-3）・開発環境の管理権限で本番環境を操作できないようにする（4-1-2-4）・誰が管理者IDを持つか把握（4-1-2-5）・重要システムのアクセス権はユーザ・管理者ごとに最小化し、特定個人への権限集中を避ける（★4：4-1-7-5）・アクセス権を年1回以上棚卸（★4：4-1-7-2）・重要システムではアクセス権の利用状況を監視（★4：4-1-7-6）
4	デフォルトパスワード・デフォルトIDを使用しない	・PC・サーバ等のデフォルトパスワードを変更するよう社内ルールを策定（★3：4-1-5-1）・サーバ等のデフォルトユーザIDは利用停止（★4：4-4-1-5）・利用停止できない場合はMFA等の強固な認証を使用
5	パスワード強度と多要素認証を確保する	・推測されやすい単語を禁止（★3：4-1-5-2）・MFAを使用する、または10回以上の認証失敗でロック → 8文字以上（4-1-5-3）・MFAも試行回数制限もできない → 英大文字・小文字・数字を含む10文字以上（4-1-5-3）・MFAのパスワードも8文字以上（4-1-3-4）・MFAは知識・所有・生体・その他（IP等）のうち異なる2種類以上（4-1-3-3）・重要機密情報を扱うクラウドサービスは常にMFA（★3：4-1-3-2）・★4では、管理者がインターネット経由でシステムへアクセスする場合も常にMFA（4-1-3-5）・パスワードの使い回し禁止、安全な保管、漏洩時の速やかな変更もルール化し周知（4-1-5-4～5、4-1-6-1～3）
6	不要なソフトウェアを削除・インストール制限する	・PC・サーバ等の許可されていないソフトウェアをすべて削除または無効化（★3：4-4-1-1）・または許可ソフト以外を自由にインストールできないようにする・OS・ソフトウェアの標準構成・設定ルールを定める（★4：4-4-1-6）
7	不要なサービス・プロトコルを停止する	・PCおよびサーバ上の不要なサービス・プロトコルを無効化（★4：4-4-1-4）
8	サーバの設定変更を管理する	・サーバ・NW機器の設定変更を行える人を業務上必要な者に限定（★3：4-1-2-8）・設定変更そのものを申請・承認制にする（★3：4-4-1-3）
9	脆弱性を管理し、OS・ミドルウェアへパッチを適用する	・脆弱性情報・脅威情報の収集～対応について担当部署の役割を設定（★4：3-2-1-1）・情報源・ツール・収集頻度を設定（3-2-1-2）・対応要否の判断基準・手順を設定（3-2-1-3）・管理機器の脆弱性残存状況を把握（3-2-1-4）・対応履歴を記録し月次で対応漏れを点検（3-2-1-5）・Critical／High、CVSS 7.0以上等はリリースから14日以内にアップデート（★3：4-4-4-2）・対象にはサーバOS・ミドルウェアを明記・14日以内に対応できない場合は、機能停止、ベンダ回避策、NW分離、不正通信の監視・遮断等を実施・可能なら自動アップデートを有効化（4-4-4-1）・原則サポート中のOS・ソフトを利用。サポート終了時は削除またはインターネットとの全通信を遮断（4-4-2-1、4-4-4-1）
10	マルウェア対策を導入・更新する	・NW接続するすべてのサーバにマルウェア対策ソフトを導入（★3：4-4-5-1）・サーバごとにスキャン範囲・頻度を定めて実行（4-4-5-2）・パターンファイルをベンダ推奨に従って更新（4-4-5-3）・メールサーバ等ではマルウェアチェックを実施（★4：4-4-5-5）
11	ファイアウォールを有効化し、ネットワークを分離する	・OSが対応していればすべてのサーバでソフトウェアFWを有効化（★4：4-5-1-8）・認証されていないインバウンド通信を遮断（★3：4-5-1-4）・FWルールを定め、不要なルールは速やかに削除・無効化（4-5-1-5～6）・インターネット経由でFWルールを変更する場合はMFAまたは信頼できるIPに限定（4-5-1-7）・社外公開サーバと重要情報を扱うサーバはそれぞれ専用セグメントに配置し、アクセスを必要最小限に限定（★4：4-5-1-9）
12	ログを取得・保管し、不正アクセスを監視する	・FWログ、Proxyログ、認証サーバログを6カ月保存（★4：4-4-3-1）・認証ログ：日時、接続元IP、ユーザID、成功／失敗を取得・認証サーバログを月1回以上監視し、不審な認証を検知（4-4-3-3）・ログ保存システムへのインターネット経由アクセスはMFA（4-4-3-2）・さらに★3で、社内外境界または端末においてインターネット→社内／社内→不正サーバの双方をリアルタイム検知・遮断（5-1-1-1）・NW機器のログ・アラートを分析しインシデントか判断（5-1-1-2）・異常時は速やかにアラートを発報し、速報レポートを通知（5-1-1-3）
13	データを安全に保管し、バックアップ・復元を行う	・バックアップの対象・頻度・保管期間を設定（★3：4-3-4-1）・重要機密情報は遠隔地バックアップ（4-3-4-2）・対象ごとにリストア手順書を作成（4-3-4-3）・重要システムは目標復旧時点まで復旧できるバックアップを保管し、目標復旧時間内に復元できることを確認（★4：7-1-1-2）・マルウェア被害で業務に支障が出るデータは、PCではなく相対的に安全な区域のサーバへ保存（★4：4-3-2-1）・重要な機密情報は暗号化するルールを策定・周知（★4：4-3-1-2）・サーバ廃棄・リース終了時は復元できない方法でデータを抹消。単なるフォーマットは不十分（★4：3-1-4-7）・抹消記録を保管（3-1-4-8）
14	サーバへの物理アクセスを制限する	・サーバ設置エリアへ入場できる人を限定（★4：4-1-8-1）・サーバ設置エリアを施錠。施錠できない場合は専用ラックを施錠（4-1-8-2）・鍵の管理者を定め安全に管理（4-1-8-3）・入退場日時・氏名を記録し、6カ月以上保存（4-1-8-4）

(2)PCのセキュリティ対策

No.	SCSが求めるサーバの基本セキュリティ対策	具体的な内容
No.	SCSが求めるPCの基本セキュリティ対策	具体的な内容
1	PC・OS・ソフトウェアを資産管理する	・PC／シンクライアントの製造元・OS・台数を把握（★3：3-1-1-1）・情報機器、OS、ソフトウェアの導入・設置・NW接続・パッチ適用に関する管理ルールを策定（3-1-1-3）・ルール遵守状況を年1回以上点検（3-1-1-4）・重要システムを構成する機器は設定情報も把握し、年1回以上点検（★4：3-1-1-6～7）
2	ユーザID・アクセス権を適切に管理する	・IDの付与・変更・削除を申請・承認制にする（★3：4-1-1-1）・原則として共有IDは禁止。共有時は利用者を特定可能にする（4-1-1-2）・退職者や一定期間未使用のIDを速やかに削除・無効化（4-1-1-3）・異動等で不要となった権限も速やかに削除（4-1-1-4）・PCへのアクセス権は必要な範囲に限定し、申請・承認・棚卸ルールを設定（4-1-7-1）・★4ではアクセス権を年1回以上棚卸（4-1-7-2）
3	PCログオンを保護し、アカウントロックを設定する	・ログオン失敗ごとに試行間隔を長くする、または少なくとも10回以上失敗すると端末をロック（★3：4-1-4-1）・設定できない場合は、より強度の高いパスワード等で代替・PCログオンには最低6文字以上のパスワードまたはPINを使用（4-1-4-2）
4	パスワード強度と多要素認証を確保する	・デフォルトパスワードを変更するよう社内ルールを策定（★3：4-1-5-1）・推測されやすい単語は禁止（4-1-5-2）・MFAまたは10回以上失敗でロック → 8文字以上（4-1-5-3）・どちらも利用できない → 英大文字・小文字・数字を含む10文字以上・パスワードの使い回し禁止（4-1-5-4）・安全に保管し、漏洩時は速やかに変更（4-1-6）・インターネット経由で社内環境へ接続する場合などは★4でMFA（4-1-3-5）
5	不要なソフトウェアを削除・インストール制限する	・利用を許可していないソフトをすべて削除または無効化、または許可外ソフトを自由にインストールできないようにする（★3：4-4-1-1）・★4では会社支給PCについて許可ソフトウェア一覧を作成（5-1-2-1）・インストール状況を年1回以上点検（5-1-2-2）
6	不要なサービス・プロトコルを停止し、安全な標準設定にする	・PC上の不要なサービス・プロトコルを無効化（★4：4-4-1-4）・デフォルトユーザIDを停止。停止できなければMFA等の強固な認証（4-4-1-5）・OS・ソフトウェアの標準構成・設定ルールを定める（4-4-1-6）
7	USB等の外部記録媒体を安全に利用する	・外部記録媒体を使用する端末ではAutoRun／AutoPlayを無効化（★3：4-4-1-2）・PC・外部記憶媒体・BYOD等の社内への持込みルールを策定（★4：4-1-9-1）・社外への持出しルールも策定（4-1-9-2）・ルールと遵守状況を年1回以上点検（4-1-9-3）
8	OS・ブラウザ・Office等へパッチを適用する	・ライセンスがあり、サポート中のOS・ソフトを利用（★3：4-4-4-1）・可能なら自動アップデートを有効化・Critical／High、CVSS 7.0以上等の更新はリリースから14日以内に適用（4-4-4-2）・PCの対象は明確にOS・ブラウザ・Officeソフトと指定・14日以内に対応できなければ、機能無効化、回避策、NW分離、通信監視・遮断等を実施・サポート切れ製品は原則利用せず、やむを得ない場合は更改計画を策定（★4：4-4-2-1）
9	マルウェア対策を導入する	・NW接続するすべてのPCにマルウェア対策ソフトを導入（★3：4-4-5-1）・PCごとにスキャン範囲・頻度を決めて実行（4-4-5-2）・パターンファイルをベンダ推奨に従い更新（4-4-5-3）・★4ではPC／Webゲートウェイで不正Webサイトへのアクセスを制限（4-4-5-4）・外部から受領したファイルはリアルタイムスキャンまたはサンドボックスで安全性確認（5-1-2-3）
10	PCのファイアウォールを有効化する	・OSが対応している限り、すべてのPCでソフトウェアファイアウォールを有効化（★4：4-5-1-8）
11	不正な通信をリアルタイムで検知・遮断する	・社内外NW境界または端末で、インターネット→社内、社内→不正サーバの双方の不正アクセスをリアルタイム検知・遮断（★3：5-1-1-1）・ログ・アラートからインシデントか判断（5-1-1-2）・異常時は速やかにアラートを発報し、速報レポートを通知（5-1-1-3）
12	PC内の重要データを暗号化し、安全な場所に保管する	・社外へ持ち出すPC内の機密情報を暗号化するルールを策定・周知（★4：4-3-1-1）・重要な機密情報も暗号化（4-3-1-2）・マルウェア被害で業務に支障が出るデータはPC内だけに置かず、社内NW／クラウド上の相対的に安全なサーバへ保管（4-3-2-1）
13	データをバックアップする	・バックアップの対象・頻度・保管期間を設定（★3：4-3-4-1）・重要な機密情報は遠隔地バックアップ（4-3-4-2）・対象ごとにリストア手順書を整備（4-3-4-3）
14	PCの持出し・返却・廃棄を安全に行う	・退職・任期満了時には会社支給PCを回収し、回収漏れを防ぐ手順を整備（★4：3-1-4-5）・PCの社外持出しルールを策定（4-1-9-2）・廃棄・リース終了時はデータを復元できないよう抹消（3-1-4-7）・単なるディスクフォーマットでは不十分と明記・データ抹消の記録を保管（3-1-4-8）

個人的には、PCが機密データを扱う場合には、以下も入れたい

No.	追加したいPC対策	具体的な対策・考え方	SCS資料の記載・補足
❶	EDRの導入	Microsoft Defender for Endpoint、CrowdStrike Falcon等を導入し、侵入後の振る舞い検知、端末隔離、調査などを行う	5-1-1-1：「社内外ネットワークの境界又は端末において、不正アクセスをリアルタイム検知・遮断する仕組みを導入」とある。ただしEDRの導入までは明記されていないため、AV等でも要件を満たすと判断される可能性がある
❷	クラウドへの自動バックアップ	OneDrive等を利用し、ユーザの手作業に頼らず自動的にクラウドへバックアップする。世代管理・バージョン履歴も利用する	4-3-4-1：バックアップの対象・取得頻度・保管期間を定めて取得することを要求。クラウドや自動バックアップの指定はないため、実運用ではOneDrive等による自動化を推奨したい
❸	リモートワイプ	持ち出しPCを紛失・盗難した場合、Intune等から遠隔で端末データを消去できるようにする	PCの持出し管理や情報保護に関する要求はあるが、リモートワイプそのものを要求する項目はない。特に社外持出しPCでは設定しておきたい
❹	ディスク暗号化	持ち出しPCではBitLocker、FileVault等でディスク全体を暗号化する。必要に応じて重要ファイルも個別暗号化する	4-3-1-1：社外へ持ち出す情報機器等の機密情報を暗号化するルールを定め周知。4-3-1-2：重要な機密情報を暗号化するルールを定め周知。BitLocker等の具体的な暗号化方式までは指定されていない
❺	USBポート等のデバイス制御	重要情報を扱うPCでは、USBメモリ等への書込み禁止やデバイス利用制限により、情報持出しを技術的に防ぐ	4-4-1-2：外部記録媒体利用時のAutoRun／AutoPlay無効化。4-1-9：PCや外部記憶媒体の持込み・持出しルールを規定。ただし、USBへの書込み禁止やUSBポート無効化等の技術的制御までは明記されていない
❻	ローカル管理者権限の制限	一般利用者にはOSのローカル管理者権限を付与せず、通常は一般ユーザー権限で利用する。必要な場合のみ管理者権限を付与する	4-1-2では管理者権限の付与対象を限定し、必要最小限の権限とすることを要求。4-4-1-1では許可外ソフトを自由にインストールできないようにすることを要求している。ただし、PCの一般利用者からローカル管理者権限を外すこと自体は明記されていない

(3)ネットワーク機器

No.	SCSが求めるネットワーク機器の基本セキュリティ対策	具体的な内容
1	ネットワーク・ネットワーク機器を資産管理する	・ネットワークの所在地・用途を把握（★3：3-1-2-1）・ネットワーク機器の製造元・モデル・保守事業者を把握（★3：3-1-2-2）・★4ではネットワーク図を作成（3-1-2-3）・ネットワーク図を年1回以上点検（3-1-2-4）
2	管理者・責任者を明確にする	・すべてのサーバ・ネットワーク機器にシステム管理者と責任者を設定（★3：4-1-2-1）・誰が管理者IDを保有しているか把握（4-1-2-5）
3	管理者ID・管理者権限を必要最小限にする	・管理者権限を付与する人を限定（★3：4-1-2-2）・原則として管理者IDを共有しない。共有する場合は利用者を特定可能にする・管理者IDには必要最小限の権限のみ付与（4-1-2-3）・不要になった管理者IDは速やかに削除・無効化（4-1-2-6）・IDの付与・変更・削除は申請・承認制（4-1-2-7）
4	管理パスワードを適切に設定する	・すべてのFW・FW機能を持つネットワーク機器・ルータについて、デフォルト管理パスワードを強固かつ一意なものへ変更するか、リモートアクセスを完全に無効化（★3：4-5-1-1）・パスワード変更手順を定める（4-5-1-2）・認証は4-1-5のパスワード基準を満たす（4-5-1-3）
5	パスワード強度・MFAを確保する	・推測されやすいパスワードは禁止（★3：4-1-5）・MFAまたは10回以上失敗でロック → 8文字以上・いずれも実施できない → 英大文字・小文字・数字を含む10文字以上・パスワードを使い回さない・★4では、管理者がインターネット経由でシステムへアクセスする場合は常にMFA（4-1-3-5）
6	ネットワーク機器の設定変更を管理する	・設定変更を行える権限を業務上必要な人だけに限定（★3：4-1-2-8）・ネットワーク機器の設定変更を申請・承認制にする（★3：4-4-1-3）
7	OS・ファームウェアの脆弱性を管理する	・脆弱性情報の収集担当・情報源・頻度・対応基準を設定（★4：3-2-1-1～3）・管理対象機器の残存脆弱性を把握（3-2-1-4）・対応履歴を記録し月次で対応漏れを点検（3-2-1-5）
8	OS・ファームウェアをアップデートする	・ライセンスがありサポート中の機器・ソフトを利用（★3：4-4-4-1）・サポート終了時は削除するかインターネットとの全通信を遮断・可能なら自動Updateを有効化・インターネット境界のネットワーク機器は、Critical／High、CVSS 7.0以上等の更新をリリースから14日以内に適用（4-4-4-2）・適用できない場合は機能停止、回避策、NW分離、不正通信監視・遮断等を実施
9	重大な脆弱性を残さない	・★4では、インターネット境界に設置するネットワーク機器のOS・ファームウェアにCVSS基本値7.0以上の脆弱性が存在しないこと（4-4-4-3）
10	ファイアウォールで不要な通信を遮断する	・すべてのFWについて認証されていないインバウンド通信を遮断（★3：4-5-1-4）・インバウンド通信のFWルールを定める（4-5-1-5）・不要になったFWルールは速やかに削除または無効化（4-5-1-6）
11	FWルールのリモート変更を保護する	・インターネット経由でFWルールを変更する場合は、MFAを使用するか、信頼できるIPアドレスだけにアクセスを制限（★3：4-5-1-7）
12	ネットワークを分離し、アクセスを最小化する	・★4では、社外公開サーバと重要機密情報を扱うサーバを、それぞれ専用ネットワークセグメントに配置（4-5-1-9）・セグメント内外のアクセスを必要最小限に限定
13	ネットワーク機器のログを取得・保存する	・FWログを6カ月保存（★4：4-4-3-1）・対象には取引先接続用の閉域網入口に設置されたFWも含む・取得項目：日時、送信元IP、送信先IP ・Proxyログも6カ月保存：日時、リクエスト元IP、URL
14	不正通信をリアルタイム検知・遮断する	・社内外ネットワーク境界または端末で、インターネット→社内と社内→不正サーバの双方について、不正アクセスをリアルタイム検知・遮断（★3：5-1-1-1）・ネットワーク機器のログ・アラートを分析し、インシデントか判断（5-1-1-2）・異常時には速やかにアラートを発報し、インシデント速報レポートを通知（5-1-1-3）

個人的な意見ではあるが、必要に応じてであるが、以下も入れたいと思っている。

No.	追加したい対策	具体的な対策例	SCS資料の記載・補足
❶	不要なポート・サービスの停止	・使用しないポートを閉じる・不要な管理サービスを停止・Telnet/HTTPではなくSSH/HTTPSを利用	SCSではFWルールによる通信制御は求めているが、ネットワーク機器自体の不要サービス停止までは具体的に規定していない
❷	管理アクセスの安全化	・管理画面への接続元IPを制限・管理用NW/VLANを分離	4-5-1-7：インターネット経由のFWルール変更時はMFAまたは信頼できるIPからの接続に限定。ただし管理NW分離等までは明記されていない
❸	UTM／NGFWによる通信防御	・IPS/IDS：攻撃通信を検知・遮断・URLフィルタリング：危険サイト、フィッシングサイト等を遮断・ゲートウェイAV：通信中のマルウェアを検査・遮断・アプリケーションコントロール：P2P、未許可クラウド等を制御・DNSフィルタリング：悪性ドメインへの接続を遮断・必要に応じてSSLインスペクション	5-1-1-1：「インターネット→社内」と「社内→不正なサーバ」の双方について、不正アクセスをリアルタイム検知・遮断する仕組みを要求。ただしUTM/NGFWや各機能の具体的な指定はない

(4)クラウド

No.	SCSが求めるクラウドサービスの基本セキュリティ対策	具体的な内容
1	利用するクラウドサービスを把握・管理する	・クラウドサービス提供者を含め、自社資産が接続している外部のシステムを把握する仕組みを整備（★3：2-1-1-1）・把握した内容を年1回以上点検（2-1-1-2）
2	クラウドサービス選定時にセキュリティを確認する	・外部情報サービス利用時のセキュリティ要件を事前に定める（★3：3-1-3-1）・利用開始時に、そのサービスが要件を満たしているか確認する
3	クラウド事業者と情報の取扱いを取り決める	・外部情報サービス提供事業者と機密情報の取扱いについて合意（★3：3-1-3-2）・機密情報の定義、利用制限、保管方法、複製可否、第三者提供、返還・廃棄等を取り決める（2-1-2-1）
4	クラウド事業者のセキュリティ対策状況を確認する	・重要な機密情報を提供する、事業継続上重要などの条件に該当する事業者は、年1回以上セキュリティ対策状況を確認（★4：2-1-3-1）・SCS等の認証状況確認、チェックシート、訪問点検等を例示
5	ユーザID・管理者IDを適切に管理する	・IDの付与・変更・削除は申請・承認制（★3：4-1-1-1等）・原則共有IDを使用しない・退職者や一定期間未使用のIDは速やかに削除・無効化・異動等で不要になったアクセス権も速やかに削除
6	アクセス権を必要最小限にする	・アクセス権の付与・変更・削除、棚卸等のルールを定める（★3：4-1-7-1）・年1回以上アクセス権を棚卸（★4：4-1-7-2）・重要情報を扱うシステムはユーザ・管理者ごとに必要最小限の権限を付与し、特定個人への権限集中を避ける（4-1-7-5）・アクセス権の利用状況を監視（4-1-7-6）
7	重要なクラウドサービスではMFAを必須にする	・重要な機密情報を扱うクラウドサービスでは、ユーザ・管理者とも常にMFA（★3：4-1-3-2）・MFAは知識・所有・生体・その他（IP等）から異なる2種類以上（4-1-3-3）・MFAで使用するパスワードは8文字以上（4-1-3-4）
8	パスワードを適切に管理する	・クラウドサービスのデフォルトパスワードを変更するルールを策定（★3：4-1-5-1）・推測しやすい単語は禁止・MFAまたは10回以上失敗でロックする場合は8文字以上・いずれもできない場合は英大文字・小文字・数字を含む10文字以上・サービス間での使い回し禁止、漏洩時は速やかに変更
9	クラウド上の重要データを適切に保護する	・重要な機密情報を暗号化するルールを策定・周知（★4：4-3-1-2）・重要情報について管理者、部署、保管場所、保管期限、開示先等を把握（★3：3-1-4-3）・社外とのファイル共有は信頼できる相手に限定し、ファイル送信時は送信履歴を残す（★4：4-3-3-1）
10	バックアップと復元手順を整備する	・バックアップの対象・頻度・保管期間を定める（★3：4-3-4-1）・重要な機密情報は遠隔地バックアップ（4-3-4-2）・バックアップ対象ごとにリストア手順書を整備（4-3-4-3）・重要システムはRPOまで復旧できるバックアップを保管し、RTO内で復元できることを確認（★4：7-1-1-2）
11	クラウドサービスのログを取得・保存する	・ログ取得・保存要件はクラウドサービスも対象（★4：4-4-3-1）・FW、Proxy、認証ログ等は原則6カ月保存・クラウドの仕様上取得できない場合は、別機能等を使って相当するログを取得・保存・認証ログは月1回以上監視して不審な認証試行を検知（4-4-3-3）
12	インシデント発生時のクラウド事業者との役割を決める	・クラウド事業者等と、インシデント発生時の自社と相手側の役割・責任を事前に定める（★3：2-1-4-1）・社内外の連絡先・報告ルートも定める（6-1-1-2）
13	契約終了時にデータ・アクセス権を確実に削除する	・契約終了時にクラウド事業者等から機密情報とアクセス権が回収・破棄されていることを確認する手順を整備（★4：2-1-5-1）
14	クラウド障害・サイバー攻撃から復旧できるようにする	・重要システムについて目標復旧レベルを定めて復旧対策を整備（★3：7-1-1-1）・例として予備機やクラウド環境による待機系の整備も記載

クラウドで機密情報を大量に管理している場合は、以下も入れたい

No.	追加したい対策	具体的な対策例	SCS資料の記載・補足
❶	CSPMによる設定不備の監視	・公開ストレージ・過剰なIAM権限・暗号化無効・危険なFW/セキュリティグループ設定等を継続監視	SCSでは設定情報の把握やアクセス権管理は要求されるが、CSPM等によるクラウド設定の継続的・自動的な監視までは明記されていない
❷	クラウドアカウント・IAMの強化	・root/特権アカウントの日常利用禁止・最小権限・MFA必須・アクセスキーの発行を最小化・長期間未使用キーの削除	4-1-1～4-1-3、4-1-7でID・権限・MFAは規定されている。ただし、クラウドのrootアカウントやアクセスキー等の具体的な管理方法までは明記されていない
❸	クラウドログの集中管理・監視	・AWS CloudTrail、Azure Activity Log等を有効化・管理操作・設定変更・認証ログを集中保存・SIEM等で異常を検知	SCSではクラウドも含めたログ取得・保存を要求しているが、CloudTrail等の具体機能やSIEMによる相関分析までは指定されていない
❹	クラウドバックアップの分離・世代管理	・自動バックアップ・世代管理・別アカウント／別リージョンへの保管・削除防止設定	4-3-4で対象・頻度・保管期間、遠隔地バックアップ等を要求。ただし、クラウドアカウント分離やイミュータブルバックアップ等までは指定されていない
❺	クラウドセキュリティ評価の活用	・ISMAP登録状況・ISO 27001、SOC 2等の第三者評価を確認・重要度に応じてサービス選定基準を設定	3-1-3-1 で外部情報サービスの管理として、外部サービスのセキュリティ要件設定・確認を要求しているが、やや曖昧な気がする。ISO27001は必須ではないか。

→診断は結構大変です。AIを活用しましょう！やりかたに関する情報はこちら。

3.ISMS

3.1 ISMSとは

(1)概要

・ISMS（Information Security Management System、情報セキュリティマネジメントシステム）は、「会社の大切な情報を守るためのルールや体制を作り、それを継続的に改善していく仕組み」です。
・ISMSでは、特定のセキュリティ製品を導入すればよい、という考え方はしません。組織が持つ情報についてリスクを洗い出し、そのリスクに応じて適切な対策を決め、実施し、定期的に見直します。
・参考資料　https://isms.jp/doc/ISMS.pdf

(2)情報セキュリティの3要素

・ISMSを理解するときに重要なのが、頭文字を取って「CIA」と呼ばれる情報セキュリティの３つの基本です。

要素	意味
機密性（Confidentiality）	許可された人だけが情報を利用できること
完全性（Integrity）	情報が勝手に改ざん・破壊されていないこと
可用性（Availability）	必要なときに情報を利用できること

・ISMSでは、この３つのた観点から情報に対するリスクを考えます。

(3)ISMSとISO/IEC 27001の関係

・ISO/IEC 27001は、このISMSを確立・実施・維持し、継続的に改善するための要求事項を定めた国際規格です。
・

ISMS	情報セキュリティを管理するための「仕組み」
ISO/IEC 27001	ISMSを構築・運用するときの「要求事項を定めた国際規格」

(4)ISMSで重要なのは「リスクマネジメント」

・すべての情報に対して、同じレベルのセキュリティ対策を行うわけではありません。
・まず、以下を確認します。

　- どのような情報を持っているか
　- どのような脅威があるか
　- どの程度の被害が発生する可能性があるか

・そのうえで、リスクの大きさに応じた対策を行います。

(5) ISMSは一度作れば終わりではない

・情報セキュリティを取り巻く環境は常に変化しています。新しいシステムを導入したり、クラウドサービスを利用したり、テレワークを開始したりすれば、新しいリスクが生まれる可能性があります。
・そのためISMSでは、PDCAを繰り返します。

 - Plan：計画する
 - Do：実施する
 - Check：状況を確認する
 - Act：改善する

・つまり、重要なのは「完璧なセキュリティ対策を一度作ること」ではなく、継続的にセキュリティを改善していくことです。
・ISO/IEC 27001も、ISMSの継続的な改善を要求しています。

3.2 ISMS認証とは

(1)概要

・「自社のISMSがISO/IEC 27001の要求事項を満たしていることを第三者に確認してもらう」仕組みがISMS認証です。
・第三者である認証機関が組織のISMSを審査し、基準を満たしていると判断されれば認証されます。

(2)ISMS認証取得の流れ

ISMS認証を取得する場合、一般的には次のような流れで進めます。

- ISMSの適用範囲を決める
- 情報資産を洗い出す
- リスクを分析・評価する
- 必要なセキュリティ対策を決める
- 社内ルールや手順を整備する
- ISMSを実際に運用する
- 内部監査を実施する
- マネジメントレビューを行う
- 認証機関による審査を受ける
- 認証取得後も継続的に改善する

(3)ISMSとPマークの違い

「プライバシーマーク（Pマーク）」は、目的が異なります。

項目	ISMS	Pマーク
主な対象	組織が扱う情報全般	個人情報
目的	情報セキュリティの管理	個人情報の適切な取扱い
代表的な基準	ISO/IEC 27001、JIS Q 27001	JIS Q 15001
考え方	リスクに応じた情報セキュリティ管理	個人情報保護を中心とした管理