# Configuration Management Plan

**Template version:** 1.0.0 · **Edition:** Ready to adopt · **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/plans/configuration-management-plan/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

| System name | System identifier | Plan version | Plan owner | Approval date |
| --- | --- | --- | --- | --- |
| [Fill in: system name] | [Fill in: unique system identifier] | [Fill in: version] | [System owner] | [Fill in: date] |

## Plan approval

This plan was reviewed and is approved by [Fill in: personnel or roles to review and approve the configuration management plan. Typical: the system owner and the Chief Information Security Officer] (CM-9d).

| Name | Title | Signature | Date |
| --- | --- | --- | --- |
| [Fill in: name] | [System owner] | | [Fill in: date] |
| [Fill in: name] | [Chief Information Security Officer] | | [Fill in: date] |

## 1. Introduction

### 1.1 Background

Configuration management keeps [Fill in: system name] in a known, approved and secure state. It does this by setting secure baseline configurations, controlling every change to them, analyzing each change for its security and privacy impact, and monitoring the system against the baselines. This plan sets out how that is done for this system, under the organization's Configuration Management Policy (CM-1, CM-9a).

### 1.2 Overview of the system

The system is described in its [system security plan](https://kston83.github.io/nist-guide/templates/plans/system-security-plan/), sections [Fill in: section numbers]. In brief:

- **Mission:** [Fill in: the mission or business functions the system supports]
- **Data flow:** [Fill in: the main information flows, or a reference to the data flow diagram in the system security plan]
- **Architecture:** [Fill in: hosting, main tiers and environments, or a reference to the architecture diagram]
- **Administration and management:** [Fill in: who administers the system, from where, and with which management tools]

### 1.3 Purpose of this document

This plan describes the roles, responsibilities, processes and procedures for configuration management of the system (CM-9a). It is the document administrators, developers, the change control board and assessors use to see how a configuration item is identified, baselined, changed and monitored.

### 1.4 Scope

This plan applies to every configuration item in section 3.1, in every environment listed in section 3.2: [Fill in: for example development, test and production]. It covers changes made by staff, contractors and service providers. [Fill in: components or services outside the plan's scope, such as those inherited from a cloud provider, and where their configuration management is described]

### 1.5 Applicable policies and procedures

- The organization's Configuration Management Policy and its procedures (CM-1)
- The [baseline configuration standard](https://kston83.github.io/nist-guide/templates/standards/baseline-configuration-standard/) (CM-2, CM-6, CM-7)
- The [change request form](https://kston83.github.io/nist-guide/templates/forms/change-request-form/) (CM-3, CM-4)
- The [component inventory](https://kston83.github.io/nist-guide/templates/forms/component-inventory/) (CM-8)
- The system's [Continuous Monitoring Strategy](https://kston83.github.io/nist-guide/templates/plans/continuous-monitoring-strategy/) (CA-7)
- The [patch and flaw remediation standard](https://kston83.github.io/nist-guide/templates/standards/patch-and-flaw-remediation-standard/) (SI-2)
- [Fill in: other laws, regulations, standards and organizational procedures that apply]

## 2. Configuration management program

### 2.1 Roles and responsibilities

| Role | Responsibilities under this plan |
| --- | --- |
| [System owner] | Owns this plan and the system's baselines; chairs or designates the chair of the change control board; approves deviations from secure configurations; ensures only approved changes are made (CM-3d) |
| [Chief Information Security Officer] | Approves this plan with the system owner (CM-9d); provides the organization-wide configuration management, scanning and inventory tools; sets the secure configurations in the baseline configuration standard |
| System security officer, or the security representative the system owner names | Carries out or reviews the security impact analysis of each change (CM-4); sits on the change control board (CM-3(4)); reviews deviations and monitoring results |
| [Senior privacy official], or a privacy representative | Reviews changes that affect personal information; sits on the board where the system processes personal information (CM-3(4)) |
| Change control board | Reviews proposed changes and approves, disapproves or holds them (CM-3b), under the charter in Appendix A |
| System administrators, developers and release engineers | Request changes; make only approved changes, through the access restrictions in section 2.3 (CM-5); update the baseline and the component inventory as part of each change |
| [Security operations team] | Runs configuration compliance scans and unauthorized-component detection; reports differences to the system owner |
| Authorizing official | Is told of each significant change and decides whether a targeted assessment or reauthorization is needed (CA-6) |

### 2.2 Program administration

#### 2.2.1 Policies and procedures

The system follows the organization's Configuration Management Policy and these procedures: [Fill in: the procedures, by name and location, for example the change management procedure and the baseline build procedure, or "this plan" where the plan itself is the procedure] (CM-1). Where the system works differently from the organization's procedures, this plan says so in the section concerned.

#### 2.2.2 Change control board functions

Configuration change control for the system is coordinated and overseen by [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], which convenes [Select one or more: [Assignment: organization-defined frequency]; when [Assignment: organization-defined configuration change conditions]. Typical: weekly, and when an emergency change is requested] (CM-3g). The board reviews each proposed change with its security and privacy impact analysis, decides on it, records the decision, and reviews emergency changes after the fact (CM-3b, CM-3c). Its charter is Appendix A.

#### 2.2.3 Change control board at the organization level

[Fill in: the organization-level board or change advisory board, if one exists, which changes it decides (for example changes to shared infrastructure or common controls), and how this system's board escalates to it; or "none"]

#### 2.2.4 Change control board at the system level

[Fill in: the system's own board, or the enterprise board on which the system has a seat, and its members by role, as in Appendix A]. [Fill in: security and privacy representatives. Typical: a representative of the security team and, where the system processes personal information, of the privacy office] are members of [Fill in: the configuration change control element of which the security and privacy representatives are to be members. Typical: the change control board] (CM-3(4)).

#### 2.2.5 Schedules and resource requirements

| Activity | Schedule | Who | Resources needed |
| --- | --- | --- | --- |
| Change control board meetings | [Fill in: for example weekly, Tuesdays] | Board members | [Fill in: time, tools] |
| Baseline review | [Fill in: the frequency in the baseline configuration standard] | [System owner] | [Fill in: resources] |
| Configuration compliance scans | [Fill in: the frequency in the baseline configuration standard] | [Security operations team] | [Fill in: resources] |
| Component inventory review and reconciliation | [Fill in: the frequency in the component inventory] | [System owner] | [Fill in: resources] |
| Review of this plan | [Fill in: for example annually] | [System owner] | [Fill in: resources] |

### 2.3 Configuration management tools

#### 2.3.1 Tools

| Tool | Used for | Configuration items covered | Who administers it |
| --- | --- | --- | --- |
| [Fill in: for example the change management system] | [Fill in: for example change requests, impact analyses and approvals] | [Fill in: all] | [Fill in: team] |
| [Fill in: for example version control and the deployment pipeline] | [Fill in: approved versions of code, infrastructure as code and configuration files] | [Fill in: items] | [Fill in: team] |
| [Fill in: for example the configuration management or endpoint management tool] | [Fill in: applying and enforcing settings] | [Fill in: items] | [Fill in: team] |
| [Fill in: for example the compliance scanner and asset discovery tool] | [Fill in: checking settings against the baseline; finding components] | [Fill in: items] | [Fill in: team] |

Only the people named in each tool's access list can change configuration items, and the tools record who made each change (CM-5). [Fill in: how access to make changes is granted and reviewed, for example through the privileged access process]

Because the tools that check baselines decide what counts as a deviation, the tools and their content (for example the scan profiles) are themselves configuration items in section 3.1, as SP 800-128 section 3.1.2 suggests.

This paragraph applies to High systems.

- The system uses [Fill in: mechanisms used to automate configuration change control. Typical: the change management system integrated with the deployment pipeline] to document proposed changes, to notify [Fill in: approval authorities to be notified of and request approval for proposed changes to the system. Typical: the change control board members] and request approval, to highlight proposed changes not approved or disapproved within [Fill in: the time period after which to highlight changes that have not been approved or disapproved. Typical: 5 business days], to prohibit changes until the designated approvals are received, to document all changes, and to notify [Fill in: personnel to be notified when approved changes are complete. Typical: the requester, the system owner and the security operations team] when approved changes are completed (CM-3(1)).

#### 2.3.2 Configuration management library

Approved versions of each configuration item, previous baselines, change records and this plan are kept in [Fill in: location, for example the version control repository and the change management system]. Master copies of approved images and installation media are kept in [Fill in: location], with access limited to [Fill in: roles] (SP 800-128 section 3.2.2).

### 2.4 Retention, archiving, storage and disposal

- Change records, including their impact analyses, test results and approvals, are kept 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 number of previous baseline configuration versions to be retained. Typical: at least the two most recent] previous versions of each baseline configuration are kept to support rollback (CM-2(3)).
- Archived baselines and change records are protected to the same level as the system, since they describe how it is built and secured (SP 800-128 section 3.3.4).
- This plan, and the records it names, are stored in [Fill in: location with restricted access], where only [Fill in: roles] can change them, to protect them from unauthorized disclosure and modification (CM-9e).
- Records past their retention period are disposed of under [Fill in: the organization's records retention schedule].

## 3. Configuration management activities

### 3.1 Configuration identification

#### 3.1.1 Types of configuration items

A configuration item is a component, a group of like components, or a non-component object such as documentation or firmware that is managed as one unit (SP 800-128 section 2.3.5). This system uses these types: [Fill in: for example operating system images, network device configurations, cloud account and service settings, infrastructure-as-code definitions, application code and its dependencies, container images, databases, security tools and their content, and key documents].

#### 3.1.2 Identification criteria

- Each component in the component inventory belongs to exactly one configuration item, and each configuration item belongs to this system only (SP 800-128 section 3.1.2).
- Components with the same platform and the same secure configuration are grouped into one item, for example all servers running one operating system version.
- New items are identified when a change request adds a component type, environment, service or document, and the change request records the new item (CM-9b).
- Items leave configuration management only when they are retired through a change request, and keep their history.
- [Fill in: any other criteria the system uses, for example a separate item for each externally facing component]

#### 3.1.3 Configuration item labeling

Items are named [Fill in: the naming convention, for example SYSTEM-TYPE-NN, such as FIN-IMG-01], and each item's versions are numbered [Fill in: the versioning scheme, for example the version control tag or the image version].

#### Configuration item list

The configuration items of the system, and the place each one's approved version is kept (CM-9c):

| CI ID | Configuration item | Type | Components or objects it covers | Secure configuration it follows | Where the approved version lives | Owner | Current approved version and date |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Fill in: ID] | [Fill in: name] | [Fill in: component group, single component, or non-component object] | [Fill in: the component inventory entries or documents in the item] | [Fill in: the benchmark from the baseline configuration standard, or not applicable] | [Fill in: repository, tool or library location] | [Fill in: role] | [Fill in: version and date] |

### 3.2 Configuration baselining

#### 3.2.1 Identification of applicable common secure configurations

The secure configuration each component type follows, and every approved deviation from it, is recorded in the system's part of the [baseline configuration standard](https://kston83.github.io/nist-guide/templates/standards/baseline-configuration-standard/) (CM-6).

#### 3.2.2 Component configuration item baselines

The baseline configuration of the system is the sum of the approved configurations of its configuration items, and is kept under configuration control (CM-2a). Each environment has its own baseline: [Fill in: for example development, test and production, and how test mirrors production]. A new baseline version is recorded when an approved change is implemented, and the previous version is retained under section 2.4.

#### 3.2.3 Non-component object baselines

Documents, diagrams, firmware and scripts are baselined by [Fill in: how, for example as versioned files in the repository, approved through the same change process].

#### Criteria for approving a baseline

A baseline is approved when [Fill in: the criteria, for example it has passed the compliance scan with only approved deviations, its tests have passed, and the system owner has approved it through a change request].

### 3.3 Configuration change control

#### 3.3.1 Handling of scheduled, unscheduled and unauthorized changes

These types of changes to the system are configuration-controlled: [Fill in: the types, for example changes to any configuration item in section 3.1, to settings, to ports, protocols and services, to accounts with privileged access, and to the boundary] (CM-3a). Each is requested on the [change request form](https://kston83.github.io/nist-guide/templates/forms/change-request-form/).

| Change type | Examples | Approval | Impact analysis |
| --- | --- | --- | --- |
| Standard (preapproved) | [Fill in: for example routine patches through the patch management tools, adding a user to an existing role] | Approved once as a class by the board; listed in Appendix B | Done once for the class, and reviewed when the class is reviewed |
| Normal | Any change not standard or emergency | The change control board, before implementation | Before the board decides |
| Emergency (unscheduled) | [Fill in: for example a fix for a known exploited vulnerability that cannot wait for the next meeting] | [Fill in: the role that may approve an emergency change, for example the system owner], then the board at its next meeting | As soon as practical, before the board reviews it |

Changes found by monitoring that have no approved request are treated as unauthorized: they are analyzed for their security impact, reversed or approved after the fact by the board, and investigated as a possible incident where the cause is unknown (SP 800-128 section 3.4).

#### 3.3.2 Security impact analysis

Each change is analyzed for its security and privacy impact before it is approved and implemented (CM-4), by [Fill in: the roles that perform analyses, for example the system security officer or a security engineer, never the person making the change]. The analysis follows the five steps in SP 800-128 section 3.3.3 and is recorded on the change request form, with the analyst's name and the date.

#### 3.3.3 Testing

Changes are tested and validated in [Fill in: the test environment] before they are finalized in production, and the results are recorded on the change request form (CM-3(2)).

#### 3.3.4 Submission of findings to the change control board

The completed request, with its impact analysis and test results, goes to the board [Fill in: how, for example through the change management system at least two business days before the meeting]. A change the analysis marks as a significant change is also reported to the authorizing official, under section 12 of the Continuous Monitoring Strategy.

#### 3.3.5 Change control board evaluation and approval

The board decides under the charter in Appendix A. Each decision, approved, disapproved or on hold, is recorded on the change request with its reason (CM-3c).

#### 3.3.6 Recording requirements

When a change is implemented, the implementer records the date and result; the affected controls are checked; and the baseline, the component inventory, the system security plan and other affected documents are updated (CM-3, CM-4(2), CM-8(1)).

### 3.4 Configuration monitoring

#### 3.4.1 Organization-level tools

[Fill in: the organization-wide tools the system inherits, for example the enterprise compliance scanner and asset discovery service]

#### 3.4.2 System-level tools

[Fill in: tools the system runs itself]. Components the tools cannot check are listed here with the manual check used instead: [Fill in: components and manual checks] (SP 800-128 section 3.4.2).

#### 3.4.3 Monitoring requirements and frequencies

| What is monitored | How | Frequency | Record |
| --- | --- | --- | --- |
| Settings against the baseline (CM-6) | Compliance scan | [Fill in: the frequency in the baseline configuration standard] | Scan evidence in the baseline configuration standard |
| Components against the inventory (CM-8, CM-8(3)) | Asset discovery and network access control | [Fill in: the frequency in the component inventory] | Reconciliation in the component inventory |
| Changes against approved requests (CM-3) | Comparison of deployment history and configuration change logs with the change records | [Fill in: for example monthly] | [Fill in: where the comparison is recorded] |
| Unnecessary functions, ports, protocols and services (CM-7(1)) | Port and service scan against the approved list | [Fill in: the frequency in the baseline configuration standard] | Review record in the baseline configuration standard |

### 3.5 Reporting

#### 3.5.1 Report recipients

| Report | Content | Recipient | Frequency |
| --- | --- | --- | --- |
| Configuration management metrics | [Fill in: for example percentage of components compliant with their baseline, open deviations, unauthorized changes and components found, and percentage of changes with an impact analysis completed before approval] | [System owner], [Chief Information Security Officer] | [Fill in: for example monthly] |
| Significant changes | The change, its analysis and the board's decision | Authorizing official | When the change is proposed |
| Continuous monitoring status | The metrics above, as the Continuous Monitoring Strategy asks | The recipients in the Continuous Monitoring Strategy | Its frequency |

#### 3.5.2 Reviewing reports

The [System owner] reviews each report, opens a change request or a plan of action and milestones item for each problem found, and looks for patterns, such as repeated unauthorized changes by one team, that call for training or tighter access restrictions (SP 800-128 section 3.4.1).

## 4. Plan review and change history

The [System owner] reviews this plan [Fill in: for example at least annually], and updates it when the system's configuration items, environments, tools or board change (CM-9). Changes to the plan go through change control.

| Date | Version | Change or review | By | Approved by |
| --- | --- | --- | --- | --- |
| [Fill in: date] | [Fill in: version] | [Fill in: description] | [Fill in: name and title] | [Fill in: name and title] |

## Appendix A. Change control board charter

**Purpose.** The [Fill in: board name] ensures that proposed changes to [Fill in: system name] go through a structured process before they are made. It asks for an impact analysis of each proposed change, reviews change requests, decides on them, and tells the people affected (CM-3b, CM-3g). It reports to [Fill in: the body it reports to, for example the organization-level change advisory board or the authorizing official].

**Scope of authority.** The board decides on every configuration-controlled change to the system's configuration items, except standard changes listed in Appendix B. It escalates to [Fill in: the higher-level board or official] any change that [Fill in: for example affects another system or a common control, exceeds a cost or schedule limit, or is a significant change].

**Membership.**

| Role | Member | Voting |
| --- | --- | --- |
| Chair | [System owner], or [Fill in: the person the system owner designates] | Yes |
| Security representative | [Fill in: for example the system security officer] (CM-3(4)) | Yes |
| Privacy representative, where the system processes personal information | [Fill in: for example the system privacy officer] (CM-3(4)) | Yes |
| Technical leads | [Fill in: for example the infrastructure lead and the application lead] | Yes |
| Operations and service desk | [Fill in: role] | [Fill in: yes or no] |
| Advisers, such as vendors | [Fill in: roles] | No |

**Operating procedures.** The board meets [Select one or more: [Assignment: organization-defined frequency]; when [Assignment: organization-defined configuration change conditions]. Typical: weekly, and when an emergency change is requested]. A quorum is [Fill in: for example three voting members, including the chair or deputy and the security representative]; without the security representative, no change is approved. The requester of each change attends to answer questions. Guests may attend at the chair's invitation. Minutes record attendance and each decision.

**Decision-making process.** Decisions are made by [Fill in: the rule, for example consensus of the voting members, with the chair deciding if there is none]. Each request is approved, approved with conditions, disapproved or put on hold, with the reason recorded. The chair [Fill in: may or may not] overrule the board's collective decision, and records the reason if so. No member approves a change they requested or will implement.

**Communicating status.** Each decision is recorded on the change request and sent to the requester, the implementer and [Fill in: others, for example the service desk and the system owner] within [Fill in: time, for example one business day]. Significant changes are reported to the authorizing official. Minutes and decisions are kept in [Fill in: location] for the retention period in section 2.4.

## Appendix B. Standard (preapproved) changes

| Standard change | Conditions | Impact analysis reference | Approved by the board on | Next review |
| --- | --- | --- | --- | --- |
| [Fill in: for example monthly operating system updates through the patch management tools] | [Fill in: for example vendor security updates only, deployed in the test group first] | [Fill in: change request ID of the class analysis] | [Fill in: date] | [Fill in: date] |

## Appendix C. References

- [NIST SP 800-128](https://csrc.nist.gov/pubs/sp/800/128/upd1/final), Guide for Security-Focused Configuration Management of Information Systems
- [NIST SP 800-70 Rev. 5](https://csrc.nist.gov/pubs/sp/800/70/r5/final), National Checklist Program for IT Products: Guidelines for Checklist Users and Developers
- [NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), the CM family
- [Fill in: organizational references]