連載「SCS専門家の資料を全部読む」の第5回です。
前回は、適用範囲に何を含め、何を外せるかを読みました。そこで後回しにしたのが、クラウドと、親会社が提供する共通のネットワークです。組織のIT基盤を構成していれば、どちらも適用範囲に入ります。けれど、組織が自分で全部を管理できるわけではありません。
制度はこれを「他組織との間で対策に係る責任を共有するもの」と呼んでいます。利用者として自分でやることと、提供者の対策を確かめることの2つに分けて扱う、という考え方です。今回は解説書の3.2.1と3.3.4を中心に読み、提供者の報告書が手に入らない架空のJ社で試します。
- 組織のIT基盤を構成するクラウドと親会社の共通ネットワークは、適用範囲に入る。契約の有無は問われない
- 利用者として行う対策の例（ID・認証・バックアップ・監視・インシデント対応）
- 提供者に確かめる事項の例8件と、そのうち4件が★4だけの要求事項であること
- 確かめ方の例（サービス仕様、SOC2 Type 2報告書、開示された報告書、個別の照会、シートの共有、登録の確認）
- 架空のJ社：SOC2報告書がない、親会社の管理だから除く、をどう読むか
- 資料が答えていないところ
クラウドと共通ネットワークは範囲に入る。ただし責任を分け合う
結論から書きます。組織のIT基盤を構成するクラウドや、親会社が提供する企業グループ共通のネットワークは、適用範囲のIT基盤に含まれます（解説書3.2.1）。解説書はこれを、IT基盤を構成するが「他組織との間で対策に係る責任を共有するもの」と書いています。
条件が付いている点は押さえておきたいところです。解説書の第3章の冒頭は、こうしたクラウドや共通ネットワークが適用範囲に「含まれる場合がある」という書き方でした。使っているサービスがすべて無条件に入るのではなく、組織のIT基盤を構成し、責任を共有するものが入る、と読むのが正確だと思います。
前回読んだIT基盤の中身は3つでした。サーバ群、端末、そしてこの「責任を共有するもの」です。範囲の外に置くものではなく、範囲の中で扱い方が違うもの、と読むのが素直だと思います。
制度構築方針の2.2.2にも、同じ項目があります。註には、責任共有モデルに基づいて、自社で対策を実装するか、提供者の対策状況を確かめる必要がある、とありました。確かめ方の例は、ISMAP登録の有無やSOC2レポートの確認です。責任共有モデルは、提供する事業者と利用者が、サービスのセキュリティの責任を共有し合う考え方を指します。
範囲に入るかどうかに、契約の名義は関係ありません。制度構築方針（案）の意見公募では、自社が直接契約していないクラウドも対象かを問う意見がありました。回答は、契約の有無にかかわらず、IT基盤を構成し、他社と対策の責任を共有するものは適用範囲に含める必要がある、というものです。同じ意見公募では、SaaSもクラウドサービスに含める想定だ、とも答えていました。どちらも「案」の段階の回答です。
管理できるところは全部、できないところは確かめる
解説書3.2.1は、範囲内のもののうち「自ら管理可能である対象」について、該当する段階の要求事項・評価基準を「すべて満たさなければならない」としています。
そのうえで、こうも書いています。利用者から提供者へ、詳細な対策状況の確認や、追加の対策を頼むのは、一般に難しい。だから、次の2つを行う必要がある、という流れです。
- 利用者の立場として行う必要のある対策の実施
- 外部情報サービス等で実施される対策の確認
正直、この2つに分けた書き方は分かりやすいと感じました。管理できるところは基準どおりに自分でやる。管理できないところは、相手がやっているかを確かめる。線を引く基準が「自分で管理できるか」になっています。
利用者として行う対策：段階に応じて、少なくともこれだけ
1つ目の、利用者として行う対策から見ます。解説書は、サービスの類型で詳細は異なるとしつつ、登録を目指す段階（★3か★4）に応じて、少なくとも次を含めて実施することが求められる、としています。
| 区分 | 解説書が挙げる要求事項 | ★3 | ★4 |
|---|---|---|---|
| 不正アクセスへの対策 | ID管理（4-1-1 ユーザID、4-1-2 管理者ID） | ○ | ○ |
| ユーザ認証（4-1-3 認証の強度・実装方法、4-1-4 ロック制御） | ○ | ○ | |
| 強固なパスワード（4-1-5） | ○ | ○ | |
| 不正アクセスの検知及び対応 | 保管データの保護（4-3-1 データの暗号化） | － | ○ |
| バックアップの取得（4-3-4） | ○ | ○ | |
| 継続的な監視（5-1-1 ネットワーク接続・データの監視、5-1-2 機器・ソフトウェアの挙動監視） | 5-1-1のみ | ○ | |
| インシデント対応手順（6-1-1） | ○ | ○ |
出典：解説書（SCS-620）3.2.1。★の別は要求事項・評価基準（SCS-400 Ver.1.1）の要求事項ごとの欄。4-1-4は、要求事項としてはパソコン・スマートデバイスのロック制御ですが、ここでは解説書3.2.1の括りに合わせています
★の別を並べると、4-3-1と5-1-2は★4だけの要求事項でした。解説書の「段階に応じて」は、この差を指していると読めます。★3なら、残りの8件が利用者側の対策の目安になりそうです。
クラウドで言えば、IDを誰に発行し、いつ消すか。多要素認証を使うか。データを自分でバックアップするか。どれも、サービスの機能を使うかどうかを決めるのは利用者です。提供者が機能を用意していても、使うと決めて設定するのは利用者側の仕事だ、と筆者は読みました。
提供者に確かめる事項の例は8件。うち4件は★4だけ
2つ目の、提供者の対策の確認です。解説書3.3.4は、前回のA社の事例を使い、Y社（IaaS/PaaS）やZ社（SaaS）に遵守状況を確かめる要求事項の例を挙げています。
| 区分 | 要求事項 | ★3 | ★4 |
|---|---|---|---|
| 物理セキュリティの管理 | 4-1-8 サーバの設置エリアへの入退室の管理・記録 | － | ○ |
| 4-1-9 可搬媒体の持込み・持出しの制限 | － | ○ | |
| 識別・認証・アクセス制御の機能 | 4-1-2 管理者IDの発行・変更・削除の手続 | ○ | ○ |
| 4-1-3 認証の強度・実装方法の決定 | ○ | ○ | |
| 提供に関連するソフトウェアの管理 | 3-2-1 脆弱性の管理体制・管理プロセス | － | ○ |
| 4-4-1 安全な構成の確立・維持 | ○ | ○ | |
| 4-4-2 サポート期限の切れたOS・ソフトウェアの利用停止・更改 | － | ○ | |
| 4-4-4 パッチ・アップデートの適用手続 | ○ | ○ |
出典：解説書（SCS-620）3.3.4。★の別はSCS-400 Ver.1.1の要求事項ごとの欄
8件のうち4件（4-1-8・4-1-9・3-2-1・4-4-2）は、★4だけの要求事項です。前回、C事業所を外す理由に★4だけの4-4-2が使われていた、と書きました。ここでも同じことが起きています。
利用者側の対策と違い、3.3.4には「段階に応じて」の一言がありません。あるのは脚注18の、確認対象をどこまでとするかはサービスの類型等により異なる、という文だけです。★3の登録で、★4だけの4件まで提供者に確かめるのか。資料からは決めきれませんでした。筆者は、★3なら少なくとも★3の欄にもある4件が確かめる候補になる、と読んでいます。ただ、3.3.4は確かめる対象を段階ごとに分けておらず、脚注18は範囲が類型で変わるとしています。★3ならこの4件だけでよい、とまでは資料から言えません。
書き方の強さにも差があります。3.2.1は、提供者の対策の確認を「必要である」と書きます。3.3.4は、例の要求事項を確かめることが「考えられる」です。確かめること自体は必要で、何をどこまで確かめるかは例示、と読むのがよさそうです。
確かめ方は1つではない
確かめる手段も、資料ごとに例が少しずつ違います。並べると次のとおりです。
| 箇所 | 確かめ方の例 |
|---|---|
| 制度構築方針2.2.2の註 | ISMAP登録の有無、SOC2レポート |
| 解説書3.2.1 | 認証の取得状況、SOC2報告書、サービス仕様 |
| 解説書3.3.4 | サービス仕様、SOC2 Type 2報告書、事業者等が開示する報告書、事業者への個別の照会 |
| 解説書 別紙3-1-3-1 | 認証の取得有無、SOC2報告書。機密情報を扱うクラウドにはISMAP登録サービスの利用も有効 |
| 解説書3.2.1（親会社の共通ネットワーク） | 提供者からアセスメントシート等を共有してもらう、しかるべき段階の★3・★4の登録を確認する |
SOC2は、米国公認会計士協会（AICPA）が定める、委託会社の内部統制やサイバーセキュリティについての内部統制の保証の報告書です（解説書の脚注19）。Type 2は、一定の期間（通常は6か月以上）にわたって、管理策が持続的に実装されていることを示す評価とされています。「Type 2」と型まで書いているのは3.3.4だけでした。
並べて分かるのは、SOC2報告書は手段の1つにすぎない、ということです。サービス仕様の確認も、個別の照会も、同じ列に並んでいます。どれか1つが必須、という書き方の箇所はありませんでした。逆に、どれか1つを使えば足りる、という意味でもありません。定めた要件を満たしているかを、サービスの中身に照らして確かめることが求められています。
確かめる基準そのものは、別紙の3-1-3-1（要件を定め、利用時に満たしているか確かめる）と3-1-3-2（機密情報の扱いの合意。難しければ公開情報等で確かめる）です。意味は★3連載の第3回で読みました。適合基準を全件で並べるのは第11回です。
親会社の共通ネットワークは、シートか登録で確かめる
共通ネットワークも、クラウドと「同様の対応が求められる」と解説書3.2.1は書いています。確かめ方の例は2つです。提供者（親会社等）からアセスメントシート等を共有してもらう。または、★3か★4のうち、しかるべき段階の登録を親会社が持っているかを確かめる。どちらも「有効である」という書き方です。
具体的な姿は、解説書3.3.2（4）の子会社B社の例にあります。B社が単体で登録するなら、親会社A社の管理部門にアセスメントシート等を送って回収し、共通のIT基盤が基準に合っているかを確かめる必要がある、とされています。さらにB社は、A社を通じて、データセンターのX社やクラウドのY社・Z社の対策状況を確かめます。
子会社から見ると、確かめる先が二重になっています。親会社そのものと、親会社の先の提供者です。子会社の目線では、提供者を確かめる道筋も親会社を経由する形になる、と読めました。
事例：提供者の報告書が手に入らないJ社（架空）
ここからは架空の場面です。報告書が手に入らないとき、資料のどこが答えになるかを試します。
状況（架空）
J社は、計測機器メーカーの販売子会社で、従業員は約45名です。取引先から★3の登録を求められ、自己評価を進めています。
- 拠点間のネットワークとインターネットの出口は、親会社が提供している
- メールは、親会社が契約したSaaSを、親会社から割り当てられたIDで使っている
- 受発注は、小さなソフト会社が提供する販売管理のSaaSを、J社が自分で契約して使っている。取引先の価格表と注文の履歴が入っていて、J社はこれを機密情報として扱っている
- 親会社は、SCS評価制度の登録を持っていない
J社の記入には、次のように書かれていました。適用範囲の説明（シートの質問2）は「本社事務所のPCとファイルサーバ、販売管理のSaaS。親会社が提供するネットワークとメールは、親会社の管理のため除く」。評価基準3-1-3-1の根拠欄は「販売管理SaaSの提供者にSOC2報告書を依頼したが、作成していないとの回答。確認できていない」で、判定は「未実施」です。★3確認責任者として、この記入を読みます。
資料の文
- 解説書3.2.1：クラウドや親会社の共通ネットワークは、責任を共有するIT基盤として範囲に含む。自ら管理可能な対象は基準をすべて満たす。利用者側の対策を行い、提供者の対策を確かめる
- 意見公募の回答：契約の有無にかかわらず、責任を共有するものは範囲に含める
- 解説書3.2.1・3.3.4：確かめ方は、認証の取得状況、SOC2報告書、サービス仕様、開示された報告書、個別の照会。共通ネットワークは、シートの共有か登録の確認
- 解説書3.3.2（4）：子会社は、親会社の管理部門とのシートのやりとり等で、共通のIT基盤が基準に合っているかを確かめる
読み方
先に引っかかるのは、適用範囲の説明のほうです。親会社のネットワークとメールを「親会社の管理だから除く」としています。けれど資料では、J社のIT基盤を構成しているなら、どちらも責任を共有するものとして範囲に入ります。J社の社員が日々の業務で使っている以上、構成していると見るのが自然でしょう。メールは親会社の契約ですが、契約の名義は問われません。この回答は、資料と食い違っている可能性が高いと読みます。
範囲に入れると、J社の仕事は2つに分かれます。メールのIDの申請や、パスワードの決まりなど、J社が自分で決めて運用している部分は、基準どおりに対策する。親会社が管理している部分は、親会社からシートを共有してもらうなどして確かめる。親会社は登録を持っていないので、登録の確認という道は使えません。
販売管理のSaaSは、範囲に入れてあります。問題は根拠欄の「SOC2報告書がないので確認できていない」です。資料では、SOC2報告書は確かめ方の1つでした。サービス仕様や、提供者への個別の照会でも確かめられます。報告書がないことは、そのまま「確かめられない」ことを意味しません。
もう1つ気になるのは、何を確かめようとしたのかが書かれていない点です。3-1-3-1の順番は、先に自社の要件を定め、それをサービスが満たすか確かめる、でした。要件が決まっていれば、たとえば多要素認証が使えるか、データの保存先はどこか、といった項目ごとに、仕様や照会で確かめる道があります。
確認者として返すなら、例えば次の3点を聞くことになりそうです。
- 親会社のネットワークとメールのうち、J社が自分で決めて運用している部分はどこか
- 親会社から、共通のネットワークとメールの対策状況を示すもの（シート等）を受け取れるか
- 販売管理のSaaSに求める要件を定めた文書の名前と、要件ごとに何で確かめたか（または確かめる予定か）
確認者は、記入の妥当性を確かめ、必要に応じて助言します（ガイド4.1）。ただ、記入した情報の真実性に責任を負うのはJ社です。研修実施基準の科目の例も、改善に向けた助言はしても、対策の設計・実装を代行したり指示したりしてはならない、としています（SCS-330B 附属書B）。
資料が答えていないところ
- どの手段でも確かめられない項目が残ったとき、どう判断するか。仕様や照会のほかに、3-1-3-2には、合意が難しければ公開情報や説明書で機密情報の扱いを確かめる道も示されています。それらを使っても残った項目を、不適合とするのか、ほかの手当てで足りるのかは、書かれていません
- 「しかるべき段階の登録」の意味。子会社が★4を目指し、親会社が★3の登録だけを持つ場合に足りるのか、文からは読み取れません
- 確かめ直す時期。事例の文は「サービス調達時」、3-1-3-1は「利用時」です。★3の2-1-1-2には、取引先が管理・提供するシステムの把握情報を年1回以上点検する基準があります。ただ、提供者の対策を確かめ直す頻度は、3-1-3には書かれていませんでした
資料どうしで、少しずれているところ
今回も、同じことを違う言葉で書いている箇所がありました。
| 箇所 | 書き方 | 気になった点 |
|---|---|---|
| 解説書3.2.1と3.3.4 | 利用者側の対策は「段階に応じて」。提供者に確かめる例には段階の一言がない | 3.3.4の8件のうち4件は★4だけの要求事項 |
| 解説書3.2.1と3.3.4 | 確かめることは「必要である」。例の要求事項を確かめることは「考えられる」 | 必要なのは確かめること。何を確かめるかは例示と読める |
| 方針2.2.2・別紙と、解説書の本文 | ISMAPは方針と別紙3-1-3-1にあり、本文の3.2.1・3.3.4にはない | 本文では、SOC2報告書が確かめ方の1つとして繰り返し挙がる |
| 解説書3.3.4と3.2.1 | 3.3.4は「SOC2 Type 2報告書」、3.2.1は「SOC2報告書」 | 型まで書くのは3.3.4だけ |
| 解説書の事例と別紙3-1-3-1 | 事例は「サービス調達時」、評価基準は「利用時」に確かめる書き方 | 食い違いではなく、調達時と利用時の両方で確かめることはあり得る。確かめ直す頻度は、どちらにも書かれていない |
1行目は、前回の4-4-2と同じ型の引っかかりです。解説書の事例は★3と★4をまとめて書いていて、★の別は要求事項の表で確かめるしかありません。読むときは、番号ごとに★の欄を見る癖をつけておくほうが安全だと感じました。
筆者の立場から：線は「管理できるか」で引かれる
この3回で、線の引き方が少しずつ見えてきました。第3回の取得単位では、線は組織で引かれます。第4回の適用範囲では、端末の持ち主で引かれていました。今回は、範囲の内側で、自分で管理できるかどうかで線を引いています。
管理できるところは、基準をすべて満たす。管理できないところは、相手がやっていることを確かめる。そして確かめた中身を、文書の名前とともに残す。責任を共有するといっても、任せきりにしてよいという意味ではない、と筆者は読んでいます。
正直、最初は「SOC2報告書を集める話」だと思って読み始めました。けれど資料は、報告書がなくても仕様や照会で確かめる道を並べていました。求められているのは特定の書類ではなく、何を求め、何で確かめたかを説明できること。そう読むと、報告書が手に入らない小さな組織にも、道は残されていると考えます。
なお、筆者には監査を受けた経験も、した経験もありません。この記事も、専門家の資料を学習者として読んだ記録です。
注意点
SOC2報告書があっても、利用者側の対策は残る
報告書で確かめられるのは、提供者側の対策です。IDの発行や削除、多要素認証を使うかどうか、自分でのバックアップは、利用者側の仕事として残ります（前述の通り、解説書3.2.1は2つを分けて求めています）。報告書を受け取ったことだけで、クラウドの部分が済んだと考えないほうがよさそうです。
「親会社の管理だから」は、範囲から外す理由にならない
親会社のネットワークや、親会社が契約したサービスも、組織のIT基盤を構成していれば、責任を共有するものとして範囲に入ります。外すのではなく、自分で管理する部分と、親会社に確かめる部分に分けて書く形です。親会社が登録を持っていなければ、シートを共有してもらうなどの別の道を考える必要があります。
まとめ
- 組織のIT基盤を構成し、他組織と対策の責任を共有するクラウドと親会社の共通ネットワークは、適用範囲に入る。契約の有無は問われず、SaaSも含む想定（意見公募の回答）
- 自分で管理できる部分は、該当する段階の基準をすべて満たす。管理できない部分は、提供者の対策を確かめる。この2つに分けて扱う
- 利用者側の対策の例は、ID管理・認証・パスワード・データの保護とバックアップ・監視・インシデント対応手順。うち4-3-1と5-1-2は★4だけの要求事項
- 提供者に確かめる事項の例は8件。うち4件（4-1-8・4-1-9・3-2-1・4-4-2）は★4だけ。★3でどこまで確かめるかは、資料からは決めきれない
- 確かめ方は、サービス仕様、SOC2 Type 2報告書、開示された報告書、個別の照会など。共通ネットワークは、シートの共有か登録の確認。どれか1つが必須とは書かれていない
- 架空のJ社では、「親会社の管理だから除く」は資料と食い違う可能性が高く、「SOC2報告書がないので確認できない」は、ほかの確かめ方が残っていると読んだ
引っかかった点
- 解説書3.3.4の8件のうち、★4だけの4件を★3の登録で提供者に確かめるのか。前述の通り、筆者は★3の欄にもある4件が少なくとも候補になると読んでいますが、4件だけでよいとまでは資料から言えません
- 仕様にも照会にも答えのない項目が残ったときの扱い
- 「しかるべき段階の登録」が、親会社と子会社で目指す段階が違うときにどう読まれるか
参考にした一次資料
- IPA「★3・★4 要求事項・評価基準」（解説書 SCS-620 v1.0 の第3章冒頭・3.2.1・3.3.1・3.3.2・3.3.4・別紙3-1-3、自己評価等ガイド SCS-410 v1.0 の4.1・別紙3-1-3-1・3-1-3-2・2-1-1-1・2-1-1-2、要求事項・評価基準 SCS-400 Ver.1.1。ガイドとSCS-400は2026年10月29日の軽微な修正版）
- IPA「SCS評価制度 制度規程・委員会」（研修実施基準 SCS-330B の附属書B）
- IPA「SCS評価制度の詳細情報」（制度構築方針〈経済産業省・国家サイバー統括室、2026年3月〉2.2.2と、制度構築方針（案）への意見公募の結果）
この記事は2026年11月3日時点で確認した内容です。制度は詳細化が進んでいる段階で、資料には今後も改定や追加が予定されています。判断の前に、必ず一次資料で最新の状態を確認してください。