SaaSのセキュリティ資料案内｜公開情報と請求先を整理

業務用SaaSを検討する企業が、社内の情報システム担当へサービスの説明を渡す。Webサイトには認証マークがあるものの、どの製品が対象か、データの取扱いをどこで確認できるか、監査報告書を請求できるかが分からない。担当者は一つずつ問い合わせ、SaaS事業者も同じ案内を何度も返すことになります。認証マークの横に「詳しくはお問い合わせください」と書くだけでは、審査を進める入口になりません。

この記事は、SaaS・業務用クラウドサービスの経営者とWeb担当者が、自社のセキュリティ情報ページを整えるための話です。審査で聞かれる項目ごとに、公開ページで読める説明、請求が必要な資料、個別の質問先を対応させます。実際の対策、認証の範囲、報告書の開示可否は、製品・セキュリティ・法務などの責任者が確認します。制作会社が安全性を保証したり、公開すべき情報を独断で決めたりするものではありません。

認証マークから、審査項目へ進めるようにする

みやあじよのSaaS向けサイト制作は、情報管理のページで提供側の機能と利用企業側の設定を分け、確認項目、担当者向け原稿、資料・窓口への導線をつくると案内しています。コラムではそのうち「審査担当が資料を探す」ときの画面に絞ります。マークや規格名は、一定の範囲で認証・評価を受けたことを示す材料になりますが、利用者が知りたい製品、提供形態、期間、機能すべての答えにはなりません。

IPAの中小企業向けガイドライン第4.0版は、クラウドサービス安全利用の確認資料を付録に置いています。Cloud Security AllianceのCAIQも、クラウド事業者の管理策を項目ごとの質問で文書化する枠組みです。検討企業が確認したい内容は、認証の有無だけではありません。サイトはその項目に対して、どこまで公開情報で答え、詳細はどの方法で確認できるかを示します。

最初の棚卸しでは、営業に届く質問票、見積前の問い合わせ、既存のセキュリティ資料、製品ヘルプ、契約文書、外部監査の資料を集めます。管理画面の機能説明と、事業者自身の運用説明が混ざっていないかを確認します。古い提案書に書かれた対策を、現在も有効だと推測してサイトへ載せません。更新責任者が確認できない項目は「公開原稿待ち」として残します。

審査項目・公開情報・請求先を一表にする

次の表は、架空の業務用SaaSのページ設計例です。具体的な対策や取得済み認証を表すものではありません。自社で使うときは製品と契約形態ごとに実際の説明を確認し、資料名・公開範囲・担当窓口へ置き換えます。列を分ける目的は、資料そのものを何でも公開することではなく、審査担当が必要な情報の所在と取得方法を見つけられるようにすることです。

表は左右にスクロールできます。

審査で確認される項目	公開ページで示す情報	詳細資料・請求先	確認・更新担当
対象サービスと範囲	対象製品、プラン、提供地域、説明の対象時点	対象一覧や条件の詳細が必要なら担当窓口	製品責任者
データの取扱い	保存・処理の範囲、公開できる方針と関連ページ	個別の処理条件は契約・情報管理窓口	セキュリティ・法務
利用者の管理機能	権限、認証、記録など提供機能の案内先	設定手順は製品資料・デモの窓口	製品担当
第三者評価・報告書	実際の認証名、適用範囲、対象期間を確認済みで掲載	報告書の受領条件と請求先を明記	認証・監査担当
質問票や個別審査	標準回答の所在と回答できる範囲	企業固有の質問票は受付フォームへ	審査対応担当

審査項目から公開ページ、限定資料の請求、個別質問の三つの行き先へ分け、対象範囲と版を確認する図 — 架空のSaaSサイトの案内構成例。審査項目から公開情報、請求資料、個別回答へ進み、資料ごとの対象と版を確認します。

公開欄に「暗号化しています」「安全に運用しています」といった広い文だけを入れても、審査項目との対応は分かりません。自社で確認できた事実を、どのデータ・どの製品・どの期間に当てはめられるかを添えます。一方、内部構成や個別の報告書を公開すると判断するのもWeb担当者の役割ではありません。責任者が公開区分を決め、サイトはその区分に合わせて説明と請求先を示します。

公開・請求・個別回答の境目を明記する

公開できる概要には、製品が提供するセキュリティ機能、利用企業が設定する項目、適用中の認証の範囲、関連するポリシーの案内などが候補になります。実際に何を公開するかは事業者が決めます。請求が必要な資料には、配布条件や対象者の確認が必要な報告書などがあります。企業固有の質問票は、標準資料で答えられる部分と個別の確認が必要な部分を分けます。「問い合わせ」という一語にすべて押し込めず、どの状態ならどの窓口へ行くかを表示します。

AtlassianのコンプライアンスFAQは、詳細なセキュリティ・プライバシー・コンプライアンス資料をTrust Portalに集め、認証を伴うセルフサービスと追加のサポートを案内しています。Google CloudのSOC 2案内も、報告書を請求する経路に加え、対象サービスや対象期間を示しています。両社の運用を小規模SaaSがそのまま再現する必要はありません。ただ、公開ページで「資料がある」と知らせることと、実物へ適切にアクセスさせることを別に設計している点は参考になります。

資料名だけでなく、適用範囲と版を示す

同じ会社が複数のSaaSを提供している場合、会社名の認証がすべての製品・プランに当てはまるとは限りません。M&A、別環境、ベータ機能、地域別の提供では、対象が違うこともあります。認証や監査の適用範囲を、担当者が確認できる資料に合わせて書きます。「当社サービスは認証済み」とだけ表示して、対象外の製品へ同じ印象を与えないようにします。

