The deployment path is defined by configuration committed to the repo
Why it matters
SOC 2 CC8.1 requires that changes to infrastructure and software reach production through an authorized, repeatable path, and the first thing an auditor traces in the change-management section is "show me how a merged change becomes a deploy." This is an evidence-pointer check: it verifies committed evidence of the deployment path (a CI deploy job, a platform config file like vercel.json, a Dockerfile with orchestration, or IaC), which is what an auditor will ask for. It does not claim to see dashboard state. AI-built and vibe-coded apps fail this by construction: the standard flow is clicking "import repo" in the Vercel or Netlify dashboard, after which the platform deploys every push while the repo itself carries zero record of how production comes to exist. The deploy works, but when an auditor, a new engineer, or an incident review asks "what config governs this deploy," the answer lives only in a dashboard nobody can diff, review, or roll back through git. Committing the config file the platform already supports turns an invisible deploy path into reviewable, versioned evidence.
Severity rationale
Low because platform git integration (a Vercel or Netlify dashboard connected to the repo) is a legitimate, controlled deploy path that is invisible from the repo, so a fail here usually means missing committed evidence of the path rather than an actually ad hoc deployment.
Remediation
Commit the configuration your platform already honors: a minimal vercel.json at the repo root for Vercel, netlify.toml for Netlify, fly.toml for Fly, or a deploy job in .github/workflows/deploy.yml that runs your platform CLI. Even a minimal file pins the deploy path in git:
{
"$schema": "https://openapi.vercel.sh/vercel.json",
"framework": "nextjs"
}
If you ship containers, commit the compose file or Kubernetes manifest beside the Dockerfile so the image has a committed path to production. The platform's git integration keeps doing the actual deploying; the committed file is the CC8.1 evidence an auditor traces when asking how a merged change ships.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the SOC 2 Technical Readiness Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- soc2:2017 · CC8.1 — Changes to infrastructure and software are authorized, tested, approved, and implemented
- iso-27001:2022 · A.8.32 — Change management
- nist:rev5 · CM-3 — Configuration Change Control
Taxons
History
- 2026-07-03·v1.0.0·Initial soc2-readiness v1 authoring; evidence-pointer check that the deployment path (CI deploy job, platform config file, Dockerfile plus orchestration, or IaC deploy resources) is committed to the repo per SOC 2 CC8.1.·by soc2-readiness-v1-build