営業ツール導入前のセキュリティチェックリスト｜情シス確認7項目

営業ツール（フォーム営業ツール・SFA・インサイドセールス支援ツールなど）の導入を進めようとしたときに、情シスから「セキュリティチェックシートを埋めてから稟議に上げてください」と差し戻された経験はないでしょうか。渡された社内テンプレートを開くと 100 項目以上あり、どこから手を付ければよいのか、ベンダーに何を聞けば埋まるのか、そもそも自社の営業ツール導入に本当に必要な項目はどれなのかが分からず、稟議が止まってしまうケースは少なくありません。

一方で情シスの側も、営業ツール固有の観点（送信除外の運用・接触履歴の管理・営業代行との情報共有）を汎用チェックシートだけで見抜くのは難しく、質問を繰り返した結果として稟議が長期化しがちです。結果として、営業部門・情シス・ベンダーの三者間で同じ確認事項が往復し、導入判断にかかる期間が想定より延びてしまいます。

汎用の SaaS チェックリストは「網羅性」を担保するために項目が多くなる一方で、営業ツール導入時の意思決定に本当に効く観点は 7 つ程度まで絞り込めます。7 つに絞る意味は、稟議段階で「この項目でツール候補を落とすかどうか」を早期に判別できるスクリーニング基準を持つこと、そしてベンダーヒアリングと稟議書起票の両方に同じ確認軸を再利用することにあります。

本記事では、営業ツール導入前に情シスが確認している 7 項目を、ベンダーへの質問例・稟議書への転記例とセットで整理します。一般 SaaS のチェックリストにはない「送信除外・接触履歴の管理」「営業代行・BPO 共有時の組織単位データ分離」「送信メタデータ（開封・クリック）の取扱い」など、営業ツール特有の観点を含みます。稟議書の作成前に手元で 7 項目を埋め、ツール候補ごとに横並び比較できる状態を目指してください。

営業ツールと一般 SaaS では情シスが見る観点が違う

営業ツールが扱う情報は、一般業務 SaaS（グループウェア・会計・勤怠管理など）と比べて次の 4 種類が特徴的です。

• 顧客個人情報: リード・見込み顧客の氏名・所属企業・役職・メールアドレスなど
• 送信先ドメイン: フォーム送信・メール送信の宛先となる企業ドメインリスト
• 接触履歴: 送信済み・返信・開封・クリック・失敗の記録
• 送信メタデータ: 開封・クリック計測タグ、短縮 URL、トラッキングピクセルなど

一般業務 SaaS では「社内情報を社内利用者だけに閲覧させる」ことが主眼になりますが、営業ツールでは「顧客情報を扱う」だけでなく「自社ドメインから外部の企業へ能動的に送信する」動作が発生します。この違いから、情シスは以下の 3 つを特に警戒します。

1. 顧客個人情報の漏洩: 個人情報保護法・自社のプライバシーポリシーとの整合。営業リストが外部に流出した場合の説明責任
2. 外部への誤送信: すでに他社（取引先・別チャネル）が接触済みの企業へ二重送信することによる信頼毀損、送信文面の取り違え、送信除外リスト未反映による事故
3. 営業代行・BPO との情報共有事故: 外部委託先にリストや文面を渡す運用で、他社データが混在する・退職者アカウントが放置される・退会後もデータが残り続けるリスク

こうした営業ツール特有の観点は、汎用 SaaS チェックシート（多くは 50〜170 項目）では基本セキュリティ項目に埋もれて見落とされがちです。100 項目を機械的に埋めるより先に、営業ツールに効く 7 項目を軸として押さえ、ツール候補間の差を早期に判別できる状態を作ることをおすすめします。

以降の章では、この 7 項目を「基本セキュリティ（項目 1〜3）」「営業ツール固有（項目 4〜5）」「組織・運用（項目 6〜7）」の 3 群に分けて解説します。稟議書の作成前に手元で埋めることを想定した粒度で、各項目に「情シスが見ている観点」と「ベンダーへの質問例」を併記します。

