---
name: security-questionnaire-answers
description: 顧客から届いたセキュリティチェックシート（委託先のセキュリティ評価、CAIQ、情報セキュリティ審査、デューデリジェンスの質問票）の回答案を、自社のポリシーと事実だけから作る。わからない項目にはすべて担当者をつけ、裏づけのない認証や管理策は書かない。見込み客からセキュリティチェックシートが届いたとき、「委託先評価に記入してほしい」と言われたとき、成約前に購買部門がセキュリティの回答を求めているときに使う。
---

# セキュリティチェックシートの回答

> 法的助言ではない。弁護士の確認に備えるための最初の点検であり、その代わりにはならない。[要確認: 日本の法令・契約実務は弁護士に]

セキュリティチェックシートの回答は、顧客への書面での約束であり、契約書に添付されることも多い。いちばんよい回答は、短く、本当で、送れる資料で裏づけられている。誰も証明できない「はい」より、計画つきの「いいえ」のほうが強い。

## 使う場面

- 見込み客の購買部門やセキュリティ担当から、質問票やスプレッドシートが届いたとき。
- 契約更新で、更新された委託先評価が届いたとき。
- 過去のチェックシートから、使い回せる回答集を作るとき。
- セキュリティポリシーそのものを書くこと、規格への準拠を主張することには使わない。それにはポリシーの責任者が、準拠については監査人が必要になる。

## 用意するもの

- 質問。元の番号のまま。
- 自社の根拠資料。セキュリティポリシー、過去に回答したチェックシート、監査報告書、構成メモ、委託先一覧、ユーザーが述べた事実。根拠がまったくなければ、書き始める前に一度だけ求める。一般的な知識から書かない。
- 未解決の項目の担当者（エンジニア、創業者など）。わからなければ「[担当: 要確認]」と書く。
- 任意: 商談の状況。どの質問が契約の妨げになるかを知るため。

## 手順

1. **根拠に索引をつける。** 根拠ごとに短い名前をつけて並べる（例:「アクセス管理規程 第2版、2026年3月」）。すべての回答は、この名前か、この会話でユーザーが述べた内容のどれかを引く。
2. **形式を見分ける。** Cloud Security Alliance の CAIQ のような標準の質問票は、管理策のフレームワークに対応した「はい／いいえ」の質問でできている。回答の選択肢と番号はそのまま残す。詳しいことは回答を変えずに、コメント欄に書く。
3. **質問を仕分ける。** 根拠から答えられる、一部だけ答えられる、わからない、のどれかに印をつける。わからないものは担当者をつけて未解決の一覧に入れる。「多くの会社ではこうしている」で埋めない。
4. **「はい／いいえ」を厳密に書く。** 「はい」は、その管理策が今あることを根拠が示しているときだけ。「一部」は、一部のシステムだけ、または一部の時間だけあるとき。どこかを書く。「いいえ」はないとき。ユーザーが代わりの管理策か計画を示していれば、それを続けて書く。「該当なし」は理由をつけるときだけ。
5. **認証を盛らない。** 認証、監査報告書、証明（SOC 2、ISO 27001、PCI DSS、ペネトレーションテスト）の名前は、ユーザーが報告書を出したか、日付と範囲つきで述べたときだけ書く。SOC 2 報告書は、AICPA の基準のもとで CPA 事務所（米国の公認会計士事務所）が発行する。報告書なしで「SOC 2 準拠」と書くのは盛りすぎだ。クラウド事業者の認証は自社のものではない。たとえば AWS の責任共有モデルは、クラウド「の」セキュリティ（事業者）と、クラウド「の中の」セキュリティ（顧客のデータ、アプリ、設定）を分けている。関係するなら「[事業者] 上で運用。[事業者] は [認証] を取得していると公表している」と書き、自社が取得しているように読ませない。
6. **回答は短くする。** 1〜3文。回答、仕組み、根拠の名前。宣伝の言葉（「銀行レベル」「軍事レベル」「完全に安全」）は使わない。
7. **契約上の約束に印をつける。** 約束を求める質問（◯時間以内の漏えい通知、データの保管場所、監査権）には「[約束: 弁護士に確認]」と印をつける。回答が契約の一部になることがあるからだ。
8. **回答シートと未解決の一覧を書く。** 回答をそのまま貼り戻せるよう、質問票の番号を残す。

