セキュリティチェックシートの"証跡"とは？提出を求められたときの考え方・具体例・ない場合の対応

取引先から届いたセキュリティチェックシート。回答を作成して提出したら、「証跡も一緒に提出してください」と言われたことはありませんか？

「証跡」という言葉は、日常業務ではあまり耳にしないかもしれません。そのため、何を出せばいいのか、どこまで出せばいいのか、見当がつかないという方も多いのではないでしょうか。

簡単にいえば、「証跡」とは、チェックシートの回答内容が事実であることを示す裏付け資料のことです。

求められている内容は、実はそこまで難しいものではありません。この記事では、登録セキスペ（情報処理安全確保支援士）・行政書士の観点から、証跡の考え方、具体例、そして証跡がない場合の対応まで、全体像をわかりやすく解説します。

→セキュリティチェックシート対応の全体像はこちら

取引先は証跡で「何を」確認しようとしているのか

証跡の具体例に入る前に、まず「なぜ取引先が証跡を求めるのか」を理解しておくことが大切です。
ここを押さえておくと、何を準備すればいいかの判断がしやすくなります。

チェックシートだけでは「確認できない」

チェックシートの回答が「はい」だけでは、取引先からすると「本当に？」という疑念が生じやすいです。証跡は、その「本当に？」に答えるための資料です。

背景には、サプライチェーン全体でのセキュリティ管理という考え方があります。経済産業省の「サイバーセキュリティ経営ガイドライン Ver3.0」では、重要10項目の一つとして、ビジネスパートナーや委託先を含めたサプライチェーン全体での対策推進が求められています。取引先がチェックシートや証跡を求めるのは、このガイドラインが示すリスク管理の実践の一環です。

また、IPA（独立行政法人情報処理推進機構）の「中小企業の情報セキュリティ対策ガイドライン第3.1版」でも、中小企業がサプライチェーン上の攻撃の足掛かりにされるリスクが明記されています。

つまり、証跡の提出は単なる書類仕事ではなく、取引先のリスク判断材料なのです。

取引先が見ている3つの観点

取引先が証跡を通じて確認したいことを、実務上わかりやすく整理すると、以下の3つの観点に集約できます。

① 対策が「実在する」こと
導入済み・設定済みであるという事実の確認です。「ウイルス対策ソフトを入れています」と回答したなら、実際に入っていることを示す資料が求められます。

② 対策が「機能している」こと
形だけでなく、実際に運用されているかの確認です。ソフトを入れているだけでなく、定義ファイルが更新されているか、スキャンが実行されているかといった点です。

③ 対策が「継続している」こと
一時的ではなく、定常的に行われているかの確認です。「1年前に設定しました」ではなく、今も継続していることを示す資料が有効です。

なお、ここで挙げている「実在・機能・継続」は、特定のガイドラインが定めた公式な分類ではありません。経済産業省やIPAのガイドラインが求める対策や記録の考え方を、チェックシート対応の実務に即してわかりやすく整理したものです。以降のセクションでは、この3つの観点に沿って証跡の具体例を見ていきます。

「証跡の型」別・具体例一覧

ここからは、証跡の具体例を紹介します。

チェックシートの「設問ごと」ではなく、「証跡の型ごと」に整理しました。こうすることで、「自社にどんな証跡があり得るか」を全体的に把握しやすくなります。

各設問に対応する具体的な書き方や証跡例については、取引先セキュリティチェックシートの頻出質問20選で詳しく解説していますので、あわせてご覧ください。

型①：画面スクリーンショット系

具体例：
ウイルス対策ソフトの管理画面、クラウドサービスの権限設定画面、バックアップ設定画面、パッチ適用状況の画面など。

3観点との対応： 主に「実在」と「機能」の裏付けになります。

撮影時のポイント：
スクリーンショットは、ただ画面を撮ればいいわけではありません。取引先が確認したいのは「何を使っているか」「いつ時点の情報か」「どの範囲が対象か」です。

そのため、以下の点を意識してください。

製品名が映り込んでいること — 何のツールを使っているかがわかるように
日付が映り込んでいること — 定義ファイルの更新日、スキャンの実行日時など
対象範囲がわかること — 全端末が対象なのか、一部なのか
個人情報はマスキングすること — ユーザー名やメールアドレスが不必要に映り込んでいないか確認