情シス確認 7 項目の全体像とチェック観点マップ

詳細に入る前に、7 項目の全体像を一覧で提示します。ツール候補の比較表としても、稟議書テンプレートの追記欄としても再利用できる形にまとめています。

7 項目の一覧表

3 群に分けた読み進め方

7 項目は次の 3 つのグループに分かれます。稟議差し戻しリスクの高さと、ツール間で差が付きやすい順に並べています。

• 基本セキュリティ（項目 1〜3）: 一般 SaaS でも共通の基礎項目。ここが未対応のツールは稟議の入り口で落ちる
• 営業ツール固有（項目 4〜5）: 汎用チェックシートではカバーされにくいが、営業ツール導入判断で最も差が付く領域
• 組織・運用（項目 6〜7）: 導入後の運用まで見通した確認項目。マルチテナント設計と第三者認証・インシデント SLA

以降、この順に 7 項目を「情シスが見ている観点」「ベンダーへの質問例（Q）」「営業ツールで特に注意すべきポイント」の 3 点セットで解説します。

【項目 1〜3】データ管理・認証・暗号化の基本セキュリティ

まずは一般 SaaS でも共通する基礎 3 項目から整理します。「基本」と書いていますが、この 3 項目のうち 1 つでも情シスの想定水準に届いていないと、稟議は入り口で差し戻されます。特に営業ツールでは「取り扱うデータの中に個人情報が含まれる」ことを前提に、保存期間・削除ポリシー・多要素認証をベンダーに確認してください。

項目 1: データ管理範囲と保存期間

情シスが見ている観点

• どのデータを・どこ（リージョン）に・どの期間保存するか
• 個人情報保護法上の「保有個人データ」の削除依頼への対応可否と手順
• 契約終了後のデータ削除ポリシー（削除タイミング・完全削除の証跡）
• サードパーティ（AI 利用・分析基盤）へのデータ渡し有無

ベンダーへの質問例（Q）

• Q1: 弊社が入力する顧客情報・送信履歴・添付ファイルは、どのリージョンのどのクラウド（AWS / GCP / Azure 等）に保存されますか
• Q2: データの保存期間はデフォルトで何日ですか。ユーザー側で短縮できますか
• Q3: 契約終了時のデータ削除ポリシーを教えてください（削除タイミング・削除範囲・完全削除の証跡）
• Q4: サービス提供時に外部の AI サービス（LLM 等）に顧客データを送信することはありますか。ある場合、送信先・データ範囲・オプトアウト可否を教えてください

営業ツールで特に注意すべきポイント

営業ツールでは「送信対象の企業ドメイン一覧」「送信履歴（成功・失敗）」「返信メール本文」の 3 つが特に大量に蓄積されます。契約終了時に「送信履歴だけ削除されない」「一部のメタデータが分析基盤に残る」といった仕様がないかを確認します。AI 機能を持つツールでは、フォーム自動発見や業種分類のために顧客データが外部 LLM へ渡る可能性があるため、渡す範囲と保持ポリシーを合わせて確認してください。

項目 2: 認証・アクセス制御

情シスが見ている観点

• 多要素認証（MFA）の必須化可否
• SSO 連携（SAML / OIDC）の対応可否と対応 IdP
• IP アドレス制限・アクセス元制限の設定粒度
• 権限分離（管理者 / 閲覧者 / 送信担当者 等）と最小権限の原則
• 退職者アカウント無効化の運用手順

ベンダーへの質問例（Q）

• Q1: 多要素認証はテナント単位で必須化できますか。対応する 2FA 方式は何ですか（TOTP / WebAuthn / SMS 等）
• Q2: SSO 連携は SAML 2.0 / OpenID Connect のいずれに対応していますか。IdP の指定はありますか
• Q3: IP アドレス制限は設定可能ですか。設定粒度はテナント単位・ユーザー単位のどちらですか
• Q4: 権限ロールは何種類ありますか。カスタムロール作成・監査ログ閲覧権限の分離は可能ですか

