# Change Request Form

**Template version:** 1.0.0 · **Edition:** Annotated (with guidance) · **NIST basis:** SP 800-53 Rev. 5, release 5.2.0

*Tailor this template before adoption; it is not legal advice.* Latest version: <https://kston83.github.io/nist-guide/templates/forms/change-request-form/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

> **Guidance:** Use one form per change. The parts follow the change control steps in section 3.3.2 of [NIST SP 800-128](https://csrc.nist.gov/pubs/sp/800/128/upd1/final) (August 2011, with updates as of October 10, 2019; final, current as of October 2026): request, analyze, test, approve, implement, verify and close. Part A adapts the sample change request in its Appendix E. Part B is the security and privacy impact analysis: its tables adapt the security impact analysis template in Appendix I, and its five steps are the ones in section 3.3.3. The analysis lives on this form, not in a separate document, so the board, and later the assessor, sees it next to the decision. Assessors sample changes from the system's deployment history or configuration logs, trace each to a form, and check three things most often: that the analysis is dated before the approval, that someone other than the implementer did it, and that a significant change reached the authorizing official. A change management system can hold these fields instead of a document, as long as each record has them; for a High system, that is how CM-3(1) is usually met. The register at the end is also downloadable as a CSV file.

| System | Change ID | Change type | Date prepared | Status |
| --- | --- | --- | --- | --- |
| [Fill in: system name and identifier] | [Fill in: unique change ID] | [Fill in: standard, normal or emergency] | [Fill in: date] | [Fill in: requested, analyzed, approved, disapproved, on hold, implemented, verified or closed] |

## 1. How to use this form

- Use this form for every type of change the system's Configuration Management Plan lists as configuration-controlled (CM-3a). A standard change cites the change request that approved its class, and needs only Part A and Part F.
- The analyst who completes Part B has security or privacy responsibilities and the skills to understand the change, and is not the person who will implement it. Part B is signed and dated before the decision in Part E (CM-4).
- For an emergency change, the person the Configuration Management Plan names may approve the change so work can start. Part B is completed as soon as practical, and the change control board reviews the change at its next meeting, recording that review in Part E (CM-3).
- Implement the change only after Part E records approval (CM-3d).
- Keep the completed form, with its attachments, for [Fill in: the time period to retain records of configuration-controlled changes. Typical: at least one year, or the life of the system if longer] (CM-3e).
- [Fill in: the configuration change control element responsible for coordinating and overseeing change control activities. Typical: a change control board with the system owner, technical leads and a security representative] reviews the register at each meeting for changes waiting on a decision, emergency changes not yet reviewed, and approved changes not yet verified (CM-3f, CM-3g).

## Part A. Change request

| Field | Entry |
| --- | --- |
| Title of the change | [Fill in: short title] |
| Requested by | [Fill in: name, role and team] |
| Description of the change | [Fill in: what will change, including all additions, deletions and modifications] |
| Justification | [Fill in: why the change is needed, for example a business requirement, a vulnerability, an audit finding] |
| Urgency | [Fill in: scheduled, urgent or emergency] |
| Configuration items and components to be changed | [Fill in: configuration item IDs from the Configuration Management Plan and component IDs from the component inventory] |
| Other components, configuration items or systems affected | [Fill in: dependencies, interfaces, and other systems and their owners] |
| People involved in making the change | [Fill in: names or roles] |
| Expected functional impact | [Fill in: what users or operations will notice, and any outage] |
| Impact of not making the change | [Fill in: the risk or cost of not changing] |
| Interface or integration issues | [Fill in: known issues] |
| Changes required to other applications | [Fill in: changes, or none] |
| Work plan | [Fill in: planned implementation date and window, deliverables, and the back-out plan] |
| Resources or funding required | [Fill in: resources, or none] |
| Supporting documents | [Fill in: attachments, for example the design, vendor release notes] |

## Part B. Security and privacy impact analysis

### B1. Background

| Field | Entry |
| --- | --- |
| Project type | [Fill in: new development, enhancement or maintenance] |
| Systems affected | [Fill in: system names] |
| Security categorization of the affected systems | [Fill in: for example Moderate] |
| Baseline changes | [Fill in: how the baseline configuration will change, for example a new image version or a new allowed port] |
| Planned start and completion of deployment | [Fill in: dates] |

### B2. Change type

Mark each type that applies; more than one may apply.

| Change type | Applies (X) | Explanation |
| --- | --- | --- |
| New network device, such as a router, switch, firewall or VPN gateway | | |
| New server, virtual machine, container image or cloud compute resource | | |
| New end-user device type, such as desktops, laptops or mobile devices | | |
| Other new hardware | | |
| Decommissioning of existing hardware or resources | | |
| New operating system, or upgrade of an existing one | | |
| New commercial or open-source software, or an upgrade or patch of it | | |
| New custom application, or an upgrade or fix of one | | |
| New database management system, database instance, or change to an existing one | | |
| New or upgraded middleware or service | | |
| New cloud service, or a change to a cloud service's settings | | |
| Change to infrastructure-as-code definitions or the deployment pipeline | | |
| Change to ports, protocols or services used or provided by the system (CM-7) | | |
| Change to security functions, such as cryptographic modules, authentication, authorization, roles, logging or security patches | | |
| New information type processed, stored or transmitted, or new personal information | | |
| Interface or interconnection added, changed or removed (CA-3) | | |
| Change of location or hosting | | |
| Other change | | |

### B3. Components affected

| Component ID (component inventory) | Component name | Network address | Manufacturer and model | Serial number or asset tag | Operating system and version | Software affected |
| --- | --- | --- | --- | --- | --- | --- |
| [Fill in: ID] | [Fill in: name] | [Fill in: address] | [Fill in: manufacturer and model] | [Fill in: serial or tag] | [Fill in: OS and version] | [Fill in: software and versions] |

### B4. Analysis

> **Guidance:** These are the five steps of a security impact analysis in SP 800-128 section 3.3.3. NIST's CM-4 discussion adds what the analysis covers: the security and privacy plans, policies and procedures; the design and operating procedures, to see how the change affects the controls; the effect on supply chain partners; how the change creates new privacy risks; and a risk assessment to decide whether more controls are needed. Scale the depth to the change: one line per step is enough for a minor change, while a new component or a new place where data is stored needs a full analysis. "None" in every row is a common finding.

| Step | Findings |
| --- | --- |
| 1. Understand the change: how it will be built and deployed, with a high-level architecture overview where useful. For a change already made, what the audit records and the people who made it show | [Fill in: summary] |
| 2. Identify vulnerabilities: known vulnerabilities in products being added, for example from the National Vulnerability Database or the vendor's advisories; for custom code, the results of code review or testing | [Fill in: vulnerabilities found, or none, with the sources checked] |
| 3. Assess risks: the likelihood and impact of each vulnerability being exploited, and whether to accept, avoid or reduce the risk | [Fill in: risk rating and response] |
| 4. Assess the impact on existing controls: controls the change alters, settings or baselines it changes, and other components or systems that depend on what is changing, including supply chain partners | [Fill in: controls affected, by control ID, and how] |
| 5. Plan safeguards and countermeasures: changes to the request, or controls to add, where the risk is not acceptable | [Fill in: safeguards, or none needed] |

### B5. Privacy

| Question | Answer |
| --- | --- |
| Does the change add, remove or alter personal information the system processes, or how it is processed or shared? | [Fill in: yes or no, and how] |
| Does the privacy impact assessment or a system of records notice need updating? | [Fill in: yes or no; reference to the update] |
| Privacy reviewer | [Fill in: name, role and date, or not applicable] |

### B6. Analyst sign-off

| Analyst | Role | Date completed |
| --- | --- | --- |
| [Fill in: name] | [Fill in: role with security or privacy responsibilities] | [Fill in: date, which is before the decision date in Part E] |

## Part C. Significant change decision

> **Guidance:** A significant change is one likely to affect the security or privacy state of the system. The [Continuous Monitoring Strategy](https://kston83.github.io/nist-guide/templates/plans/continuous-monitoring-strategy/), section 12, lists it as a trigger: a security impact analysis, a targeted assessment of the affected controls, and an authorizing official decision on reauthorization. Its examples are a new hosting environment or a major architecture change. Changes that commonly qualify: a new interconnection, a new type of information or personal information, a change in categorization, a move to a different cloud service or data center, replacing a security function such as authentication, or removing a control. When unsure, treat the change as significant and let the authorizing official decide. Deciding it here, before approval, means the authorizing official hears about the change before it happens, not at the next assessment.

| Question | Answer |
| --- | --- |
| Is this a significant change under section 12 of the system's Continuous Monitoring Strategy? | [Fill in: yes or no] |
| Reason | [Fill in: the criterion it meets, or why it meets none] |
| Decided by | [Fill in: name, role and date] |
| If yes: date the authorizing official was told, and how | [Fill in: date and method] |
| If yes: the authorizing official's decision | [Fill in: for example proceed with a targeted assessment of the affected controls, reauthorize, or proceed and accept the risk; name and date] |
| If yes: system security plan, privacy plan and continuous monitoring strategy updates needed | [Fill in: documents and sections] |

## Part D. Testing

| Field | Entry |
| --- | --- |
| Test environment | [Fill in: environment, and how it is separated from production] |
| Tests performed | [Fill in: the tests run against the change, functional and security, such as a compliance scan and a vulnerability scan of the changed component] |
| Results | [Fill in: results for each test, or a reference to the test record] |
| Tested and validated by, and date | [Fill in: name and date] |

The change is tested, validated and documented before its implementation is finalized (CM-3(2)).

> **Guidance:** For a High system, CM-4(1) also asks that the change be analyzed in a separate test environment, physical or logical, before it reaches production, looking for impacts from flaws, weaknesses, incompatibility or intentional malice. Record the environment and what the analysis there found. Keep production personal information out of the test environment unless it is protected to the same level.

## Part E. Decision

| Field | Entry |
| --- | --- |
| Decision | [Fill in: approved, approved with conditions, disapproved, or on hold] |
| Conditions or further action | [Fill in: conditions, such as added safeguards; or, if disapproved, the reason and what would change the decision] |
| Decided by | [Fill in: the change control board, with the meeting date, or the emergency approver] |
| Security representative present | [Fill in: name] |
| Emergency change reviewed by the board on | [Fill in: date, or not applicable] |

| Approver | Role | Signature | Date |
| --- | --- | --- | --- |
| [Fill in: name] | [Fill in: role] | | [Fill in: date] |

## Part F. Implementation, verification and closure

| Field | Entry |
| --- | --- |
| Implemented by, date and time | [Fill in: name, date and time] |
| Implementation result | [Fill in: successful, partially successful, or backed out, with details] |
| Controls verified after the change, by whom and how | [Fill in: for example compliance and vulnerability scans compared with the results before the change, and a test of the affected controls] |
| Verification result | [Fill in: the affected controls are implemented correctly, operating as intended and producing the desired outcome, or what was found] |
| Documents updated | [Fill in: baseline configuration, component inventory, system security plan, configuration item list, diagrams, plan of action and milestones, or none] |
| Stakeholders notified | [Fill in: who was told, for example users and the service desk] |
| Closed by and date | [Fill in: name and date] |

> **Guidance:** CM-4(2), in the Moderate and High baselines, asks that after the change the affected controls are verified as implemented correctly, operating as intended and producing the desired outcome. SP 800-128 section 3.3.2 says a change request is not closed until the change is confirmed deployed without issues, and section 3.3.4 lists the documents to update afterward, noting that a system with high risk or significant changes may need reauthorization.

### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 5.i, defines a significant change as "a change that is likely to affect the security or privacy state of an information system," and says that under ongoing authorization, reauthorization is typically an event-driven action in response to an event or significant change that raises security or privacy risk above the agency's risk tolerance, and may be a complete or a targeted review. Section 5.a says systems undergoing significant changes are expected to meet NIST standards and guidelines immediately on deployment. As of October 2026.

- The Part C decision shall use the OMB Circular A-130 definition of a significant change, and each significant change shall be reported to the authorizing official before it is implemented, or, for an emergency change, as soon as it is made. (CM-4)
- A significant change shall be deployed meeting the current versions of the NIST standards and guidelines that apply to it, as OMB Circular A-130, Appendix I, section 5.a, expects. (CM-3)

## Register

| Change ID | Title | Requested by and date | Type | Configuration items affected | Impact analysis by and date | Security and privacy impact | Significant change; authorizing official told | Test result | Decision, by and date | Implemented by and date | Verification result | Closed |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Fill in: ID] | [Fill in: title] | [Fill in: name and date] | [Fill in: standard, normal or emergency] | [Fill in: CI IDs] | [Fill in: analyst and date] | [Fill in: summary and risk rating] | [Fill in: no; or yes, with the date told] | [Fill in: pass or fail, with reference] | [Fill in: decision, board or approver, date] | [Fill in: name and date] | [Fill in: result] | [Fill in: date] |