# Baseline Configuration Standard

**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/standards/baseline-configuration-standard/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

> **Guidance:** The configuration management policy says every component is configured to the most restrictive settings that still let the system work, using published secure configurations, and that every deviation is approved; this standard names those configurations, records the deviations and holds the evidence. Keep its values in step with the CM-2, CM-6 and CM-7 statements in the policy, since assessors compare the two. Configuration settings are among the most tested controls because scanners make them easy to measure: assessors run or ask for a compliance scan, and ask for the approval behind every failed setting. Start from a published configuration rather than writing your own. [NIST SP 800-128](https://csrc.nist.gov/pubs/sp/800/128/upd1/final) (August 2011, with updates as of October 10, 2019) section 3.2.1 names the National Checklist Program, DISA Security Technical Implementation Guides (STIGs) and CIS Benchmarks as sources of common secure configurations, and product vendors as another. [NIST SP 800-70 Rev. 5](https://csrc.nist.gov/pubs/sp/800/70/r5/final), National Checklist Program for IT Products (final May 8, 2026, superseding Rev. 4), explains how to find and use checklists in the [National Checklist Program repository](https://ncp.nist.gov/repository). Both are current as of October 2026. Reference a benchmark by name and version; do not copy its text into this standard, since some benchmarks carry license terms.

| Owner | Approved by | Version | Effective date |
| --- | --- | --- | --- |
| [Chief Information Security Officer] | [Fill in: name and title] | [Fill in: version] | [Fill in: date] |

## 1. Purpose and scope

This standard sets the minimum requirements for the secure configuration of the systems of [Organization name]: the published configurations each component type starts from, the functions the organization prohibits or restricts, how baselines are recorded and kept current, how deviations are approved, and how compliance is shown. It applies to every component in each system's [component inventory](https://kston83.github.io/nist-guide/templates/forms/component-inventory/), including virtual machines, container images, network and security devices, databases, applications and the settings of cloud services the organization configures.

Part A applies across the organization. Each system completes Part B, which its [Configuration Management Plan](https://kston83.github.io/nist-guide/templates/plans/configuration-management-plan/) references.

## 2. Roles

| Role | Responsibilities |
| --- | --- |
| [Chief Information Security Officer] | Owns this standard; selects the secure configuration for each component type; provides the compliance scanning tools and content; reviews deviations that affect more than one system |
| [System owner] | Completes Part B for the system; keeps the baseline current; approves the system's deviations; acts on scan results |
| Security representative, such as the system security officer | Reviews each deviation request before the system owner approves it; reviews scan results |
| System administrators and engineers | Build and maintain components to the baseline; test configurations; request deviations through change control |
| [Security operations team] | Runs compliance scans, reports results, and responds to unauthorized changes |

## Part A. Organization-wide requirements

### 3. Secure configurations

- Each component type shall be configured using [Fill in: common secure configurations to establish and document configuration settings for components employed within the system. Typical: the secure configuration baselines named in the baseline configuration standard], set to the most restrictive mode consistent with operational requirements. (CM-6a)
- The secure configuration for a component type shall be chosen in this order: a checklist for the product and version from the National Checklist Program repository, which includes DISA STIGs and CIS Benchmarks; failing that, the vendor's published security baseline; and only where none exists, a configuration the [Chief Information Security Officer] approves, written from the vendor's hardening documentation. (CM-6a)
- The configuration settings shall be implemented on every component before it is connected to a production network or placed in service. (CM-6b)
- Each component type's configuration shall be tested before use, in a test environment where one exists, and conflicts resolved or recorded as deviations under section 8. (CM-6b)

| Component type | Secure configuration and version | Source | Profile or level | Scan content used to check it | Owner |
| --- | --- | --- | --- | --- | --- |
| [Fill in: for example server operating system, by product and version] | [Fill in: benchmark name and version] | [Fill in: National Checklist Program, DISA, CIS, or vendor] | [Fill in: for example the level 1 or the member-server profile] | [Fill in: for example the SCAP content or scanner policy name and version] | [Fill in: role] |

> **Guidance:** SP 800-128 section 3.2.2 suggests where to start when not everything can be done at once: higher-impact systems first, then the components risk assessments and vulnerability scans point to, and the product deployed most widely, since one configuration covers the most components. Benchmarks are written for a product version; when the version changes, the benchmark usually changes too, which is a trigger for the baseline review in section 6.

### 4. Settings every baseline includes

Whatever its source, each baseline shall include these settings where the component supports them. (CM-6a)

- disable portable storage devices on servers, and on other components allow only the organization-issued devices the Media Protection Policy permits (MP-7);
- keep the platform's memory protections on, such as address space layout randomization and data execution prevention (SI-16);
- restrict mobile code and active content, such as office document macros, scripts and browser extensions, to what the organization allows (SC-18);
- change or disable default accounts and passwords, and remove sample content and unused default services (CM-6, IA-5);
- enable the audit events the Audit and Accountability Policy requires (AU-2, AU-12);
- turn on host firewalls, allowing only the ports and protocols in Part B (CM-7, SC-7);
- set session lock and time limits (AC-11, AC-12);
- install updates automatically or through the patch management tools (SI-2).

### 5. Prohibited and restricted functions, ports, protocols, software and services

- Each system shall be configured to provide only [Fill in: mission-essential capabilities for the system. Typical: the capabilities documented in the system security plan]. (CM-7a)
- The use of [Fill in: prohibited or restricted functions, system ports, protocols, software, and/or services. Typical: the functions, ports, protocols, software and services listed as prohibited or restricted in the baseline configuration standard] shall be prohibited or restricted: the table below lists those that apply to all systems, and each system adds its own in Part B. (CM-7b)

| Item | Prohibited or restricted | Condition for restricted use |
| --- | --- | --- |
| [Fill in: for example unencrypted remote administration protocols, such as Telnet] | [Fill in: prohibited] | |
| [Fill in: for example file sharing protocols on internet-facing components] | [Fill in: restricted] | [Fill in: for example only on internal file servers] |
| [Fill in: for example peer-to-peer file sharing software] | [Fill in: prohibited] | |
| [Fill in: for example remote access tools other than the managed remote access service] | [Fill in: prohibited] | |

### 6. Baseline configuration

- Each system shall develop, document and maintain under configuration control a current baseline configuration, recorded in Part B and in the locations its Configuration Management Plan names. (CM-2a)
- The baseline shall record, for each configuration item, the secure configuration and version it follows, its approved deviations, its software and firmware versions, and its place in the system architecture. (CM-2a)
- The baseline shall be reviewed and updated [Fill in: the frequency of baseline configuration review and update. Typical: at least annually], when required by [Fill in: the circumstances requiring baseline configuration review and update. Typical: a significant change to the system, a new version of the secure configuration it is based on, or a security incident], and when components are installed or upgraded. (CM-2b)
- Changes to the baseline shall be made only through the change request process, and each new baseline version shall name the change requests it includes. (CM-2a, CM-3)
- [Fill in: the number of previous baseline configuration versions to be retained. Typical: at least the two most recent] previous versions of each baseline shall be retained, protected to the same level as the system, to support rollback. (CM-2(3))
- Baselines shall be kept current, complete, accurate and available using [Fill in: automated mechanisms for maintaining baseline configuration of the system. Typical: configuration management and infrastructure-as-code tools that record the approved baseline]. (CM-2(2))
- Individuals traveling to locations the organization deems to be of significant risk shall be issued [Fill in: the systems or system components to be issued when individuals travel to high-risk areas. Typical: loaner laptops and mobile devices] with [Fill in: configurations for systems or system components to be issued when individuals travel to high-risk areas. Typical: a minimal configuration with full-disk encryption, no stored organizational data and access only through the organization's VPN], and on their return [Fill in: the controls to be applied when the individuals return from travel. Typical: inspecting the device, wiping and reimaging it before reuse, and resetting the user's credentials] shall be applied. (CM-2(7))

### 7. Implementing and enforcing settings

- Settings shall be applied centrally, through group policy, configuration management tools or infrastructure as code, rather than by hand, wherever the component supports it. (CM-6b)
- Images and templates shall be built from the current baseline and rebuilt when it changes, so new components start compliant. (CM-2, CM-6b)
- Changes to configuration settings shall be monitored and controlled through the change request process. (CM-6d)

This paragraph applies to High systems.

- Configuration settings for [Fill in: system components for which to manage, apply, and verify configuration settings. Typical: all servers, workstations and network devices] shall be managed, applied and verified using [Fill in: automated mechanisms. Typical: configuration management tools and compliance scanning]. (CM-6(1))
- In response to an unauthorized change to [Fill in: configuration settings requiring action upon an unauthorized change. Typical: security-relevant settings in the baseline configuration], the [System owner] shall [Fill in: actions to be taken upon an unauthorized change. Typical: alert the security operations team, restore the approved setting and investigate the change as a potential incident]. (CM-6(2))

### 8. Deviations

- Any deviation from the established settings for [Fill in: system components for which approval of deviations is needed. Typical: all system components] shall be identified, documented and approved, based on [Fill in: operational requirements necessitating approval of deviations. Typical: documented operational needs that the system owner approves and the security team reviews]. (CM-6c)
- A deviation shall be requested through a change request, with the operational need, the risk and any compensating measures, reviewed by the security representative, and approved by the [System owner] before the setting is changed. (CM-6c)
- A deviation that leaves a high-risk setting unmet, such as one the benchmark marks as most severe, shall also be accepted by an official the risk management strategy authorizes to accept risk at that level. (CM-6c, RA-7)
- Each approved deviation shall be entered in the system's deviation register in Part B and configured as an exception in the scanner, so compliance reports show it as approved rather than as a failure. (CM-6c)
- Each deviation shall have an expiry or review date, and shall be reviewed at each baseline review, when the benchmark version changes, and when the component is upgraded. (CM-6c)

### 9. Compliance scanning and evidence

- Every component in the component inventory shall be scanned against its secure configuration [Fill in: frequency, for example at least monthly, matching the frequency the Continuous Monitoring Strategy sets for configuration data], using authenticated scans with SCAP-validated tools and SCAP content where available. (CM-6d)
- Each scan cycle shall report the components the scan did not reach, and those components shall be checked by another means and recorded. (CM-6d)
- Components the tools cannot check, such as some appliances, shall be checked manually against their configuration on the same cycle, with the check recorded. (CM-6d)
- A failed setting with no approved deviation shall be corrected, or entered in the system's plan of action and milestones, within [Fill in: time, for example 30 days]. (CM-6b, CA-5)
- Scan results shall be kept as evidence for at least [Fill in: retention, for example three years, or the authorization period]. (CM-6)

### 10. Unauthorized changes

- Differences between a component's settings and its baseline that match no approved change request or deviation shall be treated as unauthorized changes: reported to the [System owner], reversed or approved after the fact through change control, and investigated as a potential incident where the cause is unknown. (CM-3, CM-6d)

### 11. Least functionality review

- Each system shall be reviewed [Fill in: the frequency at which to review the system to identify unnecessary and/or non-secure functions, ports, protocols, software, and/or services. Typical: at least quarterly], using port, service and software scans compared with Part B, to identify unnecessary or nonsecure functions, ports, protocols, software and services. (CM-7(1)(a))
- The [System owner] shall disable or remove [Fill in: functions, ports, protocols, software, and services within the system deemed to be unnecessary and/or nonsecure. Typical: any function, port, protocol, software or service the review finds unnecessary or nonsecure], through a change request. (CM-7(1)(b))

## Part B. System baseline

Complete one Part B for each system.

| System | System owner | Configuration Management Plan | Baseline version | Last reviewed |
| --- | --- | --- | --- | --- |
| [Fill in: system name and identifier] | [Fill in: name and title] | [Fill in: location] | [Fill in: version] | [Fill in: date] |

### 12. Configuration items and their secure configurations

| Configuration item | Component type | Secure configuration and version | Image, template or code that applies it | Components covered | Last scan and result |
| --- | --- | --- | --- | --- | --- |
| [Fill in: CI ID and name from the Configuration Management Plan] | [Fill in: type] | [Fill in: benchmark and version] | [Fill in: image or repository path and version] | [Fill in: count or component IDs] | [Fill in: date and percentage compliant] |

### 13. Approved ports, protocols and services

| Port and protocol | Service | Components | Direction | Purpose | Approved by and change request ID |
| --- | --- | --- | --- | --- | --- |
| [Fill in: for example 443/TCP] | [Fill in: service] | [Fill in: components] | [Fill in: inbound or outbound] | [Fill in: purpose] | [Fill in: name and ID] |

### 14. Deviation register

| Deviation ID | Configuration item and components | Benchmark rule ID and title | Required setting | Actual setting | Operational need | Compensating measures | Security review by and date | Approved by and date | Change request ID | Review or expiry date |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Fill in: ID] | [Fill in: CI and components] | [Fill in: rule ID and title] | [Fill in: setting] | [Fill in: setting] | [Fill in: the documented operational need] | [Fill in: measures, or none] | [Fill in: name and date] | [Fill in: system owner and date] | [Fill in: ID] | [Fill in: date] |

### 15. Scan evidence

| Scan date | Scope | Tool and content version | Components scanned of components in the inventory | Compliance rate | Failures not covered by a deviation | Action taken | Reviewed by |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Fill in: date] | [Fill in: CIs or environment] | [Fill in: tool, content and version] | [Fill in: for example 118 of 120, with the two explained] | [Fill in: percentage] | [Fill in: number, with rule IDs] | [Fill in: corrected, change request, or plan of action and milestones ID] | [Fill in: name and date] |

