セキュリティチェックシートの答え方:質問の意図と、コストをかけすぎない内規の決め方

従業員10〜100人ほどのSaaS企業で、初めて取引先のセキュリティチェックシートやDD(デューデリジェンス)の質問票を受け取った、CTOや情シス兼任の方に向けた整理です。「何と答えればいいか分からない」と「答えるために重い社内ルールを作ってしまい、ずっとコストがかかる」の2点を中心に扱います。

一般的な情報であり、法務・監査・コンプライアンスの助言ではありません。このページに従えば適合する、という保証もしません。回答は契約の前提や表明として扱われることがあります。実態と違う回答は、してはいけません。個別の契約上の影響は弁護士など専門家に確認してください。

作成: myuon(個人運営)。AIの支援を受けて作成しました。第三者の専門家によるレビューは、現時点では受けていません。確認日: 2026-11-05。

なぜ質問票が届くのか

取引先は、自社のデータや業務を、あなたの会社のサービスに預ける(または連携する)ことになります。その相手が事故を起こすと、取引先自身の顧客や監督当局への説明責任が生じます。質問票は、その説明のための材料集めです。聞き手が確認したいのは、おおむね次の3点です。

• 事故の確率が極端に高くないか。基本的な対策が、やっているつもりではなく、実際に動いているか。
• 事故が起きたとき、被害を抑えて知らせてくれるか。気づく仕組みと、連絡の経路があるか。
• 状況を説明できる人がいるか。誰が責任者で、決めたことが文書や記録に残るか。

つまり多くの質問は「完璧か」ではなく「分かって運用しているか」を見ています。小さな会社が大企業と同じ体制を持っていなくても、持っていないこと自体は即失格を意味しません。正直な説明と代替策が、評価される場面は多いはずです(ただし、聞き手の基準は会社ごとに異なり、このページでは保証できません)。

大原則:回答は実態と一致させる

• やっていないことを「はい」と答えない。「近いうちにやる予定」は「はい」ではありません。「予定あり(時期)」と書きます。
• 回答は契約の一部になりうる。質問票の回答が契約書の表明保証や添付資料に取り込まれたり、後日の事故の際に説明の根拠として参照されたりすることがあります。取り込み方は契約ごとに違うため、契約条項を確認してください。
• 書くのは、今できること。将来の理想は回答欄ではなく、ロードマップとして別に示します。
• 根拠を示せないことは、強い言葉で書かない。「常に」「すべて」「完全に」は、反証が1件あれば虚偽になります。
• 回答者と承認者を決める。技術的な回答の正確さは現場が、契約への影響は経営者や法務の目を通して確認します。

迷いやすい質問10類型

特定の質問票の文面ではなく、よくある種類を、このページの言葉で書いています。どの質問票にも同じ形で出るとは限りません。各類型に、聞き手の意図、答え方の型、求められうる証跡、過剰に約束しないコツを書きます。答え方の型は、次の3つを使い分けます。

• はい:実際に行っており、説明や記録で示せる。
• いいえ、代替策あり:その形ではやっていないが、同じ目的を別の方法で満たしている。何をしているかを書く。
• 該当なし:その事業の形では、その対象が存在しない。理由を1文添える。「面倒だから」「やっていないから」は該当なしではありません。

クレジットカード情報を扱う場合など、業界標準(例:PCI DSS)に基づく自己評価を求められることがあります。これらの標準の本文は、各標準の策定団体が利用条件を定めています。このページでは標準の名前だけに触れ、内容の要約は行いません。必ず策定団体の公式資料を直接確認してください。カードを自社で保持しない構成(決済代行の画面遷移やトークン化など)にすると、対象範囲が小さくなる場合がありますが、どの自己評価が該当するかは、決済代行会社やカードブランド・アクワイアラーに確認してください。

重い内規を作らないための考え方

質問票に答えるために作った社内ルール(内規)は、作った瞬間から「守り続ける」コストを生みます。ルールを守れていない状態は、「ルールがない」状態より悪く見えます(書いたことと実態が違う、になるため)。次の方針で作ると、コストを抑えられます。

1. 実際にやっていることだけを書く。先に運用を作り、あとから書き写す順番にします。
2. 自動化できる統制を優先する。「毎月、人が確認する」より「設定で強制する」「ツールが検知する」を選びます。設定は人が忘れても動き続けます。
3. 見直しの頻度は、維持できる最低限にする。半期や年1回で十分な項目が多いです。実施日を記録できる場所(カレンダー、チケット)に固定します。
4. ルール1つに、担当者と証跡の場所を1つ。誰がやり、どこを見せれば分かるかが決まっていないルールは、書かない。
5. 数字は、守れる幅で。「必ず」「毎日」の代わりに「原則」「営業日内に着手」のような言い方で、守れる水準に合わせます。
6. 求められるまで作らない。質問されていない文書を先回りして量産しません。

