新しいSaaSの導入相談を現場から受けた際、情シスはどのレベルまで評価すべきでしょうか。「無料トライアルだから」「規模が小さいベンダーだから」と簡略化した結果、契約後にデータ取り扱いの問題が発覚し、契約解除に追い込まれる事例が後を絶ちません。

導入前のセキュリティ評価は、契約締結後よりも圧倒的に低コストで実施できます。評価フレームワークを社内に標準化しておくことで、現場の起案担当者は「何を確認しておけば情シスの承認が下りるか」を理解し、情シスは限られた工数で多くの起案案件を捌けるようになります。

本記事では、SaaSベンダーのセキュリティ評価で使えるチェックリストを、第三者認証・データ取り扱い・契約条項・運用機能の4カテゴリで整理しました。リスクスコア算出のテンプレートと、ベンダー比較の実務フォーマットも併せて提示します。

SaaSセキュリティ評価 チェックリストの目的と位置づけ

SaaSセキュリティ評価 チェックリストとは、ベンダー選定・契約・更新の各タイミングで、第三者ベンダーが提供するクラウドサービスの安全性を体系的に評価するための定型項目集です。「採用の合否判定」と「採用後のリスクモニタリング」の双方に活用します。

評価の目的は3つあります。第1に、契約前にリスクを把握し、自社の許容範囲を超えるベンダーを採用しないこと。第2に、採用後に問題が発覚した場合の「想定内・想定外」を切り分けること。第3に、監査時にデューデリジェンスの記録として提示できることです。

評価の対象は単なる「セキュリティ機能」だけではありません。財務健全性、サポート品質、契約条項、運用負荷など、リスクと運用に関わる多面的な観点を含みます。情報セキュリティ部門だけでなく、法務・調達・現場部門との連携が必要なテーマです。

チェックリストを整備する効果は以下の通りです。

• 起案者が事前に確認すべき項目を理解し、申請の手戻りが減る
• 評価結果の記録が残り、監査・コンプライアンス対応の根拠になる
• 担当者の経験差に依存しないベンダー選定品質を確保できる
• 同等候補製品の客観的比較ができる

参考：クラウドサービス利用のための情報セキュリティマネジメントガイドライン（経済産業省）

評価の全体構造（4カテゴリ × 重要度）

評価項目は以下の4カテゴリに分類すると整理しやすくなります。

• 第三者認証・コンプライアンス: ISO/IEC 27001、SOC 2、ISMAP、Pマーク等の保有状況
• データ取り扱い・所在: データセンター所在地、暗号化、バックアップ、削除プロセス
• 契約条項・法務: SLA、損害賠償、解約・データ持出、準拠法
• 運用機能・連携: SSO/MFA、SCIM、監査ログ、API、サポート体制

各項目は重要度を3段階で運用するのが現実的です。

必須（Must）: 該当しない場合は採用見送り

• 推奨（Should）: 該当しない場合は補完策を求める
• 任意（Nice to Have）: 評価の参考情報として記録

重要度は、扱うデータの機微性、業務での重要度、規制要件によって変動します。機密情報を扱う基幹SaaSは「必須」の比率を高くし、社内コミュニケーションツールは「推奨」中心で運用するなど、SaaSのリスクプロファイルに応じて調整します。

評価結果はリスクスコア化することで、複数候補の客観比較が容易になります。スコア化の方法は後述の「リスクスコア算出」で詳述します。

参考：Cloud Controls Matrix v4（CSA）

第三者認証・コンプライアンス評価項目

ベンダーが取得している第三者認証は、客観的な信頼性指標になります。認証ごとに評価範囲と粒度が異なるため、目的に応じて使い分けが必要です。

主要な認証・基準

• ISO/IEC 27001: 情報セキュリティマネジメントシステム（ISMS）の国際規格。組織全体の管理体制を評価する
• ISO/IEC 27017: クラウドサービス特有の管理策を含む補完規格
• ISO/IEC 27018: クラウド上の個人情報保護に特化した規格
• SOC 2 Type 2: 米国公認会計士協会（AICPA）のTrust Services Criteriaに基づく保証報告書。一定期間の運用状況を評価する（「認証」ではなく「保証報告書」）
• ISMAP: 政府情報システム向けクラウドサービス安全性評価制度
• Pマーク（プライバシーマーク）: 個人情報保護に関する国内認証
• PCI DSS: クレジットカード情報を扱う場合の業界規格