※個人データを取り扱う場合の法的根拠として、個人情報保護委員会のガイドライン（通則編）別添「講ずべき安全管理措置の内容」では、技術的安全管理措置として「アクセス制御」「不正ソフトウェア対策」等の措置と手法例が具体的に示されています。スクリーンショットは、これらの措置の実施状況を示す資料としての機能が期待できます。チェックシートの設問のうち、個人データに直接関係しない技術的設問については、IPAの「中小企業の情報セキュリティ対策ガイドライン」の対策項目が参考になります。

型②：規程・ポリシー文書系

具体例：
情報セキュリティ基本方針、個人情報取扱規程、インシデント対応手順書など。

3観点との対応： 主に「実在」の裏付けになります。規程が文書として存在すること自体が証跡です。

提出時のポイント：
全文を提出する必要はありません。表紙＋目次＋該当ページの抜粋で十分です。取引先が確認したいのは「組織としてルールを定めているかどうか」であって、規程の細部まで精査したいわけではありません。

「うちにはまだ規程がない……」という場合でも、IPAがサンプルとして「情報セキュリティ関連規程」や「情報セキュリティ基本方針」を無料で公開していますので、これらをベースに自社の状況に合わせてカスタマイズすることで、規程の整備を始めることができます。

※個人データを取り扱う場合の法的根拠として、個人情報保護法ガイドライン（通則編）では、「個人データの適正な取扱いの確保について組織として取り組むために、基本方針を策定することが重要である」と明記されています。取扱規程の整備も、組織的安全管理措置として求められています。情報セキュリティ全般の規程整備については、IPAガイドラインでも対策の基本として位置づけられています。

型③：運用記録・ログ系

具体例：
パッチ適用履歴、アクセスログ、バックアップ実行ログなど。

3観点との対応： 主に「機能」と「継続」の裏付けになります。対策が「動いている」「続いている」ことを示す証跡です。

提出時のポイント：
ログをそのまま提出しても、取引先には読み解けないことがほとんどです。以下の3点を添えて提出すると、伝わりやすくなります。

何の記録か — 「バックアップの実行ログです」等の説明
対象期間 — 「直近3か月分」等
確認した結果 — 「すべて正常に完了しています」等の簡潔なコメント

※個人データを取り扱う場合の法的根拠として、個人情報保護法ガイドライン（通則編）別添では、組織的安全管理措置の「取扱状況の確認のための手段の整備」として、情報システムの利用・アクセス状況の記録が手法例として挙げられています。また、経済産業省の「サイバーセキュリティ経営ガイドライン Ver3.0」でも、重要10項目の中で対策状況のPDCAサイクル（実施・報告・改善）が求められており、運用記録は「PDCAが回っていること」の証跡としての機能が期待できます。

型④：教育・研修実施記録系

具体例：
研修の実施日・参加者リスト・使用資料の表紙など。

3観点との対応： 主に「継続」の裏付けになります。

「大がかりな研修」でなくても大丈夫：
「年1回の全社研修」のような正式なものでなくても、証跡として機能する記録はあります。

朝礼でセキュリティに関する注意喚起を行った記録（日付・内容のメモ）
メールで全社員に周知した履歴（送信日・件名・本文の写し）
チャットツールでの共有履歴

簡単に言えば、「従業員に対してセキュリティに関する教育・周知を行っている」ことが確認できる記録であれば、形式は問われないケースが多いと考えられます。

IPAも「情報セキュリティハンドブック（ひな形）」を無料で公開しています。従業員向けの周知資料を作る際の参考になります。

※個人データを取り扱う場合の法的根拠として、個人情報保護法ガイドライン（通則編）別添では、人的安全管理措置として「従業者に対する教育」が措置の一つとして挙げられています。中小規模事業者向けの手法例としては、「個人データの取扱いに関する留意事項について、従業者に定期的な研修等を行う」とされています。情報セキュリティ全般の従業員教育については、IPAガイドラインでも基本的な対策として推奨されています。

型⑤：契約・委託管理系

具体例：

委託契約書における安全管理条項（個人データの取扱い、再委託の可否、事故時の報告義務等が記載された部分）
委託先から取得したセキュリティチェック回答書や自己点検報告書
委託先が取得している第三者認証の証明書（ISMS認証、プライバシーマーク等）
クラウドサービスの利用規約・SLA（セキュリティ関連条項の部分）
秘密保持契約（NDA）