重い内規と軽い内規の例

公的機関も、中小企業向けの方針や内規の例を公開しています。たとえばIPAの「中小企業の情報セキュリティ対策ガイドライン」には、基本方針、情報セキュリティ関連規程、5分でできる自己診断などの付録があります(第4.0版、2026-03-27公開、確認日 2026-11-05)。利用の際は、IPAの案内する出典明記などの条件に従ってください。雛形は大きめなので、そのまま採用せず、自社が実際にできる範囲まで削ってから使うのが、ここで述べたコストを抑える考え方です(雛形が自社に合うかは、このページでは判断できません)。

分からない質問への対処と、聞き返し方

1. 推測で「はい」と答えない。分からない場合は、社内で実態を確認してから答えます。確認に時間がかかるなら、回答期限の延長を相談します。
2. 用語の意味を聞き返す。質問票の言葉は会社独自の意味で使われていることがあります。「ここでの〇〇は、具体的にどのシステム・どの範囲を指しますか」と聞いてよいものです。
3. 目的を聞く。「この質問で確認したいリスクは何ですか。同じ目的を別の方法で満たしている場合、その説明で足りますか」と聞くと、代替策の余地が分かります。
4. 回答形式を聞く。選択式でも補足欄や別紙を付けてよいか、証跡は要約でよいか、機密資料はNDAのもとで見せる形でよいかを確認します。
5. やりとりを残す。聞き返しの内容と相手の回答は、メールなど記録に残る手段で行います。後日「この意味で答えた」と説明できます。

聞き返しの文例

• 「設問Xの『重要なデータ』は、お客様の入力データのみを指しますか。運用ログも含みますか。」
• 「当社では〇〇の代わりに△△で同じ目的を満たしています。その説明を回答欄に記載してよろしいでしょうか。」
• 「設問Yは、当社サービスの構成上、該当しないと考えます(理由:…)。該当なしとして回答してよいか、ご認識を教えてください。」

回答ライブラリを作る

質問票は形式が違っても、聞いていることは何度も重なります。回答を一元的に残しておくと、次回から短時間で済み、回答の矛盾も防げます。

• 1行1論点で持つ。論点、標準の回答文、答え方の型(はい/代替策/該当なし)、根拠となる証跡の場所、最終確認日、担当者を列にします。表計算ソフトで十分です。
• 過去の回答をそのまま流用しない。流用前に、現状と一致するか確認し、確認日を更新します。古い回答は、事実と違う回答になります。
• 変更があったら、ライブラリも更新する。ツールの変更、委託先の変更、組織変更が起きたときに、更新するルールにしておきます。
• 提出した版を保存する。誰に、いつ、どの回答を出したかを記録します。後で契約上の確認が必要になったときに、実際に出した版を参照できます。
• 機密の扱いに注意する。ライブラリには社内構成の情報が入るため、閲覧権限を絞ります。外部の生成AIなどに質問票や回答を入力する場合は、取引先とのNDAや社内規則に反しないか先に確認してください。
• AIの下書きは、そのまま出さない。下書きの作成には使えても、事実の確認は人間が行います。

出典と確認した範囲

確認日: 2026-11-05。

• IPA: 中小企業の情報セキュリティ対策ガイドライン(第4.0版、2026-03-27公開、ページ更新は2026-09-30と表示。付録に基本方針の雛形、5分でできる自己診断、規程の例などがあると記載されていることを確認)

このページで確認できていないこと

• 経済産業省のサイバーセキュリティ経営ガイドラインのページは、アクセスが拒否(HTTP 403)されたため、読んでいません。内容に基づく記述はしていません。
• IPAのガイドラインの付録の中身は、ダウンロードして読んでいません。ページ上の説明のみを確認しています。
• PCI DSSなどの標準の内容、各社の質問票の文面、市販のテンプレートは、参照・引用していません。
• 各質問票の具体的な基準、契約上の効力、法令上の通知義務の内容は、このページでは扱っていません。
• このページ内の「聞き手の意図」「答え方」は、運営者の整理に基づく一般的な考え方で、特定の取引先の基準を示すものではありません。専門家のレビューは受けていません。

今後について

答え方の例や内規のひな形などの追加資料を、今後公開する可能性があります。現時点で、購入や申し込みの受付、メールアドレスの収集は行っていません。