Configuration Management Policy

Approval #

Revision History #

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

1. Purpose and Scope #

In this policy, the CISO sets the Organization’s requirements for configuration management in every information system that the Organization operates or that others operate for it. The CISO issues the policy under these authorities:

• The Federal Information Security Modernization Act (FISMA) of 2014.
• National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5.
• Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource.
• The OMB memoranda and Executive Orders that apply.

The Organization also uses this policy to carry out the NIST Cybersecurity Framework (CSF) 2.0, which Executive Order 13800 and OMB Circular A-130 require.

1.1 Program Objectives #

This policy covers configuration management for every platform the Organization operates. Most exploited weaknesses are known misconfigurations and unauthorized changes. The Organization must keep a hardened baseline for every platform and must control every change with a security impact analysis before deployment. It must keep a complete and current component inventory, including software composition derived from software bill of materialss (SBOMs). It must detect drift from approved baselines automatically.

This policy applies to everyone in the program: executives who accept risk, System Owners who fund the controls, security officers who run them, and every user. By following it, the Organization meets its FISMA obligations for this control family and shows its maturity in the annual Inspector General (IG) FISMA evaluation. The Organization’s target is Level 4 (Managed and Measurable). The CISO tracks progress with the performance measures and the improvement commitments later in this policy.

1.2 CSF 2.0 Alignment #

The controls in this policy support these CSF 2.0 categories:

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

These categories fall under the Detect, Identify, Protect function(s) of CSF 2.0. The Organization’s CSF 2.0 Profile maps each category to the NIST SP 800-53 controls in this policy.

This policy covers every configuration management control in the low baseline of FIPS 200 and NIST SP 800-53B:

• CM-01 — Policy and Procedures
• CM-02 — Baseline Configuration
• CM-04 — Impact Analyses
• CM-05 — Access Restrictions for Change
• CM-06 — Configuration Settings
• CM-07 — Least Functionality
• CM-08 — System Component Inventory
• CM-10 — Software Usage Restrictions
• CM-11 — User-installed Software

2. Authority and References #

The CISO issues this policy under the authority of:

• FISMA 2014 (44 U.S.C. § 3551 et seq.) — Statutory mandate for federal information security programs
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• OMB Circular A-130 — Managing Information as a Strategic Resource
• OMB Circular A-123 — Management’s Responsibility for Internal Control (revised March 10, 2026)
• NIST CSF 2.0 — Cybersecurity Framework (mandated by EO 13800 and OMB Circular A-130)
• EO 13800 — Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• 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.
• 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.

2.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 in the Policy section.

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)

3. Policy #

The Organization must implement and maintain its configuration management controls to meet the following requirements:

CM-01 — Policy and Procedures #

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

Requirement:

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].

Implementation guidance:

The Organization must keep an organization-level configuration management policy and the procedures that put it into practice. The designated officials manage the development, documentation, and distribution of both documents. They must deliver each approved version to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and the key stakeholders who follow it. The policy must state why the program exists, what it covers, who owns each duty, how organizational units coordinate, and what compliance requires. It must stay consistent with the laws, executive orders, directives, and regulations that apply to the Organization. The designated officials must review and update the policy and the procedures every year. They must also review both documents after a major incident or a major change to applicable policy.

CM-02 — Baseline Configuration #

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

Requirement:

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.

Implementation guidance:

System Owners must develop and maintain a current baseline configuration for each system and keep it under configuration control. The baseline must list the system’s components, their placement in the architecture, and the settings the system depends on. System Owners must review and update the baseline every year. They must also update it when the system boundary or architecture changes significantly, when applicable policy directs, and when someone installs or upgrades a component. Administrators must bring each new or rebuilt component to the approved baseline and the current patch level before it joins a production network. Under Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive (BOD) 25-01, the Organization monitors cloud baselines in the cloud platform for drift and enforces them with automated tooling. Administrators deploy the endpoint baseline through the mobile device management (MDM) tool and the domain baseline through group policy. Configuration compliance scans verify that deployed systems still match the approved record. A baseline that no longer matches the running system is a finding.

CM-04 — Impact Analyses #

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

Requirement:

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

Implementation guidance:

The ISSO must analyze each proposed configuration-controlled change for its security and privacy impact before anyone implements it, following NIST SP 800-128. The ISSO must coordinate with the Privacy Officer when the change affects personal information. In the analysis, the ISSO must find the change’s vulnerabilities, assess the risk, identify the affected controls, and plan safeguards. The ISSO must also decide whether the change counts as significant under NIST SP 800-37 Rev 2, and the Authorizing Official decides whether a significant change needs reauthorization. No change may reach the Configuration Control Board without its completed analysis.