チェック項目

• 自社が必要とする認証を保有しているか
• 認証の有効期限と次回更新時期が公表されているか
• 認証範囲（事業所、サービス）が利用予定のSaaSをカバーしているか
• 監査報告書（SOC 2 Type 2）の閲覧が可能か（NDA締結により可能なケース）
• 過去にインシデントを起こしている場合、その内容と再発防止策の開示
• 業界特化の認証（HIPAA、FedRAMP等）が要件に該当するか

第三者認証は「持っていれば安全」ではなく、「最低限の管理体制が整っている」ことの確認手段です。認証の有無だけで判断せず、後述のデータ取り扱い・契約条項とあわせて総合判断する必要があります。

参考：ISMAP 制度概要（独立行政法人情報処理推進機構）

データ取り扱い・所在に関する評価項目

データの所在地、暗号化、削除プロセスは、漏洩リスクと法令遵守に直結する評価項目です。特に個人情報・機密情報を扱うSaaSでは詳細な確認が必要になります。

データ所在・主権

• データセンター所在地: 主要データ・バックアップの所在国
• データレジデンシー要件: 自社の規制要件（金融、医療、政府）への適合
• データの域外移転: クロスボーダーでのデータ転送経路と保護措置
• 米国Cloud Act、EU GDPR等の海外法制適用リスク
• 国内データセンターオプションの有無と追加費用

暗号化・保護

• 通信暗号化: TLS 1.2/1.3対応、最新化のロードマップ
• 保管時暗号化: AES-256等の業界標準アルゴリズム
• 暗号鍵管理: ベンダー管理、顧客管理（BYOK/HYOK）の選択肢
• データベース・バックアップの暗号化範囲
• アクセスログの暗号化と保管

バックアップ・可用性

• バックアップ取得頻度と保持期間
• リカバリーポイント目標（RPO）とリカバリータイム目標（RTO）
• ディザスタリカバリ計画（DR）の整備状況
• 過去12か月のダウンタイム実績

データ削除・持出

• 解約後のデータ保持期間とエクスポート方法
• 削除リクエストへの対応プロセスと完了通知
• データの完全消去証明の発行可否
• API・CSV等での全データエクスポート機能

学習・解析利用

• 顧客データを学習・解析に利用するか（特にAI機能）
• 学習利用のオプトアウト設定の可否
• 統計データ・匿名化データの第三者提供有無
• 再委託先（サブプロセッサ）の開示

参考：個人情報保護法ガイドライン（個人情報保護委員会）

契約条項・法務評価項目

契約書のセキュリティ・法務関連条項は、漏洩発生時の責任範囲と賠償範囲を決定づけます。法務部門との連携で詳細レビューが必要な領域です。

SLA・サポート

• 稼働率SLA（99.9%、99.99%等）と未達成時の補償
• 計画停止の事前通知期限と頻度
• インシデント時のサポート応答時間（24/7、営業時間内）
• 日本語サポートの有無と対応範囲
• エスカレーションルートの明確化

インシデント対応

• 漏洩発生時の通知期限（24〜72時間）と通知経路
• インシデント詳細レポートの提供義務
• 顧客側調査への協力義務（フォレンジック、ログ提供）
• 共同対応窓口の設置

損害賠償・責任

• 損害賠償上限（例として年間契約金額を基準に設定されることがある。契約類型や交渉力により大きく異なる）
• 賠償対象範囲（直接損害のみ、間接損害含む）
• 免責事項（不可抗力、第三者攻撃等）
• 賠償保険の加入状況

解約・データ持出

• 解約予告期間
• 解約時のデータエクスポート支援
• 削除完了までの期限と削除証明
• データ移行ツール・支援サービスの有無

監査権・準拠法

