SaaSの数が増え続けるなか、現場の情シスからは「結局、何をどこまでチェックすればいいのか」という声が絶えません。導入時のセキュリティ評価、運用中の設定監視、退職時のアカウント削除。それぞれを場当たり的に対応していては、抜け漏れは避けられません。

体系化されたチェックリストがあれば、点検作業は標準化され、レビューに使える時間も増えます。属人化していた判断基準が共有資産になり、新任担当者の立ち上がりも早くなります。本記事では、情シスが現場で使えるSaaSセキュリティ点検項目を「導入時・運用時・退職時」の3フェーズで整理しました。

評価軸はISO/IEC 27001、CSAクラウドコントロールマトリクス、ISMAPの観点を踏まえ、現実的な運用粒度で再構成しています。チェックリストはそのままコピーして社内の点検運用に組み込める形式で記載します。

SaaSセキュリティ チェックリストが必要な理由

SaaSセキュリティ チェックリストとは、各SaaSの設定・運用・契約状況を評価するための定型項目集です。情シスが個別判断せず、誰が点検しても同じ結果に収束する仕組みをつくることが目的になります。

理由は3つあります。第1に、SaaS数の爆発的増加です。中堅企業以上では50を超えるSaaSを抱えるケースが増え、すべてを記憶頼みでチェックするのは現実的ではなくなりました。第2に、責任共有モデルでは利用企業側に多くの設定責任が残ります。ベンダー任せでは設定ミスを防げません。第3に、監査・コンプライアンス対応です。ISO27001、SOC2、ISMAP、Pマーク等の取得・更新時に、点検記録の提示が求められます。

チェックリストを整備すると、以下の効果が得られます。

• 点検結果が記録に残り、監査対応の根拠資料になる
• 担当者の経験差に依存しない品質を確保できる
• 改善サイクル（PDCA）を回しやすくなる
• 経営層への報告に「合格率」という共通指標が使える

「ベテラン頼み」から「仕組み頼み」への転換が、SaaS時代の情シス運用の出発点です。

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

チェックリストの全体構造（3フェーズ × 5領域）

実務で運用しやすくするには、点検タイミング（フェーズ）と点検対象（領域）の2軸で整理することが有効です。フェーズは「導入時・運用時・退職時」の3つ、領域は「契約・ID・データ・設定・監査」の5つに分割します。

フェーズ別の主な目的は以下です。

• 導入時: ベンダー評価とアーキテクチャ整合性を確認し、リスクの低いSaaSのみを採用する
• 運用時: 設定状態とアクセス権を継続監視し、構成ドリフトと過剰権限を防ぐ
• 退職時: アカウント停止・データ引き継ぎ・ライセンス回収を漏れなく実施する

領域別の主な観点は以下です。

• 契約: 第三者認証、SLA、データ所在、解約条項
• ID: SSO、MFA、特権管理、SCIM対応
• データ: 暗号化、バックアップ、DLP、データ保持期間
• 設定: 共有設定、外部連携、API、デフォルト権限
• 監査: ログ取得・保存・転送、アラート、レビュー周期

このマトリクスをベースに、自社の必須項目と推奨項目を分け、重要度を3段階（必須・推奨・任意）で運用するのが現実解です。

参考：Cloud Controls Matrix v4（CSA）

導入時チェックリスト（ベンダー評価・契約・初期設定）

新しいSaaSを採用する際の点検項目です。導入前に止めるべきSaaSをふるい落とし、採用後に必要な初期設定を漏らさないことが目的です。

ベンダー評価（契約締結前）

• 第三者認証の保有: ISO/IEC 27001、SOC 2 Type 2、ISMAP、Pマーク、TRUSTe等のいずれかを保有しているか
• データ所在地: 主要データセンター・バックアップの所在地が公表されており、自社のデータレジデンシー要件と整合するか
• データ取り扱い: 学習・解析利用の有無、再委託先の開示、削除依頼への対応プロセスが明示されているか
• インシデント通知: 漏洩発生時の通知期限（24時間〜72時間）と通知経路が契約書に明記されているか
• SLA: 稼働率、計画停止、サポート応答時間、補償条項が許容範囲内か
• 解約・データ持出: 解約後のデータエクスポート方法、削除証明、保持期間が明記されているか

契約条項の確認

• 個人情報取扱業務委託契約書（DPA）が締結できるか
• データ漏洩時の損害賠償上限・除外事項が許容範囲か
• 契約準拠法・紛争管轄が日本法・日本国内裁判所で対応可能か
• 監査権・現地査察権の有無
• 米国Cloud Act、EU GDPR等の海外法制適用リスクの確認

初期設定（採用直後）

• SSO連携: SAML/OIDCで自社IdPと接続できているか
• MFA強制: 全ユーザーまたは少なくとも管理者アカウントで必須化されているか
• パスワードポリシー: 長さ・漏洩パスワード拒否・MFA必須化の設定が自社基準を満たすか（NIST SP 800-63B では定期変更や複雑性ルールの強制より、長さとMFAが重視されています）
• 管理者アカウント: 個人に紐づく管理者権限として発行し（共有管理者アカウントは監査性が低下する）、PAM対象としたか
• API・外部連携: 不要な外部連携を無効化し、利用するものはアクセス範囲を最小化したか
• 共有設定デフォルト: 「組織内のみ」「特定ユーザーのみ」を初期値に設定したか