CM-05 — Access Restrictions for Change #

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

Requirement:

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

Implementation guidance:

System Owners must define and document the physical and logical access restrictions that govern who may modify each system. The CISO must approve those restrictions before anyone enforces them. Only qualified and explicitly authorized individuals may start a configuration-controlled change. Authorization follows the role: the System Owner records it and withdraws it when the person’s duties change. Group policy enforces the logical restrictions for domain resources, and customer-configured access policies in the cloud platform enforces them for cloud infrastructure. Physical restrictions govern access to the spaces where a person can change a system. Any person who can alter a system without an approved restriction that covers them is a gap the System Owner must close.

CM-06 — Configuration Settings #

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

Requirement:

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.

Implementation guidance:

System Owners must configure every system component to the most restrictive settings that still meet explicit mission and business requirements. The CISO sets the approved baseline for each kind of component, the deviation approvers, the scan thresholds, and the time to fix drift in the Secure Configuration Baseline Standard (STD-CFG-001). System Owners must implement the approved settings. The System Owner must identify and document each deviation, and get it approved under that standard before it exists in production. Administrators must apply the baseline settings and current patches to each new or rebuilt component, and confirm them with a compliance scan, before it joins a production network. Administrators apply and hold the settings through the MDM tool and group policy, and configuration compliance scans verify them. Under CISA BOD 25-01, System Owners apply the mandatory secure configuration policies to each in-scope cloud tenant. An undocumented deviation is an unauthorized change.

CM-07 — Least Functionality #

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

Requirement:

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].

Implementation guidance:

System Owners must configure each system to provide only the capabilities its mission requires. The System Owner must document the permitted ports, protocols, software, and services in the System Security and Privacy Plan (SSPP) and the authorization package. No system may run the auto-execute function or peer-to-peer file sharing services unless the CISO authorizes them. High-risk services and protocols that an approved benchmark restricts stay restricted. System Owners decide which functions are mission-essential for their systems, and the ISSO verifies that the running system matches that decision. The Organization treats function creep as configuration drift: the ISSO finds it and opens a ticket, and the System Owner removes it.

CM-08 — System Component Inventory #

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

Requirement:

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.

Implementation guidance:

System Owners must keep a component inventory for each system that accurately reflects the system and includes every component in it. Each component belongs to exactly one system, with no duplicates and no orphans. Each record must carry, at a minimum, the hostname, Internet Protocol (IP) address, manufacturer, type, model, name, serial number, version number, and logical location. Physical hardware records must also carry the item and barcode. System Owners must review and update the inventory at least every month and after each significant system change. Under CISA BOD 23-01, the inventory must reflect the network as scanned. System Owners must include SBOM data that meets the CISA 2026 SBOM Minimum Elements. Under OMB M-21-30, System Owners must flag each product that meets NIST’s definition of critical software under Executive Order 14028. The Chief Information Officer (CIO) sets the rules for the same assets across their life cycle, for software licenses, and for the yearly physical inventory in the IT Asset Management Policy (POL-ITAM-001).

CM-10 — Software Usage Restrictions #

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

Requirement:

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.

Implementation guidance:

All personnel must use software and its documentation under the contract agreements and copyright law that govern it. The Organization must track software protected by quantity licenses to control copying and distribution. System Owners must not permit deployment beyond the entitlements the Organization holds. The Software Manager keeps the agency-wide license inventory and runs the monthly true-up under the IT Asset Management Policy (POL-ITAM-001). Where the Organization authorizes peer-to-peer file sharing, it must control and document that use so no one distributes copyrighted work without authorization. The Organization prohibits unauthorized peer-to-peer use and treats it as a policy violation.

CM-11 — User-installed Software #

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

Requirement:

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)).

Implementation guidance:

The Organization Rules of Behavior govern how users install software, and every user must accept them before receiving access. The Organization must enforce installation rules technically, at a minimum through the approved whitelist and blacklist. Software the whitelist does not authorize, or the blacklist names, does not install. The CISO must make sure the Organization monitors compliance continuously. System Owners must treat an unauthorized installation as a configuration incident: they remove it, open a ticket, and trace it to the control that should have prevented it. A user who needs software the list does not cover must request it. The request process is the only sanctioned path to a new installation.

Security Impact Analysis and Significant Change #

The ISSO must analyze the security and privacy impact of every proposed change to a system before the Configuration Control Board decides on it. A significant change is a change that is likely to substantively affect the security or privacy posture of a system, as NIST SP 800-37 Rev. 2 defines it.

