取引先セキュリティチェックシートの回答管理｜根拠・承認・有効期限を揃える方法
取引先から届くセキュリティチェックシートは、会社ごとに設問の表現や粒度が違います。提出済みのExcelやPDFだけを保管していると、似た設問へ違う回答を返したり、失効した認証書を再利用したり、製品変更前の説明を残したりします。回答の速さより先に、同じ主張を同じ条件で再現できる仕組みが必要です。
結論：取引先セキュリティチェックシートの正本は、提出ファイルではなく「統制ID・標準回答・適用範囲・根拠資料・責任者・承認状態・有効期限」を結び付けた回答ライブラリにします。受領した設問を統制IDへ対応付け、標準回答をそのまま使えるか、補足が必要か、例外承認が必要かを判定してから提出物を作ります。製品仕様、委託先、認証、インシデント、契約条件が変わったら、影響する回答だけを検索して再確認します。
安全な回答運用は、答えを使い回すことではなく、同じ主張を同じ根拠・適用範囲・承認状態で再現できることです。
本記事のポイント
- 回答の正本は提出済みファイルではなく、統制ID・標準回答・根拠・適用範囲・承認状態を結び付けた回答ライブラリです。
- 根拠は認証書だけに寄せず、文書の確認・責任者への確認・設定や運用の検証を組み合わせ、有効期限と再確認条件を持たせます。
- 製品仕様、委託先、認証、インシデント、契約条件が変わったら影響する回答を検索し、再承認してから次の質問票へ流用します。
回答の正本を「提出ファイル」から分離する
提出ファイルは取引先とのやり取りを証明する記録ですが、次の案件で再利用する正本には向きません。同じ内容でも「暗号化していますか」「保存データの保護策は何ですか」「顧客データはどの方式で保護されますか」のように設問が変わり、回答欄の長さや選択肢も異なるからです。提出ファイルをコピー元にすると、どの回答が最新か、どの製品・プラン・地域へ適用できるかを判定できません。
正本は、設問文ではなく自社の統制や説明責任を中心に組み立てます。たとえば「保存データの暗号化」を一つの統制IDにし、その下へ標準回答、対象製品、対象環境、根拠資料、例外、承認者を置きます。取引先の設問は、この統制IDへ対応付けてから回答します。CSAのCloud Controls Matrix（CCM）v4.1は17ドメイン・207統制からなるクラウド向け統制フレームワークで、CAIQはその統制に沿った質問票です。自社の統制IDをCCMや利用している規格へ対応付けておくと、設問の表現が違っても同じ管理策へ寄せやすくなります。
| 管理対象 | 役割 | 正本にするか | 更新の起点 |
|---|---|---|---|
| 回答ライブラリ | 統制ごとの標準回答、適用範囲、根拠、承認状態を管理する | する | 製品・運用・契約・認証の変更 |
| 根拠ライブラリ | 規程、手順、設定記録、試験結果、認証書などを管理する | する | 改訂、失効、再評価、責任者変更 |
| 取引先別の提出ファイル | どの時点で何を回答したかを証明する | しない | 提出、差し戻し、契約変更 |
| メールやチャット | 質問の背景、補足、承認経緯を残す | しない | 照会、追加説明、承認 |
標準回答は「はい／いいえ」だけにしません。最低限、主張、適用範囲、条件、参照できる根拠、最終確認日を持たせます。「保存データは暗号化される」という主張でも、本番環境だけか、バックアップも含むか、顧客が鍵を管理できるかで意味が変わります。SaaSのセキュリティ認証・第三者保証の見方で確認する対象範囲と期間も、回答へ直接ひも付けます。
設問を統制IDへ寄せ、回答を3種類に分ける
受領した設問をそのまま新しい回答として登録すると、ライブラリはすぐに重複します。まず設問の目的を読み、「何のリスクを、どの対象について、どの強さで確認しているか」を分解します。そのうえで既存の統制IDへ対応付けます。対応付けられない設問だけを、新しい統制候補としてセキュリティ責任者へ回します。
回答は次の3種類へ分けると、営業やカスタマーサクセスが独自判断しにくくなります。
| 回答区分 | 判定条件 | 扱い | 承認 |
|---|---|---|---|
| 標準回答 | 対象製品・プラン・地域・契約条件が標準の適用範囲内 | 承認済み文面と根拠をそのまま使う | ライブラリの承認で足りる |
| 補足回答 | 主張は同じだが、取引先の用語や回答欄に合わせた説明が必要 | 標準回答を変えず、補足欄に差分を記録する | 事前に定めた担当範囲で確認する |
| 例外回答 | 未実施、適用外、条件付き、将来対応、個別契約が必要 | リスク、代替策、期限、顧客への影響を明記する | 統制責任者と必要に応じて法務・事業責任者が承認する |
「将来対応予定」を標準回答へ混ぜてはいけません。現時点の事実と、契約上確約できる内容を分けます。未実施の管理策は、実施済みのように見える表現へ丸めず、「未実施」「適用外」「代替策あり」のどれかを明示します。取引先がYes／Noしか受け付けない場合でも、補足欄や別紙へ条件を書き、社内台帳には元の判断を残します。
取引先固有の要求が契約条項、SLA、データ処理条件へつながる場合は、セキュリティ担当だけで決めません。契約上の約束は法務、運用可能性は製品・インフラ責任者、商談条件は営業責任者が確認します。回答作業をRFP全体とつなげる場合は、営業RFP回答を安全に再利用する設計と同様に、回答項目ごとの所有者と承認状態を持たせます。
根拠・承認・有効期限を一つの台帳で管理する
質問票への回答は「説明できること」と「運用されていること」を分けて確認します。NIST SP 800-53A Rev. 5は、管理策の評価方法として、文書や記録を調べるexamine、担当者へ確認するinterview、仕組みや手順を動かして確かめるtestを示しています。質問票の根拠も、この3つを意識すると認証書だけへの依存を避けられます。
- 文書・記録：情報セキュリティ方針、アクセス管理手順、委託先台帳、バックアップ記録、教育記録、認証書、監査報告書
- 責任者の確認：統制責任者、製品責任者、インフラ担当、法務が、現行の運用と適用範囲を確認した記録
- 設定・運用の検証：設定値、権限レビュー、復旧試験、脆弱性対応、ログ確認など、管理策が働くことを確認した結果
根拠台帳には、資料名だけでなく、版、保管場所、対象範囲、所有者、機密区分、発行日、失効日、最終確認日を持たせます。認証書の有効期限が残っていても、対象製品や対象事業所が質問の範囲と一致しない場合は根拠になりません。反対に、外部認証がなくても、方針、設定、試験結果を組み合わせて現状を説明できる場合があります。
| フィールド | 記録例 | 空欄だと起きる問題 |
|---|---|---|
| 統制ID | DATA-ENC-01 | 似た設問の回答が別々に増える |
| 標準回答 | 現時点の事実、条件、対象範囲 | 提出者ごとに表現と約束が変わる |
| 根拠ID | 規程・設定記録・試験結果への参照 | 回答を後から説明できない |
| 統制責任者 | 情報システム、製品、法務など | 変更時に誰へ確認するか分からない |
| 適用範囲 | 製品、プラン、地域、環境、契約 | 別サービスの根拠を誤って流用する |
| 承認状態 | 下書き、確認中、承認済み、利用停止 | 未確認の回答が提出される |
| 有効期限・再確認条件 | 日付と変更イベント | 古い主張を期限なく使い続ける |
| 取引先別差分 | 追加説明、例外、契約上の約束 | 個別条件が標準回答へ混ざる |
有効期限は一律の年1回だけで管理せず、日付とイベントを併用します。認証書は失効日の前、規程は改訂時、委託先一覧は追加・終了時、製品仕様はリリース時、インシデント回答は事実関係や再発防止策が変わった時に再確認します。事例や公開文書の事実確認を版と承認でそろえる導入事例ドラフトのファクトチェック運用も、根拠・所有者・承認状態を分ける考え方として参考になります。
受付から再利用までを7段階で進める
回答時間を短くするには、受付後すぐに各部署へ設問を転送するのではなく、最初に質問票の範囲と優先度を確定します。NIST SP 1305は、サプライヤーの重要度を事業上の重要性、扱うデータの機密性、システムへのアクセスなどで分類し、重要度と影響に見合う要求を設定する考え方を示しています。自社が回答する側でも、取引先、対象製品、扱うデータ、契約規模、期限を確認すると、どこまで詳細な根拠と個別承認が必要かを決めやすくなります。
- 受付条件を確定する：取引先、対象製品、利用プラン、地域、扱うデータ、システム接続、提出期限、秘密保持条件、回答形式を記録します。
- 設問を分解して統制IDへ対応付ける：複合設問は論点を分け、既存統制へひも付けます。意味が曖昧なら、推測で埋めず取引先へ確認します。
- 標準・補足・例外を判定する：適用範囲が一致する標準回答、表現だけ補う回答、個別判断が必要な例外を分けます。
- 根拠の現在性と範囲を確認する：資料の版、対象、発行日、失効日、設定や試験の最終確認日を確認し、古い根拠を利用停止にします。
- 例外と契約上の約束を承認する：未実施、代替策、個別SLA、追加運用、将来対応を、統制責任者・法務・事業責任者の範囲に沿って承認します。
- 提出物を固定して記録する：最終ファイル、提出日時、提出者、承認版、取引先固有差分、追加質問を保存します。提出後にライブラリを変えても過去の回答は上書きしません。
- 変更と期限で再確認する：製品、委託先、認証、規程、インシデント、契約条件の変更をトリガーに、影響する統制IDと提出先を抽出し、回答を再承認します。
1件の質問票に複数製品や複数地域が含まれるときは、適用範囲を回答欄へ明記します。全社方針として共通する回答と、サービス固有の実装を混ぜると、全製品に同じ管理策があるように読めます。質問票の原文、正規化した論点、参照した統制ID、採用した回答版を残すと、差し戻しにも説明できます。
変更を検知して既存回答を再承認する
回答ライブラリは作成時より変更時に壊れます。新しい委託先を追加したのに「再委託はありません」が残る、認証範囲を変更したのに旧証明書を案内する、ログ保存期間を変えたのに以前の月数を答える、といった不一致は、質問票の担当者だけでは検知できません。
変更管理では、変更イベントと統制IDを結び付けます。製品の仕様変更なら製品責任者、委託先変更なら調達・法務、認証更新ならセキュリティ、契約条項変更なら法務が起点を登録します。影響する統制IDから、標準回答、根拠、未完了の質問票、過去に個別条件を伝えた取引先を検索し、必要なものを再承認します。
| 変更イベント | 見直す回答 | 確認する根拠 | 取引先への対応 |
|---|---|---|---|
| 新機能・構成変更 | データ保存、権限、ログ、可用性 | 設計、設定、試験、運用手順 | 未提出分を更新し、契約上の通知要否を確認 |
| 委託先の追加・変更 | 再委託、データ所在地、アクセス | 委託先台帳、評価、契約 | 通知・同意条件と過去回答を照合 |
| 認証の更新・失効 | 認証取得、対象範囲、監査期間 | 新旧証明書、監査報告、適用範囲 | 古い資料の共有を止め、参照先を更新 |
| 重大インシデント | 検知、通知、復旧、再発防止 | 確定した事実、対応記録、改善計画 | 契約・法令・個別回答に沿って通知 |
| 規程・契約の改訂 | 責任分界、保持期間、削除、監査権 | 承認済み規程、契約ひな型 | 標準回答と個別例外を再承認 |
誤った回答を見つけた場合は、正本だけを静かに直さず、影響範囲を確認します。どの取引先へ、いつ、どの版で提出したかをたどり、契約や信頼へ影響する場合は訂正します。公開情報の訂正でも履歴・影響範囲・再発防止を残すプレスリリース訂正の版管理と同様に、質問票でも旧回答を消さず、訂正理由と新しい承認版を残します。
経済産業省の方針を基にIPAが運営するサプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）も、発注側ごとに要求が異なることで受注側の負担が増える課題を示しています。制度の対象や確認方法は個別の契約・業界ルールと同じではありませんが、要求を重要度に合わせ、共通の基準と確認可能な状態へ寄せる方向性は、質問票運用の見直しにも使えます。
よくある質問（FAQ）
取引先セキュリティチェックシートの回答はどこを正本にしますか？
提出済みのExcelやPDFではなく、統制IDごとに標準回答、適用範囲、根拠、責任者、承認状態、有効期限を結び付けた回答ライブラリを正本にします。提出ファイルは、その時点で取引先へ何を伝えたかを証明する記録として別に保管します。
回答の根拠資料と有効期限をどう管理しますか？
根拠ID、版、保管場所、対象範囲、所有者、機密区分、発行日、失効日、最終確認日を記録します。認証書の期限だけでなく、規程改訂、製品変更、委託先変更、試験実施などのイベントでも再確認します。
取引先固有の例外回答を誰が承認しますか？
管理策の事実は統制責任者、契約上の約束は法務、製品や運用の実現性は製品・インフラ責任者、商談条件は事業責任者が確認します。例外の種類と金額・リスクに応じた承認表を先に決め、営業担当者だけで確約しない運用にします。
製品・委託先・認証の変更を既存回答へどう反映しますか？
変更イベントへ影響する統制IDを登録し、そのIDにひも付く標準回答、根拠、進行中の質問票、過去の取引先別差分を抽出します。新しい事実と根拠で再確認し、承認済みになるまで旧回答を新規提出へ使わないようにします。
質問の意味が分からない場合はどう答えますか？
自社に都合のよい解釈で埋めず、対象となる製品、データ、環境、期間、要求水準を取引先へ確認します。確認した前提を提出物と社内台帳に残し、同じ表現の設問が届いたときに判断を再利用できるようにします。
認証書があれば個別の根拠確認は不要ですか？
不要にはなりません。認証の対象組織、製品、拠点、期間、除外事項が質問の範囲と一致するかを確認します。認証範囲外の項目や最新の運用状況は、規程、設定記録、試験結果、責任者確認など別の根拠で補います。
運用の根拠に使える公的・公式資料
- Cloud Security Alliance：Cloud Controls Matrix v4.1では、クラウドの管理策を17ドメイン・207統制へ整理し、CAIQとの対応を確認できます。
- Cloud Security Alliance：Introductory Guidance to CCMでは、CAIQの調整、統制への対応付け、手順・技術設計・遵守証跡などの裏付けを管理する考え方を確認できます。
- NIST SP 800-53A Rev. 5では、管理策の有効性を文書確認、担当者確認、試験で評価する方法を確認できます。
- NIST SP 1305では、サプライヤーを重要度で分類し、要求、契約、検証方法をリスクに合わせる考え方を確認できます。
- IPA：サプライチェーン強化に向けたセキュリティ対策評価制度では、取引先ごとに異なる要求が発注側・受注側へ生む課題と、共通基準による確認の方向性を確認できます。
