導入

ISMS（情報セキュリティマネジメントシステム）の取得・更新審査において、SaaS管理に関する指摘が増えています。数年前まであまり問われなかった領域ですが、最近の審査では「SaaSのアクセス権が適切に管理されているか」「シャドーITのリスクアセスメントを実施しているか」といった質問が当たり前のように飛んでくるようになりました。

情シス担当者にとって、この変化は頭の痛い問題です。100種類以上のSaaSを抱える企業では、一つひとつの棚卸しだけでも相当な工数がかかります。さらに入退社・異動のたびにアクセス権を見直し、その証跡を保管し、審査官に説明できる状態を維持するとなると、手作業では限界があります。

ISMSの審査対応で焦るのは、準備が不十分なまま審査日を迎えてしまうケースです。「Excelで台帳を作っていたが最後に更新したのは半年前」「権限変更の記録はSlackのスレッドに残っているが、正式な証跡としてまとめていない」——こうした状況は、審査官の追加質問を呼び込みます。

この記事では、ISO/IEC 27001においてSaaS管理がどのように位置づけられているかを整理したうえで、審査で指摘されやすい問題と対策、そして実践的な対応ステップを解説します。

ISMSとは何か

ISMSとは、組織が情報セキュリティリスクを体系的に管理するための仕組みです。ISO/IEC 27001という国際規格に基づき、組織が独自のポリシーや手順を定め、PDCAサイクルで継続的に改善していく枠組みを指します。

ISO/IEC 27001の概要

ISO/IEC 27001は、情報セキュリティマネジメントシステムの要求事項を定めた国際規格です。2005年に初版が発行され、2013年に改訂、そして2022年に最新版（ISO/IEC 27001:2022）が発行されました。認証を取得するには、第三者機関による審査に合格する必要があります。

規格の構成は大きく2つに分かれます。本文（第4〜10章）ではマネジメントシステムとしての要求事項を規定しており、附属書A（Annex A）では93の管理策が列挙されています。2022年改訂では管理策の数が114から93に整理され、クラウドサービスに関連する管理策が新たに追加されました。これはSaaSの普及という時代背景を反映した変更です。

ISMS認証の意義

ISMS認証を取得する意義は、対外的な信頼性の確保と内部統制の強化の2点に集約されます。取引先や顧客に対して「情報セキュリティに真剣に取り組んでいる」という証明になり、特に金融・医療・製造業では調達要件にISMS認証取得が含まれるケースが増えています。

内部的には、認証取得のプロセスでセキュリティポリシーや手順書の整備が進み、インシデント対応体制が強化されます。認証を維持するためのサーベイランス審査が定期的に実施されるため、形骸化を防ぐ仕組みとしても機能します。

日本企業のISMS認証取得数は世界最多水準にあります。ISMSユーザーグループの集計によると、日本国内のISO/IEC 27001認証取得数は7,000件を超えており、グローバルの認証数でも上位に位置しています。製造業・情報通信業・サービス業を中心に、従業員数500名以上の中堅・大手企業での取得が多い状況です。

PDCAサイクルによる継続的改善

ISMSが単なる「紙の規程」で終わらないよう、ISO/IEC 27001はPDCAサイクルによる継続的改善を要求しています。Plan（方針・目標の設定）、Do（管理策の実施）、Check（有効性の評価・内部監査）、Act（改善）のサイクルを回すことで、組織のセキュリティレベルを維持・向上させる仕組みです。

SaaS管理の文脈では、このPDCAが形式だけになりやすい落とし穴があります。規程は整備したが実態の棚卸しが追いついていない、定期レビューの証跡が残っていないといった状態は、Check・Actが機能していないことを意味します。審査官はまさにここを確認します。

参考: ISMSユーザーグループ「ISO/IEC 27001認証取得企業リスト」

SaaS時代のISMSで問われる管理策

ISO/IEC 27001:2022の附属書Aに定められた93の管理策のうち、SaaS管理に直接関わるものが複数あります。2022年改訂でクラウド関連の管理策が整理されたことで、SaaSを多く使う企業にとっての要求事項は以前より明確になりました。

A.5.9: IT資産管理（情報および関連資産の目録）

ISMSでは、組織が保有・利用するすべての情報資産を特定し、台帳（インベントリ）として管理することを求めています。かつてこの「情報資産」はサーバーやPCが主な対象でしたが、SaaSが当たり前になった現在では、クラウドサービスも当然含まれます。

SaaSを情報資産として台帳管理する場合、サービス名・利用部署・用途・保有データの分類・ベンダー情報を記録します。審査では「台帳はあるか」だけでなく「最後にいつ更新したか」「現場で実際に使われていない野良SaaSが含まれていないか」まで確認されます。

A.5.15: アクセス制御