• 監査権・現地査察権の有無
• 第三者監査報告書（SOC 2、ISO 27001）の閲覧可否
• 契約準拠法（日本法、米国法等）
• 紛争管轄裁判所
• 個人情報取扱業務委託契約書（DPA）の締結可否

価格・契約期間

• 契約期間と自動更新条項
• 値上げ条件と通知期限
• 利用量変動への対応（増減時の月割計算等）
• 早期解約時の違約金

参考：サイバーセキュリティ経営ガイドライン Ver3.0（経済産業省）

運用機能・連携評価項目

採用後の運用負荷を左右する技術的な機能評価です。情シスが日常運用で関わる項目が中心になります。

認証・アクセス制御

• SAML 2.0、OpenID Connectでの SSO 連携
• MFA対応（TOTP、FIDO2、生体認証）
• 条件付きアクセス（IP、デバイス、時間帯）
• 管理者権限の階層化、特権アクセス管理（PAM）対応
• セッションタイムアウト、リフレッシュトークン管理

ID 管理・プロビジョニング

• SCIM 2.0対応、プロビジョニング自動化の範囲
• グループ・ロール同期
• 一括棚卸し用APIの提供
• ゲストユーザー、外部協力者の管理機能

監査ログ・アラート

• 操作ログの取得粒度（ログイン、設定変更、データアクセス）
• ログ保持期間とエクスポート方法
• SIEMへの転送機能（Syslog、API、コネクタ）
• リアルタイムアラートと通知方法

設定管理

• セキュリティベースライン設定のテンプレート提供
• 設定変更履歴の保存
• IaC（Infrastructure as Code）対応、設定の構成管理
• API経由での設定取得・変更

サードパーティ連携

• API公開範囲とレート制限
• OAuth 2.0、APIキー管理
• アプリ承認ワークフロー
• 利用中の外部連携の可視化

参考：NIST SP 800-207 Zero Trust Architecture（NIST）

リスクスコア算出と意思決定への活用

評価結果を客観的な意思決定材料にするには、各項目に重み付けをしたスコアリングが有効です。

スコアリング方法

各項目を0〜3点で評価します。

• 0点: 該当機能・条項なし
• 1点: 一部対応、補完策が必要
• 2点: 標準対応、自社要件を満たす
• 3点: 充実した対応、業界トップレベル

カテゴリごとに合計点を算出し、必須項目で1点以下があれば総合判定は「採用見送り」または「補完条件付き承認」とします。推奨項目で1点以下が3つ以上あれば、補完策の協議が必要です。

スコアシートの例（1製品あたり）

カテゴリ別の重み付けは、SaaSの重要度に応じて調整します。基幹SaaS向けの一般例は以下です。

• 第三者認証: 25%
• データ取り扱い: 30%
• 契約条項: 25%
• 運用機能: 20%

総合スコアが80点以上は「推奨」、60〜79点は「条件付き承認」、60点未満は「見送り」が標準的な閾値です。閾値は自社のリスク許容度に応じて調整します。

意思決定のフロー

評価結果は単独で判断せず、以下のフローで活用します。

• 必須項目に欠落: 採用候補から除外
• 推奨項目に複数欠落: 補完策の協議、補完不可能なら見送り
• 同等候補が複数: スコアと運用工数・価格の総合判断
• 採用後: 半期〜年次で再評価、スコア低下時は契約条件の見直し

参考：ISO/IEC 27036（サプライヤ関係のための情報セキュリティ）

SaaSセキュリティ評価に関連する用語集

記事内で頻出する専門用語を整理します。

• 第三者認証: 独立した審査機関が組織の管理体制を評価・認証する制度
• ISO/IEC 27001: 情報セキュリティマネジメントシステムの国際規格
• SOC 2 Type 2: 一定期間の運用状況を評価する米国の保証基準
• ISMAP: 政府情報システム向けクラウドサービス安全性評価制度
• BYOK/HYOK: Bring/Hold Your Own Key。顧客が暗号鍵を自ら管理する方式
• DPA: 個人情報取扱業務委託契約書（Data Processing Agreement）
• データレジデンシー: データの所在地に関する規制要件
• RPO/RTO: バックアップ・災害復旧の目標値（Recovery Point/Time Objective）
• サブプロセッサ: ベンダーがデータ処理を委託する第三者
• リスクスコア: 評価項目を数値化した客観指標

