Buyers ask who can deploy to production because anyone who can change what ships can change what runs on their data. Show a short list of people and service accounts with deploy rights, the approval rule that gates a release, and a deploy log that ties each release to a reviewed change.
The question behind the question
Supply chain attacks often target the build and release path, not the product code. A reviewer wants to know whether one stolen laptop or one over-privileged account could push malicious code. Your answer should show that no single person or token can do that unseen.
What to show
| Evidence | What it proves |
|---|---|
| List of humans with deploy rights, with roles | Access is limited and known |
| List of service accounts and tokens that can deploy | Automation is inventoried |
| Branch protection and required review settings | Code is reviewed before it can release |
| Deploy log with commit and approver | Each release traces to a reviewed change |
| Last access review date | Access is rechecked |
Export these on a schedule and keep them with your evidence pack.
Three common weak points
Shared credentials. One deploy login used by the whole team makes it impossible to say who did what. Move to individual accounts and give automation its own identity.
Long lived secrets in CI. If your pipeline stores a cloud key that never expires, a leak is serious. GitHub's documentation on OpenID Connect explains how a workflow can request a short lived token instead, so you avoid duplicating cloud credentials as long lived secrets. Other platforms offer the same approach. See our guide to explaining OIDC to buyers.
Admin bypass. If administrators can skip review rules, say whether that is logged and who holds that role. Many teams leave bypass on without noticing.
Separation of duties for a small team
A five person startup cannot have a separate release team. You can still add friction:
- Require a review from someone other than the author.
- Use a protected environment so deploys need an approval.
- Keep production credentials out of developer laptops.
- Alert on deploys outside business hours or from unusual accounts.
State what you do, not what a larger company would do. A small team that applies two or three of these consistently answers the question well.
Contractors and former staff
Include them in the review. Check that departed staff and ended contractors lost access on their last day. Reviewers ask this often, and a dated offboarding record answers it.
Wording the answer
"Production deploys run from CI after a reviewed pull request merges to the default branch. Four engineers can approve a release. No individual holds standing production credentials. We review deploy rights quarterly and can share the last review." Replace each statement with your own facts.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how checks and review stand between a change and the main branch, which is the control a deploy log relies on.
Safeguard policies and gates can block pull requests that fail your rules, and its agent identity feature helps give automation a distinct identity. Try a free scan to start.
Quick check
Is a deploy log enough on its own?
No. It shows what happened, not who was allowed to do it. Pair it with the access list and review rules.
How often should we review deploy access?
Quarterly is common, and also whenever someone leaves or changes role.
Sources
Last reviewed: 19 October 2026.
