【Vanta導入企業向け】Integrationの設定について
自動テストを活用するための実務ポイント
コラム「【Vanta導入企業向け】内部統制整備とエビデンス収集について」でも触れたとおり、VantaはAWS、GitHub、MDMツール、EDRツールなど、情報セキュリティに関わる各種サービスと連携（インテグレーション）することで、自動テスト（Automated Test）を実行し、内部統制の有効性を検証します。
この仕組みはVantaの大きな強みですが、インテグレーションの設計や運用を誤ると、かえって作業が煩雑になったり、監査対応で混乱を招く原因となります。本記事は、インテグレーション作業のポイントを整理します。
範囲は「過不足なく」が原則
インテグレーションで重要なのは、単にツールを接続することではなく、「どこまでをSOC2の対象とするか」を設計することです。
範囲が広すぎる場合、SOC2の対象外となる環境やリソースまで含まれてしまい、自動テストの結果として大量の指摘が発生し、不要な対応が増えます。一方で、範囲が狭すぎる場合には、本来対象とすべき統制がカバーされず、後から監査法人による追加指摘や再対応が発生します。
いずれの場合も、問題はツールではなく、「どこまでを対象とするか」という設計の不備に起因します。
自動テストの対象と除外（deactivate）の考え方
ツールとのインテグレーションが完了すると、Vantaは自動的に各サービスから情報を収集し、設定されたルールに基づいて各統制項目のテストを実施します。たとえば、AWSを連携した場合、次のような構成要素がすべてテスト対象になります：
- EC2
- DynamoDB
- CloudWatch Logs
- ECR
- IAM
- ALB 等
その結果、Vantaのダッシュボード上には、各種テストにパスしていない箇所が表示されます。ここで重要なのが、すべてを実際に改善しなければならないわけではないという点です。中には以下のような理由でテスト対象から除外（deactivate/scope out）すべきものもあります：
- ステージング・開発環境：本番環境以外はSOC2の対象外となるため、インテグレーションのScopeの段階で除外対象とするのが一般的です。
- 誤検知や特殊な運用上の理由：システム設定上問題がないにもかかわらずエラーと判断される場合や、要件に合致しないが補完統制が十分備わっている場合等、合理的な説明があれば除外可能です。
除外する場合には合理的な説明が不可欠
ただし、テスト対象から除外（deactivate）した内容やその判断の妥当性は、監査法人の確認対象になります。除外の根拠や背景を適切に説明できなければ、監査時に再対応を求められる可能性があります。
したがって、以下のような対応を取ることが望ましいでしょう：
- 除外の前に社内で十分に理由とリスク評価を整理する
- 必要に応じて監査法人と事前に相談・合意形成を行う
- 除外理由を記録する
事前のすり合わせがすべてを決める
インテグレーションの設計や除外の判断は、後から修正することも可能ですが、その場合は手戻りが大きくなります。スコープの設定や除外の考え方、自動テスト結果の扱いといった前提については、監査法人とのプレ評価段階で方向性を確認しておくことが重要です。ここが曖昧なまま進めると、「なぜこの範囲なのか」「なぜ除外したのか」といった説明を後から求められ、結果として対応コストが増加します。
まとめ
Vantaの自動テストは強力な仕組みですが、「接続すれば自動で最適化される」ものではありません。インテグレーションの範囲設定や除外の判断、テスト結果の扱いといった点については、いずれも設計と判断が求められる領域です。これらを整理せずに進めると、不要な対応の増加や監査対応の長期化につながる可能性があります。
特に重要なのは、プレ評価の段階から監査法人に対して前提や状況を早めに共有しておくことです。監査法人は指摘を行う存在ではありますが、対立する相手ではなく、適切な水準を見極めるために前提を共有すべき相手でもあります。初期段階から認識を揃えておくことで、後工程での差戻しや手戻りを避けることができます。
本記事が、Vantaのインテグレーションを適切に設計・運用する上での参考となれば幸いです。