Treat a dependency update as a standard change when it is low risk, repeatable and follows a documented procedure that was approved once in advance. Treat it as a normal change when the package is new, the update crosses a major version, or the blast radius is unclear. Your own change policy decides the line.
What the two terms mean
Many change management processes borrow vocabulary from IT service management. A standard change is a routine, well understood change that has been pre-authorised, so each instance needs a record but not a fresh debate. A normal change goes through review and approval each time, often with a change advisory group. An emergency change skips the queue and is reviewed afterwards.
Your organisation may use different names. What matters is that the categories exist, are written down and are applied consistently.
NIST SP 800-53 control CM-3 asks organisations to determine and document the types of changes to a system that are configuration-controlled, and to review and approve them with explicit consideration of security impact. Deciding which dependency changes are pre-approved types is exactly that exercise.
A practical split
| Change | Suggested category | Why |
|---|---|---|
| Patch update of an already approved package, tests pass, no new transitive packages | Standard | Small, reversible, same trust decision |
| Minor update with no new transitive packages and a clean scan | Standard, if your policy says so | Behaviour may shift, tests are the guard |
| Major version bump | Normal | Breaking changes are likely |
| A package that was never approved | Normal, via the intake flow | New trust decision |
| A new transitive package with a different maintainer or licence | Normal | The update adds a supplier |
| Security fix for an actively exploited flaw | Emergency, with after-the-fact review | Speed matters, record still needed |
Conditions that keep a standard change honest
A pre-approval is only as good as its conditions. Write them as checks a machine can evaluate:
- The package is already on the approved list.
- The version moves by a patch or minor step.
- The dependency diff shows no new packages and no licence change.
- The pull request passes tests and the security gate.
- A named reviewer other than the author approved the merge.
- The change ticket links to the pull request and the scan result.
If any condition fails, the change drops out of the standard path and goes to normal review. That fallback is what auditors look for.
Evidence for each path
For a standard change, keep the ticket or automation record, the pull request, the test run and the scan output. For a normal change, add the impact analysis and the approver. For an emergency change, add the reason, the time of approval and the follow-up review.
Review the pre-approval itself on a schedule, perhaps twice a year, and record that you did. If standard changes start causing incidents, tighten the conditions.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a gate on the pull request turns your conditions into a pass or a block.
Safeguard lets teams express such conditions as policies and gates on pull requests, with SBOM and dependency scanning feeding them. You can run a free scan at gold.safeguard.sh/scan. Your auditor and your own policy decide what counts as standard.
Quick check
Can an automated update bot open standard changes?
Yes, if the bot follows the pre-approved conditions and a human reviewer other than the author still approves the merge. Keep the bot's pull request as evidence.
Does a standard change skip the change ticket?
No. It skips fresh approval debate, not the record. Each instance still needs a traceable ticket or automated entry.
Sources
Last reviewed: 19 October 2026.
