このページの要点
- 回答のうち約束にしたい部分だけを別紙に書き写し、それ以外は回答日時点の情報提供として整理する。
- 認証は、取得した法人・適用範囲・基準の版・有効期限を添えて書き、「準拠」と「取得」を混ぜない。
- 導入していない措置は列挙せず、「万全」「定期的に」「保証」などの言葉に引きずられず、頻度・主体・範囲を具体的に答える。
- 認証の失効や措置の変更、事故の初報は、通知・協議・顧客の出口まで契約に書いておく。
結論：チェックシートの回答は「営業資料」ではなく、後から約束として読まれうる書面として作る
法人向けのSaaSを導入する会社は、契約を結ぶ前に、提供者へ「セキュリティチェックシート」を送ってくることがよくあります。自社の情報や個人データを預ける相手の安全管理を確かめるための質問票で、決まった書式はありません。「はい・いいえ」や「○・△・×」で答える形式も、自由記述の形式もあります。提供者の側では、営業担当者が急いで埋めて返す扱いになりがちです。
ところが、この回答は、事故やトラブルが起きたときに「あのとき提供者はこう答えていた」という形で持ち出されます。契約書になくても、契約を結ぶ前提だったと主張される余地が残るからです。ISMS（組織の情報セキュリティ管理の仕組みが基準に適合していることを第三者が確認する認証）などを「取得している」と書いた場合は、認証の範囲や期限が実態と合っているかも問われます。先に結論を三つにまとめます。
- 回答の位置づけを、提供者が先に選ぶ：約束にしたい部分は別紙に書き写して契約の内容にし、それ以外は「回答日時点の情報提供であり、契約の内容ではない」と整理します。選ばずに放置すると、回答は「契約書にはないが、契約の前提にされた書面」という、いちばん扱いにくい位置に残ります。
- 認証の表明は、誰が・何について・いつ時点で・どの基準で、を添える：「ISMS認証取得済み」の一文だけでは、適用範囲の外で運用している場合や期限が過ぎた場合に、事実と食い違います。
- 回答・規約・プライバシーポリシーを同じ言葉に揃え、実施していない措置は書かない：書類ごとに強さの違う表現が並ぶと、顧客は最も強い表現を約束として読みます。
このページは、契約を結ぶ前後に出す「回答」と「認証の表明」の扱いに絞ります。個人データを預かる委託先としての定め（漏えいの通知、再委託、報告と監査）はSaaSの委託先と個人情報のページ、責任の上限はSaaSの責任制限のページ、利用者アカウントの管理の分担はアカウントとセキュリティのページで扱っています。以下は一般的な説明です。
チェックシートは、なぜ顧客から送られてくるのか
理由は、顧客の側の義務にあります。個人情報保護法は、個人データの取扱いを委託する事業者に、委託を受けた者への必要かつ適切な監督を求めています（25条）。SaaSに個人データを載せる顧客は提供者を監督する立場に置かれ、チェックシートはその記録として使われるため、更新や機能追加のたびに再び届くこともあります。
回答は契約の内容になるのか：取り込む、排除する、放置する
多くのSaaSの契約書には、締結前の書面・口頭のやりとりに優先する趣旨の完全合意条項があります。これがあれば、回答は契約の内容にならない、と読むのが条項の趣旨に沿います。ただし、これだけで責任がなくなるわけではありません。顧客が判断の材料にした事実は残るからです。提供者の選択肢は三つに分かれます。
- 取り込む：約束にしたい部分だけを、別紙「セキュリティ対策の概要」に、実施している措置として書き写します。回答書を添付するなら、基準日と、契約の内容とする範囲を限ります。契約の内容にした以上、実施していなければ債務不履行になりえます。
- 排除する：完全合意条項と回答書の冒頭の注記で、回答は情報提供であり契約の内容ではないと整理します。故意に事実と異なることを答えた場合まで排除するとは書けず、顧客の審査が通らず、結局は別紙に取り込む交渉になることもあります。
- 放置する：事故のあとに、契約の内容か前提かが争われ、書類ごとの食い違いがそのまま責任の議論の材料になります。
整った形になりやすいのは、約束にしたい部分を別紙に取り込み、それ以外は回答日時点の情報提供として排除する組合せです。別紙を契約書類のどこに置くか（優先順位）は、SaaS契約の組み立てのページで説明しています。
契約の内容にならなくても、責任が消えるとは限らない
回答が事実と異なっていたとき、顧客の側から主張されうる筋道（一般的な整理）
| 筋道 | 根拠となる規定 | 主に問われること |
|---|---|---|
| 契約上の義務の違反 | 民法415条（債務不履行） | 回答が別紙などで契約の内容に取り込まれていたか。その措置を実施していたか |
| 錯誤による取消し | 民法95条1項2号・2項 | 顧客が基礎とした事情が真実に反し、その事情が基礎とされていることが表示されていたか |
| 詐欺による取消し | 民法96条1項 | 事実と違うと知りながら答えて、顧客を誤信させたか |
| 不法行為による賠償 | 民法709条 | 故意又は過失で、顧客の権利や法律上保護される利益を侵害したか |
| 不正競争としての誤認表示 | 不正競争防止法2条1項20号・4条 | 役務の質や内容を誤認させる表示が、取引に用いる書類や通信にされたか。故意又は過失があるか |
最後の筋道は見落とされがちです。2条1項20号は、役務の質や内容を誤認させる表示を、広告のほか「取引に用いる書類若しくは通信」にすることも対象にしています。チェックシートの回答が当たるかは個別の事情によりますが、認証を取得していないのに取得していると答えるような場合は、この条文の関心と重なります。錯誤の取消しでは、事情が基礎とされていることが「表示されていた」ことが必要で（民法95条2項）、回答書の冒頭の注記は、この要件を意識した工夫です。
実務で多いセキュリティ条項の六つの型と、それぞれの弱点
SaaSの規約、プライバシーポリシー、保守や開発の委託契約、顧客から示される秘密保持契約を見比べると、セキュリティに関する条項は次の六つの型に集まります。回答がこれらと食い違わないよう、先に自社の書類がどの型かを確かめます。
セキュリティ条項の六つの型
| 型 | 典型的な書き方 | 弱点 | 直し方 |
|---|---|---|---|
| 努力義務・無保証型 | 合理的な範囲で安全管理措置を講じるよう努める。不正アクセス等の完全な防止は保証しない | 何をしているかが書かれず、審査で「措置が不明」と返される | 努力義務は残し、措置の概要を別紙へ。事故の通知を併せて置く |
| 措置列挙型 | アクセス制御、通信・保存の暗号化、ログ、診断、教育などを並べる | 列挙したものは約束と読まれる。頻度や範囲が実態とずれる | 実施しているものだけを、主体と頻度を決めて書く |
| 別紙参照型 | 安全管理措置は別紙の基準に基づき実施する | 措置を事前通知なく変更できる条項と衝突する | 変更は水準の維持を条件にし、重要な変更は通知する |
| 事故通知型 | 事故又はそのおそれを知ったときは直ちに報告し、原因の特定、再発防止、報告書の提出を行う | 「直ちに」「おそれ」が広く、守れない約束になる | 初報の期限、続報の事項、報告書の範囲を段階に分ける |
| 監査型 | 事前に日時・範囲・方法を通知して監査し、不備は是正して報告する。費用は請求側が負担し、重大な過失があったときだけ受ける側が負担する | 監査人の資格と、他の顧客の情報に触れない方法が決まっていない | 書面報告を原則とし、立入りは協議。監査人の条件を足す |
| 保存方法の禁止型（顧客の雛形） | 暗号化されていない電子保存、外部ストレージやクラウドサービスへの保存を、書面による承諾なしに禁止する | SaaSの提供者は、事業の性質上クラウド基盤に保存している。そのまま受けると契約の初日から違反状態になる | 標準の構成（基盤、暗号化、保存場所）を別紙に書き、承諾済みの保存先とする |
最後の型は気づかずに署名されやすいため、署名の前に回答書の構成と両立するかを見比べます。
ISMS・プライバシーマーク・SOC 2：認証や報告書を「取得している」と書くときの確認事項
認証や第三者の報告書は、チェックシートでもっとも強い回答材料で、書き方の誤りの影響も大きくなります。まず、よく出てくるものが一般に何を示すかを整理します。
よく出てくる認証・報告書と、書くときに付ける情報
| 名称 | 一般に示すこと | 書くときに付ける情報 | ずれやすい点 |
|---|---|---|---|
| ISMS認証（ISO/IEC 27001、国内ではJIS Q 27001） | 組織が定めた適用範囲の情報セキュリティマネジメントシステムが基準に適合していること | 取得した法人、認証機関、適用範囲、基準の版、有効期限 | 適用範囲の外の拠点やサービスで運用している。審査には定期の周期があり、期限の管理が要る |
| プライバシーマーク | 個人情報の取扱いに関する制度で、付与は法人単位 | 付与された法人、有効期間 | システムの技術的な安全性を示す制度として答える。グループ会社の取得を自社のものとして書く |
| SOC 2などの保証報告書 | 第三者が、サービス提供組織の統制について出す保証報告書 | 報告書の種類、対象のサービス、対象の時点又は期間、発行者 | 対象のシステムが顧客の使う機能と異なる。対象期間が過ぎている |
各制度は改定されることがあるため、書くときは運営団体の最新の案内と自社の認証書で確認します。書く前の確認事項は共通しています。
認証・報告書を書く前の五つの確認
- 誰が：取得しているのは、契約の当事者となる法人か。グループ会社や基盤事業者のものではないか。
- 何について：適用範囲に、顧客が使うサービス、開発・運用の拠点、顧客データを保存する環境は入っているか。
- いつ時点で：記載した有効期限や報告書の対象期間は、契約の開始後も続くか。回答の基準日はいつか。
- どの基準で：基準の版や種類（ISMS認証と、クラウドサービスに特化した認証の別など）を書いたか。「準拠」と「認証取得」を混ぜていないか。
- 今も続いているか：失効、停止、範囲の縮小があれば、回答を直す手順があるか。
「取得に向けて準備中」と書く場合は、顧客がそれを前提に契約を結ぶこともあります。未取得であることを先に書き、予定の時期は、書くなら実現を約束するものではないと添えます。
よくある失敗と直し方：規約・プライバシーポリシー・回答書に見られる書き方
規約、プライバシーポリシー、委託契約のセキュリティ記述には、実態を超えて読める書き方、書類の中で強さが食い違う書き方、結果を約束するように読める書き方が繰り返し見られ、回答も同じ型に陥ります。誤りやすい書き方と整えた書き方を並べます（一般的な例です）。
書き方の例（一般的な例） セキュリティの回答・説明の書き方
認証の表明
理由適用範囲の外や期限切れの状態があると、一文が事実と食い違います。範囲と期限があれば、顧客は自分で判断できます。
措置の列挙が実態を超える
理由他社のポリシーや大企業向けの雛形を写すと、実際に導入していない措置が並びます。列挙したものは約束と読まれ、「定期的に監査」と書けば実施しない年が約束違反の疑いになります。
「万全」と「保証しない」の同居
理由顧客や利用者は強い表現のほうを引用します。弱い表現が別の書類にあっても、強い表現を取り消してくれません。
見出しと本文のずれ
理由1項が保存データの暗号化まで約束していると読まれる一方、2項に保存の説明はなく、実態と一致するか確かめられません。
診断の頻度
理由「定期的」は頻度も主体も分かりません。「年1回」と書いた書類が複数あるのに実施しない年があると、約束違反になります。
措置の変更権と免責の広がり
理由措置を別紙に取り込む顧客は、無制限の変更権では取り込む意味がないと考えます。「攻撃による損害は一切」だと、措置を怠った場合まで免責と読めます。
通知期限の食い違い
理由顧客は最も短いものを約束として読みます。守れない約束や、適用場面の違う約束は、事故の際に債務不履行の議論になります。
保守契約の「セキュリティ対策」
理由「保守契約を結んでいたのに、なぜ事故が起きたのか」という苦情は、結果を約束するように読める書き方から生じます。提供条件はSLAのページにあります。
基盤事業者・提供者・顧客の責任を層に分けて書く
クラウド基盤の上でサービスを動かす提供者の書面には、「共有責任モデル」と呼ばれる整理を置くものがあります。基盤事業者の認証を自社のもののように書く誤りを避けるため、誰がどの層に責任を負うかを分けて書きます。
三つの層と、回答に書くときの注意
| 層 | 主な内容 | 書くときの注意 |
|---|---|---|
| 基盤事業者の層 | 物理的な設備、ネットワークの冗長性、基盤の可用性 | 基盤事業者の認証や報告書は、この層の範囲に限ると断って書く。提供者の認証と並べて混ぜない |
| 提供者の層 | アプリケーション、利用者アカウントの管理機能、データへのアクセス制御、操作ログの保全、再委託先の管理 | 別紙に実施している措置として書く。約束になるのはこの層だけと整理する |
| 顧客の層 | 利用する端末とネットワーク、利用者の登録と削除、パスワード等の管理、連携する外部サービスの認証情報 | 規約の責任と整合させる。提供者の層の欠陥まで顧客の責任と読める書き方にしない |
顧客の層の責任ばかりを長く書き、提供者の層の措置が空白の規約もあります。審査では「提供者の義務がない」と読まれ、事故のあとは免責の及ぶ範囲が争点になります。外国の事業者に個人データの取扱いを委ねる場合の説明でも、提供先の認証の名称と範囲と、自社の「同等と認識している」という評価は分けて書きます。
回答の鮮度の保ち方
回答の誤りの多くは、質問の言葉に引きずられて起きます。「すべての」「常に」と聞かれれば例外が1件で虚偽になり、「保証できるか」に「できる」と答えれば結果債務のように読まれ、「準拠しているか」に「はい」と答えれば認証の取得と区別がつきません。認証の有無と参考にした基準は分けます。回答は、質問の項目、内容、根拠の資料、回答者と確認者、回答日、次の見直し日を台帳に残します。
認証が失効したとき、回答の誤りに気づいたとき：契約でどう備えるか
認証を別紙に書いた、あるいは回答を契約の内容にした場合、次に決めるのは、事情が変わったときの扱いです。認証や措置を「維持する」と約束する維持義務型は、更新審査に通らなかったことが債務不履行になるため、提供者には最も重い設計です。変更の通知も約束しない参考情報型は、顧客の審査が通らないことが多くなります。落ち着きどころは、変わったときは知らせて代替措置を協議する通知・協議型で、維持義務型を求められたときは、維持の対象を「認証」ではなく別紙の「措置」に置き換える交渉がありえます。
通知・協議型の条項は、たとえば次のように書きます。説明のために書き起こした条文例で、括弧の空欄は、サービスの運用と顧客との交渉に合わせて埋めます。
条文例セキュリティに関する回答と認証の変更（条文例）
- 乙が本契約の締結前に甲の質問票に回答した内容のうち、別紙「セキュリティ対策の概要」に記載した事項は、本契約の内容とします。それ以外の回答は、回答日時点の情報の提供であり、本契約の内容を構成しません。ただし、乙が事実と異なることを知りながら回答した場合は、この限りではありません。
- 別紙に記載した認証について、失効、取消し、停止、又は適用範囲から本サービスが除かれる変更があったときは、乙は、これを知った日から（ ）日以内に、その事実と理由を甲に通知します。
- 乙は、前項の通知の後、代替の措置及び回復の見込みを甲に説明し、甲と誠実に協議します。
- 前項の協議が（ ）日以内に調わないときは、甲は、書面で通知することにより、本契約を解約することができます。この場合の未経過期間の料金の取扱いは、第○条によります。
- 乙は、別紙に記載した措置を変更する場合は、変更後の措置が全体として同等以上の水準を維持するものであることを条件とし、重要な変更は事前に甲に通知します。
- 乙は、第1項の別紙に記載した内容に誤りがあることを知ったときは、速やかに甲に通知し、訂正します。
第1項のただし書は、故意による場合まで責任を排除できないことを前提とした書き方です。第4項の解約の出口は、期間・自動更新・中途解約の条項との整合を取ります。第6項は、起算点を「知ったとき」とすると、守れない約束になりません。
次は、措置の別紙と事故の通知を規約の側に置く形です。「直ちに」を避け、初報と続報に分けて期限を定めます。
条文例別紙の措置、再委託先、事故の通知（条文例）
- 乙は、別紙「セキュリティ対策の概要」に記載した措置を講じて本サービスを提供します。乙は、不正アクセス等を完全に防止することを保証しません。
- 乙は、甲のデータを取り扱う再委託先を別紙に記載し、別紙にない再委託先に取り扱わせるときは、事前に甲に通知します。乙は、再委託先の行為について、自己の行為と同様に責任を負います。
- 乙は、甲のデータの漏えい等が生じたこと、又は生じた可能性が高いことを知ったときは、知った時から（ ）時間以内に、判明している事実を初報として甲に通知し、その後、原因、影響を受けたデータの範囲及び講じた措置を、判明したものから順次通知します。甲の求めがあるときは、原因及び再発防止策をまとめた報告書を（ ）日以内に提出します。報告書に、他の顧客の情報及び乙の運用上の秘密を含める義務はありません。
初報の数字は、顧客が法令上の報告や本人への通知を行う期限に間に合うかを見て決めます。委託を受けた事業者が委託元へ所定の通知をしたときは、委員会への報告を要しないとされ（個人情報保護法26条1項ただし書）、提供者の通知が速いほど顧客側の対応が間に合います。守れる時間を、運用の実態から決めます。
三つ目は、層ごとの責任と、外部の脆弱性診断の結果の開示を定める形です。
条文例層ごとの責任と、診断結果の開示（条文例）
- 本サービスの提供に用いる基盤事業者が管理する範囲（物理的な設備及び基盤のネットワーク）の措置は、当該事業者の定めるところによります。乙は、別紙に記載した、乙が管理する範囲（アプリケーション、利用者アカウントの管理機能、データへのアクセス制御及び操作ログの保全）の措置について責任を負います。
- 甲は、甲が管理する端末及びネットワーク、利用者アカウントの登録及び削除、並びに認証情報の管理について責任を負います。ただし、乙が管理する範囲の欠陥が原因で生じた損害については、この限りではありません。
- 乙は、外部の専門事業者による脆弱性診断を実施したときは、甲の求めに応じて、実施時期、対象及び指摘への対処状況の概要を提供します。報告書の全文は、秘密保持義務を負う甲の担当者に限り、乙が指定する方法で閲覧に供します。
- 前項の概要及び報告書は乙の秘密情報とし、甲は、乙の承諾なく第三者に開示しません。
第2項のただし書がないと、提供者の管理範囲の欠陥まで顧客の責任と読まれるおそれがあります。第3項は、全文の提供を約束した形になるのを避けています。
顧客の契約書の雛形から、質問票に流れ込む六つの要求
顧客は、チェックシートで足りないと考えると、監査を求めてきます。質問票の項目は、顧客の側の秘密保持契約や委託契約の雛形から来ていることが多く、雛形の要求と質問票での聞かれ方、整え方を対応させておくと、回答が早くなり、契約書との食い違いも防げます。
雛形の要求と質問票の対応（一例）
| 雛形の要求 | 質問票での聞かれ方 | 提供者側の整え方 |
|---|---|---|
| 暗号化、多要素認証、操作ログ、データセンターの所在国を別紙に列挙し、クラウドの利用は承諾制とする | 「保存データを暗号化しているか」「データの保存国はどこか」 | 標準の構成を別紙に一度書き、承諾済みの構成として示す。契約相手の所在国と、処理・保存する地域は分けて書く |
| 再委託は事前の書面承諾とし、同等の義務を課した書面の写しを提示させる | 「再委託先の一覧と管理方法」 | 役割別の一覧を別紙にし、変更は通知。写しを出せる範囲は、各再委託先との秘密保持の都合で決めておく |
| 事故は短い時間内に書面で通知し、原因と再発防止策を報告させる | 「通知までの時間」 | 初報は電子メール等、続報を書面とし、実際に出せる時間で書く |
| 終了時は期限内に復元できない方法で削除し、完了を書面で報告させる | 「削除の方法と証明」 | バックアップを含めた削除の完了時期を分けて書き、削除完了の報告の方法を決める |
| セキュリティポリシーの運用状況と内部監査の結果を、求めに応じて定期的に報告させる | 「監査結果の開示」 | 開示する書類の種類を、次の表のように決めておく |
| 複製・保存は必要最小限とし、個人端末や私用のクラウドへの保存を禁じる | 「私物の端末の利用可否」 | 従業員の端末の運用規程を、事実のとおりに答える |
認証と報告書を、監査の代わりに使う：開示の範囲を決める
立入りの監査を無制限に受けると、運用の負担が大きく、他の顧客の情報の保護にも支障が出ます。そこで、認証や第三者の報告書を示して監査に代える整理が役に立ちます。監査条項そのものは委託先と個人情報のページにあるため、ここでは開示に絞ります。
認証・報告書の開示の仕方を、情報の種類ごとに決める（一例）
| 情報 | 開示の仕方の例 | 理由 |
|---|---|---|
| 適用宣言書、運用規程 | 秘密保持契約の下で、閲覧に限る | 内部の管理策の構成が分かり、攻撃の手がかりになりうる |
| 脆弱性診断の報告書 | 概要を提供し、全文は閲覧に限る。技術的な詳細は出さない | 未対処の弱点の情報は、漏れたときの被害が大きい |
| 立入りの監査 | 事故があったときに、範囲と日程を協議して行う | 他の顧客の情報の保護と、運用の負担 |
顧客の雛形の監査条項を受けるときは、監査人が競合の関係者でないこと、他の顧客の情報に触れない方法をとることを足します。診断報告書の全文を渡す義務は、約束しない限り当然には生じません。開発を外部に委託した契約で、診断報告書を成果物に挙げ、診断料を報酬と別建てにする例もあります。その場合は、診断料の支払期日が診断の実施や報告書の納品と連動しているか、報告書を顧客に開示してよいかも決めておきます。
ヒヤリングで確認すること：回答と認証の方針を決める前に
ヒヤリングの問いと理由チェックシートと認証の表明を整える前に
取得している認証や報告書の名称、取得している法人、適用範囲、有効期限と次の審査の時期を教えてください。
取得した法人や適用範囲によって、書ける内容が変わります。契約期間のなかで期限が到来するなら、通知条項が要ります。
チェックシートの回答は誰が作り、誰が事実を確認し、どこに記録していますか。
営業担当者だけで回答していると、根拠のない「はい」が混ざります。記録がなければ、故意でないことの説明も難しくなります。
これまでの回答書、営業資料、提案書、規約、プライバシーポリシーのセキュリティの記述を、並べて見せていただけますか。
「万全」と「保証しない」の同居や、通知の期限、診断の頻度、暗号化の範囲の食い違いは、並べて読まないと見つかりません。
書面に列挙した措置のうち、まだ導入していないもの、頻度や担当が決まっていないものはありますか。
他社の書面を写して列挙した場合、侵入検知の仕組み、外部の監査、多要素認証などが未導入のまま並んでいることがあります。「定期的」と書いた措置が行われていないと、約束違反になります。
基盤事業者と再委託先ごとに、扱うデータの範囲、取得している認証、責任の分け方を説明した文はありますか。
自社の認証と基盤事業者の認証を分けて書くために必要です。再委託先の一覧は、個人データの委託の定めとも一致させます。
外部の脆弱性診断や保守を委託しているなら、委託契約で、報告書の帰属、顧客への開示の可否、診断料の支払時期、保守の作業項目と頻度はどう決まっていますか。
報告書を顧客に見せてよいかが決まっていないと、開示のたびに交渉になります。保守の範囲が結果の保証に読めると、事故のあとに苦情になります。
顧客から、回答書の契約書への添付、結果の保証、保存方法の禁止、立入りの監査、定期報告、削除の証明を求められたことはありますか。
求められた経験があれば、別紙に取り込む設計を先に用意できます。保存方法の禁止は、標準構成と両立するかの確認が要ります。
事故の疑いが出たとき、誰が、何時間以内に、顧客のどの窓口へ初報を出せますか。
初報の期限は、実際に出せる時間より短く書くと守れない約束になります。条項に書く前に、運用の実態を確かめます。
起きがちなこと
セキュリティの回答と認証の表明で起きがちなこと
- 営業担当者が回答を作り、免責との整合を誰も見ていない。
- 「ISMS認証取得済み」とだけ書き、適用範囲の外の拠点やサービスで運用している。基盤事業者の認証を自社のもののように書く。
- 他社のポリシーや海外の制度の書き方を写し、導入していない措置や守れない期限が並ぶ。
- 「定期的に脆弱性診断を実施」と書いたが、実施しない年があり、約束違反の疑いが生じる。
- 規約・プライバシーポリシー・回答書で、通知の期限や暗号化の範囲、「万全」と「保証しない」が食い違っている。
- 顧客の雛形にある保存方法の禁止を見落とし、署名の初日から違反状態になる。
よくあるご質問
セキュリティチェックシートの回答は、契約書の一部になりますか？
回答書そのものが自動的に契約の一部になるわけではありません。完全合意条項があれば、契約前の書面は契約の内容にならないと読むのが条項の趣旨です。ただ、顧客が判断の材料にした事実は残るため、約束にしたい部分は別紙に書き写して契約の内容にし、残りは回答日時点の情報提供と整理する設計が使われます。
ISMS認証を取得していなければ、チェックシートに答えられませんか？
答えられます。取得していないなら、取得していないと書いたうえで、実際に講じている措置（規程の整備、アクセス制御、診断の実施など）を具体的に書きます。「準拠」という言葉で認証の取得を匂わせる書き方は避けます。
認証の取得に向けて準備中、と書いてもよいですか？
書くことはできますが、顧客が契約の前提にすることがあります。未取得であることを先に書き、予定の時期は書かないか、書くなら実現を約束するものではないと添えます。
外部の脆弱性診断の報告書は、顧客に渡さなければなりませんか？
契約で開示を約束しなければ、全文を渡す義務は当然には生じません。概要の提供にとどめる、秘密保持契約の下で閲覧に限る、といった方針を事前に決めておきます。「診断結果を開示する」とだけ書くと、全文の提供を約束した形になります。
規約には「保証しない」と書いてあるので、プライバシーポリシーや回答書に強い表現を書いても問題ありませんか？
問題が残ります。顧客や利用者は強い表現を約束として引用するため、弱い表現が別の書類にあっても打ち消されません。「万全」のような言葉は避け、講じている措置を主体と頻度とともに書き、保証しない旨はどの書類にも同じ言い方で添えます。
あわせて読みたいページ
本ページは一般的な情報提供です。個別の取引への当てはめは、サービスの仕組みや契約の経緯によって異なることがあります。書き方の例として紹介している内容は、一般に見られる書き方を整理した例で、特定の事業者や案件を示すものではありません。条文は e-Gov法令検索（法令API）で確認しています（最終確認日：2026年10月22日）。参考: e-Gov法令検索 / 個人情報保護委員会 / 経済産業省 / 国税庁
