Treat a pull request as a standard change if it is pre-approved, repeatable and low risk, a normal change if it needs review before release, and an emergency change if it must ship now to stop harm. Label each one, apply the matching approval path, and keep the record.
Why classify at all
If every change gets the same heavy process, people route around it. If every change gets the same light process, risky ones slip through. Classification lets you spend scrutiny where it pays. It also gives an auditor a clear rule to test against a sample of real changes.
NIST's change control requirement asks organizations to determine and document the types of changes that are configuration controlled, then review and approve them, record the decisions and retain the records. Your three classes are one way to answer the first part.
The three classes
| Class | What it is | Approval | Evidence |
|---|---|---|---|
| Standard | Pre-approved, low risk, repeatable | Approved once as a pattern, then automatic | Label, passing checks, link to the pattern |
| Normal | Anything else | Peer review plus checks before merge | Approving review, checks, ticket link |
| Emergency | Needed now to stop an outage or active harm | Fast approval by on-call lead, review after | Incident ticket, retro-review within a set time |
Deciding which class a PR belongs to
Ask these questions in order:
- Is there an active incident or exploited vulnerability that this change fixes? If yes, it may be an emergency.
- Does it match a written standard pattern, such as a dependency patch bump with passing tests, a copy edit, or a feature flag toggle? If yes, standard.
- Does it touch authentication, authorization, payments, data stores, build pipelines or infrastructure definitions? If yes, normal at minimum, and consider extra reviewers.
- Otherwise, normal.
Write the standard patterns down. A pattern that is not written is a judgment call, and judgment calls are what auditors sample.
Make labels do the work
Use a required label or a PR template field for the class. A short CI step can fail the check if no class label is present. For standard changes, let the pipeline verify the conditions, for example "only files under the docs folder changed". For emergencies, require a link to an incident ticket and a follow-up review within one or two business days, and have a named person confirm it was done.
Watch emergency volume. If a third of your changes are emergencies, the class has become a bypass. Report the count monthly and ask why.
What to keep as evidence
- The PR with its label, approvals and check results.
- The list of standard patterns, with the date and approver of each.
- Emergency tickets with the retro-review outcome.
- A monthly count by class.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request is held or released by gate rules, which is the mechanism that enforces each class.
Quick check
Can an emergency change skip review entirely?
It can skip review before release if your policy allows it, but it should get a documented review afterward. Say so in the policy and follow it.
Is a dependency patch bump a standard change?
Often, if tests pass and your written pattern covers it. Major version bumps usually are not.
Safeguard policies and gates can hold or release pull requests based on rules you define, and compliance automation keeps the resulting records. Try a free scan.
Sources
Last reviewed: 19 October 2026.
