%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
CRMセキュリティ要件は、認証や暗号化の機能名だけでは判断できません。自社のデータと業務を決め、設定・操作・記録を確かめてから採用を判定します。
CRMセキュリティ要件は、認証や暗号化の機能名だけでは判断できません。自社のデータと業務を決め、設定・操作・記録を確かめてから採用を判定します。
「CRMの導入稟議で、情報システム部門から何を聞かれるのかわからない」「クラウドに顧客情報を預ける判断を、経営層へ説明できない」「ベンダーの回答を受け取っても、採用してよい水準なのか判断できない」——こうした悩みには、確認項目とともに、回答をどう検証し、どの結果なら次へ進めるかを決めておく必要があります。
CRMで扱う情報と業務を整理し、必要な管理方法を確認します。
Excelやスプレッドシートを含む現在の管理方法を確認するときは、顧客情報の保存先に加え、複製、メール添付、ローカル保存、担当者の異動・退職後の扱いを洗い出します。CRMへ集約した後も、誰が閲覧し、更新し、出力できるかを決め、その設定を確かめる必要があります。
本記事は「CRM導入の進め方完全ガイド｜準備・ツール選定・データ移行・定着化の全ステップ」シリーズの一部です。
この記事でわかること
CRMの導入審査を担当する情報システム部門や導入責任者に向けて、製品比較から運用開始後の見直しまで、同じ判断基準で進める方法を整理します。
- CRMセキュリティの全体像 — 扱う情報とデータの経路を整理し、ベンダーと利用企業の責任範囲を分ける方法を説明します。
- 10の評価ポイントと判定基準 — 認証、アクセス制御、暗号化、監査ログ、復旧などについて、確認する資料、試す操作、採用判断の分かれ目を示します。
- CRMベンダーへの質問方法 — 対象プラン、適用範囲、操作の証跡をそろえて尋ね、回答が不足した場合に何を追加確認するかを具体化します。
- 導入後のセキュリティ運用 — 権限の棚卸し、退職者対応、ログ確認を、担当者・確認条件・記録先を伴う手順に落とし込みます。
- 段階的な導入手順 — 対象データと利用者を絞って検証し、どの結果を確認できたら利用範囲を広げるかを説明します。
対象読者: CRM導入のセキュリティ審査を担当するCIO・情報システム部長、またはクラウドサービスの安全性を経営層に説明する必要がある導入PM
「CRMのセキュリティ要件を情シスに説明できない」「クラウドに顧客情報を預ける安全性を経営層に示したい」という方は、自社の採用条件を整理するところから読み進めてください。各表には、評価の例に加え、別の分類に属する確認項目も含まれます。表の行や評価記号だけで採用を決めず、契約予定のサービスとプランについて得た資料や操作結果を、要件ごとに対応付けて判定します。
審査票には各要件について「対象データと利用者」「許可・拒否したい操作」「確認した資料またはテスト結果」「判定者」「再確認する条件」を残します。この欄が埋まらない要件は、表に機能名が載っていても確認中として扱います。
CRMセキュリティの全体像
CRMは顧客情報を保存し、営業活動や部門間の引き継ぎに利用する業務基盤です。セキュリティ要件を整理する際は、ログインに加え、データの入力、関連付け、更新、出力、削除も対象にします。まず保存する情報を洗い出し、各操作を誰が担当するか、操作後に何を確認するかを決めます。その内容をもとに、製品ごとに権限設定と操作の確認方法を確かめます。操作の記録だけでは入力内容の正確さは分からないため、更新後の内容を確認する手順も用意します。
評価の出発点は、情報の種類ごとに「誰のどの業務に必要か」を書くことです。そのうえで、許可したい操作、拒否したい操作、問題が起きたときに確認したい記録を並べます。設定画面で制御できると分かっても、実際の役割で操作を試すまでは判定を保留します。試した結果を残せれば、製品間の比較と導入後の見直しに同じ基準を使えます。
CRMに集約される情報を分類する
最初に行うのは、CRMへ入れる情報の分類です。同じ画面に表示される情報でも、閲覧、編集、出力を許可する範囲は業務上の役割によって変わります。次の表では、実際に保存する情報に当たる行を選び、関係する部門と扱い方を確認します。
| データ種別 | 具体例 | 漏洩時のリスク |
|---|---|---|
| 個人情報 | 氏名、メールアドレス、電話番号、住所 | 個人情報保護法違反、損害賠償請求 |
| 商談情報 | 提案金額、競合情報、意思決定者 | 競合への情報流出、商談失注 |
| 取引履歴 | 受注金額、契約条件、与信情報 | 取引先との信頼関係毀損 |
| 11 | 監査・コンプライアンス | 監査ログに記録される操作、保存期間、検索・エクスポートの可否を確認する。必要な操作が記録されない場合や保存期間が要件を満たさない場合は、その用途に使えるかを判断し、別の記録方法を検討する |
| コミュニケーション履歴 | メール内容、商談議事録 | レピュテーションリスク |
| 社内情報 | 営業戦略、ターゲットリスト、KPI | 営業上の優先事項や目標が競合に知られ、戦略上の優位性を損なう |
情報の分類では、各行が自社で実際に保存するデータに当たるかを先に確認します。リスク欄は起こり得る影響の例であり、個別の法的結論を示すものではありません。監査ログに関する行はデータ種別とは別の確認事項です。この行は監査の審査欄へ移し、「どの出来事を調べるか」「何を手掛かりに探すか」「誰が取得するか」「どの記録で判断するか」に分けて記入します。
たとえば「取引の金額が想定と異なる」という報告を受けた場合、調査担当者は対象の取引と報告された変更を特定し、変更者・変更時刻・変更内容を確認する必要があります。この場面を審査欄に書き、どの記録で各情報を調べるかを割り当てます。
- 対象の取引から変更を探す ── まず、報告された取引の変更を探します。
- 見つからなければ検索条件と権限を確認する ── 検索条件と、調査担当者の参照権限を見直します。
- 記録対象外なら別の記録で結び付ける ── 同じ取引、実行者、変更を結び付けられるか試します。
結び付けられない場合は、その調査用途について要件を満たしたと判定しません。
別の記録方法を検討する際は、記録の名前だけを挙げて終わらせません。取引を識別できる情報、操作した人、変更された内容が同じ出来事として照合できるかを、調査担当者に実際に確かめてもらいます。記録の取得を別部門へ依頼する必要があれば、依頼先と受け渡し方法も審査票に残します。必要な情報がそろわない補完策は、その調査用途の代替として採用しません。
保存期間も、表の長短だけで判断しません。自社がどの報告や確認をきっかけに調査するかを先に決め、その時点で必要な記録を参照できる条件をベンダーに尋ねます。参照できない場合は、別の記録を取得・管理する担当者と方法を定めて同じ調査を試し、再現できなければ採用条件へ戻します。
各情報について、次の4つを分けます。
- 保存する場所 ── その情報をどこに置くかを決めます。
- 閲覧する役割 ── 見てよい役割を決めます。
- 更新する役割 ── 編集してよい役割を決めます。
- 出力を許可する役割 ── たとえば取引の担当者は提案内容の更新が必要でも、一覧の一括出力まで必要とは限りません。
まず必要な操作を試し、続けて不要な操作が拒否されるかを試します。必要な操作ができなければ役割設計を修正し、不要な操作を制限できなければ、その情報をCRMに置く範囲や担当者の業務を見直します。
分類表を審査に使う際は、データの所有部門にも確認を求めます。利用部門が必要な操作を示し、情報システム部門が設定で再現できるかを確かめます。意見が分かれた場合は、対象データと操作を具体化して再テストし、合意した結果を役割表に残してから次の情報分類へ進みます。
ベンダーと利用企業の責任を分ける
クラウドCRMでは、ベンダーが管理する領域と利用企業が設定する領域を分けて評価します。審査票には対策の名称だけでなく、設定・確認・事故時の対応を誰が担うかも記入します。次の表の責任主体は確認を始めるための区分として使い、実際の分担は対象サービスの資料と契約条件で確かめます。
| レイヤー | 責任主体 | 具体的な対象 |
|---|---|---|
| 1 | インフラ | データセンターの所在地と、日本国内リージョンの選択可否 |
| プラットフォーム | CRMベンダー | OS、ミドルウェア、アプリケーションのパッチ |
| データ | 共有責任 | データの暗号化（ベンダー）、分類・管理（ユーザー） |
| アクセス管理 | 主にユーザー企業 | ユーザー権限設定、パスワードポリシー |
| 運用 | ユーザー企業 | データ入力ルール、利用規約の遵守 |
| インフラストラクチャ | CRMベンダー | データセンター、ネットワーク、物理セキュリティ |
各項目について、ベンダーの担当範囲、自社の設定者・確認者、事故時の連絡先・判断者を確かめます。境界が不明な項目は、対象となるデータと操作を添えてベンダーに質問し、回答を記録します。資料上の分担が分かっても、自社で連絡や判断を担当する人がいなければ、運用条件は満たしていません。表の「1」の行も、責任分担の確定情報ではなく、保存先と選択可否を質問する項目として扱います。
たとえば退職者のアカウント停止は、自社の人事情報とCRMの管理手順をつなげて確認します。一方、製品が記録しない操作を自社の運用だけで後から調査することはできません。採用条件に必要な制御や記録が提供されるかを先に確かめ、その後に自社の担当と手順を決めます。
責任分担が決まったら、各項目に「発生を知らせる人」「設定または対応を行う人」「結果を確認する人」を割り当てます。担当を置けない項目は運用上の未解決事項として扱います。引き継ぎ先と結果の確認方法まで決まれば、導入計画へ移します。
法令と自社ポリシーを同じ表で照合する
個人情報保護法や、EU居住者のデータを扱う場合のGDPRは、CRM選定で適用範囲を確認する対象です。ベンダーによる対応の表明が、自社のデータの入れ方や利用方法まで示しているとは限りません。まず扱うデータと処理を列挙し、担当部門が適用を確認します。
次の表に挙がる法令・規制や評価記号は、対象を調べるための入口です。法令の適用も製品の適合も、表の一般的な記述からは決められません。自社の利用条件とベンダーの資料を対応付け、法務を含む担当部門の判断を記録します。
| 法規制 | 概要 | CRMへの影響 |
|---|---|---|
| 個人情報保護法（日本） | 漏洩報告義務、罰則規定を含む改正法 | 個人データの適切な管理と漏洩時の対応義務 |
| GDPR対応 | EU規制対応 | グローバル製品は概ね対応 |
| APPI（改正個人情報保護法） | 越境移転規制、仮名加工情報の導入 | 海外CRMへのデータ保管に関する規制 |
| 不正競争防止法 | 営業秘密の保護 | CRM内の商談情報は営業秘密に該当する可能性 |
確認表には、対象データ、適用を確認する法令、自社ポリシー、CRMで使う設定、担当部門、根拠資料を並べます。表の製品全般への記述は、個別製品の適合を示しません。「対応済み」という回答だけなら、どのデータ処理と契約条件を対象にした回答かを尋ね、担当部門が確認するまで判定を保留します。
法令に関する判断と製品設定の判断は、同じ審査票でつなげます。たとえば対象データの削除が必要と判断された場合は、法務部門が処理範囲を示し、利用部門がデータの所在を確認し、情報システム部門が実行方法と結果の記録方法を検証します。処理範囲が決まらなければ、機能の有無だけで適合とは判定しません。
CRMセキュリティ要件の10の評価ポイント
ここからの10項目は、機能の数を比べるための一覧ではありません。自社が扱う情報と業務フローに対して、どの制御が必要かを決める評価軸です。各項目について、対象データ、利用者、契約予定のプラン、必要な結果、確認した証跡をそろえて比較します。
採用条件を決める際は、まず守りたい情報と避けたい業務上の事態を書きます。次に、その事態を防ぐために必要な操作や記録を指定します。製品資料を確認した後は、回答がその操作と記録を対象にしているか照合します。範囲が一致すれば実機で試し、一致しなければ質問を分けて確認します。
認証とアクセス制御を評価する
評価ポイント1は認証とアカウント管理です。 多要素認証について、対応の有無に加え、管理者が対象者へ適用できるか、利用できる方式は何か、SSOとの併用条件はどうなっているかを確認します。自社でSSOを必須としているなら、対象の利用者と管理者を決め、契約予定のプランと自社の認証基盤で接続を検証します。
次の表は、多要素認証とSSOの対応状況を評価する際の基準の目安です。自社が必須とする利用者と認証方法を先に決め、表の記号ではなく、設定後に各利用者へ求められる認証と例外の扱いで判定します。
| 評価 | 基準 |
|---|---|
| ◎ 優良 | SSO＋2FA強制適用＋パスワードポリシーカスタマイズが全て対応 |
| ○ 良好 | 2FA対応＋パスワードポリシーの基本設定が可能 |
| △ 確認が必要 | 2FAがオプションのみ、SSOは上位プラン限定 |
| × 不適 | 2FA非対応、またはパスワードポリシー設定不可 |
表の評価記号をそのまま採用判定にせず、必須とした方式を対象ユーザーへ適用できるかを確かめます。設定できても一部の利用者だけが対象なら、例外となるアカウントの用途と管理者を列挙します。必須の利用者へ適用できない場合は、その認証要件を満たしません。
検証前に、通常の利用者、管理者、例外として残す必要があるアカウントを役割表に記入します。それぞれについて想定するログイン経路と、使わせたくない経路を指定します。テストは次の順に行います。
- 想定する経路で試す ── ログインできるかを確かめます。
- 想定外の経路で試す ── 続いて、ログインできないかを確かめます。
利用者の役割、試した経路、求められた認証、結果を同じ行に残せば、設定画面の表示と実際の挙動を照合できます。
SSOの接続を確認できても、対象外の利用者が残れば、その利用者を保護する方法を別に判定します。ログインに失敗した場合も直ちに不適合とはせず、認証基盤との設定、対象ユーザーへの割り当て、契約条件のどこに原因があるかを分けます。設定を直して再試行できる項目は条件付きとし、必須の利用者へ適用できないと分かった項目は採用条件との不一致として記録します。
想定外の経路を使える場合は、まず設定で制限できるかを確認します。制限できない場合は、その経路を必要とする業務と管理方法を明らかにし、自社の採用条件で例外を認められるか判定者へ戻します。
例外を認めるなら、申請者、承認者、用途、管理者、見直す条件を記録します。
対象者が想定した経路で利用でき、認めた例外を担当者が管理できることを確認してから導入手順へ進みます。認証基盤、プラン、利用者の範囲が変わったときは同じ試行をやり直します。
評価ポイント2はアクセス権限制御です。 営業担当者、マネージャー、管理者などの役割から必要な操作を洗い出し、オブジェクト、レコード、項目、チーム、エクスポートの単位で再現できるかを調べます。閲覧だけを試して終わらせず、編集、検索、レポート、出力でも同じ制限が働くかを確認します。
次の表は、ロールベースアクセス制御の粒度を評価する際の基準の目安です。役割ごとに必要な操作と制限したい操作を書き出し、設定画面での確認と、テスト用アカウントによる操作確認を分けて使います。
| 評価 | 基準 |
|---|---|
| ◎ 優良 | RBAC＋フィールドレベル権限＋IP制限が全て対応 |
| ○ 良好 | RBAC＋オブジェクトレベル権限が対応 |
| △ 確認が必要 | 基本的な権限設定のみ、細かい制御は不可 |
| × 不適 | 全ユーザーが全データにアクセス可能 |
表には権限の粒度とは別の確認事項も含まれます。権限の判定には、自社の役割表に沿った操作結果を使います。担当取引の編集が必要な役割では編集できることを確かめ、担当外の取引を見せない役割では閲覧できないことを別に確かめます。必要な制限ができない場合は、対象データを分ける運用を担当者が実行できるかを確認します。それでも採用条件を満たせなければ見送ります。
以下の画面は、HubSpotの取引一覧に取引名、クローズ日、取引ステージ、関連会社、金額が並んでいる状態です。役割ごとに見せる情報と操作を考える際の確認対象として使います。
このような一覧では、取引の閲覧・編集、関連会社の閲覧、金額の表示、一括出力を分けて確認します。営業担当者、マネージャー、管理者のテスト用アカウントで同じ画面と操作を試し、期待した結果と実際の結果を役割表に残します。画面で非表示でも検索、レポート、出力から取得できるなら、必要な制限を満たしたとは判定しません。
権限の例外が増えた場合は、個人別の設定を追加する前に、役割やチームの定義を見直します。異動時に引き継げる権限設定へ整理できたら、その設定を運用手順へ移します。役割の変更後は、必要な業務を続けられるかと、不要になった操作が拒否されるかを再テストします。
暗号化と監査ログを評価する
評価ポイント3はデータ暗号化です。 通信中と保存中のデータを分け、添付ファイルやバックアップも対象に含まれるかを確認します。暗号化方式の名称だけでは、どのデータに適用されるか、鍵を誰が管理するかは分かりません。
次の表は、データ暗号化の対応状況を評価する際の基準の目安です。自社のレコード、添付ファイル、バックアップのうち、各行がどれを対象にするかを質問へ展開し、契約予定の構成で確認します。
| 評価 | 基準 |
|---|---|
| ◎ 優良 | TLS 1.2以上＋AES-256＋カスタマー管理鍵（BYOK）対応 |
| ○ 良好 | TLS 1.2以上＋AES-256（ベンダー管理鍵） |
| △ 確認が必要 | TLS対応だが保存データの暗号化が不明 |
| × 不適 | 暗号化の対応状況が非公開 |
表には暗号化以外の評価も含まれます。暗号化の判定では、まず自社が保存するデータを通常のレコード、添付ファイル、バックアップに分けます。各データについて通信時と保存時の保護範囲、鍵の管理主体、対象外の処理を尋ねます。回答が方式名だけなら適用範囲を追加で確認し、確認できない項目は「未確認」と記録します。
鍵の管理方法が自社ポリシー上の条件なら、利用企業が行える操作と契約条件まで確認します。必要なデータが対象外なら、そのデータをCRMへ保存する必要性と別の保存方法を見直します。HubSpotの公開資料を調べる際はHubSpot Securityを確認先として使い、記載された対象サービスと契約予定の構成が一致するか確かめます。
保存方法を変更する場合は、変更後のデータ経路も確認します。CRMに置かない情報を別の場所へ保存するなら、その保管先の閲覧者、更新者、削除手順を決めます。複製先を管理できないなら補完策として採用せず、対象データや利用方法を再検討します。
評価ポイント4は監査ログとモニタリングです。 ログイン、レコードの作成・変更・削除、権限変更、設定変更、データ出力、API利用のうち、自社の調査に必要な操作を選びます。操作ごとに、何をきっかけに調査を始め、実行者・対象・時刻・変更内容のどれが判断に必要かを決めます。取引金額への問い合わせなら対象レコードから変更を探し、権限変更への問い合わせなら対象アカウントから実行者を探す、といった具合に検索の起点も指定します。
次の表は、監査ログとモニタリング機能を評価する際の基準の目安です。表の「全操作」「主要操作」「保存」は、自社に必要な操作や参照条件の代わりにはなりません。取引金額の変更を調べる場面と、管理者権限の変更を調べる場面では、検索の起点も必要な記録も異なります。それぞれについて、次の4つを決めます。
- 報告を受ける人
- 最初の手掛かり ── 検索の起点にする情報です。
- 確認したい記録項目 ── 判断に必要な項目です。
- 記録を取得する人 ── 必要な時点の記録を取り出す担当者です。
その後、各行の機能が契約予定の構成で使えるか、必要な時点の記録を調査担当者が取得できるかを確かめます。
| 評価 | 基準 |
|---|---|
| ◎ 優良 | 全操作のログ記録＋SIEM連携＋アラート機能 |
| ○ 良好 | 主要操作のログ記録＋検索機能＋1年以上の保存 |
| △ 確認が必要 | ログイン履歴のみ、データ操作のログが不十分 |
| × 不適 | 監査ログ機能なし |
表の保存期間や機能の組み合わせは、契約予定の構成について確認した結果を示すものではありません。審査では、報告を受けてから調査を始める場面を想定し、必要な時点の記録を参照できるかを確認します。たとえば取引の金額について問い合わせが来た場合は、対象レコードから変更履歴を探し、変更者と変更内容を確認する流れを指定します。管理者権限の変更なら、対象アカウントから変更操作と実行者を調べる流れを指定します。
各場面について、テスト用のアカウントとデータで操作を再現します。
- 操作前に決める ── 記録を探す担当者と検索の手掛かりを決めます。
- 操作後に検索する ── その担当者の権限で検索します。
- テスト結果と突き合わせる ── 記録が見つかったら、対象・実行者・時刻・操作内容を照合します。
- 判断者へ渡せるか試す ── 調査担当者が結果を取得し、判断者へ渡せるかを確かめます。
表示時刻の解釈や対象の識別に迷う場合は、別の記録との照合方法を確認します。
記録が見つからない場合は、操作自体が記録対象外なのか、検索条件や参照権限が足りないのかを切り分けます。必要な時点の記録を参照できない場合は、提示された保存・参照条件と自社の調査開始条件を照合します。別の証跡を使うなら、実行者と対象を同じ操作に結び付けられるか、取得者が手順を再現できるかを試します。結び付けられなければ採用条件との不一致として扱い、利用範囲を広げる判断へ進みません。
モニタリングでは、大量出力や管理者権限の変更など、自社が調査を始めたい事象ごとに、通知を受ける人、業務上の必要性を確認する人、操作の停止を判断する人を決めます。通知を受けた担当者が記録を取得し、判断者へ渡せることを確認できたら、運用手順へ移します。通知先や担当者が変わったときは、この受け渡しを再確認します。
復旧と個人データ対応を評価する
評価ポイント5はデータバックアップと災害復旧です。 ベンダー側の障害と、利用者による誤更新・誤削除を分けて質問します。バックアップの対象、保存範囲、復元できる単位、依頼方法、復元時に戻らない更新を確認します。
自社側では、停止すると困る業務と、失われた場合に再入力が必要な情報を先に整理します。誤削除を想定するなら、依頼する人、戻す対象、復元後に確認する関連付けを指定して質問します。復元によって他の更新へ影響が出る場合は、その影響を調べ、利用部門へ連絡する担当も決めます。
回答が障害復旧だけを対象とし、誤削除からの復元方法が不明なら追加質問します。必要な範囲を戻せない場合は、自社での保管や再作成を担当者が実行できるか試します。その方法でも業務を再開できなければ見送ります。保存するデータや更新元が変わったときは、復元後の確認項目を見直します。
評価ポイント6は個人情報保護法への対応です。 利用目的、同意、第三者提供、保存期間、開示や削除への対応について、担当部門が対象データと必要な処理を決めます。削除依頼を例に、コンタクトから関連する取引、活動履歴、添付ファイルまでたどれるかを確認します。
次の表は、個人データを扱う工程と機能を照合するための基準の目安です。依頼の受付から対象の特定、承認、実行、結果の記録まで、どこを製品で扱い、どこを自社の手順で扱うかを分けて確認します。
| 評価 | 基準 |
|---|---|
| ◎ 優良 | 個人データの削除・開示請求対応＋同意管理＋自動削除 |
| ○ 良好 | 基本的な個人データ管理機能＋削除機能 |
| △ 確認が必要 | 個人データの一括削除が困難、同意管理が手動 |
| × 不適 | 個人情報保護法を考慮した機能が皆無 |
| GDPR（EU一般データ保護規則） | EU居住者データの処理が適法か、対象データと処理内容に基づいて担当部門が確認する |
機能の多さだけで判定せず、具体的な依頼を想定して処理の流れを確認します。関連レコードや出力済みデータについて、CRM上で扱う範囲と別の担当者へ引き継ぐ範囲を明確にします。手作業が残るなら、担当者、作業の記録先、結果を確認する人を定めます。対象データを特定できない場合は、運用開始前に登録方法と関連付けを見直します。
評価ポイント7はGDPRへの対応です。 EU居住者の情報を扱う場合は、対象となるデータと処理を担当部門が整理し、データ処理契約、本人からの権利行使、同意管理、越境移転の条件を確認します。該当するデータを扱うかどうかを先に判定し、該当する場合は保存先と処理の流れを示して要件を決めます。該当しないと判断した場合も、事業範囲が変わったときの確認担当を決めます。
適用の判断が分かれる場合は、扱う人の情報、取得経路、利用部門を列挙し、担当部門が確認するまで判定を保留します。事業範囲やデータの取得経路が変わった際は、その一覧を更新して再確認します。
認証、データ所在、事故対応を評価する
評価ポイント8は第三者認証とコンプライアンス情報です。 認証名だけで判断せず、報告書や認証書の対象組織、対象サービス、対象期間が、契約予定のCRMを含むかを確認します。資料を取得できない場合は、閲覧条件や代替資料を質問します。
次の表には、第三者認証・規格を並べています。審査票では自社に必要なものを選び、各項目に必要な資料と判定者を対応付けます。
| 認証・規格 | 概要 | 重要度の目安 |
|---|---|---|
| ISO 27001 | 情報セキュリティマネジメントシステム（ISMS） | ★★★（必須レベル） |
| SOC 2 Type II | サービス組織の内部統制報告書 | ★★★（必須レベル） |
| ISO 27017 | クラウドセキュリティの国際規格 | ★★☆ |
| ISO 27018 | クラウド上の個人情報保護 | ★★☆ |
| CSA STAR | クラウドセキュリティアライアンスの認証 | ★☆☆ |
| PCI DSS | クレジットカード情報のセキュリティ基準 | 決済データを扱う場合のみ確認 |
| ISMAP | 日本政府のクラウドサービス安全性評価制度 | 公共機関との取引がある場合に確認 |
| 評価 | 基準 |
|---|---|
| ◎ 優良 | ISO 27001＋SOC 2 Type II＋追加認証 |
| ○ 良好 | ISO 27001またはSOC 2 Type IIのいずれかを取得 |
| △ 確認が必要 | 認証取得予定あり、または独自のセキュリティ基準を公開 |
| × 不適 | 第三者認証なし、セキュリティ基準の公開なし |
表の重要度は自社の必須条件を決めるための参考であり、すべてのCRMに一律に当てはめる基準ではありません。認証については発行先、対象サービス、対象期間を照合します。インフラ提供元の認証を、CRMベンダー自身の認証として扱わないことも確認します。
資料を受け取った後は、認証名だけで終わらせず、自社が利用するサービスや構成が対象範囲に含まれるかを確認します。範囲を読み取れない場合は、ベンダーへの質問と回答を記録します。必須条件の証跡が得られない項目は、社内の判定者が確認できるまで保留します。
評価ポイント9はデータの所在とデータ主権です。 データセンターの国やリージョン、保存先を選べるか、再委託先、越境移転の条件を質問します。回答を受けたら、対象がレコードだけか、添付ファイルやバックアップも含むかを確かめます。国内保存が自社の採用条件なら、対象データと保存先を資料・契約条件で確認します。要件を満たせない場合は、例外承認の対象にできるかを社内で判断し、承認できなければ見送ります。
保存先について回答の範囲が曖昧なら、データ種別ごとに質問を分けます。保存先と、サポートや再委託などによる処理場所も分けて確認します。運用開始後に保存するデータや契約構成を変更する際は、当初の回答が変更後の範囲に当てはまるかを見直します。
評価ポイント10はインシデント対応とサポートです。 事故発生時の通知方法、窓口、提供される情報、脆弱性の受付、サービス状況の確認方法を調べます。通知を受けた後の自社の初動も設計し、アカウント停止、ログ保全、影響範囲の確認、社内連絡の担当を決めます。必要な情報や窓口が不明なら契約前に質問し、自社の初動を始める条件と連絡経路が定まれば運用手順へ進みます。
連絡先が分かるだけでは初動手順は完成しません。通知を受ける担当者が不在の場合の引き継ぎ先、社内で判断する事項、ベンダーへ追加確認する事項を分けて記録します。担当者の異動や窓口の変更があれば連絡網を更新し、通知を受け取れる設定も確かめます。
10項目を採用判断へ変える評価方法
評価結果は「適合」「条件付き」「見送り」に分けます。条件付きの項目には、不足する証跡、補完策、担当者、解消するタイミングを記録します。複数の製品を比較するときも、同じ要件、利用者、データ、操作を提示し、判定に使った条件を残します。
要件を採用条件と確認条件に分ける
最初に、満たさなければ導入を進められない採用条件と、設定・契約・社内運用を確認して判断する条件を分けます。分類は自社のデータと業務に基づいて行います。条件を変える必要が出た場合は、変更理由と影響する情報を判定者が確認してから、各製品を同じ条件で再評価します。
次の表は、判定結果ごとに次へ進むための作業と、HubSpotの公開資料から確認する項目を並べたものです。後半の製品情報は、自社の契約条件や設定の検証結果ではありません。出典の記載範囲と契約予定の構成を照合してから判定欄へ移します。
| 評価項目 | 確認ポイント | 一般的な対応状況 |
|---|---|---|
| 適合 | 自社の対象データと利用者に対して要件を満たす | 設定方法と証跡を導入計画へ移す |
| 条件付き | 上位プラン、追加設定、社内運用で補完できる | 費用、担当者、残るリスクを記録する |
| 見送り | 採用条件を満たさず、補完策も現実的ではない | 比較対象から外し、理由を稟議資料へ残す |
| 2FA/MFA | 二要素認証の対応と適用条件 | HubSpotは無料ツールでも2FAを利用でき、有料プランではパスワードでログインする全ユーザーに必須。出典 |
| RBAC | 役割に応じた権限の設定 | HubSpotの権限セットはEnterpriseで利用できる。出典 |
| データ暗号化 | 保存時と通信時の暗号化方式 | HubSpotは通信時にTLS 1.2または1.3、保存時にAES-256を使用する。出典 |
| ISO 27001 | 認証主体と認証範囲 | HubSpot本体はISO 27001未認証で、インフラ提供元のAWSが認証を維持している。出典 |
| SOC 2 | 報告書の有無と入手条件 | HubSpotにはSOC 2 Type 2報告書があり、顧客・見込み客向けに提供している。出典 |
| 国内データセンター | 日本リージョンの有無 | HubSpotの公式掲載リージョンに日本は含まれない。出典 |
| インシデント通知 | 通知対象と期限 | HubSpotは顧客個人データの侵害を認知した場合、不当な遅延なく72時間以内に通知すると定める。出典 |
- 権限セットの作成・割り当て ── HubSpotの作成・割り当て手順には、Marketing Hub、Sales Hub、Service Hub、Data Hub、Content Hub、Revenue Hubの各項目に「Enterprise」と記載されています。
- データ処理契約 ── HubSpotのデータ処理契約は、顧客サービス利用規約の一部を構成し、HubSpotが顧客に代わって処理者として顧客個人データを処理する際の両者の合意を定めています。
認証やデータ所在の行も、資料に書かれた範囲と自社の利用範囲を分けて扱います。第三者認証では認証主体と対象サービスを確認します。データ所在では公開資料に列挙された拠点に加え、自社アカウントの保存先、バックアップ、処理場所を確認します。暗号化では通信や記憶媒体についての説明を、すべてのデータ種別と鍵管理方法の確認結果へ拡張しません。
判定は機能名ではなく、要件ごとに行います。SSOが採用条件なら、最初に対象ユーザーを列挙し、管理者と例外アカウントを含めるかを決めます。次に、契約予定のプランで自社の認証基盤との接続条件を確認します。接続後は役割ごとにログインし、想定した経路を通ることと、想定外の経路を使えないことを試します。機能一覧だけを確認した段階では、接続と利用者への適用を未確認として残します。
想定外の経路が残った場合は、設定で制限できるかを調べます。制限できないなら、その経路を必要とする業務、利用者、管理者を特定し、例外として認められるかを判定責任者へ戻します。必要な構成で接続できない場合や、必須の利用者を保護できない場合は、採用条件との不一致を記録します。各役割のログイン結果と認めた例外の管理方法がそろった場合に、その要件を適合と判定します。
審査票では、SSO要件を次の欄に分けます。
- 対象プラン（契約予定のプラン）
- 対象ユーザー
- 接続テストの証跡 ── 接続を試した記録です。
- 例外アカウント（例外として残す必要があるアカウント）
- 判定責任者
- 残る確認作業 ── 未確認の項目です。
テストで判定が変わったときは、変更前後の条件と結果を記録します。証跡を得られないまま導入判断を迎える場合は、未確認の内容が採用条件に当たるかを判定責任者が確認します。補完策を採用する場合も、実行者と結果確認者が手順を再現できてから判定を更新します。
監査ログも同じ順序で判定します。まず調査したい出来事と必要な記録項目を決め、次に契約予定の構成で記録・検索・取得できる範囲を確認します。調査担当者のアカウントで実際に記録を探し、実行した操作と照合できたら適合とします。記録がない、探せない、必要な時点に参照できない場合は原因を分けて記録し、別の証跡でも調査を再現できない採用条件は適合へ変更しません。
製品比較は同じ前提条件で行う
CRMごとにプランや権限の考え方が異なります。比較前に利用者の役割、保存するデータ、必要な操作、契約予定のプランをそろえ、同じ業務例をベンダーへ提示します。回答がそろった項目から、採用条件を満たすかどうかを判定します。
次の表では、各項目に対して同じ質問とテストを行います。評価記号や製品全般についての記述がある行も、実際の回答を記録する欄とは分けて扱います。
| 比較項目 | 確認する内容 | 判断の分かれ目 |
|---|---|---|
| 多要素認証 | 管理者による適用範囲、認証方式 | 対象ユーザーへ運用できるか |
| SSO | シングルサインオン | 上位プラン限定の製品が多い |
| RBAC | オブジェクト、レコード、フィールドレベルの権限設定 | 必要な役割と操作の粒度を再現できるか |
| IP制限 | プラン別の利用可否 | 無料/エントリープランは×、ミドルプランは△、上位プランは◎ |
| 監査ログ（詳細） | プラン別の利用可否 | 無料/エントリープランは×、ミドルプランは△、上位プランは◎ |
| サンドボックス | プラン別の利用可否 | 無料/エントリープランは×、ミドルプランは×、上位プランは○ |
| 復旧 | バックアップ対象、復元単位、依頼手順 | 許容する停止と損失の範囲に収まるか |
| データ所在 | リージョン、再委託先、越境移転 | 自社ポリシーと契約条件に合うか |
比較表には、各製品の回答に加え、対象プラン、資料、操作結果を記録します。表中のプラン別記号や製品全般についての記述を、契約予定の製品の確定情報として扱わないでください。特にプラン区分が製品の実際の名称と一致しない場合は、契約予定の構成で回答を取り直します。監査ログは同じ調査場面を再現し、同じ手掛かりから必要な記録を探せるか比較します。復旧についても、想定する誤削除と障害をそろえて質問します。
「対応」という回答でも、対象データや操作の範囲が自社要件と一致しなければ条件付きです。判断が分かれる項目から実機検証や追加質問を行い、採用条件の判定を先に確定します。比較条件を途中で変更した場合は、影響する製品の回答を取り直します。
証跡の有無まで評価する
ベンダーの回答は、回答文、公式資料、契約条項、管理画面で確認できる設定、実機で得た操作結果に分けて保存します。口頭説明だけの項目は条件付きとし、契約前に資料や条項、または操作で確認できるかを質問します。
公開資料を確認するときは、資料名、URL、確認日と、記載されている対象サービス・プランを記録します。該当箇所と自社要件を対応付け、判定者が確認できるようにします。適用範囲が書かれていない場合はベンダーに質問し、回答を記録するまで適用可否を確定しません。契約後にプランや利用範囲が変わった場合は、その変更が影響する要件を再評価します。
実機テストには、試した役割、操作、対象データ、期待した結果、実際の結果を残します。資料とテスト結果が異なれば、設定条件や対象プランを確認します。理由が分かり、必要なら再テストしてから判定を更新します。
CRMベンダーへのセキュリティ質問リスト
質問は「対応していますか」で終わらせず、どのプランで、どのデータへ、誰が、どの設定を行えるかまで具体化します。回答を受け取ったら、採用条件との対応関係と根拠資料を同じ行に記録します。回答が不足する場合は、対象範囲または検証方法を追加で尋ねます。
CRMベンダーへの照会時は、次の質問について回答内容と証跡を確認します。各出典は質問の確認先であり、個別契約への適用を示すものではありません。
| # | カテゴリ | 質問 |
|---|---|---|
| 6 | データ保護 | 契約終了後のデータ返却・削除手順と、バックアップ内データの扱いは何ですか？ 出典 |
| 7 | アクセス制御 | SAML方式のSSOに対応し、どのプランで利用できますか？ 出典 |
| 8 | アクセス制御 | 利用できる2FA方式と、管理者が全ユーザーに適用する方法は何ですか？ 出典 |
| 10 | アクセス制御 | 許可するIPアドレスや地域を指定して、ログインを制限できますか？ 出典 |
| 14 | インシデント対応 | 個人データ侵害を認識した後、顧客へ通知する期限と連絡手順は何ですか？ 出典 |
認証、権限、ログについて質問する
次の表は、認証、権限、ログについてベンダーへ確認する質問です。自社の役割表と調査したい操作を添え、回答の対象プラン、利用者、データ、取得できる証跡まで確認します。
| カテゴリ | ベンダーへの質問 | 回答で見る点 |
|---|---|---|
| 認証 | 2FA/MFAの対応方式と管理者による強制適用の可否を示してください | 任意利用か、管理者が管理できるか |
| SSO | 対応方式（SAML 2.0、OAuth 2.0等）と利用可能なプランを示してください | 対象プランと認証基盤に合うか |
| 権限 | RBACの粒度（オブジェクト、レコード、フィールドレベル）と出力制限をどの単位で設定できますか | 自社の役割を再現できるか |
| 監査 | ログへ記録される操作と検索、出力方法を示してください | 調査対象の操作が残るか |
| アラート | 不審なログインや大量出力を検知する方法はありますか | 通知を受ける条件と担当者を設定できるか |
| アクセス制御 | デバイス制限機能はありますか | 対象デバイスと適用条件を確認できるか |
権限の質問では、営業担当者、マネージャー、CRM管理者の役割表を提示します。各役割について、担当外レコードの閲覧、金額項目の編集、一括出力を許可するかまで記載して回答を求めます。回答が機能名だけなら、対象となる画面や操作を分けて追加質問します。
ログは、調べたい場面を指定して確認します。たとえば「管理者が権限を変更した場合に、変更者と対象を探せるか」と尋ねます。回答には、次の4つを含めてもらいます。
- 記録される操作
- 検索に使える項目
- 取得する担当者の権限
- 必要な時点の記録を参照できる条件
回答を受けたら、調査担当者が対象アカウントから記録を探し、実際の変更と照合できるか試します。閲覧や取得に別の担当者が必要なら、その依頼先と受け渡し方法も記録します。必要な情報を取得できない場合は、記録対象、検索項目、参照権限、参照できる時点のどこが不足するかを示して追加質問します。
データ保護、復旧、契約終了後を質問する
次の表は、暗号化、復旧、保存先、契約終了時の扱いを確認するための質問です。レコードだけでなく、添付ファイルやバックアップが回答に含まれるかも確かめます。回答の対象外となるデータがあれば、そのデータを自社が保存するか確認してから判定します。
| カテゴリ | ベンダーへの質問 | 回答で見る点 |
|---|---|---|
| 暗号化 | 通信、保存、添付ファイル、バックアップの暗号化方式は何ですか | 対象外となるデータがないか |
| 鍵管理 | 暗号鍵は誰が管理し、利用企業が管理する選択肢はありますか | 自社要件との一致 |
| バックアップ | 対象データ、頻度、保存期間、リストア手順、復元単位を示してください | 誤削除から戻せる範囲 |
| 災害復旧 | 障害時の復旧手順と利用企業への連絡方法は何ですか | 自社の対応計画へ接続できるか |
| 国内データセンター | 日本リージョンの有無 | 製品ごとに提供リージョンを確認します |
| 契約終了 | データ出力と削除の手順を示してください | 移行と削除確認を完了できるか |
| インフラ | 稼働率に関するSLAの保証範囲と、稼働率の測定・報告方法を示してください | 対象サービスと契約プラン、未達時の取り扱いを確認できるか |
| インフラ | SLAで保証される稼働率の具体的な数値と、未達時の取り扱いを示してください | 対象サービスと契約プラン、稼働率の測定・報告方法を確認できるか |
バックアップがあることと、利用企業が必要なデータを復元できることは分けて確認します。誤削除したレコードを例に、依頼者、受付先、復元対象、復元後の確認方法を順に質問します。復元を依頼できない構成なら、自社でデータを保管する案について、保管先の権限、更新、削除まで決められるかを確認します。担当者が手順を実行できなければ、復旧の採用条件を満たしたとは扱いません。
データセンターについては、一般的な利用状況から契約予定の製品の保存先を推測しません。レコード、添付ファイル、バックアップの保存先と、契約予定の構成で選べる範囲を確認します。
契約終了時は、出力できるデータと形式、関連付けを再現できるか、出力後の削除確認方法を質問します。移行に必要な情報が不足する場合は導入前に代替手順を決め、代替手順も定められなければ契約終了時の運用条件を再判定します。
法令、第三者認証、インシデント対応を質問する
個人情報保護法やGDPRへの対応は、準拠の表明だけで判断しません。自社が扱うデータの種類と保存先を示し、担当部門が必要と判断した処理について、データ処理契約、開示や削除への対応方法、越境移転の条件、再委託先の管理方法を質問します。
第三者認証では資料の対象範囲を、インシデント対応では通知経路、提供される情報、問い合わせ窓口を確認します。自社の連絡網に接続できる回答なら手順へ反映し、通知条件が不明なら契約前の確認事項として残します。担当部門が実際に通知を受け取れるか、担当者の異動後も引き継げるかまで確かめます。
| 確認項目 | ベンダーへの質問 | 回答で見る点 |
|---|---|---|
| 個人情報保護法・GDPR | 対応状況を対象データと処理ごとに示してください | 担当部門が資料と対象範囲を確認できるか |
| インシデント通知 | 通知ポリシーと事故発生後の通知期限・起算点を示してください | 契約条項や通知ポリシーで確認できるか |
| 脆弱性管理 | 管理プロセスとセキュリティパッチの適用ポリシーを示してください | 対象サービスの資料で確認できるか |
回答が複数の資料に分かれている場合は、審査票の項目ごとに根拠を対応付けます。資料間で対象サービスや条件が異なるなら、どの回答が契約予定の構成に当てはまるかをベンダーへ確認し、判定がそろってから運用手順へ移します。
情報セキュリティポリシーとCRM運用の整合
選定時に要件を満たしても、導入後の設定変更や利用者の異動に対応できなければ、確認した状態を維持できません。申請、承認、設定、結果確認を一続きの手順として設計します。各段階で担当と記録先を決め、変更後に採用条件を満たしているか確かめます。
最小限の役割と項目から設計する
最初は営業担当者、マネージャー、管理者など、業務上必要な役割を定義します。各役割について、閲覧、編集、削除、出力、権限変更を分けて記入し、利用者に割り当てます。例外が必要になった場合は、個人設定を加える前に既存の役割を見直します。
変更時は、申請者が必要な業務操作と対象データを示し、承認者が必要性を判断し、管理者が設定します。別の担当者がテスト用の操作または設定結果で確認し、役割表を更新します。申請の理由が曖昧なら設定を保留し、必要な操作が具体化してから再判断します。
プロパティも、営業プロセス、レポート、法令対応に使う項目から始めます。新しい項目の申請時には、用途、入力者、閲覧者、保存する情報の種類を確認します。用途を説明できない項目は追加を保留し、必要性が確認できたら権限と入力ルールを合わせて決めます。
役割や項目を変更した後は、申請どおりに使えることと、許可していない操作が増えていないことを確認します。結果を役割表に反映し、次の異動や申請で同じ判断を再現できるようにします。
コンタクトから請求まで一気通貫で見る
コンタクトの登録から会社との関連付け、取引の作成、顧客化、請求情報の連携まで、データが移動する経路を図にします。経路ごとに、更新元、閲覧者、出力先を確認します。連携先に渡す情報が変わる場面も記し、変更の承認者を決めます。
次の表は、業務で扱う情報と確認事項を並べたものです。バックアップと検証環境に関する行はデータ経路とは別の要件として取り出し、それぞれ復元と検証の方法を確認します。
| 対象 | 扱う情報 | 確認事項 |
|---|---|---|
| バックアップ | 保存対象、頻度、保存期間 | リストア手順と復元範囲 |
| サンドボックス | 検証環境 | 契約予定の構成で利用できるか |
| 会社 | 企業情報、担当者との関連 | 重複管理、関連付けの変更権限 |
| 取引 | 金額、ステージ、提案内容 | 担当範囲、更新履歴、出力権限 |
| 顧客 | 契約情報、対応履歴 | 部門間共有、保存期間 |
| 請求 | 請求に必要な情報 | 連携先、更新主体、閲覧範囲 |
データ経路では、元の情報をどこで更新するか、関連付けを誰が変更できるか、出力後の情報を誰が管理するかを追います。連携先へ渡す項目が変わる場合は、変更を承認する担当者と閲覧範囲を確認します。バックアップと検証環境については、表中の文言を提供状況の確定情報とせず、契約予定の構成で確認します。
CSVの出力が必要な業務には申請者と保管先を決め、画面上のビューやレポートで足りる業務は出力権限を付けない設計を検討します。出力先の管理方法が決まらない場合は、出力を許可する前に利用部門と情報システム部門で手順を決めます。
日常運用を担当者と証跡へ落とす
次の表は、確認作業を運用計画へ落とし込むための例です。記載された頻度は自社の基準としてそのまま採用せず、人事からの連絡、ログを取得できる条件、担当者の勤務体制に合わせて決めます。各タスクでは、何を見て異常と判断するかも具体化します。
| 頻度 | タスク |
|---|---|
| 毎日 | 不審なログイン（深夜時間帯、海外IP等）のアラート確認 |
| 毎週 | 異動・退職者のアカウント状況の確認 |
| 毎月 | 監査ログのレビュー（大量エクスポート、管理者操作の確認） |
| 四半期 | アクセス権限の棚卸し（不要な権限の整理、ロールの見直し） |
| 年次 | ベンダーの認証状況（ISO 27001、SOC 2等）の更新確認 |
異動・退職が分かったときのアカウント変更は、定期確認を待つ扱いにせず、人事から管理者への連絡手順に組み込みます。定期確認は、その連絡と変更が反映されたかを照合する機会として設計します。
各タスクには確認場所、確認者、異常と判断する条件、対応先、記録先を付けます。大量出力や管理者権限の変更を見つけた場合に、誰が業務上の必要性を確かめ、誰が停止を判断するかまで決めます。正常な業務操作だった場合も、照合した情報と判断を残します。
棚卸しでは現在の所属と担当業務を役割表に照らし、不要になった権限を変更する担当者と結果確認者を決めます。ログ確認で対象操作を追えないと分かった場合は、その操作を採用条件としていたかを確認します。採用条件であれば、別の証跡を取得して同じ調査を行えるか試し、できなければ利用範囲を広げる前に判定を見直します。
スモールスタートで進める導入手順
対象データ、利用者、業務範囲を絞って開始し、権限とログを検証してから段階的に広げます。範囲を広げる条件は、必要な業務を行えること、許可していない操作を拒否できること、採用条件とした操作の記録を調査担当者が取得できることです。
現状のデータ経路を整理する
Excel、スプレッドシート、メール、紙の名刺、既存システムにある顧客情報を洗い出します。誰が作成し、誰へ共有し、どこへ転記し、異動・退職の際にどう扱うかを確認します。更新元が複数ある情報は、移行後にどこを正とするかを利用部門と決めます。
次の表は、現在の管理方法からCRMへ移す際の確認例です。各行について実際の更新元と共有先を確かめ、CRMへ移した後の入力者、閲覧者、出力先を決めます。
| 現状 | 起こりやすい課題 | CRM移行時の設計 |
|---|---|---|
| 部門別の顧客台帳 | 同じ顧客情報の差分 | 会社とコンタクトの関連付け |
| メール添付の一覧 | 配布先と複製先を追いにくい | ビュー共有と出力権限 |
| 個人管理の商談メモ | 引き継ぎ時に情報が欠ける | 取引と活動履歴への集約 |
| 手作業の権限変更 | 異動や退職時の解除漏れ | 申請と無効化手順の標準化 |
洗い出した情報は、CRMへ移すもの、移行後に更新を止めるもの、例外として残すものに分けます。例外として残す場合は管理者と更新元を決めます。更新元が決められない情報は、移行前に担当部門へ判断を戻します。
限定した範囲で権限を検証する
対象部門とデータを絞り、役割別のテストを行います。営業担当者が担当取引を扱えるか、マネージャーがチームの状況を確認できるか、管理者が権限変更を追えるかを試します。役割表には、利用者、対象データ、操作、期待する結果を事前に記入します。
同時に、担当外レコードの閲覧、制限対象の項目の編集、許可のない出力が拒否されるかを確認します。意図しない操作ができる場合は設定を修正して再確認します。必要な操作ができない場合は、その役割の業務範囲か製品の制御方法を見直します。許可と拒否の両方を確認し、未解決の採用条件がないと判定できてから対象範囲を広げます。
ログについても、限定運用で発生した確認対象の操作を調査担当者が探せるか試します。対象レコードやアカウントから記録を検索し、実行者と操作内容を実際の操作に照合します。取得できなければ、記録範囲、検索方法、取得権限、参照条件のどこに不足があるかを調べます。補完策でも同じ調査を再現できなければ、利用範囲を広げる判断へ進みません。
運用結果を見て段階的に拡張する
限定運用後は、閲覧できず業務が止まった場面、不要だった権限、ログで追えなかった操作、申請から設定までの流れを整理します。役割、項目、通知、申請手順を修正し、変更後の権限を再テストしてから対象部門を増やします。
段階導入でも、開始時点で必要な認証、基本権限、データ保護、退職者対応、インシデント連絡は先に整えます。未解決の採用条件が残る場合は利用範囲を広げず、担当者が証跡と補完策を確認します。保存する情報や閲覧者が増える場合は、その増分に影響する要件を再評価します。
拡張の判断には、追加する部門、データ、役割と、それぞれに影響する要件を記録します。新しい範囲でも必要な操作と拒否したい操作を確認できたら、運用手順と役割表を更新して次へ進みます。
CRMセキュリティ評価の限界と注意点
チェックリストは確認漏れを減らす道具です。回答欄が埋まっていても、製品仕様、契約条件、自社設定、利用者の操作が一致しているかを確かめる必要があります。確認した範囲と、まだ試していない範囲を分けて残します。
上位プランだけで利用できる機能がある
SSO、監査ログ、IP制限、カスタム権限、鍵管理、検証環境などは、契約する製品とプランで利用条件を確認します。機能一覧で見つけた後に、対象プラン、追加契約の要否、設定担当、検証できる時期を記録します。
採用条件を満たす構成が分かった段階で、その構成を見積もりと導入計画へ反映します。契約予定の構成で確認できない機能は適合とせず、確認先と判定者を残します。利用範囲やプランを変更する場合は、その機能を必要とする役割とデータを再確認します。
次の表は、再利用可能なカスタム権限セットについて、契約予定の構成で確認するためのものです。利用可能なプランを確認した後も、割り当てる担当者の権限、対象ユーザーのシート、必要な操作が想定どおりになるかを確かめます。
| セキュリティ機能 | 無料/エントリープラン | ミドルプラン | 上位プラン |
|---|---|---|---|
| 再利用可能なカスタム権限セット | 無料・Starter：対象外 | Professional：対象外 | Enterprise：作成・割り当て可 出典 |
機能があっても運用できない場合がある
権限機能が細かくても、異動時に誰が変更し、誰が結果を確かめるかを決めなければ設定は維持できません。管理者の手順を試し、役割の追加・変更・解除を担当者が実行できるか確認します。個人別の例外が増えて追えなくなる場合は、役割や申請の流れを見直します。
監査ログも、記録範囲だけでは判定できません。調べたい操作を担当者が検索・取得し、対象と実行者を実際の操作に照合できるかを試します。通知を受けても判断できない場合は、対応を始める条件と通知先を見直します。必要な操作を追えない場合は別の証跡で同じ照合ができるか試し、できなければ採用条件へ戻って判定します。
ベンダー評価と自社設定を混同しない
第三者認証や暗号化はベンダー評価の材料ですが、自社のユーザー権限やデータ入力ルールを代替しません。自社の手順で補う項目も、必要な操作を製品で制御・確認できるかを確かめます。
最終判断では、ベンダーが担う対策、自社設定で担う対策、運用で補う対策、受け入れる残存リスクを分けます。担当者と確認方法が決まらない項目は条件付きとして残します。採用条件に関わる不足を解消できなければ、導入判断を進めずに見送ります。
よくある質問
CRMのセキュリティ評価は誰が主導すべきですか？
情報システム部門が技術要件と証跡を整理し、法務部門が個人データの取り扱いを確認し、利用部門が必要な業務操作を示します。最初に各部門の判定範囲を決め、採用条件が衝突した場合の判断者を定めます。利用部門が示した操作を権限テストで確認し、法務部門が必要と判断した処理の手順を確かめてから、導入判断へ進めます。
無料プランのCRMでも利用できますか？
保存する情報と自社ポリシーが求める機能によって判断が変わります。多要素認証、SSO、監査ログ、IP制限、カスタム権限など、採用条件に挙げた機能を利用予定のプランで確認します。必要な利用者へ設定でき、担当者が運用を再現できれば選択肢に残します。採用条件を確認できない場合は追加質問し、満たせない場合は見送ります。
クラウドCRMとオンプレミスCRMはどちらを選ぶべきですか？
インフラ保守、データ所在、更新作業、復旧、運用人材について、自社と提供者の責任範囲を並べて比較します。どちらの場合も、必要な権限制御と復旧手順を実行できるかを確認します。自社が担う作業について担当者、確認方法、障害時の連絡先まで決められる構成を選びます。
ベンダーがセキュリティ質問へ回答しない場合はどうしますか？
採用条件に関する回答や根拠資料を得られない項目は、適合として扱いません。秘密保持の条件下での資料提示、監査報告書の閲覧、契約条項への記載が可能かを質問します。それでも確認できない場合は、不足する証跡と判断への影響を記録し、その条件を満たすものとして導入を進めないでください。
導入後にインシデントが疑われる場合はどう対応しますか？
まず対象アカウントや連携について停止が必要な範囲を責任者が判断し、調査に必要なログを保全します。影響を受けたデータと利用者を調べ、ベンダーの窓口と社内の対応責任者へ連絡します。報告や通知の要否は法務部門を含む担当者が確認します。平常時に初動の担当者、判断者、連絡先、証跡の保存先を定め、担当者が変わった際に手順を更新します。
まとめ
CRMセキュリティ要件は、製品の機能表に自社のデータ、利用者、業務フロー、運用体制を重ねて評価します。確認する項目は、認証、アクセス制御、暗号化、監査ログ、バックアップ、個人データ対応、GDPR、第三者認証、データ所在、インシデント対応です。
- 現状を整理する ── 現在の顧客情報の所在と共有経路を整理し、守る対象と必要な操作を決めます。
- 条件を分けて集める ── 各評価ポイントを採用条件と確認条件に分け、ベンダーの回答、資料、契約条件を集めます。
- 判断が分かれる項目を検証する ── 同じ業務例で追加質問または実機検証を行い、期待した結果と実際の結果を記録します。
- 範囲を絞って広げる ── 対象部門を絞って権限とログを確認し、未解決の採用条件がないと判定できてから利用範囲を広げます。
企業様によって最適な形は異なります。採用の分かれ目は、必要な機能があるかだけでなく、自社の役割で設定を再現でき、問題が起きたときに記録を調べて対応できるかです。未確認の項目には担当者と次の確認作業を付け、判定を終えてから導入を進めます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
セキュリティ要件を決めた後のデータ移行、利用部門への定着、営業プロセスの設計は、次の記事で確認できます。移行する情報と権限を整理したら、実際の運用手順へつなげてください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