アクセス制御の管理策では、情報システム（SaaSを含む）へのアクセスを業務上の必要性に基づき適切に制限することを求めています。具体的には、アクセス申請・承認フローの整備と、最小権限の原則の適用が中心テーマです。

SaaSのアクセス制御で問題になりやすいのは、管理者権限（Admin権限）の付与基準が曖昧なケースです。「とりあえず便利だから」「前任者がAdminだったから」という理由で管理者権限が広がっていると、審査での説明に苦慮します。

A.5.18: アクセス権限のレビュー（定期棚卸し）

この管理策は、定期的なアクセス権の見直しを要求します。人事異動・退職・組織変更が発生した際に権限を見直すことはもちろん、定期的な棚卸しとその記録が必要です。

実務では、入退社時の対応は比較的できていても、「在職中のアクセス権の変化」が追えていないケースが多く見られます。部署異動した社員が前部署のSaaSに引き続きアクセスできる状態や、プロジェクト終了後も権限が残存している状態は、A.5.18の観点から指摘対象になります。

A.8.3: 情報アクセス制限

A.8.3は、情報へのアクセスを必要最小限に制限する原則（最小権限の原則）を規定しています。SaaSにおけるロール設計、閲覧権限と編集権限の区別、機密データへのアクセス範囲の制御が対象です。

SaaS製品によってはロール設計が細かく設定できないケースもあります。そうした場合は「補完的な管理策（定期的なアクセスログのレビュー等）を実施している」と説明できるよう準備が必要です。

A.8.5: セキュアな認証

A.8.5では、システムへの認証を安全に実施するための管理策を求めています。多要素認証（MFA）やシングルサインオン（SSO）の活用が代表的な対応です。SaaSごとにIDとパスワードが分散している状態は、この管理策の観点からリスクと見なされます。

ISO/IEC 27017: クラウドサービス向けガイダンス

ISO/IEC 27017は、クラウドサービスの情報セキュリティ管理に関するガイドラインです。ISO/IEC 27001の附属書Aを補完する形で、クラウドサービス固有のセキュリティ管理策を提示しています。クラウドサービス利用者（CSC）としての責任と、クラウドサービス提供者（CSP）の責任分界点の明確化が主な内容です。

SaaS利用企業にとって重要なのは、SaaSベンダーが何を担保し、何を利用者側で管理するかを把握しておくことです。ベンダーがISO/IEC 27001やSOC 2認証を取得しているかどうかの確認も、リスクアセスメントの一環として求められます。

参考: ISO/IEC 27001:2022

ISO/IEC 27017

ISMS審査で指摘されやすいSaaS管理の問題

ISMS審査でSaaS管理に関して指摘が入るパターンには、ある程度の共通性があります。ここでは情シス担当者が特に注意すべき5つの問題を取り上げます。

アクセス権の棚卸し頻度が不十分

最も多い指摘の一つが、アクセス権棚卸しの頻度に関するものです。「年1回実施している」と回答しても、「それでは人事異動後に数ヶ月間、前部署のSaaSにアクセスできる状態が続く可能性があるが、どのようなリスクコントロールをしているか」と追加質問されるケースがあります。

ISO/IEC 27001は「定期的に」という表現を使い、具体的な頻度は規定していません。ただし、人事異動が多い組織では年1回では実態に即していないと判断される可能性があります。四半期ごとを目安に、少なくとも重要システムについては確認サイクルを短くしておくことが望ましいです。

IT資産台帳にSaaSが含まれていない

IT資産台帳にオンプレミスのシステムやハードウェアしか載っていないケースは、審査でそのまま指摘されます。「契約しているSaaSは何種類あるか」「台帳で管理しているか」という質問への答えが「把握していない」では、A.5.9の要求事項を満たしていないと見なされます。

また、台帳があっても「現場が独自に契約したSaaSを把握していない」という状態——いわゆるシャドーIT——も問題です。シャドーITの存在自体がリスクアセスメント未実施の証拠となり得ます。

入退社・異動時の権限変更の証跡がない

退職者や異動者のSaaSアクセスを削除・変更した記録が残っていない場合、審査で追及されます。「メールやSlackで連絡してその都度対応している」という説明では、組織的な手順として認められないことがあります。

審査官が求めるのは「誰が、いつ、どのSaaSの権限を変更したか」が追跡できる記録です。手動対応でも記録を体系的に残す仕組みがあれば問題ありませんが、属人的な運用では証跡が分散・消失しやすく、ISMSの要求事項に合致しないと判断されます。

未承認SaaSのリスクアセスメントが未実施

現場部門が情シスに申請せずに契約したSaaSが存在し、かつそれに対してリスクアセスメントを実施していない場合、指摘対象になります。「知らなかった」という説明は通りません。ISMSでは組織として情報資産を管理する責任があり、シャドーITを「発見・評価・対処」するプロセスの整備が求められます。