参考：クラウドサービスの安全・信頼性に係る情報開示指針（総務省）

運用時チェックリスト（継続監視・定期点検）

導入後、継続的に実施する点検項目です。設定ドリフトと権限肥大化を防ぐことが主目的になります。

月次点検項目

• 新規アカウント発行: 申請ベースで承認記録が残っているか
• 権限変更履歴: 過去30日の権限変更が職務上妥当か
• 共有リンク棚卸し: 「リンクを知る全員」「組織全体」の公開設定がないか
• API連携の追加: 過去30日に追加された外部アプリの妥当性
• ログイン異常: 普段と異なる地域・時間帯・デバイスからのアクセス
• 失敗ログイン: 短時間に複数回失敗しているアカウント
• ライセンス使用率: 未利用アカウント・休眠アカウントの抽出

四半期点検項目

• アクセス権棚卸し: 全ユーザーの権限を上長レビュー、職務分離（SoD）違反がないか
• 管理者リスト確認: 退任者・異動者が管理者に残っていないか
• セキュリティ設定: ベースライン（MFA・IPアクセス制御・監査ログ）の適用率
• 第三者連携アプリ: 利用実績がない連携の削除
• バックアップ整合性: テストリストアの実施記録
• インシデント対応訓練: 年1〜2回のテーブルトップ演習

半期・年次点検項目

• ベンダー再評価: 第三者認証の更新状況、新たな脆弱性・インシデント有無
• 契約条項見直し: 規模変化・要件変化に応じた条件交渉
• ポリシー文書更新: 利用規定、運用手順書、教育コンテンツの最新化
• 退職プロセス監査: 過去1年の退職者でアカウント残存がないか
• DLPルール見直し: ヒット件数の多いルールの妥当性、誤検知の調整
• セキュリティ監査: 内部監査または外部監査の実施

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

退職時チェックリスト（アカウント・デバイス・データ）

退職・異動・契約終了時に実施する点検項目です。「即時」かつ「漏れなし」が鉄則になります。退職予定の連絡を受けた時点で、以下のチェックリストに沿って機械的に処理する運用が望ましい形です。

退職予定通知時（最終出社1〜2週間前）

• 退職予兆検知の確認: 大量ダウンロード、外部送信、業務外サイト閲覧の異常がないか
• 引き継ぎ対象データ: 共有フォルダ・チャットDM・メールアーカイブの権限移管計画
• 重要データ保全: 法務・コンプライアンス対象データの保全措置（リーガルホールド）
• ライセンス管理: 利用中SaaSのライセンス棚卸し、後任者への引き継ぎ計画

最終出社日

• ハイリスクSaaS停止: 機密情報を扱うSaaS（CRM、ERP、人事システム）から先行停止
• メール・チャット: アカウント停止と社外向け自動応答設定
• 物理デバイス: PC、スマートフォン、ICカード、社員証の回収
• ファイル整理: 個人領域に残った業務データの引き継ぎフォルダへの移動

最終出社後（24〜72時間以内）

• 全SaaSアカウント停止: 退職時刻に合わせて即時停止を実施。SSO・SCIM経由で一括停止、未連携SaaSは個別停止（OAuthトークン・APIキーも対象）
• 認証情報無効化: パスワードリセット、APIキー無効化、リフレッシュトークン失効
• データ持出ログ確認: 過去1〜3か月のダウンロード・印刷・外部送信ログの確認
• ライセンス回収: 課金停止または後任者への割当変更
• 法務・人事への完了報告: 処理結果のチェックリスト記録、アカウント停止証跡の保存

削除（退職30〜90日後）

• アーカイブ実施: 法定保存期間に応じたデータアーカイブ
• アカウント削除: 復旧不可能な完全削除の実施
• 削除証跡保存: 監査対応のための削除ログ・スクリーンショット

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

評価結果の記録と改善サイクル

チェックリストは「実施するだけ」では効果が限定的です。結果を記録し、改善サイクルにつなげる仕組みが、品質を継続的に高める鍵になります。

記録のフォーマット

最低限残すべき項目は5つです。

• 点検日時、点検者、対象SaaS
• 各項目の合否（OK/NG/対象外）
• NG項目の是正期限と担当者
• 是正完了日と確認者
• 次回点検予定日

スプレッドシートで運用する場合、SaaS名×項目のマトリクスにすると、合格率を一目で可視化できます。SMPやSSPM製品を導入していれば、ダッシュボードに自動集計される構成が理想です。

改善サイクル（PDCA）

四半期に1度、合格率の推移と頻発するNG項目を集計します。同じ項目で繰り返しNGが出る場合、原因は「ルールが守られていない」ではなく「ルールが運用に合っていない」可能性が高く、項目自体の見直しが必要です。

