プライバシー設定

このサイトでは、第三者のウェブサイト追跡技術を使用して、当社のサービスを提供および継続的に改善し、ユーザーの興味に応じた広告を表示します。同意します。また、将来的に有効となる限り、いつでも同意を取り消したり、変更したりすることができます。

すべての記事

SaaSセキュリティ評価チェックリスト｜ベンダー選定から継続監視まで実務で使える評価ガイド

ジョーシス編集部

SaaS運用に課題を感じている方へ

現在の状況をヒアリングし、最適な改善方法をご提案します。

Last updated:

November 11, 2026

この記事は読むことができます 5 分

この記事は 1 分で読むことができます

By:

ジョーシス編集部

この記事は 1 分で読むことができます

コピー

現場から「新しいSaaSを導入したい」と申請が届いたとき、情シスはどこまで確認すればよいのでしょうか。「小規模なベンダーだから」「無料枠で試すだけだから」と簡略化した結果、契約後にデータ取り扱いの問題が発覚し、契約解除に追い込まれる事例が後を絶ちません。

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

SaaSベンダーのセキュリティ評価に使えるチェックリストを、第三者認証・データ取り扱い・契約条項・運用機能の4カテゴリで体系化しました。リスクスコア算出の手順と意思決定フロー、さらに継続評価の自動化まで、実務で即使える形で解説します。

SaaSセキュリティ評価チェックリストとは何か

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

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

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

チェックリストを整備することで得られる効果は以下のとおりです。

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

なお、経済産業省は「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」を公開しており、評価項目の設計時に参照することを推奨しています。

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

評価の全体構造：4カテゴリと重要度の設計

評価項目は4カテゴリで整理するとMECEに管理しやすくなります。第三者認証・コンプライアンス、データ取り扱い・所在、契約条項・法務、運用機能・連携の4つです。

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

必須（Must）：該当しない場合は採用見送り
推奨（Should）：該当しない場合は補完策を求める
任意（Nice to Have）：評価の参考情報として記録

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

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

SaaSのセキュリティ評価を体系的に設計する際は、Cloud Security Alliance（CSA）が公開するCloud Controls Matrix（CCM）も有力な参照資料です。

参考：Cloud Controls Matrix v4（Cloud Security Alliance）

第1カテゴリ：第三者認証・コンプライアンスのチェック項目

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

主要な認証・基準の種類と意味

代表的な認証の概要を整理します。

ISO/IEC 27001は、情報セキュリティマネジメントシステム（ISMS）の国際規格です。組織全体の管理体制を評価し、情報資産の保護策が体系的に整備されているかを確認します。

ISO/IEC 27017は、クラウドサービス特有の管理策を含む補完規格です。ISO 27001取得済みベンダーがさらにクラウド固有のリスクに対応していることを示します。

ISO/IEC 27018は、クラウド上の個人情報保護に特化した規格で、個人データを扱うSaaS評価で特に重要になります。

SOC 2 Type 2は、米国公認会計士協会（AICPA）のTrust Services Criteriaに基づく保証報告書です。「認証」ではなく「保証報告書」である点に注意が必要です。一定期間の運用状況を評価するため、単なる設計ではなく実際の運用の証跡として機能します。

ISMAPは、日本の政府情報システム向けクラウドサービス安全性評価制度です。政府機関への納入実績があるSaaSはISMAP登録されているケースが多く、信頼性の目安になります。

PCI DSSは、クレジットカード情報を扱う場合に必要な業界規格です。決済機能を含むSaaSの評価では確認必須です。

第三者認証のチェック項目一覧

自社が必要とする認証をベンダーが保有しているか
認証の有効期限と次回更新時期が公表されているか
認証範囲（事業所・サービス単位）が利用予定のSaaSをカバーしているか
SOC 2 Type 2の保証報告書をNDA締結後に閲覧できるか
過去のインシデント発生状況と再発防止策が開示されているか
HIPAA、FedRAMPなど業界特化の認証が要件として必要かどうか

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

参考：ISMAP 制度概要（情報処理推進機構）

第2カテゴリ：データ取り扱い・所在のチェック項目

データの所在地、暗号化方式、削除プロセスは、情報漏洩リスクと法令遵守に直結します。個人情報や機密情報を扱うSaaSでは、とりわけ詳細な確認が求められます。

データ所在・データ主権

データセンターの所在国（主要データ・バックアップのそれぞれ）
自社の規制要件（金融・医療・政府調達）への適合状況
クロスボーダーでのデータ転送経路と保護措置
米国Cloud Act、EU GDPRなど海外法制の適用リスク
国内データセンターオプションの有無と追加費用

暗号化・データ保護

通信暗号化：TLS 1.2/1.3の対応状況と最新化ロードマップ
保管時暗号化：AES-256等の業界標準アルゴリズムの採用
暗号鍵管理：ベンダー管理か、顧客管理（BYOK/HYOK）の選択が可能か
データベースおよびバックアップへの暗号化適用範囲
アクセスログの暗号化と保管期間

バックアップ・可用性

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

データ削除・エクスポート

解約後のデータ保持期間とエクスポート可能な形式を確認します。削除リクエストへの対応プロセスと完了通知の仕組み、データの完全消去証明の発行可否、API・CSV等での全データエクスポート機能の有無も評価対象です。

AI・機械学習による学習利用

生成AI機能を内包するSaaSが増加したことで、学習データ利用への確認が必須になりました。顧客データを学習・解析に利用するかどうか、オプトアウト設定の可否、統計データや匿名化データの第三者提供の有無、再委託先（サブプロセッサ）の開示状況を確認します。

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

第3カテゴリ：契約条項・法務のチェック項目

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

