セキュリティ監査の
外部委託と費用

セキュリティ監査とは、情報資産、システム、ネットワーク、クラウド、アプリケーション、業務プロセス、委託先管理、規程、運用証跡などを対象として、情報セキュリティ上のリスクと統制の有効性を検証・評価する活動です。

情報資産には、個人情報、顧客情報、営業秘密、契約書、設計図、ソースコード、研究データ、会計データ、認証情報、ログ、AI学習用データ、クラウド設定情報などが含まれます。漏えい、改ざん、消失、利用不能が発生すると企業に損害を与える情報を広く含めて考えます。

監査・診断・ペネトレーションテストは成果物と法務上の注意点が異なるため、名称だけで発注範囲を決めると漏れが生じます。次の比較表では、目的、対象、成果物、契約上の注意点の違いを読み取れます。

脆弱性診断は技術的な欠陥の発見に強く、監査は管理体制、責任分界、規程、運用、証跡、経営報告まで見ます。ペネトレーションテストは攻撃シナリオに基づくため、対象範囲、権限、禁止行為を契約で特に明確にします。

外部委託に向く領域は、専門ツール、手動検証、攻撃シナリオ設計、認証・保証対応、客観的な証跡確認が求められる分野です。一方で、事業上の重要資産やリスク許容度は社内でしか決められません。

次の比較表は、どの領域を外部専門家に任せやすいか、どの委託先候補を検討するかを示します。自社の対象範囲に近い行を確認すると、RFPに入れるべき要件が整理しやすくなります。

外部専門家に委託しても、事業上の重要資産を定義する責任、リスク許容度を決める責任、監査範囲を承認する責任、顧客や取引先への説明責任、是正対応の意思決定、予算配分、委託先選定と契約管理は社内に残ります。

費用は、単価表だけでは判断できません。総費用は「監査対象の広さ × 検証の深さ × 必要証跡の量 × 報告・保証の水準 × 緊急度 × 是正支援の有無 + 社内工数」という式で捉えると整理しやすくなります。

見積書の外部委託費だけで判断すると、実際の予算を誤りやすくなります。次の表は、直接費用と社内・法務・技術対応まで含む費用の種類を示し、監査後に予算不足が起きやすい箇所を読み取れます。

公開価格例から見ると、価格帯は対象範囲で大きく変わります。次の一覧は、価格の数字だけでなく、どの条件が含まれているかを読み取るための整理です。

企業類型ごとの予算感は、規模と目的によって変わります。次の表では、入口として考えやすい参考予算を示し、どの範囲を段階的に広げるかを読み取れます。

契約書または仕様書では、対象URL、FQDN、IPアドレス、対象アプリケーション、API、管理画面、クラウドアカウント、リージョン、テスト時間帯、対象外システム、本番環境か検証環境か、負荷試験やソースコードレビューの有無を具体化します。

契約条項は、監査の安全性と報告書の利用価値を左右します。次の表は、委託元と委託先の関心が衝突しやすい責任制限の論点を整理し、交渉時にどの落としどころを検討するかを読み取れます。

権限付与と禁止行為

ペネトレーションテストや脆弱性診断では、委託元が委託先に明示的なテスト権限を付与します。対象システム、実施期間、実施方法の範囲を超えるアクセス、破壊的行為、データ改変、サービス停止を伴う行為、第三者システムへのアクセスを禁止する条項を置きます。

秘密保持・個人情報・ログ

セキュリティ監査では、設計図、脆弱性情報、アカウント、ログ、個人情報、営業秘密、顧客情報が外部委託先に渡ります。秘密情報の範囲、個人データの取扱い、安全管理措置、アクセス権限管理、暗号化、保管場所、海外移転、再委託、ログ保存期間、契約終了後の返還・消去、漏えい時の通知期限を定めます。

報告書の権利と利用範囲

報告書は、社内改善、取締役会報告、監査役報告、顧客説明、委託先監督、認証審査、M&A、IPO、保険、規制当局対応に使われる可能性があります。社内共有、親会社・子会社共有、顧客提示、監査法人・弁護士・規制当局への提示、NDA下の第三者開示、要約版作成、脆弱性詳細のマスキングを契約前に確認します。

委託先監査は、すべての委託先に同じ深さで行うものではありません。個人情報、基幹業務、常時接続、金融・医療・公共、クラウド基盤などのリスクに応じて確認の深さを変えます。

次の表は、委託先をリスクで層別化した場合の確認方法を示します。質問票だけで足りる相手と、外部監査・訪問監査・保証報告書まで必要になり得る相手を区別して読み取れます。

役割分担を明確にすることも重要です。次の表は、取締役会からセキュリティベンダーまでの責任を示し、監査計画や是正会議に誰を入れるべきかを読み取れます。

実務上は、第一線が事業部・情報システム、第二線がリスク管理・法務・コンプライアンス・セキュリティ、第三線が内部監査という三線モデルで整理できます。外部専門家は第二線や第三線を支援できますが、経営責任そのものを代替するわけではありません。

失敗例として、安い診断だけで全社監査が完了したと説明する、委託契約に監査権がない、監査結果を修正しない、顧客に出せない報告書を受領する、本番環境で障害を起こす、法務が最後に呼ばれる、といったものがあります。

契約前の確認不足は、費用超過や事故対応の遅れに直結します。次の表は、法務担当が最低限見るべき項目をまとめたもので、契約書・仕様書・見積書の抜けを確認するために使えます。

RFP評価では、価格だけで選ばず、監査方法論、同種実績、報告書品質、法務・個人情報対応、重大発見時対応、体制・資格、価格妥当性、スケジュール、継続支援を点数化します。

