法人向けサービスのセキュリティ情報の載せ方｜認証・データ保管・権限・問い合わせ先の整理方法

監修: 菊地 将（リブランディング株式会社）

法人向けサービスでは、機能や料金だけでなく、認証の取得状況、データの保管方法、アクセス権限、暗号化、ログなどのセキュリティ情報も比較・社内稟議の材料になります。

Assuredが2026年に従業員1,000人以上の企業の情報システム・セキュリティ担当者500人を対象に実施した調査では、84.6％がクラウドサービスの導入・継続利用を判断する際に、事業者が公開するセキュリティ情報を活用していると回答しました。72.2％は、十分な情報開示があるサービスについて、信頼度や導入優先度が高まると回答しています。

ただし、セキュリティ情報は多ければよいわけではありません。比較段階で必要な情報は公開し、詳細資料や個別構成など公開範囲を限定すべき情報は、資料や問い合わせへ分ける必要があります。

この記事では、法人顧客が確認しやすく、提供企業側も情報を管理しやすいセキュリティ情報の載せ方を整理します。

法人向けサービスのセキュリティ情報は「公開範囲」と「配置先」をセットで決める

最初に決めるべきなのは、「セキュリティページを作るかどうか」ではありません。

どの情報を、誰が、どの検討段階で必要とするのかを整理し、公開範囲と配置先をセットで決めることが重要です。

IPAのクラウドサービスに関する調査では、SaaS提供事業者の情報開示方法として、Webサイトなどで広く公開する方法と、問い合わせを受けて個別に開示する方法の双方が確認されています。一方、技術面・物理面の対策は、質問されない限り開示されにくい傾向も示されています。利用企業側では公開情報を中心に確認するケースが多く、必要な情報が公開情報だけではそろわないという課題も整理されています。

そのため、情報を一つのページへ集約するよりも、次の4段階に分けると整理しやすくなります。

セキュリティ情報は、すべてを1か所へ集めるのではなく、最初の比較から個別確認まで役割を分けて配置します。

サービスページだけですべて説明しようとすると情報量が多くなります。反対に、すべてを問い合わせ必須にすると、比較段階の顧客が必要な情報を確認できません。

「まず確認できる情報」と「必要に応じて深掘りできる情報」を分けることが基本です。

比較・稟議で確認されやすいセキュリティ情報

セキュリティ情報を整理するときは、技術項目を羅列するのではなく、顧客が自社の基準と照合できる単位に分けます。

ASPICが運用する情報開示認定制度も、クラウドサービス利用者がサービスの安全性・信頼性に関する情報を比較・評価し、選択できるようにすることを目的としています。

掲載項目は、少なくとも次のように整理できます。

すべてのサービスで同じ項目数が必要なわけではありません。

重要なのは、自社サービスの利用条件と顧客の確認事項を照合し、「導入判断に必要なのに見つからない情報」を減らすことです。

認証は取得の有無だけでなく対象範囲まで示す

ISO/IEC 27001やISO/IEC 27017などの認証を取得している場合、「認証取得済み」とだけ記載するより、何が認証対象なのかまで確認できる方が比較しやすくなります。

たとえばkintoneのセキュリティページでは、ISO/IEC 27001、ISO/IEC 27017、ISMAPなどを個別に示し、認証・登録情報や第三者評価へたどれる構成になっています。

認証ロゴの掲載だけで終わらせず、対象サービスや認証範囲を確認できる情報へつなげることが重要です。

なお、第三者認証は「そのサービスに事故が起きないこと」を保証するものではありません。ASPICも、情報開示認定について、サービスそのものの安全性を保証する制度ではなく、開示された情報をもとに利用者が判断するための仕組みだと説明しています。

データ保管は場所だけでなく保存・削除までつなげる

「国内データセンターを利用」といった情報だけでは、顧客が知りたい内容を十分に確認できない場合があります。

必要に応じて、次の情報まで整理します。

• データを保管する国・地域
• 通信時・保管時の暗号化
• バックアップの有無
• 契約終了時のデータ削除
• 保存期間や削除条件
• 外部サービスや委託先を利用する場合の取り扱い

