Yes, they can. GitHub environments support deployment protection rules such as required reviewers, a wait timer and branch limits. Together they create a record that a named person approved a job before it ran. Check your plan, because some rules are limited to public repositories on lower tiers.
What the rules do
GitHub's documentation on deployments and environments describes these protection rules:
- Required reviewers. A specific person or team must approve jobs that reference the environment. You can list up to six users or teams, and only one needs to approve.
- Prevent self-review. Users who start a deployment cannot approve it, even if they are a required reviewer. The documentation says this ensures protected environments are always reviewed by more than one person.
- Wait timer. Delays a job by 1 to 43,200 minutes, which is up to 30 days.
- Deployment branches and tags. Restricts which refs can deploy, from no restriction to protected branches only or selected patterns.
- Custom rules. GitHub Apps can add third-party checks, with a maximum of six rules enabled on an environment at once.
The documentation notes that on GitHub Free, Pro or Team plans, required reviewers and wait timers are available only for public repositories. Confirm the rule is available for your repository type before you rely on it.
Mapping to a change control
| Control statement | Environment setting that supports it |
|---|---|
| Production changes are approved before release | Required reviewers on the production environment |
| The author cannot approve their own release | Prevent self-review |
| Only reviewed code reaches production | Deployment branches limited to protected branches |
Steps to set it up
- Create a production environment and attach your deploy workflow to it.
- Add required reviewers, two or more people so approval does not stall.
- Turn on prevent self-review.
- Limit deployment branches to protected branches.
- Run a test deployment and open the run to confirm the approval line shows who approved and when.
- Export the environment settings and a sample of approved runs on a schedule.
What an auditor still needs
The approval proves who clicked approve. It does not prove the person looked at the change. Pair it with the pull request review. Also keep your retention in mind: workflow run history is subject to the retention period, so copy samples out. See the October 2026 retention change.
Try it yourself
Click through it at your own pace, or open it full screen. See how a failed check holds a change before it moves forward.
Where Safeguard fits
Safeguard offers policies and gates, SBOM and dependency scanning, and compliance and evidence automation. Gates run before release and the result is stored as a record. Start with a free scan.
Quick check
How many reviewers must approve a deployment?
Per GitHub's documentation, only one of the required reviewers needs to approve for the job to proceed.
Can the person who triggered a deployment approve it?
Not if you enable the prevent self-review option.
Sources
- GitHub Docs: deployments and environments
- GitHub Docs: retention period for checks, workflow runs and artifacts
Last reviewed: 19 October 2026.
