Configuration Management Procedure

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose #

The people named in this procedure use it to carry out the CM control family policy (POL-CM). It covers every control in the configuration management family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the CM family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the low security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

• ID.AM — Asset Management (Identify function)
• PR.PS — Platform Security (Protect function)
• DE.CM — Continuous Monitoring (Detect function)

3. Controls Covered #

This procedure covers the following 9 controls in the CM family:

3.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the CM control family. They add to the NIST SP 800-53 control requirements that the Procedure section carries out.

CISA BOD 26-04: Prioritizing Security Updates Based on Risk

• The organization must remediate vulnerabilities identified in the CISA Known Exploited Vulnerabilities (KEV) catalog according to risk-based timelines. Vulnerabilities with higher KEV Status, Exploit Automation, Technical Impact, and Asset Exposure scores must be prioritized. Deadline: Risk-based timeline per KEV catalog. (CISA BOD 26-04, §1)

CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices

• The organization must identify all end-of-support (EOS) edge devices on the network and plan to replace or mitigate each one, because these devices no longer receive security patches. (CISA BOD 26-02, §1)

CISA BOD 25-01: Implementing Secure Practices for Cloud Services

• The organization must implement secure configuration baselines for cloud computing environments, including monitoring for configuration drift and enforcing baseline compliance through automated tooling. (CISA BOD 25-01, §2)

CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection

• The organization must maintain continuous and comprehensive asset visibility through active scanning, passive flow monitoring, log queries, or API queries. Asset inventory must be kept current to enable effective vulnerability management. (CISA BOD 23-01, §1)

FedRAMP CR26: FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators)

• The organization must review each provider’s Secure Configuration Guide and set the Organization’s security settings in the cloud service to match it. (FedRAMP Consolidated Rules for 2026, AGU-USE-RSG)

OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures

• The organization must identify the EO-critical software the Organization uses or is acquiring, and apply NIST’s security measures for EO-critical software to it. (OMB M-21-30; EO 14028, §4(g)-(i))

CISA/NSA/FBI 2026 Minimum Elements for a Software Bill of Materials (SBOM)

• The organization should incorporate SBOM data into the system component inventory so that software components and their dependencies are traceable, supporting vulnerability correlation (including KEV catalog matching) and change management. (CISA 2026 SBOM Minimum Elements, Discussion)

NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems

• The organization should analyze the security impact of each proposed change before approval, and check after the change that controls still work as intended. (NIST SP 800-128, §3.3)

4. Procedure #

4.1 General Implementation Approach #

The Organization implements the CM controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the Configuration Management family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Configuration Manager carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the CM policy (POL-CM) for the role definitions.

4.2 Control-Specific Procedures #

CM-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: PR.PS (Platform Security)

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] configuration management policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the configuration management policy and the associated configuration management controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the configuration management policy and procedures; and
3. Review and update the current configuration management:

1. Policy at least every 3 years and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Procedure:

The CISO’s office keeps the master copies of POL-CM and PROC-CM as controlled documents on behalf of the designated officials. The CISO’s office tracks the review cycle and opens the review task in the policy library in the document management system every 3 years. The CISO’s office opens an out-of-cycle review the same way after a major incident or a major change to applicable policy.

During a review, the document owner compares the text with current directives, the technology environment, and lessons from incidents and assessments. The document owner then sends the revision to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and the key stakeholders on the distribution list. The document owner records the approval in the review record, updates the version history, and keeps the superseded version.

The CISO’s office verifies distribution: the distribution record shows who received each revision and when. Evidence: the review records in the document management system with their triggers, the approval records, the version history, and the distribution log for each release of the policy and procedures.

CM-02 — Baseline Configuration #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

1. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and
2. Review and update the baseline configuration of the system:

1. at least annually and when a significant change occurs;
2. When required due to include when directed by the AO; and
3. When system components are installed or upgraded.

Procedure:

The System Owner keeps each system’s baseline configuration under configuration control. The System Owner records the approved component list, the architecture placement, and the required settings, and gives each revision a version number. The System Owner links every revision to a ticketing system change record. Administrators deploy the endpoint baseline through the mobile device management (MDM) tool and enforce the domain baseline through group policy. Administrators build the cloud platform infrastructure from the approved templates for the environment.

Before a new or rebuilt component joins a production network, the administrator applies the approved baseline and the current patches. The administrator confirms both with a compliance scan and records the result on the change ticket. The ISSO records any exception as an approved deviation.

The System Owner and ISSO review each baseline every year against the running system. A significant change to the system boundary or architecture, a directive from applicable policy, or a component installation or upgrade requires an out-of-cycle update through the same change workflow. Configuration compliance scans run against the approved baseline and report drift. Each drift report becomes a remediation ticket in the ticketing system, assigned to the owning administrator.