次の配点例は、価格以外の品質要素を見える化するためのものです。比重を見ることで、報告書の使いやすさや重大発見時対応を軽視していないかを確認できます。

Q1. セキュリティ監査は毎年必要ですか。

一般的には、高リスクシステム、個人情報を扱うシステム、外部公開システム、重要委託先については、年1回又は重要変更時に実施する設計が望ましいとされています。ただし、事業内容、システム変更、顧客要求、規制業種かどうかによって結論は変わります。具体的な監査頻度は、リスク評価を整理したうえで弁護士、公認会計士、セキュリティ専門家等へ相談する必要があります。

Q2. 安い脆弱性診断だけで十分ですか。

一般的には、対象が限定されている場合には簡易診断も有用とされています。ただし、委託先管理、個人情報、クラウド、業務ロジック、経営報告、認証・保証対応まで含める場合、脆弱性診断だけでは範囲が足りない可能性があります。具体的には、対象システムと報告書の用途を整理して専門家へ確認する必要があります。

Q3. 監査で問題なしと言われたら安全ですか。

一般的には、監査結果は特定時点、特定範囲、特定方法に基づく評価とされています。範囲外のシステム、未検証のAPI、後日の設定変更、新たな脆弱性は別問題になる可能性があります。具体的な説明や顧客開示では、報告書の前提条件を確認する必要があります。

Q4. 外部委託先にすべて任せてよいですか。

一般的には、外部委託は専門性を補う手段であり、経営判断、リスク受容、委託先監督、個人情報保護、顧客説明の責任は自社に残ると考えられます。ただし、社内体制や委託契約の内容によって運用は変わります。具体的な役割分担は、契約書と社内規程を確認して設計する必要があります。

Q5. 顧客から監査報告書の提出を求められたらどうしますか。

一般的には、報告書の第三者開示が契約上許されているかを確認します。脆弱性詳細をそのまま渡すと、かえってリスクが高まる場合があるため、要約版、是正済み証明、NDA下の限定開示、SOC 2やISMS証明書などの代替資料を検討することがあります。具体的な開示方法は、契約条件と顧客要求を確認して専門家へ相談する必要があります。

Q6. ペネトレーションテストは危険ですか。

一般的には、適切な計画、明示的な権限付与、対象範囲、禁止行為、停止条件、バックアップ、監視、連絡体制がある場合、重要なリスク検証手段になるとされています。ただし、これらが曖昧なまま行うと、法的・業務的リスクが高くなる可能性があります。具体的な実施条件は、仕様書と契約書で明確にする必要があります。

Q7. 監査費用は資産計上ですか、費用処理ですか。

一般的には、会計・税務上の処理は、契約内容、成果物、システム改修との関係、社内会計方針によって変わります。単なる診断・監査は費用処理となることが多い一方、システム開発・改修と一体化している場合は個別判断になる可能性があります。具体的な処理は、公認会計士又は税理士に確認する必要があります。

Q8. 弁護士を入れる場面はいつですか。

一般的には、個人情報漏えいのおそれがある場合、重大事故後調査、顧客・当局対応、海外法制、金融・医療等の規制業種、M&A・IPO、契約責任が大きい案件、ペネトレーションテストの権限設計、委託契約改定では、弁護士の関与が検討されます。ただし、必要な関与範囲は事案により変わります。具体的には、リスクと契約関係を整理して相談する必要があります。

Q9. 内部監査部門だけでできますか。

一般的には、内部監査部門が十分な専門性を持つ場合、基本監査は可能とされています。ただし、Web、API、クラウド、ペネトレーションテスト、フォレンジック、SOC 2等は専門性が高く、外部専門家を使う合理性があります。具体的には、内部監査計画と専門領域の不足を照合する必要があります。

Q10. 最初に何をすればよいですか。

一般的には、個人情報と外部公開システムの棚卸しから始める方法が取りやすいとされています。次に、重要委託先と契約条項を確認し、高リスクのWeb、API、クラウドから外部診断を行い、是正と再診断まで予算化します。具体的な優先順位は、事業影響と法的リスクを整理して決める必要があります。

公的機関・標準化団体の資料

• 経済産業省「情報セキュリティ監査制度」
• 経済産業省「システム監査基準」
• 経済産業省「サイバーセキュリティ経営ガイドライン」
• 独立行政法人情報処理推進機構「情報セキュリティ10大脅威 2026」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• 個人情報保護委員会「委託先を監督してますか？」
• ISO「ISO/IEC 27001 Information security management systems」
• NIST「Cybersecurity Framework 2.0」
• NIST「SP 800-115 Technical Guide to Information Security Testing and Assessment」
• OWASP「OWASP Top Ten」
• OWASP「Web Security Testing Guide」
• OWASP「API Security Project」
• AICPA & CIMA「Trust Services Criteria」
• 内閣サイバーセキュリティセンター「ISMAP」
• 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」
• 厚生労働省「医療情報システムの安全管理に関するガイドライン」
• 警視庁「不正アクセス」

費用感の整理に用いた公開資料

• 脆弱性診断ライトプランに関する公開価格資料
• プラットフォーム診断サービスに関する公開価格資料
• Webアプリケーション診断・プラットフォーム診断に関する公開価格資料
• 手動脆弱性診断の費用相場に関する公開解説
• ISMSコンサルティング料金に関する公開資料
• 委託先監査・教育・リスクアセスメントに関する公開料金資料
• SOC 2対応コストに関する公開資料