## 出力の形式

```markdown
# セキュリティチェックシート — [顧客名]、[日付]

_法的助言ではありません。下記の根拠から作成した回答案です。送る前に確認してください。_

## 使った根拠
- [E1] [資料名、版、日付]
- [E2] [ユーザーの説明、日付]

## 回答
| # | 質問 | 回答 | 詳細 | 根拠 |
|---|---|---|---|---|
| [n] | [質問、短く] | [はい / 一部 / いいえ / 該当なし / 不明] | [1〜3文] | [E1] |

## 未解決の項目
| # | 必要なもの | 担当 | 契約の妨げになるか |
|---|---|---|---|
| [n] | [足りない事実や資料] | [名前または「担当: 要確認」] | [はい / いいえ / 不明] |

## 弁護士に確認する約束
- #[n]: [約束の内容] — [約束: 弁護士に確認]
```

## 例

**入力:** 予約管理アプリを提供する株式会社ヨヤクルの中村さんが、ひので損害保険株式会社から5つの質問を受け取った。根拠:「アクセス管理規程 第3版（2026年6月）: 管理ツールは全従業員が MFA つきの SSO で利用。アクセス権は四半期ごとに見直す。」ユーザーの説明:「AWS の東京リージョンで動いています。SOC 2 はまだで、9月に監査法人と始めました。バックアップは毎日取っています。」

> 1. SOC 2 Type II 報告書を取得していますか。  
> 2. すべての管理者アクセスに MFA を必須にしていますか。  
> 3. 顧客データはどこに保管されていますか。  
> 4. 保存データを暗号化していますか。  
> 5. 漏えいがあった場合、24時間以内に通知しますか。

**出力:**

```markdown
# セキュリティチェックシート — ひので損害保険株式会社、11月4日（水）

_法的助言ではありません。下記の根拠から作成した回答案です。送る前に確認してください。_

## 使った根拠
- [E1] アクセス管理規程 第3版、2026年6月
- [E2] 中村さんの説明、2026年11月4日

## 回答
| # | 質問 | 回答 | 詳細 | 根拠 |
|---|---|---|---|---|
| 1 | SOC 2 Type II 報告書 | いいえ | 当社は SOC 2 報告書を取得していません。2026年9月に監査の契約を始めました。 | [E2] |
| 2 | 管理者アクセスの MFA | はい | 全従業員が MFA つきの SSO で管理ツールを利用しています。アクセス権は四半期ごとに見直しています。 | [E1] |
| 3 | データの保管場所 | はい | 顧客データは AWS の東京リージョンに保管しています。 | [E2] |
| 4 | 保存データの暗号化 | 不明 | 根拠資料に記載がない。 | — |
| 5 | 24時間以内の漏えい通知 | 不明 | インシデント対応の規程が提出されていない。[約束: 弁護士に確認] | — |

## 未解決の項目
| # | 必要なもの | 担当 | 契約の妨げになるか |
|---|---|---|---|
| 4 | データベースとバックアップの保存時の暗号化を確認 | [担当: 要確認] | 不明 |
| 5 | インシデント対応の規程と、守れる通知までの時間 | 中村さん | 不明 |
| 1 | 共有するなら、SOC 2 報告書が出る見込みの時期 | 中村さん | 不明 |

## 弁護士に確認する約束
- #5: 24時間以内の漏えい通知 — [約束: 弁護士に確認]
```

## 送る前のチェック

- [ ] 出力の先頭に、法的助言ではない旨の一文がある。
- [ ] すべての「はい」が、その管理策が今あることを示す根拠を引いている。
- [ ] ユーザーが日付つきで示していない認証、監査、ペネトレーションテストの名前を書いていない。
- [ ] 事業者の認証を、自社のものとして書いていない。
- [ ] すべての「不明」が、担当者か「[担当: 要確認]」つきで未解決の一覧にある。
- [ ] 約束には弁護士確認の印がついている。

## よくある失敗

- 予定しているだけの管理策に「はい」と答える。予定なら「いいえ」と、その計画。
- 去年の回答を、今も本当か確かめずに写す。
- セキュリティの長い論文を書く。審査する側は、短く具体的な回答を高く評価する。