SLAとサポート体制

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

インシデント発生時の通知義務

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

損害賠償・責任範囲

損害賠償の上限は、契約類型や当事者間の交渉力によって大きく異なります。賠償対象の範囲（直接損害のみか間接損害を含むか）、免責事項の範囲（不可抗力・第三者攻撃等）、賠償保険の加入状況を確認します。断定的な賠償額を事前に想定することは難しいため、契約交渉の中で自社リスクに応じた条件設定を行うことが重要です。

解約・データ移行

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

監査権・準拠法

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

価格・契約期間

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

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

第4カテゴリ：運用機能・連携のチェック項目

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

認証・アクセス制御

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

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

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

SSO・SCIMの対応状況は、入退社時のアカウント管理コストに直接影響します。対応している場合は人事システムとの連携でプロビジョニングを自動化でき、見落としや手作業ミスを大幅に削減できます。

監査ログ・アラート

操作ログの取得粒度（ログイン・設定変更・データアクセスの各レベル）
ログ保持期間とエクスポート方法（API・CSV等）
SIEM（セキュリティ情報・イベント管理）への転送機能
リアルタイムアラートの設定と通知方法

設定管理

セキュリティベースライン設定のテンプレート提供
設定変更履歴の保存機能
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つ以上あれば、補完策の協議が必要です。

カテゴリ別の重み付け（基幹SaaS向けの一例）

重み付けはSaaSの重要度に応じて調整します。機密情報を扱う基幹SaaSでは以下の比率が参考になります。

第三者認証・コンプライアンス：25%
データ取り扱い・所在：30%
契約条項・法務：25%
運用機能・連携：20%

総合スコアが高い水準であれば「推奨」、中程度であれば「条件付き承認」、それを下回る場合は「見送り」という判定基準を、自社のリスク許容度に合わせて設定します。

意思決定のフロー

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

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

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

評価を効率化するための実務上の工夫

SaaSセキュリティ評価は重要である一方、情シスのリソースには限りがあります。全SaaSに同等の評価工数をかけることは現実的ではなく、優先順位付けが不可欠です。

重要度ランクによる評価レベルの段階化

SaaSを機密性・基幹度・コストの3軸でランク分けし、ランクに応じて評価レベルを変えます。

高重要度のSaaSには全4カテゴリの詳細評価を適用します。中重要度のSaaSには第三者認証・データ取り扱いの2カテゴリに絞り込んだ簡易評価を行います。低重要度のSaaSには公開情報の確認のみで対応し、起案者に自己確認シートを提出させる形式にします。

ベンダー向け質問票の標準化

起案者がベンダーに提出する質問票を社内で標準化することで、情シスへの申請時点で基本情報が揃っている状態を作れます。「ベンダーが回答を拒否した場合はリスクとして記録する」というルールを設けると、対応状況の記録としても機能します。

継続評価のルーチン化

採用後の評価を年次でルーチン化します。第三者認証（ISO/IEC 27001・SOC 2 Type 2）の更新状況確認を年1回の起点として、契約更新時・インシデント発生時・重要機能追加時には随時見直しを実施します。継続評価の記録が蓄積されることで、次回更新時の交渉材料としても活用できます。

シャドーSaaSへの対応

評価フレームワークの盲点になりがちなのが、現場が独自に導入したシャドーSaaSです。承認フローを経ていないSaaSは評価記録が残らず、退職者のアカウント残留や不正なデータ共有につながります。SaaS全体の可視化を先行させることが、評価フレームワークを機能させる前提条件です。

ジョーシスを活用したSaaSセキュリティ評価の効率化

チェックリストを導入時だけでなく継続評価にも適用するには、対象SaaSの可視化と評価記録の管理が前提になります。評価するSaaSを把握できていなければ、チェックリスト自体が機能しません。

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

利用SaaSの自動検出機能により、経費精算データ・SSOログ・API連携から契約済み・未承認SaaSを可視化します。ライセンス管理機能では、各SaaSの契約状況・利用率・更新時期を一元管理し、評価対象の棚卸しを効率化します。アカウント情報の管理ではロール・権限・最終ログインを可視化し、評価項目の一部を自動取得できます。各SaaSのメタデータには評価結果・スコア・次回見直し時期を記録でき、継続評価の記録管理にも対応します。

国内外700社以上の企業に導入され、IT工数を最大50%、ITコストを最大75%削減した実績があります。350以上のSaaSとの連携（31カテゴリ）により、評価対象の棚卸しから運用後のモニタリングまでを一元管理できます。

SaaS評価の自動化と一元管理を検討している方は、まず資料でジョーシスの機能をご確認ください。

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

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

評価チェックリストの理解に必要な専門用語を整理します。

ISO/IEC 27001は、情報セキュリティマネジメントシステムの国際規格です。SOC 2 Type 2は、一定期間の運用状況を評価する米国の保証報告書で、「監査報告書」ではなく「保証報告書」と表記するのが正確です。ISMAPは政府情報システム向けクラウドサービス安全性評価制度を指します。

BYOK（Bring Your Own Key）・HYOK（Hold Your Own Key）は、顧客が暗号鍵を自ら管理する方式です。DPA（Data Processing Agreement）は個人情報取扱業務委託契約書で、GDPR対応のベンダーでは締結が標準化されています。

データレジデンシーは、データの所在地に関する規制要件を指します。RPO（Recovery Point Objective）はバックアップの目標値、RTO（Recovery Time Objective）は災害復旧の目標時間です。サブプロセッサとは、ベンダーがデータ処理を委託する第三者のことを指します。SCIMは、ユーザーアカウントのプロビジョニングを自動化するプロトコルです。