営業ツールで特に注意すべきポイント

営業ツールでは「送信を実行する権限」と「送信履歴・顧客情報を閲覧する権限」を分離できるかがポイントです。全員に管理者権限を付与している運用では、退職者経由の情報流出や送信誤操作のリスクが高まります。SSO 連携が可能であれば、退職者アカウントの無効化を人事の退職処理と一元化できるため、稟議書ではあわせて記載しておくと情シスの理解が得やすくなります。

項目 3: 暗号化と通信経路

情シスが見ている観点

• 通信経路（HTTPS / TLS）の暗号化と TLS バージョン
• 保存時（at rest）の暗号化とアルゴリズム（AES-256 等）
• 暗号化鍵の管理主体（ベンダー管理 / KMS / BYOK）
• API アクセス時の認証方式（API キー / OAuth / mTLS 等）

ベンダーへの質問例（Q）

• Q1: 通信は TLS 1.2 以上で暗号化されていますか。TLS 1.0 / 1.1 は無効化されていますか
• Q2: 保存時のデータは暗号化されていますか。暗号アルゴリズムを教えてください
• Q3: 暗号鍵の管理はベンダー側のみですか、それとも顧客側で KMS / BYOK が使えますか
• Q4: 外部連携（Gmail 連携・SFA 連携等）の通信も同じ暗号化基準ですか

営業ツールで特に注意すべきポイント

Gmail 連携・SFA 連携など外部サービスと連携する営業ツールでは、連携経路の暗号化と OAuth スコープの範囲を必ず確認してください。特に Gmail 連携では「連携アカウントの全メール読取スコープ」を要求するツールがあり、情シスから最も懸念されるポイントの 1 つになります。ツールが「返信検知に必要な最小スコープに絞れるか」を確認しておくと、稟議で「なぜそのスコープが必要か」を説明しやすくなります。

【項目 4〜5】ログ監査と営業ツール固有の送信除外・接触履歴管理

ここからが営業ツール特有の観点です。汎用 SaaS チェックシートでは扱いが浅い、または項目自体が存在しない領域で、ツール候補間で最も差が付く部分でもあります。稟議書に「営業ツール特有の考慮事項」欄がある場合は、この項目 4〜5 で埋めることをおすすめします。

項目 4: ログ保存と監査証跡

情シスが見ている観点

• どの操作が監査ログとして残るか（ログイン・送信・データエクスポート・権限変更）
• ログの保存期間と改ざん防止の仕組み
• ログの検索・エクスポート機能（監査対応時の抽出容易性）
• 異常検知アラート（大量送信・不審なアクセス）の有無

ベンダーへの質問例（Q）

• Q1: 監査ログにはどの操作が記録されますか。特に「送信実行」「顧客データのエクスポート」「権限変更」「ログイン失敗」の 4 種は含まれますか
• Q2: ログの保存期間は何日ですか。ユーザー側で延長・エクスポートは可能ですか
• Q3: 監査ログの改ざん防止（追記のみ・ハッシュチェーン等）はどう実装されていますか
• Q4: 大量送信・通常と異なるアクセスパターンを検知した際のアラート機能はありますか

営業ツールで特に注意すべきポイント

営業ツールでは「誰が・いつ・どのリストに・どの文面で送信したか」を後から追跡できることが、事故発生時の対応に直結します。稟議段階で「送信操作のログ」と「エクスポート操作のログ」の両方が残る仕様かをベンダーに確認しておくと、情シスからの追加質問を減らせます。ログ保存期間が短い場合（90 日以下など）は、監査対応・情報漏洩調査時に必要な過去操作を追えないリスクがあるため、期間延長・エクスポート機能の有無を合わせて確認してください。

項目 5: 送信除外・接触履歴の管理（営業ツール固有）

情シスが見ている観点