Evidence: the versioned baseline records, the yearly review sign-offs, the ticketing system change tickets with pre-production scan results, and the scanner compliance reports that show deployed systems match the approved baseline.

CM-04 — Impact Analyses #

Baselines: Low / Moderate / High / Privacy CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

Analyze changes to the system to determine potential security and privacy impacts prior to change implementation.

Procedure:

The ISSO receives the impact analysis task in the ticketing system when a requester opens a change request. The request cannot advance until the ISSO completes the analysis. The ISSO follows the security impact analysis steps in NIST SP 800-128. The ISSO first confirms what the change does. The ISSO then looks up known vulnerabilities in the National Vulnerability Database or scans the affected hosts. Next the ISSO assesses the risk, finds the affected controls in the System Security and Privacy Plan (SSPP), and plans safeguards. The ISSO consults the Privacy Officer when the change touches personal information.

The ISSO also decides whether the change counts as significant. If it does, the Security Control Assessor reviews it, and the Authorizing Official decides on reassessment or reauthorization before the change reaches production. The System Owner signs the completed analysis. The Configuration Control Board considers the analysis, and its conditions become conditions of approval. For an emergency change, the ISSO completes the same analysis before the ticket closes. The Security Impact Analysis and Significant Change section of the Configuration Management procedure gives the full steps.

Evidence: the signed impact analysis on each change ticket, the privacy consultation records, the significant-change decisions, and the board decisions.

CM-05 — Access Restrictions for Change #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.

Procedure:

Each system’s documented access restrictions name the roles authorized to implement configuration-controlled changes and the physical and logical controls that enforce the limit. The identity team implements the logical side. Group policy scopes administrative rights on domain-joined systems, and the cloud platform access policies limit infrastructure changes to the authorized change-implementer roles. Physical access to the spaces that house change interfaces follows the same authorization records.

A person requests change authorization through the ticketing system, tied to role and need, and the System Owner approves or denies it. The System Owner removes the authorization as soon as the person’s duties change, without waiting for a scheduled review. The ISSO reconciles who holds change access against the documented restrictions and opens corrections where they differ.

Evidence: the approved access restriction documentation for each system, the authorization requests and approvals, the enforced group policy and identity and access management (IAM) policy exports, and the reconciliation records.

CM-06 — Configuration Settings #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

1. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations — to be defined];
2. Implement the configuration settings;
3. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components — to be defined] based on [Assignment: organization-defined operational requirements — to be defined]; and
4. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures.

Procedure:

The configuration management team selects each platform’s baseline under the Secure Configuration Baseline Standard (STD-CFG-001) and builds the enforced settings from it. Administrators apply and maintain endpoint settings through the MDM tool, enforce domain settings through group policy, and configure the cloud platform environments to the approved cloud baseline.

Before a new or rebuilt component joins a production network, the administrator applies the baseline settings and current patches and runs a compliance scan. The administrator connects the component only after the scan shows no unapproved deviation and no missing patch.

A requester opens a deviation request in the ticketing system with its operational justification and risk rationale. The approver listed in the standard for that kind of setting decides it, and the ISSO records each approved deviation. Configuration compliance scans run at the frequency the standard sets, against the baseline plus the approved deviations. Each drift finding becomes a remediation ticket for the owning administrator, due within the standard’s fix time. A rescan verifies closure.

Evidence: the baseline register, the pre-production scan results, the approved deviations, the compliance scan reports, the drift tickets with closure verification, and the change records behind every settings change.

CM-07 — Least Functionality #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

1. Configure the system to provide only [Assignment: organization-defined mission-essential capabilities — to be defined]; and
2. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services — to be defined].

Procedure:

The System Owner documents each system’s authorized functions, ports, protocols, software, and services with the System Security and Privacy Plan (SSPP), and administrators build the enforced configuration from that record. Group policy disables auto-execute and restricts prohibited functions on domain systems. The MDM tool enforces the same restrictions on managed endpoints. The cloud platform network security rules limit cloud workloads to their documented ports and protocols.

Vulnerability scans list what is listening and installed on each system. The ISSO compares the results with the documented authorization. For a service with no documented justification, the ISSO opens a ticketing system ticket to the System Owner for removal. Where the mission requires the service, the CISO authorizes an exception and the System Owner records it against the SSPP. The System Owner removes peer-to-peer file sharing found running without CISO authorization; no one approves it after the fact.

Evidence: the documented port, protocol, and service authorizations, the scan results, the removal and exception tickets, and the updated SSPP records.

CM-08 — System Component Inventory #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

1. Develop and document an inventory of system components that:

1. Accurately reflects the system;
2. Includes all components within the system;
3. Does not include duplicate accounting of components or components assigned to any other system;
4. Is at the level of granularity deemed necessary for tracking and reporting; and
5. Includes the following information to achieve system component accountability: [Assignment: organization-defined information — to be defined]; and

