SaaS導入の社内決裁を通す手順：公開資料で埋まる欄と、自社しか書けない欄を分ける(2026)

「このSaaSを入れたい」と稟議を上げたら、「セキュリティは大丈夫なのか」「データはどこに保存されるのか」と差し戻された。この記事は、海外SaaSの導入決裁を通すために、何をどこから集め、何を自社で書くかを分ける手順をまとめました。対象は、中小〜中堅企業の情シス、バックオフィス、SaaS選定を任された現場の担当者です。

最終更新: 2026年9月21日／独立行政法人情報処理推進機構(IPA)の公開資料と、各社の公式ページ・公開文書は同日に取得して確認しています。本文と表の「(編集部)」は、jisalab編集部の判断・整理であることを示します。

なぜ「安全性の根拠」で差し戻されるのか

「暗号化されています」「大手企業も使っています」は担当者の説明であって、決裁者が後で責任を負うための根拠にはなりません。差し戻しを減らすには、聞かれそうな項目に出典つきで答えられる状態を先に作ることです。

そこでこの記事では、確認項目の並びをIPAの公開資料にそろえます。IPAが公開している「中小企業のためのクラウドサービス安全利用の手引き」に、「クラウドサービス安全利用チェックシート」という15項目があります。手引きは、責任の持ち方についてこう書いています。

「クラウドサービスのセキュリティはサービスを提供する事業者と利用者との両者が、それぞれの役割・責任を分担し、必要とされる対策を実施することで維持・向上します。」

この記事は、その分担を「資料の出どころ」の側から整理し直したものです。IPAは15項目を「選択するとき」「運用するとき」「セキュリティ管理」のⅠ〜Ⅲに分け、「※No6,11,12,13はスマートSMEサポーター（認定情報処理支援機関）の開示情報で確認できます。」と注記していますが、事業者／自社／両方の3分類はありません。この3分類はjisalab編集部の整理です。

手順①：チェックシートの項目を、自社の決裁様式に写す

最初にやるのは、資料集めではなく様式づくりです。様式を一から作る必要はありません。IPAの手引き(全8ページ)の3ページ目に、チェックボックス付きのチェックシートがそのまま載っています。4ページ目以降は、項目ごとの「解説編」です。

ただし、IPAのシートはチェックボックスだけなので、そのままでは「確認した」としか残りません。自社の様式には、下の表の1列目を行として写し、「誰が埋めるか」(表の〔区分〕)、「根拠(URL・資料名)」「確認日」の3列を足します。あわせて、行ごとに「どこまで書けば決裁に出せるか」を決めておくと、手順②〜④で迷いません。

「両方」の4項目は、1つのセルに事業者側と自社側を分けて書きます。No.14・15は資料の出どころで〔事業者〕にしていますが、署名者や個人データの扱いなど自社側の判断も要ります(編集部)。

「根拠」の列に、何をどう書くか

いちばん迷うのが根拠の書き方です。「確認した」ではなく「どこで確認したか」を書きます。下は、編集部がSlackを例に実際に埋めてみた記入例です。

自社の行(No.3・4)の規程名・条番号は架空です。埋まらなかった欄は空欄にせず、「未確認」「一部確認」と、次に開く資料名を書きます。空欄は見落としに見えます。

手順②：事業者の公開ページで埋まる欄を埋める

決裁で使える事実は、事業者の「コンプライアンス」「セキュリティ」「トラストセンター」といったページにあります。Slackの日本語のコンプライアンスページは、冒頭付近で「セキュリティやプライバシーに関するアンケートに記入するのに必要な情報を見つけるために、サポートが必要ですか？」と呼びかけ、資料を1ページに集めています。

同ページには、ISOの証明書のようにその場でダウンロードできるもの、SOC 2(第三者の監査人が内部統制を評価した報告書)の写しのようにフォームで請求するもの、アカウントチームを通してしか出ないもの(オーストラリア政府向けの評価制度IRAPの報告書など)が混ざって並びます。この3段階は編集部の整理です。見落としやすいのは、同じページでSOC 3レポートがその場でダウンロードできることです。公開しているかは事業者によります(Notionは報告書の写しをTrust Centerで案内しています)。

監査報告書は、対象期間・対象の基準・利用者側の統制を確認する

当日取得したSlackのSOC 3は、監査人の報告書、Salesforce社の経営者による主張、システムの範囲の説明、利用者側に求める統制の一覧で構成されていました。確認するのは次の3点です。対象期間と対象の基準は1枚の中段に写し、利用者側の統制は自社側の欄に回します。

• 対象期間: 2024年11月1日〜2025年10月31日。確認日(2026年9月21日)時点で終了から約11か月です。報告書自身が、結論を将来に当てはめると統制が不十分になっているおそれがある、と断っています
• 対象の基準: セキュリティ・可用性・機密保持の3つ。同じ基準群にある処理のインテグリティ(処理が完全・正確であること)とプライバシーは含まれていません。クラウド基盤などの再委託先(subservice organizations)のサービスも監査の対象外です
• 利用者側の統制: 報告書は、サービスが利用者側で一定の統制を実施する前提で設計されているとし、利用者が実施すべき統制を一覧にしています(手順③で使います)

なお、報告書の表紙には無断での使用・複製・配布を禁じる表示があります。社内回覧の扱いに迷う場合は、PDFを稟議に貼らず、所在のURLと確認日を書く形にします(編集部)。

プランと補償の条件を、先に開いておく