• 誤送信防止の仕組み（送信前確認・送信除外リストの適用フロー）
• 除外リストの取得元（自社管理のみ / 外部 API 連携 / サードパーティ提供リスト）
• 接触履歴として保存されるメタデータの範囲（開封・クリック・トラッキングピクセル）
• 「他社（取引先・別チャネル）がすでに接触済みの企業」への二重送信をどう防ぐか
• 配信停止・オプトアウト要求への対応フロー

ベンダーへの質問例（Q）

• Q1: 送信除外リストの登録・適用はどのような仕組みですか（ドメイン単位 / 企業単位 / 個人メール単位）
• Q2: 除外リストは自社管理のみですか、それとも外部 API から取得できますか。外部 API 連携がある場合、取得元と更新頻度を教えてください
• Q3: 接触履歴として保存されるメタデータには何が含まれますか（送信日時・失敗理由・開封・クリック・トラッキングピクセル）
• Q4: 「取引先や別チャネルですでに接触済みの企業」への二重送信をシステム側で防ぐ仕組みはありますか
• Q5: 配信停止要求（オプトアウト）を受けた場合、除外反映までの想定タイムラグはどの程度ですか

営業ツールで特に注意すべきポイント

この項目は営業ツール選定の判断分岐点となる部分です。汎用 SaaS チェックシートには存在しない一方、実際の運用事故（誤送信・信頼毀損）が最も起きやすい領域でもあります。

Form Pilot では、他社（取引先・別チャネル）がすでに接触済みの企業ドメイン一覧を外部 API から取得して送信リストと突合し、該当する企業への送信を自動で回避する設計を採用しています。判断できない場合は送らない「fail-closed」を基本とする方針で、送信量の最大化ではなく「送ってよい相手にだけ送る」ことを設計の中心に据えています。送信除外の実装方式（自社履歴照合・業種ルール・外部シグナル連携・配信停止フィードバック）の詳細な比較観点は、接触済み企業を除外する営業ツール設計 で解説しています。

【項目 6〜7】組織単位のデータ分離・認証取得状況・インシデント SLA

最後の 2 項目は、導入後の運用実務に近い領域です。特に営業代行・BPO と連携する場合、または複数事業部で 1 つのツールを共用する場合、マルチテナント設計の粒度が「情報混在事故」を左右します。項目 7 の認証取得状況は「必須条件」というよりも、稟議書に添付する客観エビデンスとして扱うのが実務的です。

項目 6: マルチテナント・組織単位データ分離（営業ツール固有）

情シスが見ている観点

• テナント（組織）単位のデータ分離設計と論理境界
• サブテナント・子組織の作成可否（親子構造での権限継承ルール）
• 営業代行・BPO 事業者利用時のクライアント別データ分離
• 複数事業部利用時の「事業部間で顧客情報が見えない」設計の可否
• テナント跨ぎでの検索・エクスポートの制限

ベンダーへの質問例（Q）

• Q1: 組織単位のデータ分離はどのような設計ですか（物理分離 / 論理分離 / 行レベルセキュリティ）
• Q2: サブテナント（子組織）を作成できますか。作成できる場合、権限継承・データ分離のルールを教えてください
• Q3: 営業代行・BPO 事業者向けに、クライアントごとの送信リスト・送信履歴・文面を分離して運用できますか
• Q4: 複数事業部で 1 テナントを共用する場合、事業部間で顧客情報・送信履歴を非公開にできますか
• Q5: 管理者権限を持つユーザーは、全テナントのデータを横断検索できてしまいますか

営業ツールで特に注意すべきポイント

営業代行・BPO への委託や、複数事業部での共用が想定される場合、マルチテナント設計の粒度で「クライアント A のリストがクライアント B の担当者に見えてしまう」事故を防げるかが決まります。稟議段階で「今は自社単独利用だが、将来的に営業代行に一部委託する可能性がある」といった前提を明示し、テナント分離の粒度を確認してください。マルチテナント設計の詳細（営業代行・BPO 連携時の実装パターン）は、営業ツールの組織単位データ分離設計 で扱っています。

