SFAのセキュリティチェックリスト｜選定・契約前に確認する40項目
SFAのセキュリティを、認証・権限・監査ログ・暗号化・委託先・AI・バックアップ・契約終了まで40項目で確認。100名以上の審査で使えるCSV付きです。
この記事でわかること
対象：SFAの新規導入・更新時にセキュリティ審査を担当する情報システム、セキュリティ、営業企画、法務、購買の担当者
- 認証・権限・ログ・データ・委託先・AI・可用性・契約終了を同じ質問票で確認する
- 認証取得の有無だけで判断せず、自社の利用方法と責任分界に合う証跡を確認する
- 100名以上では、組織変更、管理者操作、出力、連携、インシデント対応まで実機と文書で検証する
目次
SFAのセキュリティは、暗号化や認証取得の有無だけでは判断できません。顧客担当者の連絡先、商談音声、提案内容、契約条件、メールなどを、誰が、どの端末から、どこまで閲覧・出力できるかを、日常運用と契約終了まで含めて確認する必要があります。
この記事では、SFA選定時に確認したい項目を8領域40問に整理します。質問の目的、確認したい証跡、自社と提供者の責任分界まで示すため、営業企画・情報システム・セキュリティ・法務・購買が同じ基準で審査できます。
40項目を自社回答・ベンダー回答・証跡で管理できるCSVです
SFAセキュリティチェックリストをダウンロード →本チェックリストは一般的な選定補助資料です。法令・業界規制・契約上の適合性を保証するものではありません。必要に応じて自社の法務・セキュリティ担当者または専門家へ確認してください。
SFAのセキュリティ審査で最初に決めること
質問票を送る前に、対象データ、利用者、利用端末、接続先、連携先を整理します。同じ製品でも、顧客情報だけを扱う場合と、商談音声・メール・生成AIまで扱う場合ではリスクと確認範囲が異なります。
| 整理項目 | 決めること | 成果物 |
|---|---|---|
| 対象データ | 顧客・案件・音声・メール・添付・機微情報 | データ分類表 |
| 利用者 | 営業・上司・営業企画・管理者・委託先 | 役割一覧 |
| 利用環境 | 社給PC・スマートフォン・私物端末・社外利用 | 端末・接続方針 |
| 連携 | ID基盤・メール・電話・会議・会計・AI | データフロー図 |
| 保持 | 保存期間・バックアップ・契約終了後の扱い | 保持・削除方針 |
| 重要度 | 停止や漏えいが事業へ与える影響 | 復旧目標・通知先 |
IPAは、IT製品の調達時にセキュリティ要件を選定・仕様書へ反映するためのガイドブックと要件リストを公開しています。自社固有のリスク評価と組み合わせ、すべての候補へ同じ質問を行います。
参考：IT製品の調達におけるセキュリティ要件リスト活用ガイドブック（IPA）
1. 認証・アカウント管理のチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 1 | SSOはどの方式・ID基盤に対応するか | 対応仕様・構成例 |
| 2 | 多要素認証を全利用者と管理者へ強制できるか | 設定画面・例外条件 |
| 3 | 入社・異動・退職を自動反映できるか | SCIM等の仕様・処理時刻 |
| 4 | 長期間未使用・不審なログインを検知できるか | 通知・ログのサンプル |
| 5 | サービス提供者の運用管理者はどう認証・承認されるか | 特権アクセス管理の説明 |
100名以上では、個別の手作業だけでアカウントを維持すると、異動・兼務・退職時の変更が遅れます。利用者登録の可否だけでなく、ID基盤からの自動作成・停止、例外アカウントの棚卸し、緊急時の管理者アクセスを確認します。
2. 権限・組織変更のチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 6 | 部門・役職・担当案件に応じて閲覧と編集を分けられるか | 権限表・実機テスト |
| 7 | 兼務・代理・一時的な案件共有を期限付きで設定できるか | 設定手順・解除方法 |
| 8 | 一括出力・削除・設定変更を限定できるか | 管理権限一覧 |
| 9 | 組織変更時に権限と担当データを一括変更できるか | 一括処理・API仕様 |
| 10 | 提供者の保守担当者が顧客データへアクセスする条件は何か | 申請・承認・記録の手順 |
権限表を読むだけでなく、営業担当者、上司、営業企画、システム管理者のテストユーザーを作り、見えてはいけない顧客・案件・音声が表示されないことを確認します。異動前後も同じシナリオで試します。
3. 監査ログ・検知のチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 11 | ログイン・閲覧・編集・削除・出力の履歴を記録するか | ログ項目の一覧 |
| 12 | 権限・設定・連携・管理者操作の変更を追跡できるか | 管理ログのサンプル |
| 13 | ログの保存期間・検索・出力形式は何か | 仕様・実機テスト |
| 14 | 大量出力や不審な操作を通知できるか | 検知条件・通知先 |
| 15 | 調査時に時刻・利用者・対象データを突合できるか | 時刻同期・証跡提供手順 |
「監査ログあり」だけでは不十分です。自社が必要とする操作が記録されるか、管理者自身の操作も残るか、インシデント後に検索・出力できるかを確認します。ログ閲覧に上位プランや追加費用が必要かも見積もります。
4. データ保護・個人情報のチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 16 | 通信時・保存時の暗号化範囲と方式は何か | 技術仕様 |
| 17 | 暗号鍵を誰が管理し、どう更新するか | 鍵管理方針 |
| 18 | データ・バックアップの保存国やリージョンはどこか | 構成図・契約条項 |
| 19 | 保存期間・個別削除・利用者削除へ対応できるか | 保持・削除仕様 |
| 20 | 契約終了時に何をどの形式で返却し、いつ削除するか | 出口条項・削除証跡 |
クラウド事業者が顧客データを取り扱わない契約・技術構成であっても、その条件を満たすかを具体的に確認します。個人データの取扱いを委託する構成なら、委託先の選定・契約・取扱状況の把握など、自社側の監督も検討します。
5. 脆弱性・開発・インシデント対応のチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 21 | 脆弱性情報を収集し、優先度と期限をどう決めるか | 管理手順 |
| 22 | 第三者診断・侵入試験をどの範囲と頻度で行うか | 概要報告・是正方針 |
| 23 | 開発・試験・本番環境とアクセスを分離しているか | 開発管理の説明 |
| 24 | 事故時に何時間以内・どの経路で通知するか | 対応手順・契約条項 |
| 25 | 原因・影響・再発防止・証跡の提供範囲は何か | 報告書例・責任分界 |
認証や第三者評価は確認材料になりますが、自社の利用構成すべてを保証するものではありません。評価対象、取得日、有効範囲を確認し、不足する項目は質問・実機・契約で補います。
参考：情報システム等の脆弱性情報の取扱いに関する資料・チェックリスト（IPA）
6. 可用性・バックアップのチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 26 | 稼働率・計画停止・補償条件は何か | SLA・実績公開範囲 |
| 27 | バックアップ対象・頻度・世代・保管場所は何か | 運用仕様 |
| 28 | 復旧目標時間と復旧時点はどのサービスに適用されるか | 復旧方針 |
| 29 | 復旧試験をどの頻度で行い結果をどう確認できるか | 試験概要 |
| 30 | 障害時の連絡・代替業務・データ再送はどう行うか | BCP・連絡手順 |
SLAの数値だけでなく、メール連携、録音、AI要約、APIなど個別機能が停止した場合の挙動を確認します。営業活動を止めないための代替記録と、復旧後の取り込み方法を自社側でも決めます。
7. 外部連携・AI・委託先のチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 31 | クラウド・AI・文字起こし等の再委託先は誰か | サブプロセッサー一覧 |
| 32 | 外部へ送信するデータ・目的・保存期間は何か | データフロー図 |
| 33 | 入力データを汎用モデルの学習へ利用するか | 利用条件・契約条項 |
| 34 | APIの認証・権限・上限・失敗時の再処理はどうなるか | API仕様・運用手順 |
| 35 | 委託先変更時の通知・異議・解約条件は何か | 変更通知条項 |
生成AIを含む場合は、機能名ではなく、入力、処理、生成、確認、保存、削除の流れで確認します。金額・期限・契約条件など影響が大きい情報は、元記録へ戻り、人が確認・修正できる運用を残します。
参考：AI事業者ガイドライン 第1.2版・チェックリスト（経済産業省）
8. 契約・運用・出口のチェック項目
| No. | 確認する質問 | 確認したい証跡 |
|---|---|---|
| 36 | セキュリティ仕様変更をどう通知するか | 通知方針 |
| 37 | 監査・質問票・証跡提供へどこまで対応するか | 窓口・費用・期間 |
| 38 | 利用者追加・組織変更・権限棚卸しの担当は誰か | 運用分担表 |
| 39 | データ一括出力の形式・期間・費用・上限は何か | 実データでの出力試験 |
| 40 | 契約終了後の保持・削除・バックアップ消去をどう確認するか | 終了手順・証明方法 |
チェック結果の判定方法
質問ごとに丸・三角・バツだけを付けず、要件、回答、証跡、残るリスク、対応責任者、期限を記録します。対応予定は実装済みと分け、契約前に必要なものは提供時期と未提供時の扱いを文書化します。
| 判定 | 意味 | 次の対応 |
|---|---|---|
| 必須適合 | 契約前に満たし証跡を確認できる | 契約・設定へ反映 |
| 代替適合 | 別の対策で同じリスクを下げられる | 代替手順と責任者を記録 |
| 条件付き | 追加費用・上位プラン・個別設定が必要 | 見積もりと提供条件を確定 |
| 未適合 | 要求を満たせない | リスク受容・候補除外を決裁 |
| 未確認 | 回答または証跡がない | 期限を決めて再確認 |
よくある判断ミス
- 認証取得だけで自社要件を満たすと判断する
- 質問票の回答だけで実機・構成図・契約条項を確認しない
- 営業部門だけで先行契約し、連携・個人情報・出口を後から確認する
- 管理者・提供者のアクセスを一般利用者と分けて確認しない
- AI機能だけを別のデータフローとして確認しない
- 対応予定の機能を実装済みとして選定する
SFAのセキュリティに関するよくある質問
クラウド型SFAはオンプレミスより危険ですか？
設置場所だけでは判断できません。クラウドでは提供者と利用者で責任を分け、オンプレミスでは自社が更新・監視・復旧まで広く担います。自社の要件と運用能力を同じチェック項目で比較します。
ISMAP登録があれば安全ですか？
ISMAPは政府が利用するクラウドサービスのセキュリティ評価制度で、有用な確認材料です。ただし、対象サービス・範囲と自社の利用構成を照合し、権限、端末、連携、運用など利用者側の対策も確認します。
チェックリストは誰が回答しますか？
サービス提供者だけでなく、自社の営業企画、情報システム、セキュリティ、法務、購買が担当領域を持ちます。自社側の権限設定、端末管理、利用ルール、棚卸しが未定なら、製品側の回答だけでは安全な運用になりません。
まとめ：製品の安全性ではなく、利用構成全体を確認する
SFAのセキュリティ審査では、製品の認証や機能だけでなく、自社の利用者・端末・権限・連携・データ・運用を含む構成全体を確認します。同じ40問を候補へ当て、証跡、責任分界、残るリスクを選定記録へ残してください。
DRIVE SFAのセキュリティ仕様と自社要件を確認する
セキュリティ情報を見る →
執筆：小花 達也
新卒でソフトバンク株式会社に入社し、デジタルマーケティングを担当。その後、ベンチャー企業数社でBtoBマーケティング、データ基盤構築、営業などを担当した後、ELW株式会社に入社。DRIVE SFAでは導入支援とマーケティングを担当。
本記事は、DRIVE SFAの導入支援・営業運用に関する知見をもとに編集しています。