Required reviews are merge controls that block code changes until one or more authorised reviewers approve them. They reduce the risk of self-approved or untested changes reaching production. In audit practice, they demonstrate that code passed an explicit approval step before implementation, which is central to change governance.
Expanded Definition
Required reviews are a governance control applied to source code, infrastructure-as-code, and configuration changes so that a merge cannot proceed until an authorised reviewer has approved it. In practice, the control separates code authorship from code acceptance, which helps prevent a single individual from introducing risky, incomplete, or unauthorised changes into production. Within software delivery pipelines, required reviews usually sit alongside branch protection, signed commits, status checks, and approval thresholds.
The term is straightforward, but its implementation is not. Definitions vary across vendors and platforms, especially around what counts as an “authorised” reviewer, whether self-approval is blocked, and how many approvals are needed for higher-risk repositories. For governance purposes, NHI Management Group treats required reviews as a control that must be both enforceable and auditable, not merely a workflow preference. That aligns well with the change-management intent reflected in the NIST Cybersecurity Framework 2.0, where controlled change and accountability are central themes.
The most common misapplication is treating required reviews as a checkbox setting, which occurs when organisations allow bypasses, weak reviewer assignment, or informal approvals outside the protected merge path.
Examples and Use Cases
Implementing required reviews rigorously often introduces delivery friction, requiring organisations to weigh release speed against the assurance gained from a second set of eyes.
- A production branch is configured so that no pull request can merge until two code owners approve the change, ensuring that risky application logic is examined by qualified maintainers.
- An infrastructure-as-code repository requires security review before Terraform changes are merged, reducing the chance that a permissive network rule or overbroad access policy reaches live systems.
- A regulated team uses required reviews to prove that emergency fixes were still reviewed after the fact, preserving audit evidence even when the deployment window was compressed.
- A CI pipeline blocks merges until tests pass and an authorised reviewer approves, which prevents “approved but untested” changes from bypassing technical checks.
- An engineering organisation aligns merge approval rules with change governance expectations in the NIST Cybersecurity Framework 2.0 and internal policy, so review authority matches the risk of the repository.
Why It Matters for Security Teams
Required reviews matter because they create a defensible approval trail for changes that could alter security posture, availability, or compliance status. When teams mismanage the control, the failure mode is often subtle: a trusted developer can merge insecure code, an unreviewed dependency update can expand attack surface, or a rushed hotfix can introduce a vulnerability that survives into production. Security teams rely on this control to reduce insider risk, limit accidental misconfiguration, and support evidence collection during audits and investigations.
The control is especially relevant where software changes affect identity systems, secrets handling, privileged access workflows, or agentic AI integrations. If a merge can alter authentication logic, token scope, or an agent’s tool permissions, required reviews become part of the organisation’s control plane rather than a simple engineering preference. That is why NHI Management Group treats review enforcement as a governance issue as much as a development one. Organisations typically encounter the real cost of weak review controls only after a bad merge reaches production, at which point required reviews become operationally unavoidable to contain the damage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Change management and approval discipline support controlled system modifications. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration change control requires authorised review and approval before implementation. |
| ISO/IEC 27001:2022 | A.8.32 | Change management controls call for review and approval of changes to information processing facilities. |
| NIST AI RMF | Governance and oversight apply when AI-related code changes can alter model behaviour or tool access. | |
| OWASP Agentic AI Top 10 | Agentic systems need review of changes that affect tool permissions, autonomy, and execution paths. |
Require documented approval before merges that change production systems or security settings.
