セキュリティチェックシートを営業だけで埋めない。回答と実装のずれを防ぐ
顧客から届いたセキュリティチェックシートへの回答は、営業担当者だけで確定させないでください。先に「実施済み」「条件付き」「未対応」を分け、技術担当者が実装と証跡を照合し、顧客への約束が増える回答だけを責任者が承認します。この経路を決めると、商談を前へ進めながら、回答と実装のずれを見つけられます。
すべてを「実施済み」に見せる必要はありません。対象範囲や例外を隠した「はい」は、社内の実装より広い約束として読まれかねません。「いいえ」だけでも顧客の判断材料が不足します。現在確認できる事実と、今後引き受ける対応を分けて書く必要があります。
では、どの証跡を実施済みの根拠とし、どの段階で経営判断へ上げるべきでしょうか。僕なら、回答台帳の一行ごとにその境界を残します。
セキュリティチェックシートの回答は、可否より証跡を先に見る
セキュリティチェックシートには「有・無」や「はい・いいえ」を選ぶ欄があっても、その印だけを回答の本体にしません。2026年9月21日時点で確認したIPAの取引先・委託先向けアンケート例も、質問ごとに対策状況の有無と、具体的な実施内容の記入欄を分けています。さらに同じ事例では、情報システム部が回答に応じて追加質問を行い、対策状況を裏付ける証跡を依頼してから対策状況を評価しています。ページの公開日は2026年4月28日です。
チェック欄を埋めた時点では、確認は終わっていません。「規程があります」という回答なら現在有効な規程の所在を、「運用しています」という回答ならその運用を再確認できる記録の所在を、回答文と結び付けます。営業資料への証跡の添付可否は別に判断し、回答台帳には社内で確認できる場所と確認者を残します。
証跡は文書だけとも限りません。2026年9月21日時点で確認したNIST SP 800-53A Rev. 5は、評価方法を examine、interview、test の三つとして説明しています。文書・仕組み・活動などを確認する、関係者と対話する、所定の条件で実際の状態と期待状態を比較する、という方法です。公開日は2022年1月25日です。
したがって、ファイルが一つ見つかっただけで「実施済み」と決めるのは早計です。規程の記述、担当者が説明する運用、実際の設定や動作が同じ状態を示すかを、質問の重要性に応じて確かめます。文書はあるが運用を確認できないなら、少なくとも無条件の実施済みには置きません。この慎重さが、営業上の回答を技術上の事実へ戻します。
実施済み・条件付き・未対応を分ける回答レビューの記入例
以下は出典の一般原則を基に僕が提案する実務上の方法で、原典所定の分類や義務ではありません。回答台帳には、質問項目、状態、顧客への回答文、証跡の所在、適用範囲・前提・例外、技術確認者、承認者、次回確認契機を同じ行に置きます。単純な可否欄と根拠を分けることで、「何を根拠に、どこまで答えたか」を後からたどれます。
たとえば質問項目が「対象システムへのアクセス権限を管理しているか」なら、回答の型は次のようになります。角括弧の中は、自社で確認した固有名詞や日付へ置き換える欄です。確認していない内容を例文から補ってはいけません。
| 状態 | 顧客への回答文 | 証跡・範囲・承認の記録 |
|---|---|---|
| 実施済み | 「[対象環境]では、[確認できた管理方法]を実施しています」 | 証跡：[規程・設定記録などの社内所在]／範囲：[証跡が示す対象]／技術確認者：[氏名・確認日]／承認者：[必要な場合のみ] |
| 条件付き | 「[確認済みの対象]では実施しています。[対象外・例外]は対象に含みません。[追加対応]は[承認済み・承認待ち]です」 | 証跡：[社内所在]／前提・例外：[条件]／技術確認者：[氏名・確認日]／承認者：[責任者・承認状態] |
| 未対応 | 「現時点では、[実装または証跡]を確認できていません。[追加対応の判断状況]」 | 不足：[実装・証跡・確認のいずれか]／取引条件への影響：[要判断事項]／承認者：[責任者・承認状態] |
実施済みに置けるのは、現在の実装と再確認可能な証跡が一致した行です。条件付きでは対象範囲、前提、例外、必要な追加対応を一続きで書き、承認待ちも状態に含めます。未対応では、現在確認できない事実と将来の予定を分けます。追加対応を予定に書くなら、責任者と承認状態も残します。
三分類が表すのは回答の確認状態です。実施済みは現在の事実、条件付きは境界と判断待ち、未対応は不足または未確認です。条件付きの欄が長くなったときは、営業と技術の間に隠れていた前提をレビューできる状態になったと捉えます。
営業・技術・責任者のレビュー経路を固定する
回答台帳を作っても、誰が確定できるかが曖昧なら、締切前に営業判断へ戻ってしまいます。回答台帳による運用も出典の一般原則を基に僕が提案する実務上の方法で、原典所定の役割分担や義務ではありません。営業は顧客が質問する目的と提出条件を整理し、技術担当者は現在の実装と証跡を確認します。条件付き回答、例外、追加対応、社内方針や契約上の要求に関わる約束は、経営者または権限を与えられた責任者が承認します。
2026年9月21日時点で確認したNIST Cybersecurity Framework 2.0の Govern 機能は、サイバーセキュリティの役割・責任・権限を確立して伝えること、組織のリーダーがリスクに責任を負うことを成果として示しています。同資料は、法令・規制・契約上の要求を理解して管理し、要求や脅威、技術、組織の使命の変化を反映して方針を見直し更新することも示しています。公開日は2024年2月26日です。
経営者が見る論点は、「この回答は現在の事実だけか」「追加の約束を含むか」「契約や社内方針を変えるか」の三つです。設定画面の細部は技術担当者が検証できる形へ整え、経営者には引き受ける約束を決められる形で上げます。その翻訳役が不在なら、経営と技術をつなぐ人がいないと、会議は決まらないで整理したように、誰が論点を経営判断へ変換するかを先に決める必要があります。
IPAの同事例でも、対策状況に懸念があり、現場判断で取引先変更などをすぐに行うことが難しい場合、調査結果を経営者へ報告し、組織としてリスク対応方針を検討しています。僕なら、現場で決められない論点が出た時点で、責任者へ上げる経路が機能しているかを確認します。
レビューは、次の順序に固定すると迷いが減ります。
- 営業が原文の質問、顧客の意図、提出条件を台帳へ移し、答えを先に作らない。
- 技術担当者が実装を確認し、文書・関係者への確認・実際の状態の確認から適切な証跡をひも付ける。
- 技術確認の結果に応じて三分類を付け、回答文の範囲・前提・例外をそろえる。
- 条件付き、未対応、追加対応を含む行を責任者が判断し、承認後の文面だけを顧客へ返す。
- 要求、技術、社内方針が変わったときに再確認できるよう、次回確認契機を残す。
この順序では、顧客の意図を持つ営業、実装を知る技術担当者、約束を決める責任者が、異なる判断を分担します。経営者が読む範囲は、経営判断が必要な行に絞ります。営業も顧客の意図と提出条件を管理する役割でレビューに加わります。
回答を送る前に、会社として引き受ける条件を決める
送信前の最終確認では、チェックシート全体を眺めるより、「条件付き」と「未対応」に絞ってください。確認するのは、証跡の不足を追加確認で解消できるか、対象範囲を限定すれば事実として答えられるか、追加対応が必要なら誰が承認するかです。ここが決まらない回答は、営業上の期待だけが先に立つため、まだ送れる状態ではありません。
回答後も台帳を閉じません。顧客への回答が契約上の要求や社内方針の変更につながった場合は、責任者が判断できる状態を保ちます。判断の背景と見直す条件を残す考え方は、CTO代行を入れると、組織の意思決定はどう変わるのかにもつながります。外部の肩書きの有無にかかわらず、営業と技術の間にある決定を引き受ける人が必要です。
顧客から届いた一つの質問票を使い、回答台帳に三分類、証跡の所在、範囲・前提・例外、確認者と承認者を入れてみてください。実施済みは証跡と一致した現在の実装に限り、条件付きは境界と承認待ちを明示し、未対応は将来の予定と分けます。この条件を会社として共有できれば、セキュリティチェックシートの回答は、実装と約束をそろえる経営判断の記録になります。
次に読む