項目 7: 認証取得状況と脆弱性・インシデント対応

情シスが見ている観点

• 第三者セキュリティ認証の取得状況（ISO/IEC 27001・SOC 2・ISMAP・プライバシーマーク 等）
• 脆弱性診断（ペネトレーションテスト・ソースコード診断）の実施頻度と結果開示範囲
• インシデント発生時の通知フロー（通知先・通知時間・報告書提供の有無）
• SLA（稼働率保証・障害時の返金 / 補填条件）
• 過去のセキュリティインシデント履歴と対応内容

ベンダーへの質問例（Q）

• Q1: 取得している第三者認証は何ですか（ISO/IEC 27001・SOC 2 Type I / II・ISMAP・プライバシーマーク 等）
• Q2: 脆弱性診断の実施頻度と、直近の実施結果概要（開示可能な範囲）を教えてください
• Q3: セキュリティインシデントが発生した場合の顧客への通知フロー（通知手段・通知までの目標時間）を教えてください
• Q4: 稼働率 SLA を教えてください。障害時の補填・返金の条件はありますか
• Q5: 過去 3 年以内に外部公表したセキュリティインシデントの件数と対応概要を教えてください

営業ツールで特に注意すべきポイント

第三者認証は「取得していない=失格」ではなく、「取得している場合はエビデンスとして稟議書に添付し、情シスの調査工数を減らす」という位置付けで扱うのが実務的です。特に ISMAP（政府情報システムのためのセキュリティ評価制度）は政府調達を意識する企業で参照されやすく、SOC 2 Type II は運用の継続性まで含む監査であるため、稟議段階で保有ステータスを聞いておくと、情シスからの追加質問が減ります。

新しい SaaS では認証未取得のケースもありますが、その場合はロードマップ（取得予定時期）と、代替となる社内セキュリティポリシー・脆弱性診断の実施状況を確認してください。認証がないから即失格ではなく、「何を代替として提示できるか」で判断する運用が現実的です。

7 項目を稟議書に落とし込む書き方とベンダーヒアリング例

7 項目を確認軸として押さえたら、次は稟議書とベンダーヒアリングへの落とし込みです。この章では、既存の稟議テンプレートに追記する形での 7 欄マッピング例と、ベンダーヒアリングで実際に投げる質問リストをまとめて提示します。コピーして自社の稟議書・質問リストに貼り込めば、そのまま起票の下地になります。

稟議書の 7 欄マッピング例

既存の稟議書テンプレートには「取扱データ」「セキュリティ対策」「監査 / 事後追跡」等の欄が既にあるケースが多いはずです。以下のように 7 項目を欄に振り分けて追記してください。

「営業ツール特有の考慮事項」欄が自社の稟議テンプレートに存在しない場合は、新規欄として追加を提案してください。この欄がないと項目 5・6 の営業ツール固有観点が「セキュリティ対策」欄に埋没し、情シスから追加質問を受けやすくなります。

ベンダーヒアリング質問リスト（7 項目に紐づけ）

初回のベンダー面談で使える質問リストを、7 項目に紐づけて 20 問にまとめました。ツール候補ごとに Excel やスプレッドシートで横並びに回答を並べると、比較検討がしやすくなります。

項目 1（データ管理範囲と保存期間）

• 弊社が入力するデータは、どのリージョンのどのクラウド上に保存されますか
• 保存期間のデフォルトと、ユーザー側で短縮できる範囲を教えてください
• 契約終了時のデータ削除ポリシー（削除タイミング・削除範囲・完全削除の証跡）
• サービス提供時に外部の AI サービスへ顧客データを渡すことはありますか

項目 2（認証・アクセス制御）

• 多要素認証はテナント単位で必須化できますか。対応方式は何ですか
• SSO 連携は SAML 2.0 / OIDC のいずれに対応していますか
• 権限ロールは何種類ありますか。カスタムロール作成・監査ログ閲覧権限の分離は可能ですか
• 退職者アカウントの一括無効化・SCIM 連携は可能ですか

