セキュリティ診断に関係する制度・公的支援の全体像

セキュリティ診断を検討し始めると、法律、登録制度、民間認証、公的支援の名称が同時に現れます。名称だけを見て「診断が必要なのではないか」と判断すると、契約上の要請と制度の説明が混ざり、社内で確認すべきことが見えにくくなります。

結論から言うと、脆弱性診断そのものを一律に法定義務とする一般的な条文は確認できません。個人情報の取扱い、対象システムの管理、取引先との契約など、自社に関係する根拠を分けて確認することが発注準備の出発点です。

この記事では、法令、法令に基づかない制度、民間認証、公的支援を分け、どの資料をいつ確認するかを整理します。診断の対象や見積条件は、制度の確認とは別の表でそろえると、関係者の判断を共有しやすくなります。

本記事で分かること

• 法令と法令に基づかない制度の読み分け
• 民間認証と診断発注の関係
• 公的支援で確認する対象サービス
• 発注前に残す確認記録

結論：制度・公的支援を分けて確認する（早見表）

制度名だけで診断の要否を決めず、根拠の種類と自社の契約・運用条件を分けて確認します。法律上の責任、制度資料の記載、取引先からの依頼は同じ欄にまとめず、それぞれの確認先と判断者を記録します。

まず法令・基準・民間認証を分ける

名称が似ていても、根拠と確認方法は異なります。まず「法律で定められた事項」「公式資料で示される制度・基準」「取引先との契約や民間認証で求められる事項」を分け、誰が確認するかを決めます。

法令と契約上の要請を分ける

個人情報の保護に関する法律は、個人データを扱う事業者に安全管理のための措置を求めています。一方で、脆弱性診断という名称の外部サービスを、すべての事業者に一律で発注させる規定ではありません。個人情報を扱う範囲、委託先との関係、社内の管理方法を確認したうえで、診断が必要になる事情を整理します。

不正アクセス行為の禁止等に関する法律との関係では、対象の管理者が承諾した範囲を確認することが発注の前提になります。自社が利用しているだけのサービスや、委託先が管理する領域を自社だけで対象に含めず、所有・管理の関係と承諾の窓口を記録します。法令の条文と契約上の依頼は、同じ要件として扱わないことが大切です。

法令に基づかない制度・基準を分ける

情報セキュリティサービス基準適合サービスリストは、IPAが公表するサービス区分を確認するための資料です。脆弱性診断サービスやペネトレーションテストに関する区分を読む際は、掲載の有無だけで個別の発注判断を終えず、対象、成果物、実施条件を見積書で確認します。IPAは掲載が個別事業者を保証するものではない旨も示しています。

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS）は、法令に基づかない制度です。2026年9月時点では開始前の準備段階として公式資料が公表されているため、取得済みの実績や登録状況を前提にせず、要求事項・評価の主体・今後の案内を公式ページで確認します。制度の説明と自社の診断発注を、一対一で結び付けないようにします。

民間認証・参照資料を分ける

民間認証や取引先独自のセキュリティ質問票は、診断の対象範囲を考える手掛かりになります。ただし、認証の対象が組織全体なのか特定のサービスなのか、更新時に何を示すのかは個別に異なります。認証名を確認したら、対象組織、対象システム、求められる記録を分けて読みます。

診断報告書は、民間認証や取引先説明に使える場合がありますが、報告書があれば常に他の確認が不要になるわけではありません。質問票で求められる対象、報告時点、再確認の扱いを照合し、必要な説明を別途用意します。発注先には、認証の名称だけでなく、どの資料に何を説明するかを伝えます。

公的支援は対象サービスを先に確かめる

支援名だけで外部診断費用の対象とは判断しません。制度が支援するサービスの範囲、登録や利用の条件、申請する主体を先に確認し、診断発注の条件とは別に整理します。

お助け隊サービスの対象範囲

サイバーセキュリティお助け隊サービス制度は、中小企業向けの支援制度としてIPAが案内するサービス制度です。外部から脆弱性診断を依頼する場合は、診断という言葉が含まれているかではなく、検討しているサービスが制度の対象として示されているかを確認します。発注したい診断の対象や成果物が、制度の説明と一致するかを見ます。

