セキュリティチェックシートの見方｜SaaS選定の12項目

セキュリティチェックシートは、SaaSの安全性を「はい・いいえ」だけで採点する表ではありません。自社が扱う情報と止められない業務を起点に、候補サービスの対策、運用、契約条件を同じ軸で確認するための質問票です。

回答欄がすべて埋まっていても、対象範囲や例外条件が分からなければ判断材料は不足しています。ここでは、情シス兼任者や総務担当者が稟議前に押さえたい項目を十二に整理し、回答の読み方と再質問の例まで示します。

セキュリティチェックシートとは

セキュリティチェックシートとは、クラウドサービスの導入前に、利用目的、技術対策、運用体制、契約条件を候補ごとに照合する質問票です。IPA「中小企業のためのクラウドサービス安全利用の手引き」では、扱う情報の重要度、事業者の信頼性、利用者管理、バックアップ、契約終了時のデータ、保存先の国・地域などを確認点として挙げています。

チェックシートの役割は、絶対的な安全を証明することではありません。自社要件とベンダー回答の間にある差を見つけ、追加確認、利用条件、承認者を記録することです。たとえば「暗号化あり」という回答だけでは、通信中なのか保存時なのか、全データが対象なのかを読み取れません。

質問数の多さも品質を保証しません。同じ内容を言い換えた質問が並ぶ一方で、終了時のデータ返却や障害通知が抜けていることがあります。質問票を受け取ったら、まず自社の必須条件を十二項目へ対応づけ、重複と空白を見つけます。ベンダー独自の書式へ転記する場合も、元の要件番号を消さないようにします。

回答を見る前に自社の利用目的と情報の重要度を決める

ベンダーへ質問票を送る前に、「誰が、どの業務で、何を保存するか」を一枚にまとめます。ここが曖昧だと、ベンダーは一般的な回答しか返せず、社内では担当者ごとに評価が割れます。

管理されない社内ツールをそのまま本番利用すると、認証、権限、更新、バックアップ、問い合わせ先の責任者が決まらないままデータだけが増えることがあります。AIで作ったか、人が手作業で作ったかが分かれ目ではありません。本番運用の責任と手順が置かれているかで線を引きます。

この整理は、候補を減らすためだけに行うものではありません。顧客から預かった情報を保存しない運用に変えれば確認不要になる項目もあれば、外部公開やデータ連携を追加した時点で再評価が必要になる項目もあります。導入時の用途を基準にし、将来やるかもしれないことまで一度に承認しないほうが、質問と回答の対応関係を保てます。

また、「必須」と「あるとよい」を分けます。社内規程や取引先との契約で求められる条件は必須、運用で代替できるものは条件付きとして整理します。すべてを必須にすると候補が消え、すべてを条件付きにするとチェックシートが形だけになります。

SaaS選定で確認する12項目

次の表は、IPAの十五の確認点と、経済産業省のSaaS向けSLAガイドラインおよび「III-6 SaaS・ASPのためのSLA」を、買い手が回答を読み比べやすい十二項目に再編したものです。回答例はすべて架空です。「よい回答」は合格を意味せず、自社要件に照らして追加確認が少ない回答の例を示します。

十二項目は互いに独立していません。たとえば「国内保存」と回答されても、障害解析や外部連携で国外処理が発生することがあります。バックアップがあっても、復元を依頼できる人、復元単位、所要時間が自社の業務に合わなければ、消失時の備えとしては足りません。項目名の一致ではなく、実際の利用経路を追って読みます。

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

RPOは、復旧時にどの時点までデータを戻すことを目標とするかを表します。RTOは、障害後どの時間内に業務やサービスを戻すことを目標とするかを表します。バックアップの取得頻度だけでは、どちらも確定しません。復元作業の受付時間や、テナント単位・レコード単位で戻せるかも合わせて尋ねます。

ログも「保存しているか」だけでは足りません。不正閲覧を調べたいのに閲覧操作が記録されない、退職者の操作を追いたいのに利用者名で検索できない、といった差が出ます。想定する事故から逆算し、誰が、いつ、何をした記録が必要かを質問文に落としてください。

「はい」だけでは判断できない回答と再質問例

短い回答がすべて悪いわけではありません。公開資料に詳しい条件があり、回答からその箇所へたどれるなら確認は進みます。問題になるのは、対象、条件、責任主体、証跡のどれも特定できない回答です。

「対応しています」という返答には、例外と利用者側の作業を尋ねます。「個別に相談」なら、相談後の回答が見積書、申込書、契約書のどこへ残るかまで確認します。営業資料と利用規約で表現が異なる場合は、契約の優先順位を質問してください。

認証も同じ読み方です。ISMS認証があることと、候補サービスのすべての機能が個別に認証されたことは同義ではありません。認証登録番号、取得組織、登録範囲を確認し、自社が使うサービスがその範囲に含まれるかを照合します。

根拠文書の優先順位をそろえる

比較時は、回答を同じ日付、同じ利用条件へそろえます。ある候補は営業担当の説明、別の候補は利用規約という状態では、公平な比較になりません。規約、申込書、SLAやSLO、公式仕様、個別回答の順序と効力を各社へ確認し、条件が変わる機能は標準とオプションを分けます。

競合比較を社内資料や外部記事へ転用する場合も、調査時点と条件を残します。消費者庁の比較広告に関する考え方では、主張の客観的実証、数値や事実の正確な引用、公正な比較方法が要件とされています。一部機能だけで製品全体の優劣を結論づけず、短所や追加条件も同じ場所に記載します。

回答・証跡を使った社内承認の進め方

回答を受け取ったら、セキュリティ担当だけで抱え込まず、業務責任者と一緒に未充足項目を整理します。製品側で満たせない条件があっても、保存する情報を減らす、権限を絞る、別のバックアップを持つといった運用条件でリスクを下げられる場合があります。

経済産業省「III-6 SaaS・ASPのためのSLA」が示すとおり、公開目標が契約上の義務なのか努力目標なのかで、未達時の扱いは変わり得ます。公開ページの数値だけを稟議へ転記せず、契約、申込書、個別合意との関係を確かめます。

承認後は、採用した製品名だけでなく、承認時の前提を運用台帳へ移します。保存禁止データ、管理者、利用開始前に有効化する設定、ベンダー情報の見直し時期を残します。用途追加、連携先追加、規約変更、重大な事故があった場合は、導入時の回答を使い回さず、影響のある項目を再確認します。

残存リスクは「問題なし」に置き換えません。たとえば時間外サポートが自社要件を満たさないなら、翌営業日までの代替手順と判断者を記録します。許容する人と期限が明確なら、未充足項目を隠さずに承認できます。

PigeonCloudの公開情報で確認できる内容

PigeonCloudは株式会社ロフタルが提供するSaaSです。

公開ページは変更される場合があります。本欄は契約書、申込書、見積書、個別のセキュリティ回答を上書きしません。

PigeonCloudを候補にする場合も、この公開情報だけで社内要件を満たしたと結論づけないでください。利用プラン、オプション、保存するデータ、外部連携によって確認点は変わります。公開ページで根拠を確認できない項目は、利用条件を添えて個別回答を依頼し、その回答を稟議の証跡として保存します。

12 項目のチェックシート（表）と PigeonCloud の資料ダウンロード

上の表は登録なしで転記して使えます。候補サービスごとに確認し、未確認の欄を残したまま関係者へ回してください。PigeonCloudの機能やセキュリティ情報を確認する場合は、製品資料をご覧ください。

PigeonCloud のセキュリティ資料を含む製品資料をダウンロード

資料の内容と上のチェック項目は同一ではありません。