項目 3（暗号化と通信経路）

• 通信は TLS 1.2 以上ですか。保存時暗号化のアルゴリズムを教えてください
• 暗号鍵の管理主体（ベンダー管理 / KMS / BYOK）を教えてください
• Gmail 連携等の外部連携では、どのスコープを要求しますか

項目 4（ログ保存と監査証跡）

• 監査ログには「送信」「エクスポート」「権限変更」「ログイン失敗」が含まれますか
• ログの保存期間と、エクスポート・改ざん防止の仕組みを教えてください
• 異常検知アラートの機能はありますか

項目 5（送信除外・接触履歴の管理）

• 送信除外リストの登録・適用はどのような単位ですか（ドメイン / 企業 / 個人メール）
• 除外リストは自社管理のみですか、外部 API 連携で取得できますか
• 「他社が接触済みの企業」への二重送信を防ぐ仕組みはありますか
• 配信停止要求（オプトアウト）を受けた場合の除外反映タイムラグはどの程度ですか

項目 6・7（組織単位分離・認証・インシデント）

• サブテナント作成・営業代行向けのクライアント別データ分離は可能ですか
• 取得している第三者認証（ISO/IEC 27001・SOC 2・ISMAP 等）とロードマップを教えてください
• インシデント発生時の顧客通知フローと稼働率 SLA を教えてください

回答をツール候補ごとに横並びで比較すると、項目 5・6 で差が付きやすいことに気づくはずです。ここが本記事の 7 項目に絞った狙いです。

導入後の運用責任分担（アカウント棚卸し・退職者対応・インシデント時の分担）

情シスが稟議段階で必ず問うのが「導入後の運用は誰が見るのか」です。導入前 7 項目の確認と合わせて、運用責任の分担案を稟議書に添えておくと、承認確率が上がります。以下は営業部門・情シス・ベンダーで役割を切り分けた責任分担マトリクスの例です。

この分担表を稟議書に添付できると、情シスの側は「導入後に営業部門から丸投げされる」懸念が下がり、承認判断のハードルが下がります。特に「退職者アカウント無効化」と「送信除外リストの更新」の 2 つは、放置されると事故に直結する運用のため、担当者と実施頻度を明記してください。

営業ツール導入の稟議は「セキュリティを守り抜くための拒否」ではなく、「セキュリティを担保しつつ営業成果を上げるための合意形成」が本質です。本記事の 7 項目と運用責任分担マトリクスを起点に、情シスとの対話を「質問への逐次回答」から「先回りした提案」に変えていってください。

Form Pilot はこの 7 項目のうち、特に項目 5（送信除外・接触履歴の管理）と項目 6（組織単位データ分離）で差別化された設計を採用しています。他社（取引先・別チャネル）が接触済みの企業を外部 API 連携で自動除外し、送信量の最大化ではなく「送ってよい相手にだけ送る」ことを設計の中心に据えています。CAPTCHA については、受信側が「機械的な送信を受けたくない」と示す意思表示として尊重し、突破しない設計です。営業ツールを選定段階から検討中の場合は、セキュリティ以外の観点（送信の実行方式・リスト作成・フォローアップ設計等）の 7 選定軸をまとめた フォーム営業ツールおすすめ｜5 カテゴリと選定 7 軸 も合わせて参考にしてください。

関連情報

営業ツールの選定・情シス承認のために、送信除外の自動化・組織単位データ分離・接触履歴の可視化を含む設計を検討中の方は、Form Pilot のサービスページ をご覧ください。他社（取引先・別チャネル）が接触済みの企業を外部リストに基づき送信対象から自動で除外し、送信量の最大化ではなく「送ってよい相手にだけ送る」ことを設計の中心に据えた、AI フォーム営業自動化 SaaS です。

営業ツール導入時のセキュリティ設計・情シス稟議の通し方について個別にご相談されたい方は、お問い合わせフォーム からご連絡ください。