サービスページでは概要だけを示し、詳細条件はセキュリティ専用ページや資料へつなぐ方法もあります。

認証・権限は「利用企業が何を制御できるか」を示す

MFAやSSOに対応していても、「対応しています」だけでは顧客が自社要件と照合できない場合があります。

たとえば、利用できる認証方式、管理者が設定できる範囲、プランによる利用条件などを整理すると判断しやすくなります。

権限管理も同様です。

管理者、一般利用者、閲覧者などの役割がある場合は、それぞれがどこまで操作できるのかを伝えます。詳細な権限表までサービスページへ載せる必要はありませんが、権限を分けられるかどうか、どこで詳細を確認できるかは分かるようにしておくとよいでしょう。

セキュリティ情報の配置先は4段階に分ける

セキュリティ情報を整理するときは、「公開する・しない」の二択ではなく、公開範囲を段階化すると運用しやすくなります。

サービスページは最初の比較に必要な情報へ絞る

サービスページには、すべての技術仕様を載せる必要はありません。

最初に顧客が確認したい項目を要約し、詳細ページへ移動できる状態を作ります。

たとえば、

• 取得している主な第三者認証
• データ保管地域
• MFA・SSOなど主要機能への対応
• 暗号化の有無
• セキュリティ専用ページへのリンク
• 詳細確認の問い合わせ先

などです。

営業担当者へ連絡する前でも、一定の判断材料を得られる状態を目指します。

セキュリティ専用ページは比較・稟議用の情報をまとめる

専用ページでは、サービスページで要約した内容を詳しく説明します。

認証、データ管理、アクセス制御、権限、ログ、バックアップ、障害対応などを一定の分類で整理すると、顧客が必要な項目を探しやすくなります。

ここで大切なのは、会社のセキュリティ方針だけを説明するページにしないことです。

「当社はセキュリティを重視しています」という説明より、利用するサービスについて何を確認できるのかが分かる構成の方が比較材料になります。

資料・チェックシートは繰り返し聞かれる詳細情報をまとめる

顧客ごとに同じ質問へ個別回答している場合は、繰り返し確認される項目を標準資料にまとめる方法があります。

GMOトラスト・ログインでは、公開資料としてセキュリティチェックに利用できる複数の資料を案内し、個別のセキュリティチェックシートについては問い合わせで受け付ける構成を採っています。

公開可能な共通情報は再利用しやすい形にまとめ、顧客固有の質問だけを個別対応へ回すことで、Webと営業の役割を分けやすくなります。

個別問い合わせは機微な情報や顧客固有条件を扱う

ネットワークの詳細構成、個別の脆弱性情報、顧客環境を前提とした設定条件など、一般公開に向かない情報までWebサイトへ載せる必要はありません。

公開情報で判断できない場合に、

「どの情報について、どこへ問い合わせればよいか」

が分かれば、非公開情報を無理に公開せずに済みます。

公開してよい情報と公開しすぎない情報の境界

公開範囲を決めるときは、各情報について次の3点を確認すると整理しやすくなります。

1. 顧客の比較・稟議に役立つ情報か
2. 公開しても攻撃や不正利用につながる具体的情報を含まないか
3. 複数の顧客へ共通して説明できる内容か

比較に役立ち、公開して問題がなく、複数顧客へ共通して説明できる情報は公開ページとの相性がよくなります。

一方、機密性が高い情報や顧客ごとに条件が変わる情報は、資料・問い合わせへ分けます。

ASPICの情報開示に関するFAQでも、信頼できる情報を開示することと、セキュリティ上の詳細をすべて公開することは同じではないと説明されています。項目によっては、対策を実施している事実を開示しながら、使用製品などの詳細までは公開しない方法があります。

「公開できないため何も書かない」のではなく、概要と確認方法だけは公開するのがポイントです。

サービスページから問い合わせまで迷わせない導線

セキュリティ情報が複数の場所に分かれていても、導線が明確なら問題ありません。

料金・対象・導入条件・契約・セキュリティなど、繰り返し発生する質問をFAQとして整理する手順は、法人向けサービスページのFAQの作り方で確認できます。

