What Is Required Check? Definition & Examples

A required check is a pull request control that blocks merging until a specified validation step succeeds. In this context, it ensures policy or scanning results are evaluated before code enters the main branch. Required checks are effective when they are scoped correctly and produce clear, relevant outcomes for the repository being changed.

What a required check does

A required check turns a pull request validation step into a merge gate. The branch cannot be merged until the named check succeeds, which makes policy enforcement, testing, or scanning part of the code promotion path rather than an optional review aid.

That gating role matters because it changes the status of a result from informative to decisive. A required check only protects the branch when the check is reliable, scoped to the right repository changes, and able to report a clear pass or fail state that reviewers can trust.

Where required checks fit in pull request governance

Required checks sit between code review and branch protection. They are usually paired with rules that restrict direct pushes, enforce approvals, or require all conversations to be resolved, but the check itself is the mechanism that blocks merge on an unmet condition.

In practice, teams use them for tests, linting, policy evaluation, secret scanning, dependency scanning, or deployment readiness checks. The important point is that the check should be relevant to the specific change, not just present in the repository, otherwise it becomes noise instead of control.

Why scope and signal quality matter

A required check is only as useful as the signal it emits. If the check is too broad, too slow, or unrelated to the changed code, it can delay merges without improving safety. If it is too narrow, it can pass while the pull request still introduces a real defect or policy violation.

Clear ownership also matters. When teams understand what the check covers, who maintains it, and what a failure means, the merge gate becomes easier to interpret and less likely to be bypassed informally.

How required checks differ from review comments

Review comments guide human judgment, while required checks enforce a machine-readable condition. That distinction is useful because a required check can make a minimum quality bar repeatable across contributors, repositories, and release cycles.

They are most effective when the underlying validation is deterministic and the failure message is actionable. Ambiguous or flaky checks create friction, because developers cannot tell whether the merge is blocked by a genuine issue or by an unreliable control.

Risk and Threat Considerations

Required checks reduce the risk of untested, unscanned, or policy-violating code entering the protected branch, but they can also create false confidence if the check is poorly designed or easy to satisfy with irrelevant results. A weak gate can look strong while missing the exact failure mode it was meant to stop.

Failure mechanism: The check passes on partial coverage, stale data, a non-representative test scope, or an unrelated path through the repository, so the merge gate does not actually validate the risky change.

Impact: Defects, insecure patterns, or policy exceptions can reach the main branch, and downstream releases inherit that weakness as if the control had succeeded.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8, OWASP SAMM and SLSA set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	CM-3 — Configuration Change Control	Required checks gate changes before merge into the protected branch.
	SI-2 — Flaw Remediation	Required checks commonly enforce tests and scans that catch flaws before promotion.
	CA-2 — Control Assessments	A required check can enforce assessment evidence before code promotion.
Recommendation — Require approved validation before merging code into the main branch. Use merge gates to block code until identified flaws are addressed. Gate merges on completed assessment or validation evidence.
CIS Controls v8	CIS-16 — Application Software Security	Required checks support secure software delivery by enforcing validation in the pipeline.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Branch protection settings and required checks are secure configuration controls for the delivery system.
Recommendation — Enforce automated checks before code enters protected branches. Harden branch protection by requiring the right validation checks.
OWASP SAMM	SD — Security & Defects Management	Required checks operationalize defect detection before code promotion.
Recommendation — Tie merge gates to repeatable defect detection and remediation.
ISO/IEC 27001:2022	A.8.25 — Secure development life cycle	Required checks are a secure SDLC control for validating changes before release.
Recommendation — Embed mandatory validation gates into the secure development lifecycle.
SLSA	Supply chain integrity	Required checks can enforce build and verification steps that protect artifact integrity.
Recommendation — Block merges until provenance and verification checks succeed.

Practitioner Guidance

What to watch for: Treat a required check as a control design problem, not just a repository setting. The check should map cleanly to the change it is intended to govern, and failure output should tell a reviewer what needs attention without extra interpretation.

Governance implication: If a check is frequently bypassed, renamed without updating branch protection, or left with unclear ownership, it stops behaving like a dependable merge requirement and becomes a brittle process artifact.

Required Check