3観点との対応： 主に「実在」の裏付けになります。

注意点：
NDAは秘密保持に関する契約であり、それ単体では「委託先を適切に監督している」ことの証跡としては十分とは言えません。取引先がこの領域で確認したいのは、「委託先に丸投げしていないか」「委託先のセキュリティ水準を把握しているか」という点です。そのため、安全管理や再委託、事故時の報告義務等に具体的に触れる契約や、委託先の対策状況を確認した記録のほうが、証跡としての説得力は高くなります。

中小企業では見落としやすい領域ですが、まずは既存の契約書の中に該当する条項がないかを確認するところから始められます。

IPAも「中小企業のためのクラウドサービス安全利用の手引き」を公開しており、クラウドサービス利用時の契約・SLAの確認ポイントがまとめられています。

※個人データを取り扱う場合の法的根拠として、個人情報保護法25条（委託先の監督）では、個人データの取扱いを委託する場合に、委託先に対して必要かつ適切な監督を行う義務が定められています。個人情報保護法ガイドライン（通則編）では、委託契約において安全管理に関する事項を明記することが手法例として示されています。個人データに限らない委託管理全般については、IPAガイドラインも参考になります。

証跡を提出する前に確認すべき4つのポイント

証跡の具体例がわかったら、次は「用意した証跡をそのまま出して大丈夫か」を確認しましょう。ただ集めるだけでは、かえって問題になるケースも考えられますので、以下の点についてあらかじめ確認しておくことが大切です。

ポイント1：日付が古すぎないか

たとえばスクリーンショットの撮影日が半年以上前だと、「今もこの状態なのか？」が取引先に伝わりません。可能な限り、提出時点に近い日付のものを用意してください。

ポイント2：対象範囲がチェックシートの設問と合っているか

たとえば、チェックシートで「全社的にウイルス対策を実施していますか？」と聞かれているのに、提出した証跡が一部の端末だけの設定画面だった場合、「全社対応」の裏付けにはなりません。証跡が示す範囲と、回答で述べている範囲が一致しているかを確認してください。

ポイント3：個人情報や機密情報が不必要に映り込んでいないか

スクリーンショットにユーザーのメールアドレスや氏名が映り込んでいないか、ログにアクセス元のIPアドレスが不必要に含まれていないか。提出前にマスキングが必要な箇所がないか確認してください。

ポイント4：証跡の内容とチェックシートの回答が矛盾していないか

これが最も見落としやすいポイントです。「全社導入済み」と回答しているのに、証跡のスクリーンショットには「対象：5台」と表示されている。こうした矛盾は、取引先に「回答の信頼性に疑問がある」と判断される原因になります。

※個人情報保護法ガイドライン（通則編）でも、安全管理措置は「事業の規模及び性質、個人データの取扱状況に起因するリスクに応じて、必要かつ適切な内容としなければならない」と明記されています（個人データを取り扱う場合の根拠です）。つまり、証跡も画一的に「これを出せばOK」ではなく、自社の状況に合った内容である必要があります。この考え方自体は、IPAガイドラインでもチェックシート全般に共通する原則として示されています。

証跡がない場合の考え方

「証跡を用意しようと思ったが、そもそも該当する資料が社内にない」という状況もあるかと思います。

結論から言うと、証跡がない＝即アウトというわけではありません。

IPAの「中小企業の情報セキュリティ対策ガイドライン第3.1版」は、中小企業が段階的に対策を進めることを前提として設計されています。「すぐに取り組める対策」から始め、段階的に発展させていくことが推奨されており、すべてを一度に完璧に整える必要はないという考え方が示されています。

対応の方向性は、大きく2つあります。

方向性①：代替的な資料で説明する

正式な証跡がなくても、類似の資料や運用実態を示す情報で代替できるケースがあります。たとえば、正式なセキュリティポリシー文書はなくても、社内で運用しているルールをメールで周知した履歴があれば、それが「ルールの存在」を示す代替的な証跡になり得ます。

方向性②：対応計画を添えて提出する

現時点では未実施の項目について、「現状」「課題認識」「対応予定」の3点を添えて回答する方法です。

記載例1（規程文書がない場合）：

現時点ではセキュリティポリシーとして文書化したものはありませんが、社内ルールとして○○を運用しています。正式な文書化は20xx年x月までに完了予定です。