経営層への報告は、「全SaaSの合格率」「重要SaaSの合格率」「前期比改善率」の3指標が伝わりやすい形式です。具体的な是正計画と、必要な投資要望を併記すると、稟議が通りやすくなります。

参考：ISO/IEC 27001:2022 情報セキュリティマネジメントシステム（JIPDEC）

SaaSセキュリティ チェックリストに関連する用語集

記事内で使用した専門用語を整理します。

• 責任共有モデル: クラウドの責任分界点。基盤側はベンダー、設定・データ側は利用企業
• CSPM/SSPM: クラウド・SaaSの設定状態を継続監視する仕組み
• IDaaS: クラウド型ID統合管理。SSO・MFA・プロビジョニングを統合提供
• IGA: アクセス権の付与・棚卸し・職務分離を統合管理するガバナンス基盤
• SCIM: ID情報をシステム間で同期する標準プロトコル
• SoD: 職務分離。同一人物に承認・実行・監査の3権限を集中させない統制
• DLP: 機密データの社外持ち出しを技術的に検知・遮断する仕組み
• DPA: 個人情報取扱業務委託契約書（Data Processing Agreement）
• リーガルホールド: 訴訟・調査対応のためのデータ保全措置
• データレジデンシー: データの所在地に関する規制要件
• SMP（SaaS Management Platform）: SaaSの契約・アカウント・利用・コストを統合管理するプラットフォーム

ジョーシスを活用したチェックリスト運用の自動化

チェックリストの項目数は、運用が安定するほど増えていきます。導入時・月次・四半期・退職時を合わせると、1社あたり数百項目になることも珍しくなく、すべてを手作業で運用するのは現実的ではありません。

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

• 利用SaaSの自動棚卸し: 経費精算データ・SSOログ・連携APIから利用SaaSを自動検出
• アカウントライフサイクル: 入社・異動・退職に応じたアカウント発行・権限変更・停止を自動実行
• ダッシュボード: 全SaaSのアカウント数、休眠率、ライセンス使用率を一画面で可視化
• 監査ログ: アカウント・権限・契約変更の履歴を一元保管、監査対応の根拠資料に活用

導入企業数は国内外700社を超え、IT工数を最大50%、ITコストを最大75%削減した事例が報告されています。350以上のSaaSと連携可能で、SCIM/API両対応により幅広い環境で導入できます。

チェックリスト運用を自動化したい方、ジョーシスの機能と効果を5分で把握したい方は、以下から資料をダウンロードください。

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

無料デモを予約する

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

Q1. チェックリストの項目数はどの程度が適切ですか

導入フェーズで30〜50項目、運用フェーズの月次で15〜25項目、四半期で30〜50項目、退職フェーズで20〜30項目が現実的な目安です。「重要度A:必須」「重要度B:推奨」「重要度C:任意」の3段階で分類し、Aだけは100%実施を目指す運用が定着しやすい形です。

Q2. すべてのSaaSに同じ基準を適用すべきですか

不要です。SaaSの重要度を「機密データを扱う」「業務基幹に組み込まれている」「ライセンス費が高額」の3観点で分類し、重要度に応じてチェックリストの厳しさを変えます。重要度の低いSaaSにまで全項目を適用すると、運用負荷が膨らみ形骸化のリスクが高まります。

Q3. SSPM製品を導入すれば手動チェックは不要ですか

完全には不要になりません。SSPMは設定状態の自動監査を得意としますが、契約条項の妥当性、退職プロセスの漏れ、職務分離の判断などは人による確認が残ります。SSPMで自動化できる項目を切り出し、それ以外を人が担当する役割分担が現実的です。

Q4. チェックリスト運用の負担を下げる工夫はありますか

3つあります。第1に、SMP・SSPMで機械的に取得できる項目を優先的に自動化すること。第2に、人が判断する項目を「年1回」「四半期1回」など低頻度に集約すること。第3に、月次点検は5〜10分で完了する程度の項目数に絞り、運用に乗せやすくすることです。

Q5. 中小企業向けに簡素化したチェックリストはありますか

可能です。最重要は「全アカウントにMFA」「退職時の即時停止」「公開設定の最小化」の3点で、これだけでも漏洩リスクは大幅に下がります。最初はこの3項目だけを月次でチェックし、運用が定着したら徐々に項目を追加する段階的アプローチが向いています。

まとめ

SaaSセキュリティ チェックリストは、属人的な運用を仕組みに変えるための共通言語です。導入時・運用時・退職時の3フェーズと、契約・ID・データ・設定・監査の5領域で整理することで、抜けのない点検運用が構築できます。

重要なのは「完璧なチェックリストをつくる」ことではなく、「合格率を可視化し、改善サイクルを回せる」状態にすることです。記録を残し、四半期で見直し、経営層へ合格率と是正計画を報告する流れが定着すれば、ガバナンスは自然に強化されていきます。

SMPやSSPMを活用して機械的に取得できる項目を自動化し、人による判断を高頻度の運用から減らすことで、情シスは限られた工数で広い管理範囲をカバーできます。チェックリスト運用とSaaS統合管理を一体で実装したい方は、ジョーシスの資料をご確認ください。

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

無料デモを予約する