One-way migration
The old application cannot read the new schema.
SecNet.Work · 2026.10 · Sources checked: 2026-10-21
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 AI-assisted SecNet educational content. Examples are fictional, not publication or endorsement by referenced organizations. Implementation decisions require organization-specific approval.
What should I do tomorrow?
- Identify change and dependency owners for one critical service.
- Review the last change’s test and rollback evidence with its service owner.
- Write authority and stop criteria for normal, standard and emergency paths.
Process map
Select a step to see its owner, action and exit evidence.
Request and type
- Owner
- Requester
- Action
- Identify the need, target CI and change path.
- Exit evidence
- Classified request.
Contents and quick navigation
- First three actions
- Concepts
- Not every change follows the same path
- See the service in impact analysis
- Define success and stop conditions in advance
- Operational authority rather than signatures
- How execution and rollback are observed
- Closure, drift and learning
- Common mistakes
- Decision practice
- Downloadable workpapers
Put the concepts in context
- 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.
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.
Related primary references: NIST SP 800-128 — Security-Focused Configuration Management ↗
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.
| 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 |
Related primary references: NIST SP 800-128 — Security-Focused Configuration Management ↗
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.
Related primary references: NIST SP 800-128 — Security-Focused Configuration Management ↗
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.
Related primary references: NIST SP 800-128 — Security-Focused Configuration Management ↗
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.
Related primary references: NIST SP 800-128 — Security-Focused Configuration Management ↗
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.
Related primary references: NIST SP 800-128 — Security-Focused Configuration Management ↗
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.
Explore the reasoning behind your decision
Fictional learning situations, not an exam, score or compliance assessment. Choices and review checks last only on this open page and are not saved to your account.
Quiet canary
The pilot group has received no requests.
Emergency patch
An active attack leaves no full test window.
Workpapers for your organization
Complete the four blank Markdown workpapers in your controlled organizational environment. The full guide includes tables, all decision rationales and sources.
Full guide and explained examplesMarkdown · ENChange requestRecord need and scope.Test and rollbackDefine success and stop boundaries.Emergency change recordExpose reason and residual risk.Closure and learningReconcile outcomes with service and records.
0 / 6 review checks selected on this page; these do not create operational evidence.
References and next work
References support the subject context; procedures and examples are original SecNet material. Verify legal applicability and current standard editions for actual use.
- NIST SP 800-128 — Security-Focused Configuration Management ↗
Configuration-management reference; change classes and example workflow are SecNet adaptations.