監査人が受け入れる変更管理の証跡

SOC 2 Type II 監査では、変更管理（CC8.1）が最も集中的にサンプリングされる統制の一つです。監査人は監査期間全体から変更を抽出し、本番環境へ反映される前に、それぞれが承認、テスト、認可を経ていたことの証明を求めます。ISO 27001（A.8.32）、PCI DSS（6.5.1、6.5.2）、NIS2の実施規則（第6.4項）も、表現は異なりますが同じことを求めています。エンジニアリングチームは通常この作業自体を行っています。欠けているのは証跡です。

監査人が検証する内容

サンプリングされた変更について、監査人は次の点を確認したいと考えています。

1. 変更が要求され、内容が記述されていること：何を、なぜ変更するのかを示すチケットまたはプルリクエストがあること。
2. 作成者以外の者がレビューしていること：職務分掌。
3. 本番環境に反映される前にテストされ、その結果があること。
4. デプロイの前に承認されていること。
5. デプロイされたものが承認されたものと一致すること：レビューされていないコードが本番環境に到達していないこと。
6. 母集団が完全であること：インフラストラクチャや設定を含め、すべての本番環境の変更がプロセスを経ていること。

有効な証跡

• ブランチ保護：メインブランチでは、マージ前に作成者以外による承認レビューを少なくとも1件と、合格したチェックを必須とすること。設定をエクスポートし、期間中に変更されていないことを示してください。
• パイプライン経由のみのデプロイ：本番デプロイは、保護されたブランチからCI/CDを経由してのみ行われ、エンジニアが直接プッシュできないこと。
• 紐付けられた記録：各デプロイが、マージされたプルリクエストに紐付き、さらにそのプルリクエストがチケットに紐付いていること。
• 同じルールで管理されるInfrastructure as Code：インフラストラクチャの変更も同じ証跡を残すこと。
• デプロイツールから出力した期間内の完全な変更一覧：監査人がここからサンプリングできること。

緊急変更

すべてのプロセスにはインシデント対応のための迅速な経路が必要であり、監査人もそれを期待しています。その経路を定義してください。誰が承認できるか、事後レビューをどれくらい迅速に行うか（1〜2営業日以内が一般的です）、そして変更をインシデントにどう紐付けるかを明確にします。そのうえで、緊急変更が本当に例外的な存在にとどまっていることを確認してください。

監査で不備となるケース

• 本番環境への直接アクセス権を持つ管理者が、時折パイプラインを迂回すること。
• 自己承認されたプルリクエスト、またはボットによるレビューのみのもの。
• 記録のないコンソールで行われた設定変更。
• 期間中にブランチ保護を「一時的に」無効化すること。
• 「CIが合格した」以上のテスト証跡がないこと（変更にはそれ以上の検証が必要だった場合）。

サンプリング：監査人が実際に行うこと

SOC 2 Type II では、監査人は通常、期間中の本番環境変更の全母集団を求め、サンプルを抽出します（サンプルサイズは母集団と監査人の方法論により異なります）。そして抽出された各変更について、要求、作成者以外によるレビュー、テスト結果、承認、およびデプロイされた内容が承認内容と一致することの証明を求めます。

これにより、実務上は次の2点が重要になります。第一に、母集団は完全であり、エクスポート可能でなければなりません。変更が複数の経路で本番環境に到達しうる場合は、経路ごとに記録が必要です。第二に、サンプリングされた変更で証跡が欠けているものが一件でもあれば、報告書で例外事項になります。監査で証跡を再構築するよりも、証跡が自動的に残るようプロセスを修正するほうが低コストです。

SOC 2 CC8.1のページでは、この管理基準がISO 27001、PCI DSS、NIS2にどのように対応するかを示しています。

一つのプロセスで、すべてのフレームワークに対応

当サイトのデータでは、変更管理の要件はフレームワーク間で関連付けられています。

方向	マッピング済み	緩やかに関連	マッピングなし
SOC 2 を保有、NIS2 が必要	49 件中 47 件 (96%)	1	1	レポート →
NIS2 を保有、SOC 2 が必要	61 件中 37 件 (61%)	0	24	レポート →

ブランチ保護とパイプライン経由のみのデプロイを伴うプルリクエストベースのプロセスは、SOC 2、ISO 27001、PCI DSS、NIS2を同時に満たします。PCI DSSには追加の要件がいくつかあります。本番前環境と本番環境の分離（6.5.3）、ライブのアカウントデータをテスト環境に持ち込まないこと（6.5.5）、重要な変更の後にセキュリティ要件を確認すること（6.5.2）です。

関連する要件については、セキュアな開発トピックを参照してください。また、SOC 2、ISO 27001、PCI DSSにまたがる証跡の再利用に関する記事もご覧ください。

よくある質問

プルリクエストは、SOC 2における変更承認として認められますか？

通常は認められます。マージ前に作成者以外によるレビューがリポジトリで強制され、承認されたコードのみがデプロイされるよう制限されており、かつ期間中の変更サンプルについてこれを示せる場合です。

緊急変更は監査のためにどのように扱うべきですか？

定義された緊急プロセスに基づき、必要に応じてまず修正を行い、その後、定められた期限内に事後レビューと承認を実施し、その変更を正当化したインシデントと紐付けた記録を残します。