クラウドサービス利用規程が形式的で実態に即していない

クラウドサービスの利用規程はあるが、「SaaS利用の申請手続き」や「承認フロー」が文書上にしか存在せず、実際には運用されていないケースも指摘対象です。規程と実態の乖離は、ISMS審査における典型的な不適合事項の一つです。

「規程は整備したが誰も読んでいない」「申請フォームはあるが現場は直接契約している」という状態は、PDCAのDoフェーズが機能していないことを示します。

SaaS管理のISMS対応 実践ステップ

ISMS対応においてSaaS管理を整備するための実践的なステップを5段階で解説します。一度にすべてを完璧にしようとするより、優先度の高い管理策から順番に着手することが現実的です。

Step1: SaaSのIT資産台帳を整備する

ISMS対応の起点となるのが、全社で利用するSaaSの棚卸しとIT資産台帳の整備です。現状把握なしにはリスクアセスメントも管理策の設計もできません。

まずは利用中のSaaSをリストアップします。情シスが把握しているものだけでなく、費用精算データや法人クレジットカードの利用履歴、各部門へのヒアリングを通じて、シャドーITを含めた全体像を把握します。

台帳に含める項目として最低限必要なのは以下です。

• サービス名・ベンダー名
• 利用部署・システムオーナー（担当者）
• 用途・取り扱うデータの種類と分類
• 契約形態（月額/年額・ライセンス数）
• ベンダーのセキュリティ認証取得状況（ISO 27001・SOC 2等）
• データ保管地（国・リージョン）
• 最終棚卸し日

台帳の更新頻度は、少なくとも四半期ごとを目安に設定します。担当者が変わっても引き継げるよう、ドキュメントの管理場所とオーナーを明確にしておくことが重要です。

Step2: SaaSのリスクアセスメント

IT資産台帳が整備されたら、各SaaSに対してリスクアセスメントを実施します。すべてのSaaSを同じ深さで評価するのではなく、取り扱うデータの機密性に応じて優先順位をつけることが現実的です。

評価軸として以下の観点を整理します。

• 保存・処理するデータの機密性（個人情報・機密情報の有無）
• サービス停止時の業務影響度
• ベンダーのセキュリティ体制（ISO 27001・SOC 2認証の取得状況、データ保管地）
• シングルサインオン（SSO）・多要素認証（MFA）への対応状況

リスクの評価後は「受容」「低減」「回避」「移転」のいずれかの対応方針を決定し、その判断根拠を記録します。この記録がISMS審査での説明材料になります。

特にベンダー評価においては、そのSaaSベンダー自身がISO 27001やSOC 2 Type 2を取得しているかどうかが一つの基準になります。取得していない場合は、追加的な確認（セキュリティ質問票の送付等）が必要になるケースもあります。

Step3: アクセス制御ポリシーの整備

リスクアセスメントの結果をもとに、各SaaSのアクセス制御ポリシーを整備します。「誰が・どのような権限で・どのように申請して承認されるか」を文書化することが目的です。

整備すべき内容は以下の3点です。

第一に、アクセス申請・承認フローの文書化です。SaaSへのアクセスを申請する際の手続き（申請者→承認者→情シスへの通知）を明確にします。フォーマットはメール申請でも専用フォームでも構いませんが、承認記録が残る仕組みにすることが重要です。

第二に、最小権限の原則の適用です。各SaaSで利用可能なロールを整理し、業務に必要な最低限の権限を付与するルールを定めます。特に管理者権限（Admin）の付与基準は、明文化しておくことが求められます。

第三に、特権アカウントの管理です。IT管理者やシステム担当者が持つ高権限アカウントについては、利用ログの記録・定期的なパスワード変更・共有アカウントの禁止といった追加管理策を設けます。

Step4: 定期的なアクセス権レビューの仕組み化

A.5.18の要求事項を満たすために、定期的なアクセス権棚卸しの仕組みを整備します。仕組み化のポイントは、棚卸しの実施と証跡保存を属人的な作業にしないことです。

推奨する棚卸しサイクルは四半期ごとです。レビューの対象は全社員のSaaSアクセス権全体で、各SaaSのシステムオーナー（担当部署のマネージャー等）がアクセス権の適切性を確認・承認します。

証跡として保存すべきものは以下です。

• 棚卸し実施日と実施者
• レビュー対象のSaaSと対象社員リスト
• マネージャーによる確認・承認の記録（メール・チケット等）
• 権限変更・削除を実施した場合の変更記録と実施者

証跡の保管期間については、ISMSの方針として最低3年間は保存できる状態にしておくことが望ましいです。

アクセス権限 棚卸し 方法

