← エピソード一覧に戻る Episode 142 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― なぜ初期SaaSでも審査で止まるのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 立ち上げのセキュリティ最低ラインを扱います。G2 は 2024 年の買い手行動で、97% が購買時にセキュリティ担当者を関与させたと示しました。つまり、まだ小さい会社でも避けて通れない論点なんです。
ミカ
ミカです。97% って、ほぼ全件じゃないですか。創業初期だと、まずは機能と営業で走るイメージでしたけど、実際は『安全に使えるか』で止まる案件がかなり多いんですね。
タカシ
その通りです。しかも G2 は、セキュリティ情報を載せたベンダープロフィールは buyer conversion が最大 16% 高かったとも述べています。セキュリティは守りだけでなく、受注率に効く営業資料でもあるわけです。
ミカ
なるほど。今日は『完璧なエンタープライズ対応』ではなくて、次の 10 社を審査で止めないための最低限を知りたい、という回なんですね。そこなら創業者でも現実的に動けそうです。
タカシ
はい。ポイントは六つです。認証、権限管理、監査ログ、バックアップと復旧、インシデント対応、そして DPA やサブプロセッサ一覧のような法務・データ管理。この順で見ると、必要な投資がかなり整理しやすくなります。
Chapter 2 基本 ― 最低ラインは認証より運用証拠
タカシ
まず定義です。セキュリティ最低ラインとは、SOC 2 を今すぐ取ることではありません。顧客の管理者や法務が『このベンダーなら社内説明できる』と言えるだけの運用証拠を揃えることです。口約束ではなく、設定と手順で見せる状態ですね。
ミカ
ここでいう運用証拠って、チェックリストが埋まることに近いですか。たとえば、誰が入れて、誰が見られて、何かあったら追えて、抜けるときは消せる、みたいな基本動作が説明できるかどうか。
タカシ
まさにそこです。Vercel は公式に RBAC を示し、役割ごとに何ができるかを整理していますし、2025 年 6 月にはチーム単位で 2FA を強制できるようにしました。つまり最低ラインとは、便利な機能より先に、アクセスの入口と鍵の配り方を整えることなんです。
ミカ
会社のオフィスで考えると分かりやすいですね。正面玄関に鍵があるだけじゃ足りなくて、金庫室の鍵は誰が持つのか、退職者のカードはいつ止めるのかまで決めないと、不安は消えないわけだ。
タカシ
そうです。だから初期 SaaS でも、管理者アカウントの MFA 必須化、役割ごとの権限分離、外部委託先や退職者の即時停止、この三つは先に押さえたい。ここがないと、後で機能を増やしても信頼の土台が弱いままです。
Chapter 3 実装 ― RBAC、監査ログ、バックアップ
タカシ
次に、審査票で効きやすい三点セットが RBAC、監査ログ、バックアップです。Linear は監査ログを直近 3 カ月保持し、Vercel も 90 日間の監査ログをエクスポート可能にしています。誰が設定変更したか追えるだけで、管理者の安心感はかなり違います。
ミカ
小さいチームだと『みんな顔が見えてるからログはいらない』と思いがちですけど、むしろ逆ですね。人数が少ないほど、問題が起きたときに誰も覚えていない、という地味な事故が起きそうです。
タカシ
その通りです。さらに Atlassian は、SIEM による集中監視、30 日の hot backup と 365 日の cold backup、日次バックアップ、四半期ごとの復元テストまで公開しています。最低ラインで大事なのは、保管だけでなく復元を試しているかです。
ミカ
バックアップって、たしかに『取っています』で終わりがちですよね。でも本当に必要なのは『何分前まで戻せるか』『誰が戻すか』まで分かること。傘を持っているだけで、一度も開いたことがない感じに近いです。
タカシ
良いたとえです。加えて、異常検知から封じ込め、復旧、顧客通知までの playbook を 1 枚でもよいので作る。Atlassian は incident response playbook を明示していますが、創業者 SaaS でも『誰に連絡し、どこに記録し、いつ顧客へ伝えるか』は今すぐ決められます。
Chapter 4 契約 ― DPA、サブプロセッサ、削除フロー
タカシ
もう一つ創業者が甘く見やすいのが、法務とデータ管理です。Vercel の DPA はサブプロセッサ一覧と追加時の通知方法を公開していますし、Linear の DPA も契約終了時に顧客データを返却または削除すると定めています。ここが曖昧だと、最後に止まります。
ミカ
つまり顧客から見ると、『どこにデータがあり、誰が処理していて、やめるときどう戻せるか』まで答えがあるかを見ているんですね。たしかに、それがないと社内稟議を通す人が困りそうです。
タカシ
Attio の公開情報も分かりやすいです。Enterprise 向けに SAML SSO の設定手順を出し、管理者限定で workspace export を案内し、ワークスペース削除時は全データが恒久削除されると明記しています。これだけでも、買い手に渡せる安心材料になります。
ミカ
創業者としては、こういう資料って大型案件が見えてから作ればいいと思いがちですけど、実際はその一歩手前で必要なんですね。大きい顧客が来てから慌てると、資料待ちで四半期をまたぎそうです。
タカシ
その通りです。だから早めに、セキュリティ 1 枚資料、標準回答付きの質問票、DPA リンク、サブプロセッサ一覧、削除とエクスポート手順の五点セットを作る。これがあるだけで、営業が『確認して戻ります』を減らせます。
Chapter 5 まとめ ― 次の10社を止めない準備
タカシ
最後に要点を五つに絞ります。第一に、管理者 MFA と最小権限。第二に、監査ログ。第三に、バックアップと復元テスト。第四に、インシデント時の連絡と記録の流れ。第五に、DPA とサブプロセッサ、削除フローです。この五つが最低ラインです。
ミカ
今日の話、すごく実務的でした。セキュリティって『監査のための飾り』じゃなくて、受注を前に進める営業加速装置なんですね。創業者が嫌でも向き合うべき理由が、かなり腹落ちしました。
タカシ
皆さんが今週やるなら、自社の現状を五項目で棚卸ししてください。設定済みか、手順書があるか、顧客向けに説明できるか。この三段階で見ると、単なる『やっているつもり』がかなり見えてきます。
ミカ
そして止まっている商談があるなら、失注理由を予算や優先度だけで片付けずに、審査で詰まった論点を書き出してみると良さそうです。実は機能不足より、説明不足だった、という案件も多そうです。
タカシ
今日は、SaaS 立ち上げのセキュリティ最低ラインを整理しました。強いプロダクトでも、信頼の土台が弱ければ前に進みません。次回は PMF 前指標を扱い、何を見れば『売上より先の手応え』が分かるのかを掘っていきます。