認証やセキュリティ機能は、上位プラン限定のことがあります。Notionのセキュリティページは、SSO(SAML 2.0。社内の認証基盤で一度ログインすれば各サービスに入れる仕組み)、SCIMによるユーザー管理(入退社に合わせてアカウントを自動で作成・停止する仕組み)、監査ログを、Enterpriseの管理者ができることとして挙げています。稟議に「SSOあり」と書いて決裁が下りたのに、契約するプランでは使えなかった、という戻り方を防ぐため、判定表のNo.9・10はプラン名つきで書きます。

稼働率の保証も、保証値だけでは足りません。Notionのセキュリティページは「Notion offers a guaranteed uptime of 99.9%」と書いています。リンク先のService Level Termsを開くと、99.9%は休日・週末と予定メンテナンスを除いた月次の計測で、Notionの管理外の事由(不可抗力を含む)による停止も除かれます。補償は、30分以上続く停止1回につき購読料の5%のクレジットで、停止が1時間を超えること、1日1回までであることが条件です。

停止時間は利用者が停止に気づいた時点から数え、72時間以内に書面で通知しなければ受け取る権利を失います。クレジットは現金に換えられず、月内の累計で購読料1週間分が上限、充当は停止が起きた月に限られます。このクレジットが唯一の救済手段とされ、適用プランの記載はこのページにはありませんでした。「99.9%保証」とだけ書くと、止まったときに補償を取り逃します。

手順③：自社しか書けない欄を書く

手順②で取ったSlackのSOC 3は、利用者が実施すべき統制を一覧にしています。自社の災害復旧・事業継続の計画、セキュリティ設定、アカウントの管理、情報分類ポリシーなどが並び、うち6件はIPAの自社側・「両方」の項目に対応づけられます(下図。抜粋と対応づけは編集部)。決裁者に「事業者は監査を受けているのに、なぜ自社の欄が要るのか」と聞かれたら、この一覧が答えになります。

自社側の欄は、書ける人が決まっています。先に割り当ててから集めると、手戻りが減ります。

• 現場リーダー: No.1(どの業務で利用するか)とNo.8(利用者の範囲)。No.2の候補比較は、選定した担当者が書きます
• 経理・管理部門: No.3(情報の重要度)とNo.4(自社ルールとの矛盾)。顧客から預かった情報を社外に置けるかは、規程と取引先との契約の両方を見ます
• 情シス: No.7(管理担当者)と、「両方」の自社側(認証、バックアップ、社内のサポート窓口)。あわせて事業者への照会の窓口

15行の様式とは別に、決裁者には1枚を出す

15行の表は情シスの作業表です。部長や管理部門が読むのは、結論と残っているリスクの1枚です。下の雛形の括弧を自社の内容に置き換えてください。A4で1枚に収まる分量が目安です。

「セキュリティは大丈夫か」への答えは、中段ではなく下段に書きます。残っているリスクを自分から出し、期限と代替策を添えて判断を求める形にすると、差し戻されにくくなります(編集部)。

手順④：請求・照会が要る欄を、期限を付けて出す

手順②で「すぐ取れる」段に入らなかった欄が、ここに残ります。請求先は資料によって違う(フォーム／アカウントチーム／サポート)ので、同じ窓口に出すものをまとめ、いつまでに必要かを添えます。

• SOC 2など、請求が要る監査報告書(No.5): 受領までの日数を聞き、決裁日から逆算します。日数が読めないなら、SOC 3で出して受領後に差し替えます
• 解約時のデータの扱い(No.13): 返却と削除の期限が、どの文書のどこに書かれているかを示してもらいます。Slackの場合、DPAの書式は手順と期限を別文書に委ねていました
• DPAの締結(No.14): SlackのDPAページは書式へのリンクを置き、「以下のリンクを使用して本契約を権限ある人物に実行してもらってください。」と案内しています。署名を今回の稟議に含めるか、別の決裁にするかを先に決めます(編集部)
• サポートの対応時間と言語(No.12): 説明資料は、サポート受付時間(週末夜間も受付可能か)、連絡方法、料金を確認の観点に挙げています。海外SaaSでは時差が直接効きます

どこに時間がかかるのか(試算)

前提は「導入したいSaaSは決まっていて、稟議の様式はあるが、安全性の確認項目が定まっていない」状態です。2件目以降は、様式ができているぶん手順①を省けます。

いちばん長いのは手順③で、文面を書く時間ではなく関係部署と合意する時間です。監査報告書の受領を待つ日数と、DPAの署名にかかる日数は含んでいません。手順④で確認し、別にスケジュールへ入れます。

つまずきやすい点

• 認証名を並べただけで終わる: 「SOC 2取得済み」と書いても、報告書を見せられなければ確認したことになりません。入手経路(その場でダウンロード／フォーム／営業経由)まで記録します
• 無料プランで試し始めたから決裁は要らない、と考える: 料金が発生しなくても、扱う情報の重要度と自社ルールとの矛盾は同じように問われます(進め方はSaaS選定・導入の進め方)
• 「両方」の4項目を、事業者に丸投げする: とくにNo.9(認証)とNo.10(バックアップ)は、事業者が機能を用意していても、設定と運用は自社の責任です。IPAの説明資料もバックアップについて、拡張機能があれば使う、社内のストレージにも取る、複数世代を取る、を例に挙げています(設定の進め方はSaaSのセキュリティ設定を固める手順)

よくある質問(FAQ)

あわせて読みたい