- The asset inventory, to state systems affected accurately
- The configuration baseline for each affected platform, to judge security impact
- For OT changes: the process owner's availability and the maintenance-window calendar
ATL-017RECORDEDITORIAL REVIEW COMPLETE
Change Request and Validation Package
One package per change: the request (what, why, systems affected, risk class, rollback, approvals), a required safety and operations sign-off for anything touching production, a post-change validation checklist, and an emergency-change variant with retroactive review built in.
Using this artifact
Purpose, inputs, and completion
Purpose. Most self-inflicted outages and many security regressions arrive through changes nobody reviewed, and most unexplainable incident timelines have a hole where the change record should be. This package is the single document each change carries from request through validation: what is changing and why, who judged the risk and approved it, how it rolls back, and how success was verified afterward. For production and OT scope it adds the sign-off that keeps security changes from becoming downtime.
When to use it. Complete the request section and obtain approvals before work begins — the package travels with the change, not after it. For any change touching production or OT systems, the safety and operations sign-off section must be completed; treat it as a gate, not a courtesy. After implementation, run the validation checklist inside the window while rollback is still practical, and file the completed package where the next incident investigation will look for it.
- Write the rollback plan before requesting approval, and answer the tested question honestly — a rollback that exists only as a sentence has never saved anyone.
- Classify risk by what fails if the change goes wrong, not by how long the work takes; a two-minute firewall rule can be a high-risk change.
- For any change touching production or OT systems, the safety and operations sign-off section is required — a package without it is not approvable for that scope, however small the change.
- Run the validation checklist after the change, in the window, before declaring success; 'it seems fine' the next morning is how broken monitoring goes unnoticed for a quarter.
- Use the emergency variant when action genuinely cannot wait — then complete the retroactive review within five business days, or emergency becomes the routine path.
Keeping it honest
Evidence, validation, and failure modes
- A per-change record of request, risk class, approvals, and rollback plan
- A completed post-change validation checklist tied to each change
- An emergency-change trail showing retroactive review actually happens
- Pick three recent changes visible in system logs (a firewall rule, a patch, a permission change) and find their packages; a change with no package is the finding.
- Pick one high-risk package and check the rollback-tested field against reality — ask the implementer to describe the test; hesitation is the answer.
What looks done but is not
- The form exists but the emergency path is the habit: everything is urgent, nothing is reviewed, and the retroactive-review fields stay blank.
- Rollback plans say 'restore from backup' for systems whose restore has never been rehearsed and would take a day the window does not have.
- OT changes are approved by IT alone; the process owner learns about the new firmware when the line stops.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain completed packages for at least three years; when an incident investigation asks 'what changed and who approved it?', this stack is the answer or the absence of one.
Full document
Preview — exactly what prints
RECORD · CONFIGURATION & CHANGEv1.0 · REVIEWED 2026-08-06
Change Request and Validation Package
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Most self-inflicted outages and many security regressions arrive through changes nobody reviewed, and most unexplainable incident timelines have a hole where the change record should be. This package is the single document each change carries from request through validation: what is changing and why, who judged the risk and approved it, how it rolls back, and how success was verified afterward. For production and OT scope it adds the sign-off that keeps security changes from becoming downtime.
How to use it
Complete the request section and obtain approvals before work begins — the package travels with the change, not after it. For any change touching production or OT systems, the safety and operations sign-off section must be completed; treat it as a gate, not a courtesy. After implementation, run the validation checklist inside the window while rollback is still practical, and file the completed package where the next incident investigation will look for it.
Change request
The request states what, why, where, and how it comes back out. Approval is of this text — an approval of a hallway summary approves nothing.
Request
| Change ID and title | What is changing (specific systems, settings, versions) | Why (business or security reason) | Systems affected (from the asset inventory) | Risk class (standard / high / emergency) and why | Planned date and window | Rollback plan — and has it been tested? (Y/N, how) | Requested by | Approved by, role, date |
|---|---|---|---|---|---|---|---|---|
Risk class drives the rest of the package
Standard changes need the request, one approval, and the basic validation checks. High-risk changes — anything touching authentication, backups, network boundaries, or production — additionally need a rehearsed rollback and the full validation checklist. Emergency is not a risk class you choose for speed; it is the variant below, with its own review debt.
A worked example of the request's load-bearing fields — replace with your own change.
| Field | Example entry |
|---|---|
| EXAMPLE: Change ID and title | CHG-2026-041 — Enforce SMB signing on both file servers |
| EXAMPLE: Risk class and why | High — touches authentication between every endpoint and the file store |
| EXAMPLE: Rollback plan, tested? | Group Policy revert staged and rehearsed on FS-TEST; 15 minutes; yes, 2026-07-30 |
Safety and operations sign-off (required for OT scope)
Required — not optional — for any change touching production systems, production networks, or equipment that can affect safety or output. An unsigned section here voids the approval above for OT scope.
Sign-off
| Process owner (named person) | Maintenance window agreed (start / end) | Safety review completed by and date | Production impact if the change fails, and the response | Vendor coordination needed? (who, confirmed when) | Process owner sign-off (signature / date) |
|---|---|---|---|---|---|
Safe operation outranks the change
No change proceeds on a live production system without the process owner's agreement, an approved window, a tested rollback, and a completed safety review — and where the change conflicts with safe operation, the change waits or is compensated instead. A security improvement that stops the line teaches the plant to route around this process, which costs more security than the change bought.
Post-change validation
Run inside the window, while rollback is still cheap. Each item is checked by a named person — 'the team verified it' verified nothing.
Validation checklist
Record who checked each item and when, in the notes column of your filed copy.
- The change works as intended: the specific capability it was meant to deliver has been exercised, not assumed.
- Security settings are intact: affected systems diffed against their configuration baseline; no setting silently reverted or newly deviated.
- Monitoring is healthy: logs from affected systems still arrive at the log platform, and alerting tested where the change touched it.
- Rollback rehearsed and timed before the window — the actual procedure, on the actual or equivalent system.
- For OT scope: process confirmed stable by the process owner before the window closes, and the vendor's post-change checks completed where the equipment is vendor-supported.
Emergency change variant
For action that genuinely cannot wait for approval — a burning vulnerability, a failing system. The paperwork shrinks; the review debt does not.
Emergency record
| Emergency change ID | What was done, to which systems, when | Why it could not wait for normal approval | Authorized verbally by, at what time | Retroactive review date (within 5 business days) | Retroactive reviewer and decision (endorse / corrective actions listed) |
|---|---|---|---|---|---|
The retroactive review asks two questions: was this genuinely an emergency, and did the action leave anything behind — a weakened setting, a bypassed gate, an untested state — that now needs a standard change to correct. Count emergency changes per quarter; a rising count is the change process failing quietly.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader |
| Approval authority | Executive sponsor |
| Review frequency | A package is completed for every change; the template itself is reviewed annually and after any change-related incident |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain completed packages for at least three years; when an incident investigation asks 'what changed and who approved it?', this stack is the answer or the absence of one. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.