SOC2は、取った瞬間よりその後が面白い

SOC2ゆるミートアップ#2 - SOC2取得対応経験者LT会のスライドです。
https://security-compliance.connpass.com/event/373192/

Transcript

1. SOC 2は、 取った瞬間より その後が面白い 整うのを待たずに前へ。SOC 2を “走りながら育てる” という選択 2026/1 ひまわり
2. 今日のゴール 2 TODAY’S GOAL 整備途上でも、説明できる運用を積み上げれば 確実に前に進めると知ること 今年、SOC2準備を 動かす人が増えたら嬉しい 監査要求を現場に落とす 「３つの型」を持ち帰る
3. 自己紹介 3 SELF INTRODUCTION 社内IT（企画／構築／運用／管理） 20年以上 現職： 情シス＆CSIRT立ち上げ中 システムや組織が ”ちゃんと回り始める瞬間“が好き ひま （X: @3flowerxxxxx)
4. なぜSOC 2が必要だったか 4 WHY SOC2? 海外エンプラ展開 × SaaS では もはやデファクトスタンダード 持っていないと、 そもそも商談の入口に立てない 取得は前提。 論点は「やる／やらない」ではなく、「どう作るか」だった
5. 5 すべてが整うのを 待てないフェーズ 短いサイクルで拡大し続けている
6. SOC2 進行、そしてIT基盤整備が同時進行 6 TIMELINE IT基盤整備 SOC2 進行 T0 Type1レポート受領 T+3 Type2 監査期間開始 アカウント管理 自動化 T-6 GRCツール導入 T-2 監査法人契約 デバイス管理 自動化 監査期間 監査準備 ドキュメント修正・証跡収集 端末刷新 モバイル管理強化 T-7 IT基盤刷新 監査期間 セキュリティルール改修 システム設定チューニング 例外ルール回収 Now
7. 統制項目は全社横断、監査対応は２人 7 ROLES/ OWNERSHIP プロダクト（開発・SRE） データ保護、暗号化、NWセキュリティ、バックアップ、ログ管理、バージョン管理、コー ドレビュー、テスト、脆弱性管理、ペンテスト、災害復旧訓練、インシデント対応訓練 社内IT／セキュリティ リスク評価、データ分類、ID管理、デバイス管理、PCのセキュリティ、セキュリティ教育、 ベンダー管理 人事 組織図、雇用契約、従業員評価プロセス、服務規律とセキュリティ規定の接続 法務 サービスの利用規約、プライバシーポリシー、委託条項、開示請求依頼等の手続き セールス／マーケ 顧客情報管理プロセス 内部監査 統制の有効性確認、サンプリング、是正措置フォロー 経営 リスク報告、サイバーセキュリティ対策報告、事業継続計画 情シス （私） SRE （1名） 統制項目 関連部門 監査対応
8. 本題：監査要求を運用に落とす３つの型 8 CORE FRAMEWORK 意思決定を設計する 議論を止めないための翻訳 約束を設計する 約束と実態をズラさないための表現調整 進化の順番を設計する SOC 2を走りながら育てる
9. 型❶：議論を止めないための翻訳 9 意思決定を設計する 専門用語のままだと、 経営層の意思決定が止まる 相手が決められる粒度に落とす 提示順序： 監査要件 → 施策オプション → 判断軸
10. 型❶テンプレ：議論を止めない構造 10 意思決定を設計する 翻訳 A or Bにする 判断軸 監査用語→社内用語 Yes / Noで迫らず、選択肢を作る TSC→評価基準項目 Control → ルールと運用 案A：最小実装 まずは手動・既存ツールで対応 案B：将来拡張 自動化・新ツール導入前提 迷ったときの基準 将来不足しない？ 後から追加コストは？ 説明責任を果たせる？ その場で方針が決まる状態を作る
11. 型❷：約束と実態をズラさないための表現調整 11 約束を設計する 監査コメントが来ると、社内は 「その指摘、正しいの？」という議論で止まる 監査対応は正誤判定ではなく 指摘を「どう着地させるか」の調整 論点を固定して、自社が確実に 「守れる約束」に落とし込む
12. 12 受け入れるのか 根拠を示して拒否するのか 表現調整で折り合うのか SOC 2監査指摘の論点は 正誤 ではない 議論を「勝ち負け」から「守れる約束の設計」に戻す
13. 型❷：着地の実例（本文＋カバーレター） 13 約束を設計する 「守れる表現」に落とす 例：障害通知の約束 法務の視点 必ず通知しなければならないという「契約不履行リスク」を回避 「障害発生時は、顧客に通知する」 「障害発生時は、影響範囲を考慮し、 適宜顧客へ通知する」 法務の守り（言い切り回避）と、監査の守り（意図明確）を両立 カバーレター 意図・根拠を補強する 本文（公開文書） 「適宜」の運用定義を明示 監査の視点 裏付けとなる運用ルールが存在することを明確にする ✓ 重大な障害の場合に通知を行う ✓ 軽微なメンテナンスは対象外とする ✓ ステータスページへの掲載をもって通知とみなす
14. 型❸：SOC 2を走りながら育てる 14 進化の順番を設計する 進化の順番を設計する 運用フローはType 1で固定済み 実装を育てる 統制（ルール）は守り、 実装を段階的に置換する
15. 型❸：進化の３レール 15 進化の順番を設計する 個別→標準 手動→自動 RAIL１ Before スプレッドシート管理 台帳への入力・更新 暫定→恒久 まず運用で守り、あとで仕組み化 After 管理DB／ツール導入 自動同期・自動収集 システム化 RAIL２ Before 例外申請 Slack承認時の個別ログ 個別 → 標準 例外を許容し、徐々に標準へ After 標準ワークフロー 例外フローの廃止・統合 標準化 個別→標準 RAIL３ Before 四半期ごとの棚卸し 目視チェック・証跡保存 手動 → 自動 統制目標は変えず、手段を置換 After 継続的な自動監視 異常検知アラートのみ対応 実装置換 統制自体は変えず、実装だけを進化させるという設計にする
16. まとめ 16 SUMMARY & KEY TAKEAWAYS 議論を止めないための翻訳 監査要件を社内言語に落とし、意思決定を設計する 約束と実態をズラさない表現調整 無理な約束を避け、守れる約束を設計する SOC 2を走りながら育てる 暫定から恒久へ。進化の順番を設計する SOC 2は、 取った瞬間より その後が面白い 完璧を待つのではなく、 「説明できる運用」を積み上げていく。