契約上の約束、個人情報保護法、クラウドの共有責任、技術水準、顧客への説明責任を重ねて、合理的な管理水準を読み解きます。
契約上の約束、個人情報保護法、クラウドの共有責任、技術水準、顧客への説明責任を重ねて、合理的な管理水準を読み解きます。
契約、個人情報保護、クラウド実務、表示内容を重ねて、合理的な専門事業者として説明できる水準を確認します。
2026年5月9日時点の公開情報を前提に、SaaS事業者が負うセキュリティ義務の水準を企業法務と情報セキュリティの両面から整理します。結論は、事故を絶対に起こさない結果保証ではなく、対象サービスのリスクに照らして合理的な専門事業者であれば実装、運用、説明しているべき技術的、組織的、契約的管理措置の水準です。
この結論が重要なのは、SaaSでは顧客情報、従業員情報、営業秘密、決済情報、APIキー、監査ログなどが外部環境で処理され、事故時には契約責任、個人情報保護法、委託先管理、行政報告、本人通知、信用毀損が同時に問題になるためです。読者は、次の要点から「どの水準を求め、どの証跡を残すか」を読み取ってください。
SaaS事業者の義務は、低リスクの社内ツールと、金融、医療、公共、基幹業務を支えるサービスで同じにはなりません。データの機微性、業務依存度、顧客数、予見可能な脅威、契約や営業資料での表示、認証・監査の有無を総合して決まります。
次の一覧は、このページ全体で扱う判断材料を俯瞰するものです。各項目は独立したチェックではなく相互に影響します。データの機微性や業務重要度が高いほど、右側の契約・運用・証跡まで厚く確認する必要があると読み取ってください。
認証、アクセス制御、暗号化、ログ、脆弱性管理、バックアップ、インシデント対応が実効性を左右します。
リスク評価、変更管理、委託先評価、顧客通知、再発防止策を説明できる状態が紛争予防になります。
重要データが外部システムに置かれることで、事故時の責任分界と通知協力が問題になります。
SaaSは営業管理、会計、人事労務、電子契約、ファイル共有、決済、開発管理、生成AI連携、医療、教育、行政関連サービスまで広く使われます。利便性の反面、セキュリティ事故が起きると、利用企業は「どこまで対策しているべきだったか」「契約上の責任限定は有効か」「個人情報保護法上の報告や本人通知は誰が担うか」を検討する必要があります。
次の比較一覧は、SaaS事故で問題になりやすい類型と、それぞれで確認すべき責任分界を示しています。左の類型は事故の入口、中央は利用企業が受ける影響、右は契約・運用で確認すべきポイントです。事故原因を一つに決めつけず、設計、設定、通知、証跡のどこに不足があったかを切り分けて読むことが重要です。
| 事故類型 | 主な影響 | 確認すべき責任分界 |
|---|---|---|
| 不正ログイン、権限昇格 | 顧客情報、従業員情報、認証情報の漏えい | MFA、ログイン制限、管理者権限、顧客側のアカウント管理 |
| テナント分離不備 | 他社データの閲覧、マルチテナント全体への波及 | 設計検証、IDOR対策、検索・キャッシュ・出力時の分離 |
| 設定不備 | 共有リンク、公開範囲、APIキーの誤公開 | 安全側の初期値、警告、監査ログ、利用者教育 |
| ランサムウェア、改ざん、消失 | 業務停止、復旧費用、行政・顧客対応 | バックアップ、RTO、RPO、復旧訓練、ログ保全 |
| 通知遅延 | 二次被害、報告遅延、信用毀損 | 通知期限、緊急連絡先、原因調査協力、公表方針 |
SaaS事業者側でも、投資水準、顧客の設定ミスと自社設計の境界、セキュリティ資料の開示範囲、SLA、責任限定、インシデント通知条項の設計が課題になります。単に「クラウドなので利用者責任」や「約款で免責済み」と説明するだけでは不十分です。
次の判断の流れは、事故後に義務違反の有無を検討する順番を表します。上から下へ進む順番に意味があり、原因類型、契約、法令、当時の合理的対策、予見可能性、損害の因果関係を順に確認することで、感情的な責任論を避けやすくなります。
漏えい、不正閲覧、改ざん、消失、障害、設定ミス、外部攻撃などを切り分けます。
利用規約、個別契約、SLA、DPA、セキュリティ別紙、チェックシート回答を照合します。
個人情報保護法、業種規制、海外法、顧客側の報告義務を確認します。
既知脆弱性、標準的な設定、業界標準、認証要件を基準にします。
通知遅延、ログ不備、表示との乖離があれば不利に働きます。
証跡と対応記録があれば事故発生と義務違反を区別しやすくなります。
SaaS、セキュリティ義務、義務の水準を分けて、評価対象を明確にします。
SaaSとは、利用者がソフトウェアを自社にインストールせず、クラウド上で提供されるアプリケーション機能をインターネット等で利用する形態です。CRM、SFA、会計、人事、電子契約、チャット、グループウェア、ストレージ、マーケティングオートメーション、チケット管理、EC支援、BI、AI連携サービスなどが典型です。
次の一覧は、SaaSのセキュリティ義務を構成する8つの義務群を示しています。各項目は、技術だけでなく契約・顧客説明・事故対応まで含む点が重要です。読者は、自社サービスや導入先SaaSについて、どの義務が契約書や運用手順に落ちているかを読み取ってください。
脅威モデリング、セキュアコーディング、コードレビュー、リリース前レビューを含みます。
開発本番環境、開発環境、認証基盤、ログ、バックアップ、監視の管理を含みます。
運用不正アクセス、マルウェア、脆弱性、設定不備を予防し、検知後に対応します。
検知個人情報保護法上の安全管理措置、委託先管理、漏えい等対応と接続します。
個人情報IaaS、PaaS、メール、監視、決済、AI APIなどのサプライチェーンを管理します。
委託ログ保全、影響範囲特定、顧客通知、行政報告支援、再発防止を含みます。
事故対応契約、仕様書、セキュリティ資料、営業資料、質問票回答と実態を一致させます。
表示情報提供、警告、安全な初期値、設定診断、監査ログ、ヘルプ文書を提供します。
支援義務の水準とは、どの程度の対策を講じれば法的・契約的に相当と評価されるかという基準です。完全無欠の安全性は存在しないため、事故の有無だけでなく、事前のリスク評価、合理的対策、既知脆弱性への対応、ログ保存、顧客通知、再発防止策というプロセスも評価されます。
契約、不法行為、個人情報保護、業種規制、海外法を横断して確認します。
法的枠組みは一つの法令だけで完結しません。SaaS利用契約は、利用規約、申込書、注文書、サービス仕様書、SLA、DPA、セキュリティ別紙、秘密保持契約、サポート規約、個別契約などで構成され、ソフトウェア利用許諾、継続的役務提供、準委任的要素、保管・処理委託的要素が混在します。
次の比較表は、義務水準を形成する法的・実務的な枠組みを整理したものです。左列は根拠、中央列は主な確認対象、右列は契約や運用へ落とすべき事項です。読者は、どの根拠が自社のSaaSに関係するかを横断的に確認してください。
| 枠組み | 主な確認対象 | 実務への落とし込み |
|---|---|---|
| 契約法上の義務 | 安全管理措置、暗号化、通知、稼働率、バックアップ、再委託管理 | 抽象条項だけでなく、セキュリティ別紙やDPAで具体化します。 |
| 債務不履行・不法行為 | 既知脆弱性放置、MFA不備、テナント分離欠陥、通知遅延、ログ不備 | 事故時点の予見可能性、回避可能性、因果関係を証拠で示します。 |
| 個人情報保護法 | 安全管理措置、委託先監督、漏えい等報告、本人通知、外的環境把握 | 顧客が法令義務を履行できるよう、情報提供と協力義務を定めます。 |
| 業種別規制・公共調達 | 金融、医療、公共、重要インフラ、上場会社、ISMAP等 | 一般SaaSより高い監査、データ所在、BCP、報告基準を組み込みます。 |
| 海外法・GDPR等 | 処理者契約、再処理者、侵害通知、越境移転、監査協力 | 海外顧客、海外子会社、国外基盤利用がある場合にDPAを整えます。 |
個人情報保護法では、個人データの安全管理措置、委託先監督、漏えい等発生時の報告・本人通知が重要です。SaaS事業者が顧客データを閲覧しないと説明する場合でも、管理者権限、保守アクセス、障害対応、暗号鍵管理、ログ閲覧、API連携、バックアップ、再委託先を通じた実質的アクセス可能性を確認する必要があります。
インシデント条項では、通知期限、通知先、通知方法、発生日・発覚日・影響範囲・対象データ・原因・初動対応・再発防止策、追加情報の提供、ログ保全、行政報告・本人通知への協力、公表方針、費用負担、責任制限との関係を具体化します。
SaaSでは事業者が管理する領域が大きい一方、利用企業にも設定・権限・教育の責任が残ります。
SaaSでは、IaaSやPaaSよりもアプリケーション層を事業者が管理するため、利用者が直接変更できない部分については事業者の責任範囲が大きくなります。ただし、アカウント管理、権限設定、MFA、IDプロバイダ連携、APIキー、共有リンク、外部共有、データ投入、社内教育、端末・ネットワーク保護などは利用企業側にも残ります。
次の比較一覧は、SaaS事業者と利用企業の責任分界を示します。列ごとに管理主体が異なり、どちらか一方だけに全責任が寄るわけではありません。自社の契約では、この一覧の項目が条項、ヘルプ、管理画面、監査ログにどう反映されているかを読み取ってください。
| 領域 | SaaS事業者側 | 利用企業側 |
|---|---|---|
| アカウント | MFA機能、SSO連携、ログイン制限、不審ログイン検知を提供 | MFA有効化、退職者削除、共有ID禁止、権限レビューを運用 |
| データ保護 | 通信・保存時暗号化、テナント分離、バックアップ、削除・返却手順を整備 | 投入データの適法性、機微情報の混入防止、エクスポート管理を実施 |
| 設定 | 安全側の初期値、警告、診断、危険設定の確認画面を提供 | 公開範囲、共有リンク、API連携、Webhookの設定を管理 |
| 事故対応 | ログ保全、原因調査、通知、復旧、再委託先連携を実施 | 社内影響範囲、本人・取引先対応、行政報告要否、代替運用を判断 |
設定不備は利用者の単純ミスだけではなく、利用者側の理解不足、提供側の情報・ツール不足、ミスを起こしにくい設計への配慮不足が複合して生じ得ます。そのため、SaaS事業者は危険な設定を防ぐUI、警告、推奨テンプレート、設定診断、監査ログを用意し、利用企業はそれを継続運用する必要があります。
データの性質、業務重要度、顧客規模、脅威、技術水準、表示、認証が中心です。
義務水準は、すべてのSaaSに同一の対策を求めるものではありません。取り扱う情報、利用目的、顧客属性、想定脅威、影響範囲、業務重要性、法規制、契約上の約束、技術的実現可能性、費用対効果を総合して決まります。
次の重要項目一覧は、義務水準を引き上げる主要要素を整理したものです。各項目はリスクを上げる方向に働くため、該当項目が多いサービスほど、契約、技術、監査、通知、証跡を厚くする必要があります。読者は、各項目を自社のサービスや導入予定SaaSに当てはめて確認してください。
個人データ、要配慮個人情報、人事労務、決済、医療、営業秘密、認証情報、APIキー、未公表重要事実は高い管理が求められます。
電子契約、決済、コールセンター、医療予約、物流、会計締め、給与計算などは可用性、復旧、通知の水準が高くなります。
数名利用と数百万ユーザーのプラットフォームでは、マルチテナント波及、通知対象、社会的影響が異なります。
認証突破、フィッシング、API濫用、SQLインジェクション、XSS、SSRF、サプライチェーン攻撃、クラウド認証情報窃取は広く想定されます。
管理者MFA、TLS、保存時暗号化、脆弱性スキャン、WAF、ログ監視、バックアップ、パッチ管理は基本的対策に近づいています。
金融機関レベル、最高水準、完全暗号化、24時間365日監視などの表示は、実態とずれると重大なリスクになります。
認証・監査・第三者評価も重要です。ISO/IEC 27001、ISO/IEC 27017、SOC 2、ISMAP、PCI DSS、ISMSクラウドセキュリティ認証などは有用な資料ですが、認証範囲、対象サービス、対象組織、審査時点、適用除外、運用実態を確認しなければ十分とはいえません。
ガバナンス、開発、認証、暗号化、テナント分離、脆弱性、ログ、BCPを具体化します。
SaaS事業者の管理措置は、単なるセキュリティ機能の羅列ではなく、経営、開発、運用、契約、顧客説明が一体で動く体制として設計する必要があります。特に顧客データを扱うSaaSでは、管理措置が契約別紙やセキュリティ資料に正確に反映されていることが重要です。
次の比較表は、主要な管理領域と具体策を整理したものです。左から右へ、管理領域、実装・運用すべき措置、契約・監査で確認する証跡を並べています。機能があるだけでなく、いつ誰が確認し、どの証跡を残すかまで読み取ってください。
| 管理領域 | 主な措置 | 確認すべき証跡 |
|---|---|---|
| ガバナンス | 方針、責任者、リスクアセスメント、委員会、内部監査、教育 | 規程、議事録、リスク受容記録、教育記録、監査記録 |
| セキュア開発 | 要件定義、脅威モデリング、SAST、DAST、OSS脆弱性管理、SBOM、CI/CD保護 | レビュー記録、診断結果、修正履歴、変更管理記録 |
| 認証・認可 | MFA、SSO、RBAC、最小権限、特権管理、セッション制御、監査ログ | 権限一覧、レビュー履歴、管理者操作ログ、緊急アクセス記録 |
| 暗号化・鍵管理 | TLS、保存時暗号化、バックアップ暗号化、鍵ローテーション、HSM、顧客管理鍵 | 暗号化範囲、鍵管理手順、ローテーション記録、廃棄手順 |
| テナント分離 | DB、ストレージ、API、検索、ログ、キャッシュ、管理画面、バックアップの分離 | 設計資料、テスト結果、診断結果、権限チェック記録 |
| 脆弱性・パッチ | 情報監視、CVSS評価、修正期限、緊急パッチ、外部診断、報告窓口 | 脆弱性台帳、対応期限、適用記録、代替策、診断報告 |
| ログ・監視 | 認証、管理者操作、権限変更、データ出力、API、設定変更、セキュリティアラート | ログ保存期間、改ざん防止、アクセス権限、顧客提供範囲 |
| バックアップ・BCP | 頻度、保存期間、暗号化、分離、RTO、RPO、復旧訓練、障害通知 | 復旧テスト、バックアップ設定、障害報告、訓練記録 |
次の段階別モデルは、SaaSのリスクに応じて管理水準を上げる考え方を示します。水準は固定的な法分類ではありませんが、対象サービスがどの列に近いかを見れば、契約審査やベンダー評価で要求事項を調整しやすくなります。
| 水準 | 対象となるSaaSの例 | 求められる主な対策 |
|---|---|---|
| 基礎水準 | 小規模、低機微データ、限定利用 | TLS、基本アクセス制御、パスワード管理、バックアップ、脆弱性対応、秘密保持、最低限のログ |
| 標準水準 | 一般的なB2B SaaS、個人データを含む業務利用 | MFA、RBAC、保存時暗号化、監査ログ、脆弱性診断、インシデント通知、DPA、委託先管理、削除・返却手順 |
| 高水準 | 大量個人データ、営業秘密、基幹業務、上場企業利用 | ISMSやSOC 2、詳細アクセス管理、特権管理、SIEM、ペンテスト、RTO/RPO、顧客監査対応、CSIRT、BCP訓練 |
| 厳格水準 | 金融、医療、公共、重要インフラ、決済、行政 | 業界別基準、ISMAP等、強固なテナント分離、データ所在管理、顧客管理鍵、高度ログ、24時間365日監視、第三者監査 |
セキュリティ別紙、SLA、責任限定、監査権、再委託、削除・返却を分けて確認します。
SaaS利用契約では、本文に「合理的な安全管理措置を講じる」と置くだけでは足りない場合があります。重要なSaaSでは、セキュリティ別紙やDPAで対象データ、保存場所、暗号化、アクセス制御、ログ、脆弱性管理、インシデント通知、委託先、監査、削除・返却を具体化します。
次の比較表は、契約審査で見落としやすい項目を整理したものです。左列は条項領域、中央列は確認すべき内容、右列は交渉時の読み方です。SLA、責任制限、個人データ、秘密保持を一つの条文に押し込まず、救済や例外を分けて読むことが重要です。
| 条項領域 | 確認内容 | 読み方 |
|---|---|---|
| セキュリティ別紙 | 対象サービス、対象データ、保存場所、暗号化、アクセス制御、ログ、脆弱性管理、バックアップ、変更管理 | セキュリティ資料と実態が一致しているか確認します。 |
| SLA | 稼働率、除外時間、メンテナンス、復旧目標、障害通知、補償内容 | 可用性だけでなく、データ復旧や業務継続も確認します。 |
| 責任限定 | 上限額、間接損害、特別損害、秘密保持違反、個人データ漏えい、故意・重過失の例外 | 重大事故を通常障害と同じ上限にする合理性を確認します。 |
| 監査・資料提出 | ISO認証、SOC 2、ISMAP、ホワイトペーパー、診断概要、委託先一覧、質問票回答 | 現地監査が難しい場合の代替資料を準備します。 |
| 再委託 | 事前承認、包括承認、変更通知、異議申立て、同等義務、越境移転 | どの国の誰がどのデータにアクセスし得るかを確認します。 |
| 削除・返却 | エクスポート、削除証明、バックアップ削除時期、法令保存ログ、ポータビリティ | 終了時に顧客がデータを失わず、不要データが残らない設計にします。 |
次の条項設計の一覧は、紛争予防のために契約へ落とすべき方向性を示します。各項目はそのまま貼り付ける文言ではなく、対象サービスのデータ、顧客属性、利用料、保険、業種規制に合わせて調整する前提で読んでください。
アクセス制御、認証、暗号化、ログ管理、脆弱性管理、バックアップ、インシデント対応、委託先管理を含めます。
漏えい、滅失、毀損、不正アクセス、改ざんを認識した場合に、影響範囲特定と行政報告・本人通知へ協力します。
顧客データを扱う再委託先へ安全管理義務と実質的に同等の義務を課し、重要な変更を通知します。
認証書、監査報告書、ホワイトペーパー、質問票回答、サブプロセッサー情報を合理的範囲で提供します。
契約終了時に顧客データを返却または削除し、ログやバックアップの保存期間とアクセス制限を明示します。
暗号化、監視、国内保存、第三者認証、アクセス制限の説明が実態とずれないよう管理します。
事故後に説明できるよう、基準、証跡、設定管理、委託先管理を平時から運用します。
セキュリティ義務は、事故時に初めて作るものではありません。SaaS事業者は、自社サービスに適用される基準を文書化し、契約と実態を一致させ、顧客の設定責任を明確化しつつ支援し、インシデント対応を演習し、透明性を高める必要があります。
次の一覧は、SaaS事業者側と利用企業側の平時対応を並べたものです。左右は対立関係ではなく、同じリスクを別の立場から管理する関係です。導入時、更新時、監査時、事故後の再評価で、どちらの証跡が不足しているかを読み取ってください。
| 立場 | 整備すべきもの | 証跡として残すもの |
|---|---|---|
| SaaS事業者 | 情報セキュリティ基本方針、個人情報保護方針、アクセス管理規程、開発セキュリティ規程、脆弱性管理規程、インシデント対応規程、委託先管理規程、ログ管理規程、バックアップ・復旧手順、DPA、顧客向け資料 | リスク評価、脆弱性対応履歴、パッチ記録、アクセスレビュー、ログ保存記録、顧客通知記録、教育記録、監査報告書 |
| 利用企業 | SaaS台帳、データ分類、ベンダー評価、DPA確認、インシデント通知条項、再委託先・データ保存国確認、責任限定確認、MFA・権限レビュー・退職者削除運用、APIキー管理 | チェックシート、契約書、承認記録、設定変更記録、権限レビュー、委託先評価、定期レビュー、障害時の代替手段検討記録 |
よくある誤解は、事故を生みやすい思考パターンです。次の注意点一覧は、契約交渉や事故後の説明で特に問題になりやすい考え方を整理しています。各項目は短いですが、実際には契約、設定、証跡、顧客説明へ波及します。
SaaSであっても、利用者側にはアカウント管理、権限設定、端末管理、社内教育、外部共有管理の責任が残ります。
秘密保持違反、個人データ漏えい、故意・重過失、表示と実態の乖離がある場合、免責だけでは紛争を避けにくくなります。
認証範囲、対象サービス、運用実態、事故時点の統制状態を確認する必要があります。
管理者権限、保守アクセス、バックアップ、ログ、暗号鍵、再委託先を通じた関与が残る場合があります。
契約、個人情報保護、委託先管理、内部統制、監査、広報、顧客対応、経営判断と一体です。
次の社内チェック表は、SaaS事業者側と利用企業側が平時に確認すべき項目を、実務で使いやすい形に整理したものです。列ごとに立場が異なり、左側はサービス提供者の統制、右側は導入・利用企業の委託先管理と設定運用を示します。監査や事故後の説明では、各項目について実施日、責任者、証跡の有無を読み取ってください。
| SaaS事業者側の確認項目 | SaaS利用企業側の確認項目 |
|---|---|
| サービス別のデータ分類、セキュリティ方針、規程、手順、セキュア開発プロセスを整備しているか。 | SaaSで扱うデータ、個人データ、機密情報、基幹業務該当性を確認しているか。 |
| MFA、RBAC、特権管理、保存時・通信時暗号化、テナント分離検証があるか。 | ベンダーの認証・監査資料、DPA、セキュリティ別紙、インシデント通知条項を確認しているか。 |
| 脆弱性管理とパッチ期限、ログ保存・監視・アラート、バックアップと復旧訓練を運用しているか。 | 再委託先、データ保存国、責任限定条項、障害時の代替手段を確認しているか。 |
| 委託先・再委託先、インシデント対応計画、訓練、顧客向けセキュリティ資料を管理しているか。 | MFA、権限管理、退職者削除、外部共有・公開設定、APIキー・連携アプリを管理しているか。 |
| 契約・営業資料と実態、データ削除・返却手順、生成AI連携時のデータ利用条件が一致しているか。 | 委託先管理の証跡、契約終了時の返却・削除手順、定期レビュー記録を保存しているか。 |
生成AI機能では、入力データ、学習利用、ログ保存、削除、再委託が追加論点になります。
生成AI連携SaaSでは、従来のSaaSセキュリティに加えて、プロンプトに個人データや営業秘密が入るリスク、AIベンダーへの再委託、学習利用の有無、入出力ログの保存、管理者閲覧可能性、誤出力、プロンプトインジェクション、外部ツール連携による漏えい、オプトイン・オプトアウト、データ分離と削除が問題になります。
次の一覧は、生成AI機能を含むSaaSで追加確認すべき論点です。各項目は通常のSaaS契約だけでは見落とされやすいため、AI処理のデータの流れ、保存期間、第三者提供、学習利用、ログ管理、顧客管理機能を別途確認する必要があります。
個人データ、営業秘密、認証情報、契約情報がプロンプトや添付ファイルに入らない設計を確認します。
顧客データをAIモデル学習に使うか、オプトアウトできるか、明示的承諾が必要かを確認します。
入力、出力、履歴、ベクトルDB、埋め込みデータ、検索インデックスの保存・削除範囲を確認します。
顧客データが他社テナントの出力や学習に影響しない分離設計を確認します。
一般的には、一律には決まらず、契約、個人情報保護法、業種規制、標準・ガイドライン、データの性質、サービスの重要度、技術水準、SaaS事業者の表示内容を総合して判断されます。ただし、具体的な契約や事故状況によって結論は変わるため、個別の見通しは弁護士等の専門家へ相談する必要があります。
一般的には、事故発生だけで直ちにSaaS事業者の責任が決まるわけではありません。顧客側のアカウント管理不備や設定ミスが原因となる場合もあります。他方で、設計不備、既知脆弱性の放置、通知遅延、ログ不備があれば、SaaS事業者の責任が問題となる可能性があります。
一般的には、安全管理措置、委託先管理、漏えい時の通知・報告協力、DPA、再委託先管理、データ削除・返却、ログ、暗号化、アクセス制御が重要とされています。ただし、データの種類、処理国、業種規制、契約内容によって確認事項は変わります。
一般的には、実際に個人データへアクセスできない設計か、保守、サポート、ログ、バックアップ、再委託先で取り扱いが生じるかによって評価が変わります。顧客データを直接閲覧しない構成でも、認証、暗号化、テナント分離、脆弱性管理などの安全な設計・運用を説明できる状態が重要です。
一般的には、認証や監査報告は重要な証拠になりますが、それだけで十分とはいえません。認証範囲、対象サービス、統制の運用実態、事故原因との関係を確認する必要があります。
一般的には、利用料や契約形態は考慮要素になりますが、個人データや機密情報を扱う場合には最低限の安全管理義務が残る可能性があります。具体的なリスク配分は、利用目的、契約条件、データの機微性によって変わります。
一般的には、対象データ、データ保存国、暗号化、MFA、権限管理、ログ、バックアップ、インシデント通知、再委託先、監査資料、SLA、責任制限、データ削除・返却を確認することが有用です。重要SaaSでは、資料を整理したうえで法務・情報システム・セキュリティ担当が共同で検討する必要があります。
一般的には、サービスの性質や顧客データの機微性に応じて、セキュリティ資料、監査報告、認証範囲、再委託先、データ保存国、インシデント通知手順、削除・返却手順などを説明できることが望ましいとされています。ただし、攻撃に悪用される詳細情報や他社情報を無制限に開示する必要があるとは限らず、秘密保持契約や閲覧範囲を設定する運用も考えられます。
一般的には、管理画面の設定、権限付与、外部共有、APIキー管理など利用企業が管理する領域で起きた事故は、利用企業側の運用が問題となる可能性があります。他方で、危険な初期設定、分かりにくい警告、アクセス制御の設計不備、既知の欠陥がある場合には、SaaS事業者側の説明責任や契約上の義務も問題となり得ます。
一般的には、リスクに応じた合理的な安全管理措置を、契約、資料、運用記録、監査証跡で説明できる水準と整理できます。どの対策が必要かは、扱うデータ、業務重要度、脅威、技術水準、顧客への表示、事故時の証跡によって変わります。
公的機関、標準化団体、国際的なセキュリティ標準を中心に整理しています。