The deployment path is defined by configuration committed to the repo

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.

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.

• ID: deployment-config-in-repo
• Severity: low
• What to look for: This is an evidence-pointer check: it measures whether the deployment path is defined by files committed to the repo, not whether deploys succeed. Enumerate four evidence classes. (1) CI deploy: .github/workflows/*.yml jobs or steps invoking vercel deploy / vercel --prod, netlify deploy, flyctl deploy / fly deploy, gcloud run deploy / gcloud app deploy, eb deploy, aws ecs update-service, kubectl apply, helm upgrade, actions/deploy-pages, or a docker push followed by a deploy command; .gitlab-ci.yml with a deploy stage; deploy jobs in Jenkinsfile or .circleci/config.yml. (2) Platform config at the repo root: vercel.json, netlify.toml, fly.toml, render.yaml, app.yaml (Google App Engine), amplify.yml, railway.toml / railway.json, apprunner.yaml, Procfile (Heroku-style). (3) Container path: Dockerfile PLUS at least one orchestration manifest referencing the app image (docker-compose.yml / compose.yaml, k8s/**/*.yaml or kubernetes/**/*.yaml, Helm Chart.yaml). (4) IaC deploy resources: *.tf declaring resources the app runs on (aws_ecs_service, google_cloud_run_service, vercel_project), serverless.yml, sst.config.ts, a Pulumi program, or a CDK app. These file surfaces are language-independent: Django, FastAPI, Flask, and Go HTTP servers use the same platform configs, workflows, and manifests, so do not mis-skip a non-JS repo just because package.json is absent. Separately, establish deployability for the fail branch: a framework app (next, nuxt, remix, @sveltejs/kit, astro in dependencies; an express / fastify / koa server entrypoint; Django manage.py / wsgi.py; a FastAPI or Flask app module; a Go main.go starting an HTTP server) with production markers (a build script, .env.production or NODE_ENV === 'production' references, or a README describing a live URL). For every candidate artifact, open it and quote the deploy step, config key, or resource block — never credit a filename you did not read.
• Pass criteria: Any ONE evidence class is present and real: (a) a CI workflow containing an actual deploy step (a command or action that pushes to a hosting target, not just build/test), (b) a platform config file from the list at the repo root that is valid for its platform (a minimal vercel.json counts: its presence pins the platform in git), (c) Dockerfile plus at least one orchestration manifest referencing the app image, or (d) IaC files declaring the resources the app runs on. Do NOT pass on a filename alone: an .example / .template file, an empty or placeholder-filled config, or a workflow whose deploy step is commented out or gated behind if: false does not count as pass.
• Fail criteria: The repo is a deployable production app and none of the four evidence classes exists. Fail the sneaky variants too: CI workflows that only lint, test, and build with no deploy step; a deploy job that is commented out or gated behind if: false; a package.json "deploy" script that is an echo stub or TODO; a Dockerfile with no orchestration manifest and no platform config anywhere (the image is defined but its path to production is not); a platform config that is an unadopted template (.example / .template suffix) or contains unfilled placeholders like {{PROJECT_NAME}}.
• Skip (N/A) when: The repo is a library, CLI, or published package that is not deployed: package.json has a bin field or publishing markers (files plus main / exports) with no web framework dependency and no server entrypoint; or a pyproject.toml / setup.py declaring a distributable package with no app entrypoint; or a Go module that builds a CLI binary only. Quote: "Library/CLI/package repo (publishing markers, no web framework or server entrypoint); nothing is deployed".
• Before evaluating, quote: On pass, the path of the deploy artifact plus the 1-3 lines showing the deploy step, the platform config key, or the IaC deploy resource. On fail, quote the evidence that the app is a deployable production app (the framework dependency line, server entrypoint path, or build script) and name the deploy-config locations searched. Never pass on a filename alone without confirming it is not a stub or template.
• Report even on pass: "Deploy path evidenced by <path>: <ci-deploy-job | platform-config (vercel/netlify/fly/render/...) | dockerfile+orchestration | iac>".
• Detail on fail: "Next.js app with a production build script, but no deploy workflow, platform config (vercel.json, netlify.toml, fly.toml), Dockerfile+orchestration, or IaC is committed. If you deploy via Vercel git integration, commit a vercel.json so the deploy path is evidenced in the repo." or ".github/workflows/ci.yml runs lint and test only, the deploy job is commented out, and no platform config exists. Commit evidence of the real deploy path: re-enable the deploy job or add the platform config file."
• Remediation: Commit the config your platform already honors: a minimal vercel.json at the repo root (even just { "framework": "nextjs" }), netlify.toml, or fly.toml; or add a deploy job to .github/workflows/deploy.yml running your platform CLI. If you ship containers, commit the compose file or Kubernetes manifest beside the Dockerfile. The platform keeps deploying via git integration; the committed file is the auditor-ready CC8.1 evidence.