### 16. Least functionality reviews

| Review date | Method | Findings | Items disabled or removed, with change request IDs | Reviewed by |
| --- | --- | --- | --- | --- |
| [Fill in: date] | [Fill in: for example port and service scan compared with section 13] | [Fill in: findings, or none] | [Fill in: items and IDs] | [Fill in: name] |

#### Federal systems

[NIST SP 800-128](https://csrc.nist.gov/pubs/sp/800/128/upd1/final), section 3.5, says federal agencies use SCAP-enabled tools with SCAP-expressed checklists to automate configuration management and produce assessment evidence for SP 800-53 controls. [SP 800-70 Rev. 5](https://csrc.nist.gov/pubs/sp/800/70/r5/final) refers to FAR 39.101(c) on its pages 4 and 9; NIST's planning note on the publication page (June 8, 2026) says "the current RFO deviation specifically excludes FAR 39.101(c)" and that NIST will update the publication once the FAR RFO final rule is finalized. Check the FAR text your agency follows before relying on it. As of October 2026.

- Compliance scans shall use SCAP-validated tools and SCAP-expressed checklists from the National Checklist Program where one exists for the product, as SP 800-128 section 3.5 describes. (CM-6)

## 17. Review

The [Chief Information Security Officer] reviews Part A [Fill in: for example annually], and whenever a benchmark the standard names is replaced or the configuration management policy changes. Each system owner reviews Part B with the baseline, [Fill in: the frequency of baseline configuration review and update. Typical: at least annually].

| Version | Date | Change | Approved by |
| --- | --- | --- | --- |
| [Fill in: version] | [Fill in: date] | [Fill in: summary of change] | [Fill in: name and title] |