制度の案内にあるサービスと、個別の診断見積書の作業範囲は同じとは限りません。対象サービスの登録状況や利用条件を確認したうえで、診断会社へ依頼する内容を別紙にまとめます。制度の説明に合わせて対象範囲を広げたり狭めたりする前に、管理者の承諾と業務上の優先順位を確かめます。

申請前に確認する登録・利用条件

公的支援を利用する場合は、申請者、利用するサービス、申請時期、必要な記録を制度ごとに確認します。案内ページの要約だけで判断せず、公式の募集要領や対象サービスの説明へ進み、適用条件が自社に当てはまるかを担当者と確認します。

診断発注を急ぐ事情があるときも、支援の確認と発注準備を一枚のスケジュールに混ぜない方が判断しやすくなります。支援の手続きで確認中の事項は未確定として残し、診断対象、連絡先、成果物の条件は発注用の表で確定させます。二つの進行を分けることで、どこで判断が止まっているかを共有できます。

診断発注と支援利用を混同しない

診断の発注では、管理下にある資産、実施を承諾する範囲、希望する報告内容を整理します。支援利用では、制度が対象とするサービスや利用条件を整理します。確認する資料と判断する担当が違うため、一つのチェック欄で完了扱いにしないことが重要です。

たとえば発注仕様が固まっていても、支援利用の条件が確認途中なら、その状態を区別して関係者へ共有します。反対に支援に関する案内を確認できても、認証後の画面や連携先を診断対象へ含めるかは別の判断です。セキュリティ診断の発注ガイドを参照し、対象と条件を先に言語化します。

発注前に残す確認記録

制度確認は見積条件と別の記録として残します。確認した資料名、確認日、判断が必要な点、担当者を一覧にすると、更新情報が出た場合にも見直す範囲を追いやすくなります。

関係する制度を洗い出す

最初に、取引先から受けた質問、社内規程、扱う情報、利用している外部サービスを並べます。そのうえで、法律、契約上の要請、制度資料、民間認証のどれに関係するかを一項目ずつ付けます。根拠が分からないものは空欄で終えず、確認先と期限を記入します。

一覧は制度名を増やすことが目的ではありません。発注前に判断が必要な事項を見つけ、誰が確認するかを決めるための表です。関係が薄い制度を対象外にした場合も、対象外とした理由を残すことで、後からの再確認がしやすくなります。

契約・取引先の要求を確認する

取引先の要求では、診断を実施した事実、対象範囲、報告の時点、説明する相手のどれが求められているかを分けて確認します。「診断をしているか」という質問でも、実際には対象の管理方法や緊急時の連絡体制を尋ねている場合があります。質問票の文言をそのまま発注仕様に置き換えず、必要な説明を整理します。

診断とペネトレーションテストの選び方も、依頼の目的と対象を分けることで整理できます。脆弱性診断とペネトレーションテストの違いを確認し、検証したいことを短い文でまとめてから、承諾範囲と成果物を依頼先へ伝えます。

公式資料の確認日を残す

制度や支援の案内は更新されるため、資料名だけでなく確認日を残します。本記事で触れた法令・制度の記載は、2026年9月に公式資料を確認した内容です。更新があった場合に、どの判断を見直す必要があるかを特定できるようにします。

費用構造を確認するときも、制度の有無と見積条件を混同しないことが必要です。脆弱性診断の費用構造を参照し、対象や成果物などの条件をそろえたうえで、社内の比較表を更新します。制度確認表と見積比較表を分ければ、確認の根拠を説明しやすくなります。

まとめ

セキュリティ診断に関係する情報は、法令、法令に基づかない制度、民間認証、公的支援に分けて確認します。診断の対象、承諾範囲、成果物は制度確認とは別の表でそろえ、確認日と担当者を残すと、更新や契約変更にも対応しやすくなります。

制度や発注準備に関する記事は、法令・制度の記事一覧から確認できます。