基本的には、

サービスページ → セキュリティ専用ページ → 詳細資料 → 必要に応じて問い合わせ

という順序を作ります。

最初の比較で概要を確認し、必要に応じて詳細情報へ進める導線を作ることで、すべてを問い合わせ対応にする必要がなくなります。

サービスページでは概要を確認でき、さらに知りたい人は専用ページへ進める。標準化できる情報は資料で確認でき、個別条件だけを問い合わせる構造です。

FAQを用意する場合も、FAQをセキュリティ情報の中心にする必要はありません。

「データはどこに保管されますか」「SSOに対応していますか」など、繰り返し発生する質問への回答先として使い、認証・権限・データ管理などの体系的な説明は専用ページや資料側に残します。

こうすると、FAQ全体を膨らませずにセキュリティ情報へ誘導できます。

公開後は更新責任と基準日を決める

セキュリティ情報は、一度掲載したら終わりではありません。

公開後の更新責任・レビュー工程まで含めた運用の全体像は、コンテンツ制作・運用体制で整理しています。

認証範囲、利用しているクラウド環境、対応する認証方式、権限機能、委託先などが変われば、公開情報とのずれが発生します。

最低限、次の変更を更新のきっかけとして決めておくと管理しやすくなります。

• 第三者認証の取得・更新・対象範囲変更
• データ保管地域や基盤の変更
• SSO・MFAなど認証機能の追加・変更
• 権限・ログ機能の変更
• バックアップ・障害対応方針の変更
• 外部委託先や利用サービスの重要な変更
• セキュリティ問い合わせ窓口の変更

認証やサービス仕様が変わったときに、Web上のセキュリティ情報も更新対象として確認できる運用を決めておきます。

Web担当者だけに更新を任せるのではなく、セキュリティ・開発・法務・営業などから変更情報が届く流れも決めておきます。

ページ上に更新日や確認基準日を表示できると、顧客側も情報の新しさを判断しやすくなります。

自社ページを確認するチェックリスト

法人向けサービスのセキュリティ情報を見直す際は、次の項目を確認してください。

• サービスページからセキュリティ情報へ移動できる
• 第三者認証は名称だけでなく対象範囲も確認できる
• データの保管国・地域を確認できる
• 通信時・保管時の暗号化について確認できる
• MFA・SSOなど主要な認証機能を確認できる
• 権限管理・ログの概要を確認できる
• バックアップやインシデント対応の方針を確認できる
• 公開できない情報について確認方法が案内されている
• 個別チェックシートの問い合わせ先が分かる
• 情報の更新日または確認基準日が分かる

不足項目が多い場合でも、すべてを一度に公開する必要はありません。

まず比較・稟議で繰り返し確認される情報を整理し、サービスページ、専用ページ、資料、問い合わせのどこで回答するかを決めると進めやすくなります。

自社ページの不足情報を一覧で確認したい場合は、無料ダウンロード資料も活用してください。営業担当者へ質問が届く前に、認証・データ保管・権限・問い合わせ導線の不足を洗い出す用途に使えます。

まとめ

法人向けサービスのセキュリティ情報は、情報量を増やすことよりも、顧客が必要な情報へたどり着ける開示設計が重要です。

最初の比較に必要な内容はサービスページ、体系的な説明はセキュリティ専用ページ、詳細な共通情報は資料、機微な情報や個別条件は問い合わせへ分けます。

第三者認証、データ保管、暗号化、認証・アクセス制御、権限、ログ、バックアップ、インシデント対応などを整理し、それぞれについて「何を公開するか」「どこで詳しく説明するか」「公開できない場合はどう案内するか」を決めてください。

公開できない情報までWeb上へ出す必要はありません。一方で、「詳細は問い合わせ」とだけ記載して比較材料そのものをなくすと、顧客は自社要件との照合が難しくなります。

公開情報と限定情報の境界を決め、比較から稟議、個別確認まで途切れない導線を作ることが、法人向けサービスのセキュリティ情報設計の基本です。

参考文献・データ元

‹ 親記事: コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理