資料一覧には、資料名、対象製品、対象期間または版、更新日、入手方法、承認者を持たせます。サイトに掲載するのは読者が必要とする情報へ絞りますが、社内の管理表では承認経路まで残します。公開PDFのURLを差し替える際に古いURLが残るなら、旧版を開いた人への案内も考えます。期限付きの資料やログインが必要な資料は、リンク切れ時に代わりの請求先が分かるようにします。

表の「対象時点」は、読者が情報の新旧を判断するために必要です。製品の機能が変わったのにセキュリティページだけ旧仕様のままなら、審査担当はどれが正しいか分かりません。更新日だけを上書きして内容を見直さない運用も避けます。製品変更、提供地域の変更、新しい報告書、認証の更新、窓口変更が起きたとき、誰が原稿を直し、誰が公開を承認するか決めます。

公開ページと資料の記載が異なる場合は、まず正本を特定します。営業資料の短い言い方をWebへ持ち込み、契約文書の条件を落とさないようにします。「保存先」「第三者提供」「障害時の連絡」など、言葉の意味が部署で違う項目は原稿の承認前にそろえます。制作会社は文を読みやすくできますが、対策の実施状況や契約上の適用範囲を確認したことにはなりません。

請求フォームは、必要な資料へ届く入口にする

「セキュリティ資料を請求する」ボタンから進むフォームで、請求者が欲しい資料を選べないと、担当者は折り返し用途を尋ねることになります。製品名、検討段階、必要な資料の種類、質問票の有無、連絡先など、振り分けに必要な項目を考えます。ただし初回から社内審査の全質問票を自由添付で集めるかは、ファイルの受取・保存・閲覧方法を決めてから判断します。機密情報を含む資料の送付方法も事業者の管理手順に合わせます。

請求を受け付けても、資料の閲覧権がその場で認められたとは限りません。完了画面では「請求を受け付けました」「担当者が対象資料と受渡し方法を確認します」など、現在の状態を伝えます。自動でダウンロードを提供する場合は、対象者と配布条件を事業者が確認した資料だけにします。返答予定や利用可能な窓口を載せるなら、運用上守れる範囲で表記します。

質問票を受け付ける場合、既存の標準回答へ案内できる部分と、製品固有の回答が必要な部分を分けます。利用企業のセキュリティ基準に適合するかを、サイトの説明だけで判定したように見せません。審査の判断は利用企業が行い、SaaS事業者は自社の事実と資料を提供します。回答できない項目や契約前には開示できない資料があるなら、その理由と次の相談先を担当者が確認して示します。

ページの配置と表示を試す

セキュリティ情報は独立したページを設け、製品紹介、料金、導入案内から必要な箇所へリンクします。全社共通の情報と製品固有の情報があるなら、見出しを分けます。認証ロゴだけを並べる入口より、「データの取扱いを確認」「権限・認証機能を見る」「報告書を請求」など目的の分かるリンクが有効です。契約文書やプライバシー関連のページへ進む場合も、何を読めるかをリンク名に含めます。

スマートフォンでは、表を縮小画像にせず、項目と行き先をテキストで維持します。横スクロールなら動くことを示し、行の右端に請求先が隠れたままにならないか確認します。担当者が社内で共有する場面も想定し、リンク先のページタイトルに製品名と資料の種類を含めます。自動返信やダウンロードページにも同じ名称を使うと、どの資料を受け取ったか照合しやすくなります。

公開前には、認証マークを見た初回の審査担当、特定製品の報告書が欲しい担当、独自質問票を持つ担当の三人を想定してたどります。それぞれが正しい適用範囲、資料の状態、次の窓口へ行けるかを確認します。リンク切れ、期限切れの資料、旧版のPDF、フォームの通知先も試します。社内でページを承認する人が、実際の請求後の画面まで見て初めて「案内できている」と判断できます。

提供機能と利用企業の設定を混同しない

SaaS事業者が機能を提供することと、利用企業がその機能を使う設定にしていることは別です。たとえば権限管理の機能がある場合、ページでは利用可能なプラン、設定できる管理者、設定方法の参照先を製品担当に確認します。利用企業の権限の割り当てまで事業者が行うかどうかは、導入支援の範囲と整合させます。「権限を適切に管理」と一文にまとめると、どちらが何をするのか読めません。

審査で「対応していますか」と聞かれた項目に対して、機能がある、標準で有効、別途設定が必要、個別契約で提供などの状態を同じ「対応可」で表さないようにします。製品担当が違いを確認したうえで、公開ページの短い説明と詳しいヘルプ・資料をつなぎます。プラン変更や機能追加で状態が変われば、一覧の該当行、製品ページ、請求資料の版をまとめて見直します。

資料を出せない場合にも、ページから完全に消すとは限りません。公開できる範囲で資料の存在、対象、請求可否、代替して確認できる情報を案内できるか責任者に聞きます。逆に、存在しない資料を「ご希望の方へお送りします」と約束してはいけません。今ある資料と回答体制で実行できる導線にすることが、審査担当にも営業担当にも分かりやすい案内になります。

制作会社へ渡すものは、製品一覧、公開済みのセキュリティ説明、認証・報告書の対象範囲、資料ごとの開示区分、FAQと質問票、更新と請求の担当者です。未確定の項目を「近日公開」で埋めるより、担当者と確認日を残して公開判断へ戻します。問い合わせや資料請求が増減したか、審査に進みやすくなったかは公開後に実測し、推測の改善率を載せません。