Step5: クラウドサービス利用規程の整備

SaaS管理の全体を束ねる形で、クラウドサービス利用規程を整備します。規程は「作ること」が目的ではなく「現場に使われること」が目的です。難解な法的文書にならないよう、実務担当者が参照しやすい構成にすることが大切です。

規程に含めるべき主な項目は以下です。

• SaaS利用申請の手続きと承認フロー
• 承認済みSaaSのリスト（ホワイトリスト）と未承認利用の禁止
• 業務データの取り扱い（機密情報をSaaSにアップロードする際のルール）
• アカウント管理（共有アカウント禁止・退職時の削除等）
• インシデント発生時の報告手順

規程の実効性を高めるためには、全社員への周知と定期的な教育が必要です。ISMS審査では「従業員にどのように周知しているか」「教育の実施記録はあるか」が確認されるため、研修の実施記録や確認テストの結果等を保存しておきます。

ITガバナンスとは　 IT内部統制とは

JosysによるISMS対応の自動化

ここまで解説した5つのステップを、手作業で完全に維持し続けることは容易ではありません。Josysは、ISMS対応に必要なSaaS管理の主要プロセスを自動化するプラットフォームです。国内外700社以上の導入実績を持ち、情シス部門の工数削減と審査対応力の向上を支援しています。

Access Reviews: アクセス権棚卸しの自動化と証跡保存

Josysのアクセス権レビュー機能は、SaaSのアクセス権棚卸しを自動化します。定期的にレビュータスクを生成し、各SaaSのシステムオーナー（マネージャー等）に確認依頼を送付します。

確認結果は自動的にシステムに記録され、「誰が・いつ・どのアカウントのアクセス権を確認・承認したか」という証跡が自動保存されます。棚卸しのたびにExcelを作成・配布・回収する作業がなくなり、証跡の散逸リスクも解消されます。ISMS審査では、この記録をそのまま証跡として提出できます。

SaaS Discovery: シャドーITを含む全SaaSの可視化

Josysのサービスディスカバリー機能は、組織内で利用されているSaaSをIT資産台帳として可視化します。情シスが把握していないシャドーITも含め、利用実態を自動的に検出します。

IT資産台帳の整備に必要なサービス名・利用部署・ライセンス数・契約状況を一元管理できるため、A.5.9のIT資産管理要求事項への対応を効率化できます。定期的な棚卸し作業も、Josys上での確認と承認のみで完結します。

SaaSセキュリティとは

Access Automation: 入退社・異動の権限変更を自動記録

入退社・組織変更に伴うSaaSのアクセス権変更を自動化するのがAccess Automationです。人事システムと連携し、退職者のアカウント無効化・異動者の権限変更を自動実行します。

変更の実行ログは自動的に記録されるため、「いつ・誰の・どのSaaSの権限が変更されたか」が追跡可能な状態になります。ISMS審査で問われる「入退社時の権限変更の証跡」を手作業なしで用意できます。

IT資産管理 方法

SOC 2 Type 2認証取得済みの信頼性

JosysはSOC 2 Type 2認証を取得しています。SOC 2は米国公認会計士協会（AICPA）が定めるクラウドサービスのセキュリティ基準で、Type 2は一定期間にわたる運用の有効性を第三者が評価したものです。

ISMS審査においてサプライヤー管理（A.5.21等）の観点から「利用しているSaaSのセキュリティ体制は確認しているか」と問われた際、JosysのSOC 2 Type 2認証を証拠として提示できます。Josysを活用することで、自社のISMS対応とベンダー管理の両面から信頼性を担保できます。

参考情報:

• Josys製品サイト
• Josys Access Reviews機能

まとめ

ISMS対応においてSaaS管理が問われる根本にあるのは、「証跡」と「継続的な管理」の2点です。アクセス権が適切かどうかよりも、「適切であることを証明できるか」「仕組みとして継続できているか」が審査の焦点になります。

手作業での対応には限界があります。100種類を超えるSaaSのアクセス権を四半期ごとに棚卸しし、すべての変更を記録し続けることは、ツールなしでは多大な工数を要します。Josysのようなプラットフォームを活用することで、審査対応に必要な証跡の取得と管理の継続性を、大幅に効率化できます。

ISMS対応のSaaS管理に課題を感じている情シス担当者は、まず現状のIT資産台帳とアクセス権棚卸しの実態を確認するところから始めることをおすすめします。

Josysの資料をダウンロードして、ISMS対応に必要なSaaS管理の自動化事例を確認する

IT内部統制とは　 SOX対応 IT管理 方法　SaaSセキュリティとは

この記事は2026年4月時点の情報をもとに作成しています。ISO規格の要求事項や審査実務については、認証機関および情報セキュリティの専門家にご確認ください。