• The ISSO must complete a security impact analysis for each proposed change and record it in the change ticket in the ticketing system.
• The ISSO must follow the five analysis steps in NIST SP 800-128.
• The Configuration Control Board must not approve a change until the analysis is complete.
• When the analysis finds a significant change, the Security Control Assessor must review it and record whether the current authorization still holds.
• The Authorizing Official must then decide whether the change needs a new assessment or a new authorization. The Authorizing Official must decide before the change goes into production.
• The System Owner must sign each completed analysis. The ISSO must store the signed analysis with the system’s authorization records in the governance, risk, and compliance (GRC) system.

The ISSO must treat each of these changes as significant:

• a new or upgraded operating system, middleware component, or application;
• a change to the system’s ports, protocols, or services;
• a new or upgraded hardware platform;
• a change to how the system processes information, including personally identifiable information (PII);
• a change to cryptographic modules or services;
• a change to security or privacy controls;
• a move to a new facility or to a new hosting or cloud provider;
• a change to the authorization boundary, a new subsystem, or a merger with another system;
• a new connection to another system, or a new public-facing IP address or URL;
• a change to the system’s information types or security category;
• a new Authorizing Official for the system;
• the loss of a cloud provider’s Federal Risk and Authorization Management Program (FedRAMP) authorization.

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.

Related Required Processes #

• The ISSO reviews significant change notices from FedRAMP authorized cloud providers under Using FedRAMP and FedRAMP 20x Authorized Cloud Services in the Assessment, Authorization, and Monitoring procedure.

4. Roles and Responsibilities #

These roles apply across this policy. Each System Owner records the system-specific assignments in the system’s System Security and Privacy Plan (SSPP).

5. Performance Measurement #

The CISO manages this policy with the measures below, which meet the IG FISMA maturity model’s Level 4 (Managed and Measurable) criteria. The CISO collects and trends the measures and reports them to the CIO and the Authorizing Officials. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.

The CISO keeps the measurement data for the annual IG FISMA evaluation and for trend analysis across reporting periods.

6. Compliance and Enforcement #

Every employee, contractor, and other user with access to an information system that the Organization operates, or that others operate for it, must comply with this policy. The CISO records each case of non-compliance as a finding in the Organization’s continuous monitoring program. The ISSO tracks the finding to resolution as a POA&M item, as OMB Circular A-130 and NIST SP 800-37 Rev. 2 describe.

A violation of this policy can lead to suspension of system access, withdrawal of the system’s authorization to operate (ATO), and administrative or disciplinary action under applicable law, regulation, and human capital policy.

The Inspector General assesses the maturity of configuration management controls each year through the IG FISMA reporting metrics. The target maturity level for this policy area is Level 4: Managed and Measurable.

7. Continuous Improvement #

Level 4 is the minimum the Organization aims for. To meet the IG FISMA maturity model’s Level 5 (Optimized) criteria, the CISO improves configuration management through these commitments:

1. Review the performance measures in this document at least annually; where a measure has met its target for four consecutive periods, tighten the target or replace the measure with a more demanding indicator.
2. Conduct an annual effectiveness review of this policy area using IG FISMA audit results, assessment findings, incident data, and metric trends; document resulting changes in the revision history.
3. Feed lessons learned from incidents, assessments, and exercises into updates of this document and its procedures within 90 days of the triggering event.
4. Benchmark against the IG FISMA maturity model annually and maintain a documented plan to reach and sustain Level 4 (Managed and Measurable), with a roadmap toward Level 5 (Optimized).
5. Enforce configuration baselines as code with automated remediation of drift, reducing mean time from detection to correction.
6. Integrate SBOM ingestion into the CMDB so software composition updates automatically with each release.

8. Exceptions and Waivers #

The CISO may grant an exception to this policy only when compliance is not technically feasible or would harm the mission. To request one, the System Owner sends the CISO a written request that includes:

1. A business justification and a risk assessment.
2. Compensating controls that reduce the risk the exception creates, following the NIST SP 800-53B guidance on compensating controls.
3. A proposed end date no more than one year away.

The CISO decides each request in coordination with the Authorizing Official. An exception that involves privacy risk also needs the agreement of the Senior Agency Official for Privacy (SAOP). The CISO re-evaluates each exception when it comes up for renewal. The System Owner records each approved exception in the system’s SSPP, and the ISSO tracks it as a POA&M item.

9. References #

These are the sources this document cites, with a link to each official text.

• 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 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 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 BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• CISA Known Exploited Vulnerabilities Catalog, updated continuously.
• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• 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-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems, August 2011.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures, August 10, 2021.
• 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.