Not All Changes Are Equal: Standard, Normal, and Emergency Changes

A developer opens a pull request to fix a typo on the company's "About Us" page. Three days later, the fix is still waiting for approval. Meanwhile, another team is preparing to migrate the payment database schema, and they are also waiting for the same approval process. The typo fix and the database migration are treated identically: both need a meeting, a sign-off, and a slot in the next release window.

This situation is frustrating, but it is also common. When every change goes through the same approval pipeline, small fixes get stuck behind heavyweight processes, and high-risk changes may not get the scrutiny they deserve. The problem is not governance itself. The problem is treating all changes as if they carry the same risk.

Why One-Size-Fits-All Approval Fails

The instinct to control every change comes from a good place: nobody wants a broken production environment. But when the approval process does not distinguish between a text update and a schema migration, two things happen. First, low-risk changes pile up waiting for approvals that add no real safety. Second, the team becomes numb to the process. When everything requires a sign-off, people stop thinking about whether the sign-off actually matters. They just wait for the checkbox.

The result is a system that slows down safe changes without making risky ones any safer. The fix is not to remove governance. The fix is to make governance proportional to risk.

Three Categories of Change

Most mature teams divide changes into three categories based on risk and familiarity: standard, normal, and emergency. Each category has a different approval path.

The following flowchart illustrates how a change enters the pipeline and is routed to the appropriate approval process based on its classification.

flowchart TD A[Change Request] --> B{Is it an emergency?} B -->|Yes| C[Emergency Change] C --> D[Make change immediately] D --> E[Document & post-review] B -->|No| F{Is procedure documented & proven?} F -->|Yes| G[Standard Change] G --> H[Automated pipeline approval] H --> I[Deploy] F -->|No| J[Normal Change] J --> K{Assess risk level} K -->|Low| L[Peer review] K -->|High| M[CAB or multi-stakeholder review] L --> N[Approve & deploy] M --> N

Standard Changes

A standard change is something the team has done many times before. The procedure is known, the outcome is predictable, and the risk is well understood. Examples include updating static content on a marketing page, adding a server to handle traffic spikes, or re-running a pipeline that failed due to a temporary network issue.

Because the team already knows exactly what will happen and has a proven procedure, standard changes do not need manual review or approval. The team simply follows the documented procedure. The key requirement is that the procedure must be documented and auditable. If something goes wrong, the team can trace back and check whether the procedure was followed correctly.

Standard changes are where automation shines. If a procedure is truly predictable, it should be codified in the CI/CD pipeline. The pipeline itself becomes the approval mechanism: if the automated checks pass, the change goes through.

Normal Changes

A normal change is something the team has not done before, or the risk is not fully understood. Examples include adding a feature that changes business logic, upgrading a database version, or modifying security configuration.

Normal changes require review. The reviewer could be a peer developer, a security team member, or a Change Advisory Board (CAB), depending on the risk level. But review does not have to mean a slow process. For low-risk normal changes, a quick review by one or two people is enough. For high-risk normal changes, the review may involve more stakeholders and additional testing.

The critical point is that normal changes are not blocked by default. They are reviewed proportionally. A team that has clear criteria for what makes a change low-risk versus high-risk can route each change to the appropriate review depth automatically.

Emergency Changes

An emergency change is something that must be done immediately to fix a live problem. Examples include a production server going down, corrupted data, or a security vulnerability being actively exploited. In these situations, waiting for a review or an approval meeting would make the problem worse.

Emergency changes have a fast track. The team can make the change immediately, but there is a catch: the change must be documented and evaluated afterward. The team needs to record what was changed, who changed it, why it was an emergency, and what the impact was. After the incident is resolved, the team evaluates whether the emergency change was appropriate or needs further correction.

The fast track is not a free pass. It is a trade-off: speed now, accountability later. Teams that abuse the emergency track by classifying routine changes as emergencies will eventually lose trust and create real risk.

How to Classify Changes

The three categories are only useful if the team has clear criteria for each one. Without criteria, classification becomes arbitrary. One person's standard change is another person's normal change, and the whole system breaks down.

Start by defining what makes a change standard. A good rule of thumb: if the team has performed the same change at least five times without incident, and the procedure is fully documented, it is a candidate for standard status. If there is any uncertainty, it belongs in the normal category.

For normal changes, define what makes a change high-risk versus low-risk. Common factors include: does the change touch the database schema? Does it affect authentication or authorization? Does it change how money is handled? Does it require a rollback plan? The more yes answers, the higher the risk.

For emergency changes, define what qualifies as an emergency. A typo on a landing page is not an emergency. A production outage affecting paying customers is. The team should agree on examples of genuine emergencies and examples of situations that look urgent but are not.

Integrating Classification into the Pipeline

Once the criteria are clear, the next step is to integrate classification into the CI/CD pipeline. This does not mean building a complex approval system. It means adding a simple field to the change request or the deployment ticket that asks the developer to classify the change. The pipeline can then route the change to the appropriate review path.

For example, a GitHub Actions workflow can automatically label a pull request as standard when it only touches documentation or configuration files, and then skip the manual approval step:

name: Classify Change
on: pull_request

jobs:
  classify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: .github/labeler.yml

  deploy-standard:
    if: contains(github.event.pull_request.labels.*.name, 'standard')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy without manual approval
        run: echo "Deploying standard change..."

And the accompanying .github/labeler.yml file defines which paths map to the standard label:

standard:
  - changed-files:
      - any-glob-to-any-file: ['docs/**', 'config/**', '*.md']

For standard changes, the pipeline can proceed automatically after the usual tests pass. For normal changes, the pipeline can pause and notify the appropriate reviewers. For emergency changes, the pipeline can allow the deployment but trigger a post-deployment documentation requirement.

The goal is not to build a bureaucracy. The goal is to make the pipeline reflect the team's understanding of risk. When the pipeline handles classification automatically, the team spends less time on process and more time on actual work.

A Practical Checklist

Before your next deployment, ask these questions:

  • Is this change something we have done before with a documented procedure? If yes, treat it as standard and automate the approval.
  • Is this change new or uncertain? If yes, identify the risk level and assign the appropriate reviewer.
  • Is this change needed to fix a live problem? If yes, make the change now, but document everything and schedule a post-incident review.

The Takeaway

Governance is not about slowing everyone down. It is about applying the right amount of control to the right change. Standard changes should fly. Normal changes should get proportional review. Emergency changes should get speed with accountability. When the team agrees on the criteria and bakes them into the pipeline, approval becomes smarter, not heavier.