ジョーシスを活用したSaaS評価の効率化

評価チェックリストを導入時だけでなく、運用中の継続評価にも適用するには、対象SaaSの可視化と評価記録の管理が前提になります。

ジョーシスは、SaaS・デバイス・人を一元管理するAI駆動のSMPです。SaaS評価の文脈では、以下の機能が直接的な貢献となります。

• 利用SaaSの自動検出: 経費精算、SSOログ、API連携から契約済み・未契約SaaSを可視化
• ライセンス管理: 各SaaSの契約状況、利用率、更新時期を一元管理
• アカウント情報: ロール、権限、最終ログインを可視化、評価項目の自動取得を一部支援
• 評価記録の保管: 各SaaSのメタデータに評価結果・スコア・次回見直し時期を記録

導入企業数は国内外700社を超え、IT工数を最大50%、ITコストを最大75%削減した事例が報告されています。350以上のSaaSと連携可能で、評価対象の棚卸しから運用後のモニタリングまで、SaaS管理の中核を担います。

SaaS評価の自動化と一元管理を実現したい方は、以下から資料をダウンロードください。

5分でわかるJosys（資料ダウンロード）

無料デモを予約する

SaaSセキュリティ評価 チェックリストに関するよくある質問

Q1. 中小SaaSベンダーは認証を持っていないことが多いですが、採用は不可ですか

不可とは限りません。認証保有は信頼性の指標の1つですが、必須ではないケースもあります。代替手段として、自社による詳細評価（質問票回答、契約条項の強化、定期監査権の確保）で補完できれば、採用可能なケースがあります。リスクとビジネス価値のバランスで判断します。

Q2. 評価チェックリストは何件のSaaSに適用すべきですか

機密情報を扱うSaaSは全件、それ以外は重要度に応じて段階適用が現実的です。リソース上、全SaaSに同等の評価をかけるのは難しいため、SaaSの重要度を「機密性・基幹度・コスト」の3軸でスコア化し、重要度の高いSaaSから優先的に詳細評価を適用するアプローチが現実的です。

Q3. 評価結果はどの程度の頻度で見直すべきですか

新規導入時は必須、既存SaaSは半期〜年次が標準的です。インシデント発生時、契約更新時、重要機能追加時は随時見直しが必要です。継続評価を効率化するため、ベンダーから提供される第三者監査報告書の年次確認をルーチン化すると工数を抑えられます。

Q4. 評価結果の記録はどの形式で残すべきですか

最低限、以下の5項目を記録します。評価日、評価者、各項目のスコア、総合スコアと判定、次回見直し時期。スプレッドシートでも運用可能ですが、SaaS数が増えると管理が煩雑化するため、SMP製品のメタデータ管理機能を活用する方法が現実的です。

Q5. ベンダー側がチェックリストへの回答を拒否する場合はどう対応しますか

拒否される場合、リスク許容度を再評価する必要があります。一般公開情報（プライバシーポリシー、サービス規約、認証保有状況）と類似ベンダーの情報で代替評価を行い、結果が許容範囲を超えるなら採用を見送るのが安全な対応です。情シスとしての立場を強化するには、起案フローでの「ベンダー回答必須」をルール化することも有効です。

まとめ

SaaSセキュリティ評価 チェックリストは、ベンダー選定の品質を仕組みで担保するためのフレームワークです。第三者認証、データ取り扱い、契約条項、運用機能の4カテゴリで評価項目を整理し、リスクスコアで客観比較することで、属人的な判断を組織の合意可能な意思決定に変換できます。

重要なのは、評価を「導入時の1回」で終わらせず、契約更新・インシデント発生・重要機能追加のタイミングで再評価する継続運用に組み込むことです。SMP製品でSaaSの一覧と評価記録を一元管理することで、限られた情シスの工数で広い管理範囲をカバーできます。

評価運用の自動化と一元管理を実現したい方は、ジョーシスの資料を参照ください。

5分でわかるJosys（資料ダウンロード）

無料デモを予約する