記載例2（ログが取れていない場合）：

現在のシステム構成ではアクセスログの取得ができていません。x月のシステム更新時にログ取得機能を有効化する予定です。

ただし、これで必ず通るとは限りません

上記の対応で再提出が認められるケースは多いですが、取引先の要求水準や業界によっては、代替資料や改善予定だけでは不十分と判断されることもあります。 特に、金融系や大手SIerが発注元の場合は、具体的な対策完了を求められるケースも珍しくありません。

IPAのガイドラインが段階的対応を前提としているのは事実ですが、それは「どの取引先でも未整備のまま受け入れてもらえる」ことを保証するものではありません。

自社の回答が取引先の期待値に合っているかどうか、判断に不安がある場合は、提出前に専門家に確認しておくことをお勧めします。

証跡がない項目について、どこまで説明すべきか・代替資料で足りるかの判断に迷ったら、まずは無料相談でご状況をお聞かせください。

→ 無料相談を予約する

証跡準備で「やってはいけない」こと

最後に、証跡を準備する際に絶対に避けるべきことを3つお伝えします。

NG①：スクリーンショットの加工・演出

必要なマスキングを施す場合などを除き、設定画面のスクリーンショットを加工して、実態と異なる状態を見せることは避けるべきです。たとえば、実際には無効にしている機能を有効に見せるために画像を編集するような行為です。

NG②：他社テンプレートのそのまま流用

インターネット上で見つけた他社のセキュリティポリシーを、社名だけ差し替えて自社の規程として提出することも避けるべきです。取引先によっては提出後にヒアリングを行うことがあり、そこで「この規程のこの部分は、御社ではどう運用していますか？」と聞かれたときに答えられなければ、かえって信頼を損なってしまうリスクが高いです。

NG③：実態と異なる証跡の提出

実施していない対策を、あたかも実施しているかのように見せる資料を作成・提出するというのは最も深刻です。虚偽報告は絶対に避けるべきです。

法的リスクについて

実態に合わない証跡を提出すること自体が、ただちに特定の法令違反になるわけではありません。しかし、以下の2つの観点からリスクが生じ得ます。

① 安全管理措置の不備が問題になるケース

実態に合わない証跡を出した結果、実際の安全管理措置が不十分な状態のままインシデントが発生した場合、個人情報保護法23条（安全管理措置義務）をはじめとする法的責任が問題になり得ます。ここで問われるのは「虚偽の証跡を出したこと」そのものではなく、「安全管理措置が実際に不十分だったこと」です。しかし、虚偽の証跡を出していたという事実は、「対策の不備を認識しながら放置していた」と評価される材料になりかねません。

※個人情報保護法23条（安全管理措置）、24条（従業者の監督）、25条（委託先の監督）は、いずれも個人データを取り扱う場合に適用される法的根拠です。

② 契約上の表明との不一致が問題になるケース

取引基本契約に表明保証条項やセキュリティに関する遵守事項が含まれている場合、チェックシートの回答と実態が異なることは、契約上の義務違反として問題になり得ます。インシデント発生時に取引先から損害賠償を請求される際、「チェックシートでは対策済みと回答していた」という事実が、責任の範囲を広げる方向に働くリスクがあります。

大切なのは、正直に現状を伝えたうえで、改善の意思を示すことです。「いいえ」と答えることは、取引先からの信頼を失うことではありません。むしろ、実態と異なる「はい」を出すことのほうが、長期的にはるかに大きなリスクを抱えることになります。

セキュリティ対策の不備がもたらす経営者の法的リスクについては、セキュリティ対策に消極的な経営者が問われる責任とは？で詳しく整理しています。

まとめ

証跡とは、チェックシートの回答が事実であることを示す裏付け資料のこと
取引先は、対策の「実在・機能・継続」の3つの観点で証跡を確認している
証跡の準備は、何を出すかよりも「自社の実態に合った形で出せているか」が重要

証跡の準備は、慣れていない方にとっては負担に感じるかもしれません。しかし、証跡を整理する過程で自社のセキュリティ対策の現状が可視化され、結果として今後のチェックシート対応もスムーズになります。

どの証跡を、どこまで準備すればいいかの判断に迷ったら、まずは30分の無料相談でご状況をお聞かせください。