2. Review and update the system component inventory at least monthly.

Procedure:

The ticketing system configuration management database (CMDB) is the authoritative component inventory, with one record per component and each component assigned to a single system. Implementers create and retire records through the change process: the implementer updates the CMDB before closing an installation, removal, or upgrade ticket.

The vulnerability management team runs scanner discovery scans that reconcile what they find against the CMDB. Unmatched discoveries and stale records become correction tickets to the System Owner. Each component record holds the required attributes, and the System Owner attaches SBOM data to software records. The System Owner flags each product that meets NIST’s definition of critical software, with the platform it runs on. The configuration management team applies NIST’s security measures for critical software to each flagged product. The ISSO records any measure not yet in place as a plan of action and milestones (POA&M) item.

At least every month, and after each significant system change, the System Owner certifies that the inventory is accurate. The IT Asset Manager reconciles accountable IT equipment, including devices at telework locations, under the IT Asset Management Procedure (PROC-ITAM-001).

Evidence: the CMDB records with their change history, the critical software flags, the correction tickets, and the monthly certification.

CM-10 — Software Usage Restrictions #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

1. Use software and associated documentation in accordance with contract agreements and copyright laws;
2. Track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and
3. Control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.

Procedure:

Software enters the environment through the authorized software process, and its license terms enter with it. The administrator records the license type, the entitlement count, and the contract reference in the ticketing system with the software record. The Software Manager compares deployment counts from scanner software inventory data with entitlements in the monthly true-up. For each over-deployment, the Software Manager opens a correction ticket to the System Owner, who removes installations or acquires licenses and documents the resolution.

The Software Manager keeps the license inventory and reports to the Chief Information Officer (CIO) under the IT Asset Management Procedure (PROC-ITAM-001).

The least-functionality controls block peer-to-peer file sharing by default. Where the CISO has authorized a specific use, the authorization documents the purpose and the safeguards against misuse of copyrighted work, and the ISSO reviews usage against it.

Evidence: the license records with entitlements, the correction tickets, and the peer-to-peer authorizations with their reviews.

CM-11 — User-installed Software #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

1. Establish [Assignment: organization-defined policies — to be defined] governing the installation of software by users;
2. Enforce software installation policies through the following methods: [Assignment: organization-defined methods — to be defined]; and
3. Monitor policy compliance Continuously (via CM-7 (5)).

Procedure:

The Organization enforces installation rules at the endpoint. The MDM tool application controls and group policy software restriction policies implement the whitelist and blacklist, so an unauthorized installation fails at the attempt. Users acknowledge the Organization Rules of Behavior, which state what they may install and how to request what is missing. Requests go through the ticketing system to security review.

Continuously, the ISSO runs the compliance review. The ISSO compares scanner software inventory data with the authorized list. The System Owner removes any unauthorized software found installed, and the ISSO opens a ticket and examines how it bypassed enforcement. Trends, such as repeat offenders and repeat software, inform policy and training.

Evidence: the enforcement policy exports, the Rules of Behavior acknowledgments, the continuous compliance reports, and the removal tickets with their root-cause notes.

4.3 Security Impact Analysis and Significant Change #

The ISSO runs the security impact analysis for every change request in the ticketing system before the Configuration Control Board meets on it. The first step follows the five analysis steps in NIST SP 800-128. The second step decides whether the change is significant and, if it is, who must act before production.

Step 1: Analyze the change #

Find out how the proposed change affects the system’s controls and risk.

Step 2: Decide whether the change is significant #

Send significant changes to the assessor and the Authorizing Official before production.

Step 3: Sign, store, and verify #

Keep the record and confirm the controls still work.

Evidence: the change ticket with the analysis and the significant change answer, the assessor’s review, the Authorizing Official’s decision, and the signed analysis in the GRC system.

Source: NIST SP 800-37 Rev. 2, Appendix F (significant change and reauthorization); NIST SP 800-128 with Update 1 (2019), section 3.3 (security impact analysis); NIST SP 800-53 Rev. 5, CM-04 and CA-06.

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Configuration baseline documents
• Change request tickets and approvals
• Configuration change log
• CM board meeting minutes
• Evidence for IG FISMA metric RAM.01
• Evidence for IG FISMA metric RAM.02
• Evidence for IG FISMA metric RAM.03
• Evidence for IG FISMA metric RAM.04
• Evidence for IG FISMA metric CM.01
• Evidence for IG FISMA metric CM.02
• Evidence for IG FISMA metric CM.16

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the POA&M process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• 2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA/NSA/FBI joint guidance: CISA/NSA/FBI joint guidance, July 29, 2026.
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
• CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices, February 5, 2026.
• CISA Known Exploited Vulnerabilities Catalog, updated continuously.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems, August 2011.
• OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures, August 10, 2021.