# Secure change and emergency change management

A security patch can interrupt service. Change management brings the right risk to the right authority instead of merely collecting signatures. Distinguish normal, standard and emergency paths while addressing dependencies, data transformations, rollback limits and evidence of outcomes.

Original SecNet educational content with fictional examples, not publication/endorsement by referenced organizations. Page exercise choices last only for the open session; no real organizational data is collected.

2026.10 · 2026-10-21

## What should I do tomorrow?

1. Identify change and dependency owners for one critical service.
2. Review the last change’s test and rollback evidence with its service owner.
3. Write authority and stop criteria for normal, standard and emergency paths.

## Concepts

**Standart değişiklik** — A repeatable operation with preauthorization, bounded scope and evidence.

**Acil değişiklik** — An expedited path where delay is harmful, still requiring authority and records.

**Rollback** — Return to an earlier state; reverting code may not reverse changed data.

**CAB** — An organizational review arrangement, not necessarily the same meeting for every task.

**Drift** — Divergence of actual configuration from an approved baseline.

## Process map

### 1. Request and type

Requester

Identify the need, target CI and change path.

Classified request.

### 2. Impact and test

Service owner + technical team

Assess dependencies, tests and data rollback.

Test and impact record.

### 3. Authority and readiness

Designated change authority

Approve timing, communication and stop criteria.

Authorized execution plan.

### 4. Execute and observe

Operator + observer

Execute within scope; stop at defined thresholds.

Timestamped execution trace.

### 5. Validate and close

Business owner + independent reviewer

Validate service, security and CMDB updates.

Outcome and learning record.

## Not every change follows the same path

Normal changes are planned through impact and authority review. Standard changes need repeatable procedures, narrow scope and tested outcomes. Having done something before is insufficient; changed targets or data effects require reassessment.

Emergency paths address harmful delay. Record remaining uncertainty, authority and compensating controls instead of hiding missing tests. Assign a retrospective review date. Do not use an emergency label to conceal routine planning failures.

- [ ] Each type has entry criteria and approval authority.

Reference: [NIST SP 800-128 — Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final)

## See the service in impact analysis

A firewall change can affect DNS, identity, backup and application flows, not just one device. Validate CMDB relationships against observed traffic and service owners. Check concurrent work: two individually safe operations may cause a combined failure.

For migrations, schema changes and trust transitions explain rollback limits. Test whether older applications can read transformed data. Taking a production backup does not demonstrate recovery within the required window.

Change-path comparison

| Subject | Focus | Validation / boundary |
| --- | --- | --- |
| Normal | Review according to impact and risk | Approved scope and testing |
| Standard | Preauthorized bounded procedure | Procedure conditions and repeat testing |
| Emergency | Harm from delay and authorized decision | Minimum tests, records and retrospective review |

- [ ] Service dependencies and data effects appear in the approval.

Reference: [NIST SP 800-128 — Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final)

## Define success and stop conditions in advance

For a fictional order API update, test more than startup. Exercise authentication, payment, record integrity, authorization denial and monitoring signals. Define synthetic data, expected outcomes and a reviewer independent of the operator.

For staged or canary deployment choose comparison groups, observation windows and rollback thresholds for the service. Low traffic makes a short quiet interval weak evidence. Predetermine stop authority and notification recipients.

- [ ] Test, success, stop and rollback criteria are written.

Reference: [NIST SP 800-128 — Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final)

## Operational authority rather than signatures

Bind approval to version, targets, window, operator and rollback plan. Reassess scope changes after approval. Use risk-proportionate separation rather than allowing requesters to approve their own high-risk work unilaterally.

Use deputies and escalation when emergency authorities are unavailable. Silence is not approval. Record the time, scope and authority of verbal emergency approval, reconciling it into the formal record promptly. A managerial signature does not automatically remove legal or contractual duties.

- [ ] Approval is bound to actual version and target.

Reference: [NIST SP 800-128 — Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final)

## How execution and rollback are observed

Before execution confirm target identity, current version, backup status and access. Timestamp steps without exposing secrets. Observers track error rates, latency and security signals. A green deployment-tool status alone is insufficient proof of success.

When thresholds are exceeded use the authorized stop/rollback path. Avoid improvised dual writes during inconsistency. Retest business transactions and security controls after rollback. Route residual differences to authorized risk decisions and time-bound correction.

- [ ] Business and security are retested after rollback.

Reference: [NIST SP 800-128 — Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final)

## Closure, drift and learning

Update CMDB, versions, baselines, runbooks and monitoring rules. The business owner validates the service. Honestly record a failed change even after successful rollback. Repeated causes may indicate systemic gaps in testing, design or approval scope.

Investigate the source, difference and impact of unauthorized change or drift. Automatically reverting every difference can undo legitimate emergency repairs. Reconcile against authorized state. Report failure, emergency frequency and evidence-free closures together; fewer requests do not demonstrate better control.

- [ ] Closure updates baselines and learning records.

Reference: [NIST SP 800-128 — Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final)

## Common mistakes and better approaches

**Assuming a backup means rollback is ready.** — Test compatibility and restoration within the required time.

**Expanding targets after approval.** — Reassess and authorize the new impact.

**Closing on a green deployment status.** — Validate business transactions and security controls.

## Decision examples and explained answers

### One-way migration

The old application cannot read the new schema.

**Deploy the old code alone.** — Revisit

Code rollback does not reverse data transformation. Without evidence of compatibility, an improvised revert may worsen interruption or corruption.

**Validate data compatibility and the approved recovery path.** — Supported approach

Test rollback limits before execution. During an incident preserve integrity, follow the authorized runbook and validate outcomes with the owner; backup existence alone is insufficient.

### Quiet canary

The pilot group has received no requests.

**No errors, release to everyone.** — Revisit

No errors without traffic does not establish correct operation. Without exercised workflows and controls, the success decision lacks evidence.

**Validate representative synthetic transactions and observation coverage.** — Supported approach

Exercise approved synthetic samples. The designated authority decides staged expansion only when scope and observation are adequate for service risk.

### Emergency patch

An active attack leaves no full test window.

**Skip every control and consider records later.** — Revisit

Urgency does not remove target, authority or evidence requirements. Uncontrolled broad deployment can amplify impact and obscure the source of failure.

**Use narrow scope, authority, minimum tests and rollback.** — Supported approach

Record risk and test gaps. Use the authorized emergency path with monitoring and stop conditions, then schedule review of outcomes and outstanding validation.

## Official references

- [NIST SP 800-128 — Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final) — Configuration-management reference; change classes and example workflow are SecNet adaptations.