# Information Security and Privacy Policy

**Template version:** 1.0.0 · **Baseline:** High · **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/policies/consolidated/>. Dedicated to the public domain under CC0 1.0 (<https://creativecommons.org/publicdomain/zero/1.0/>): adopt and change it without attribution.

> **Guidance:** This policy brings every family policy into one document, as an alternative to adopting a policy per family. It is assembled from the same sources. The sections every family policy shares are written once, and each family's statements are in its own part under Policy statements. Each family's -1 control asks for a policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination and compliance, plus procedures, dissemination, a designated official and a review cycle; the shared sections meet those elements for every family listed under Control families. Assessors check each element for each family, so keep every shared section even when it is short. For any one scope, adopt either this policy or the family policies, not both, so each requirement has one source.

## Purpose

This policy states what [Organization name] requires for Information Security and Privacy, and who is accountable for meeting those requirements. (XX-1a.1(a))

## Scope

This policy applies at the [Select one or more: organization-level; mission/business process-level; system-level. Typical: organization-level] to every system that [Organization name] owns or operates, or that is operated on its behalf, and to every person with access to those systems, including employees, contractors and partners. (XX-1a.1(a))

## Control families

This policy is the policy of each control family below, in place of separate family policies. Its shared sections meet the first control of each family, the -1 control, which asks for a policy and procedures; a reference such as (XX-1a.1(a)) cites that item of the -1 control of every family below. PM-1 asks for different elements, so the Program Management part opens with its own statements for it. Each family's statements are in its own part under Policy statements.

| Family | Policy control | Accountable role |
| --- | --- | --- |
| Access Control (AC) | AC-1 | [Chief Information Security Officer] |
| Awareness and Training (AT) | AT-1 | [Chief Information Security Officer] |
| Audit and Accountability (AU) | AU-1 | [Chief Information Security Officer] |
| Assessment, Authorization, and Monitoring (CA) | CA-1 | [Chief Information Security Officer] |
| Configuration Management (CM) | CM-1 | [Chief Information Security Officer] |
| Contingency Planning (CP) | CP-1 | [Chief Information Security Officer] |
| Identification and Authentication (IA) | IA-1 | [Chief Information Security Officer] |
| Incident Response (IR) | IR-1 | [Chief Information Security Officer] |
| Maintenance (MA) | MA-1 | [Chief Information Security Officer] |
| Media Protection (MP) | MP-1 | [Chief Information Security Officer] |
| Physical and Environmental Protection (PE) | PE-1 | [Facilities manager] |
| Planning (PL) | PL-1 | [Chief Information Security Officer] |
| Program Management (PM) | PM-1 | [Chief Information Security Officer] |
| Personnel Security (PS) | PS-1 | [Chief Information Security Officer] |
| Risk Assessment (RA) | RA-1 | [Chief Information Security Officer] |
| System and Services Acquisition (SA) | SA-1 | [Chief Information Security Officer] |
| System and Communications Protection (SC) | SC-1 | [Chief Information Security Officer] |
| System and Information Integrity (SI) | SI-1 | [Chief Information Security Officer] |
| Supply Chain Risk Management (SR) | SR-1 | [Chief Information Security Officer] |

- Where the table names a role other than the [Chief Information Security Officer] for a family, that role shall be accountable for the family's part of this policy and shall approve exceptions to it, in coordination with the [Chief Information Security Officer]. (XX-1a.1(a))

## Roles and responsibilities

- The [Chief Information Security Officer] is accountable for this policy and shall approve exceptions to it. (XX-1a.1(a))
- The [Fill in: an official to manage the information security and privacy policy and procedures. Typical: Chief Information Security Officer] shall manage the development, documentation and dissemination of this policy and its procedures. (XX-1b)
- Each [System owner] shall implement this policy for their system and document how in the system security plan. (XX-1a.1(a))
- Each person within scope shall follow this policy and report suspected violations to the [Chief Information Security Officer]. (XX-1a.1(a))

## Management commitment

The [Senior leader] approves this policy and shall provide the resources needed to implement it. (XX-1a.1(a))

## Coordination

The [Chief Information Security Officer] shall coordinate this policy with the legal, privacy, human resources and procurement functions, and with the owners of related policies, before each approval. (XX-1a.1(a))

## Compliance

- This policy shall be consistent with the laws, executive orders, directives, regulations, policies, standards and guidelines that apply to [Organization name], including [Fill in: laws, regulations and standards that apply to the organization]. (XX-1a.1(b))
- The [Chief Information Security Officer] shall review compliance with this policy through the organization's assessment and continuous monitoring activities. (XX-1a.1(a))
- An exception to this policy shall be requested in writing, approved by the [Chief Information Security Officer], time-limited and recorded with its compensating measures. (XX-1a.1(a))
- Violations of this policy shall be handled through the organization's sanctions process. (XX-1a.1(a))

## Procedures

The [Fill in: an official to manage the information security and privacy policy and procedures. Typical: Chief Information Security Officer] shall ensure that documented procedures exist to implement this policy and its associated controls. (XX-1a.2)

## Dissemination

- The [Fill in: an official to manage the information security and privacy policy and procedures. Typical: Chief Information Security Officer] shall disseminate this policy to [Fill in: personnel or roles to whom the information security and privacy policy is to be disseminated. Typical: everyone within its scope, through the policy library]. (XX-1a)
- The [Fill in: an official to manage the information security and privacy policy and procedures. Typical: Chief Information Security Officer] shall disseminate the procedures that implement this policy to [Fill in: personnel or roles to whom the information security and privacy procedures are to be disseminated. Typical: the people who carry them out, and the system owners]. (XX-1a)

## Policy statements

> **Guidance:** Each statement below comes from the clause for one control or enhancement in the chosen baseline. The reference at the end of each statement names the control item it meets.

### Access Control (AC)

#### Account management (AC-2)

> **Guidance:** AC-2 makes account management a controlled life cycle: every account has a known type, an owner, an approval and a removal trigger. Each statement below maps to one lettered item of the control. Assessors test these by sampling account requests, recent departures and the last access review, so keep the records each statement implies.

- The [System owner] shall define and document, for each system, the account types allowed and the account types prohibited. (AC-2a)
- The [System owner] shall assign one or more account managers for each system. (AC-2b)
- The [Account manager] shall require [Fill in: prerequisites and criteria for group and role membership. Typical: a completed access request, a signed access agreement and completed security awareness training] before granting group or role membership. (AC-2c)
- The [Account manager] shall record, for each account, the authorized user, group and role membership, access authorizations and [Fill in: attributes (as required) for each account. Typical: an expiration date for temporary accounts, and time-of-day or location restrictions where the system supports them]. (AC-2d)
- The [Account manager] shall create an account only after approval by [Fill in: personnel or roles required to approve requests to create accounts. Typical: the user's supervisor, plus the system owner or data owner for privileged roles]. (AC-2e)
- The [Account manager] shall create, enable, modify, disable and remove accounts in accordance with this policy and the account management procedure. (AC-2f)
- The [Account manager] shall monitor the use of accounts for activity that does not match the account's type or authorization. (AC-2g)
- The [Supervisor] shall notify the account manager and [Fill in: personnel or roles to be notified. Typical: the system owner and the system security officer] within [Fill in: time period within which to notify account managers when accounts are no longer required. Typical: 5 business days] when a user's account is no longer required. (AC-2h.1)
- The [Human resources office] shall notify the account manager and [Fill in: personnel or roles to be notified. Typical: the system owner and the system security officer] within [Fill in: time period within which to notify account managers when users are terminated or transferred. Typical: 24 hours, or the same day for privileged users] when a user is terminated or transferred. (AC-2h.2)
- The [Supervisor] shall notify the account manager and [Fill in: personnel or roles to be notified. Typical: the system owner and the system security officer] within [Fill in: time period within which to notify account managers when system usage or the need to know changes for an individual. Typical: 5 business days] when a user's system usage or need to know changes. (AC-2h.3)
- The [Account manager] shall authorize access only on the basis of a valid access authorization, the intended system usage and [Fill in: attributes needed to authorize system access (as required). Typical: time-of-day, day-of-week or network location restrictions, where needed]. (AC-2i)
- The [System owner] shall review all accounts on the system for compliance with this policy [Fill in: the frequency of account review. Typical: quarterly for privileged accounts and at least annually for all other accounts]. (AC-2j)
- The [Account manager] shall disable or remove each account the review finds is no longer authorized. (AC-2j)
- The [Account manager] shall change the authenticators of a shared or group account when an individual is removed from the group. (AC-2k)
- The [Chief Information Security Officer] shall ensure account management processes are aligned with personnel termination and transfer processes. (AC-2l)

> **Guidance:** Where the organization does not use shared or group accounts, keep the AC-2k statement and note in the system security plan that none are deployed; the assessor will still ask. Evidence for AC-2l is usually an automated feed from the human resources system to the identity provider, or a documented handoff in the [onboarding, transfer and termination checklist](https://kston83.github.io/nist-guide/templates/forms/onboarding-transfer-and-termination-checklist/) (PS-4). The [account management procedure](https://kston83.github.io/nist-guide/templates/procedures/account-management-procedure/) carries out these statements step by step; the [access request form](https://kston83.github.io/nist-guide/templates/forms/access-request-form/) and the [access review record](https://kston83.github.io/nist-guide/templates/forms/access-review-record/) are the records assessors sample for AC-2e and AC-2j.

#### Automated system account management (AC-2(1))

- The [System owner] shall support the management of system accounts using [Fill in: automated mechanisms used to support the management of system accounts. Typical: the organization's identity provider and its provisioning workflows]. (AC-2(1))

#### Automated temporary and emergency account management (AC-2(2))

- The [System owner] shall ensure the system automatically [Select one: remove; disable. Typical: disable] temporary and emergency accounts after [Fill in: the time period after which to automatically remove or disable temporary or emergency accounts. Typical: 72 hours for emergency accounts, and the end date approved at creation for temporary accounts]. (AC-2(2))

#### Disable accounts (AC-2(3))

- The [Account manager] shall disable an account within [Fill in: time period within which to disable accounts. Typical: 1 business day] when the account has expired. (AC-2(3)(a))
- The [Account manager] shall disable an account within [Fill in: time period within which to disable accounts. Typical: 1 business day] when it is no longer associated with a user or individual. (AC-2(3)(b))
- The [Account manager] shall disable an account within [Fill in: time period within which to disable accounts. Typical: 1 business day] when it is in violation of organizational policy. (AC-2(3)(c))
- The [System owner] shall ensure the system disables an account that has been inactive for [Fill in: time period for account inactivity before disabling. Typical: 90 days]. (AC-2(3)(d))

#### Automated audit actions (AC-2(4))

- The [System owner] shall ensure the system automatically audits account creation, modification, enabling, disabling and removal actions. (AC-2(4))

#### Inactivity logout (AC-2(5))

- Each user shall log out [Fill in: the time period of expected inactivity or description of when to log out. Typical: at the end of each work session, and when leaving the device unattended for longer than the device lock period]. (AC-2(5))

#### Usage conditions (AC-2(11))

- The [System owner] shall ensure the system enforces [Fill in: circumstances and/or usage conditions to be enforced for system accounts. Typical: restrictions by time of day, day of week and network location] for [Fill in: system accounts subject to enforcement of circumstances and/or usage conditions. Typical: privileged and emergency accounts]. (AC-2(11))

#### Account monitoring for atypical usage (AC-2(12))

- The [System owner] shall ensure system accounts are monitored for [Fill in: atypical usage for which to monitor system accounts. Typical: logons at unusual times or from unusual locations, use of dormant accounts, and repeated failed privilege elevation]. (AC-2(12)(a))
- The [System owner] shall ensure atypical usage of system accounts is reported to [Fill in: personnel or roles to report atypical usage. Typical: the security operations team and the system owner]. (AC-2(12)(b))

#### Disable accounts for high-risk individuals (AC-2(13))

- The [Account manager] shall disable the accounts of an individual within [Fill in: time period within which to disable accounts of individuals who are discovered to pose significant risk. Typical: 1 hour] of discovery of [Fill in: significant risks leading to disabling accounts. Typical: credible indicators of insider threat, or notice of an adverse personnel action]. (AC-2(13))

#### Access enforcement (AC-3)

> **Guidance:** AC-3 is enforced by the system, not by people: the statement makes the system owner accountable for configuring it. Assessors check that the roles and permissions in the system match the access authorizations approved under AC-2.

- The [System owner] shall ensure the system enforces approved authorizations for logical access to information and system resources in accordance with this policy. (AC-3)

#### Information flow enforcement (AC-4)

> **Guidance:** Information flow enforcement decides where information may go, not who may see it: firewall and proxy rules, cross-domain and data loss prevention filters, and cloud network policies. The [Boundary Protection Standard](https://kston83.github.io/nist-guide/templates/standards/boundary-protection-standard/) holds the rules; interconnection agreements (CA-3) approve flows to other systems.

- The [System owner] shall ensure the system enforces approved authorizations for controlling the flow of information within the system and between connected systems based on [Fill in: information flow control policies within the system and between connected systems. Typical: the boundary protection standard and the approved interconnection agreements]. (AC-4)

#### Flow control of encrypted information (AC-4(4))

- The [System owner] shall ensure encrypted information is prevented from bypassing [Fill in: information flow control mechanisms that encrypted information is prevented from bypassing. Typical: the boundary firewalls and data loss prevention service] by [Select one or more: decrypting the information; blocking the flow of the encrypted information; terminating communications sessions attempting to pass encrypted information; [Assignment: organization-defined procedure or method]. Typical: decrypting the information at the boundary for inspection]. (AC-4(4))

#### Separation of duties (AC-5)

- The [System owner] shall identify and document [Fill in: duties of individuals requiring separation. Typical: requesting and approving access; developing and deploying code to production; administering a system and reviewing its audit logs]. (AC-5a)
- The [System owner] shall define system access authorizations that support separation of those duties. (AC-5b)

#### Least privilege (AC-6)

- The [System owner] shall ensure users, and processes acting on behalf of users, are granted only the access necessary to accomplish their assigned organizational tasks. (AC-6)

#### Authorize access to security functions (AC-6(1))

- The [System owner] shall authorize access to [Fill in: security functions (deployed in hardware, software, and firmware). Typical: account management, audit configuration, security settings and cryptographic key management] only for [Fill in: individuals and roles with authorized access to security functions and security-relevant information. Typical: the system administrators and security personnel named in the system security plan]. (AC-6(1)(a))
- The [System owner] shall authorize access to [Fill in: security-relevant information for authorized access. Typical: audit logs, security configuration settings and access control lists] only for [Fill in: individuals and roles with authorized access to security functions and security-relevant information. Typical: the system administrators and security personnel named in the system security plan]. (AC-6(1)(b))

#### Non-privileged access for nonsecurity functions (AC-6(2))

- Users of accounts or roles with access to [Fill in: security functions or security-relevant information, the access to which requires users to use non-privileged accounts to access non-security functions,. Typical: the security functions and security-relevant information authorized under AC-6(1)] shall use non-privileged accounts or roles when accessing nonsecurity functions such as email and web browsing. (AC-6(2))

#### Network access to privileged commands (AC-6(3))

- The [System owner] shall authorize network access to [Fill in: privileged commands to which network access is to be authorized only for compelling operational needs. Typical: all privileged commands] only for [Fill in: compelling operational needs necessitating network access to privileged commands. Typical: administration that cannot be performed from a local console or dedicated management network]. (AC-6(3))
- The [System owner] shall document the rationale for such access in the system security plan. (AC-6(3))

#### Privileged accounts (AC-6(5))

- The [System owner] shall restrict privileged accounts on the system to [Fill in: personnel or roles to which privileged accounts on the system are to be restricted. Typical: the system administrators named in the system security plan]. (AC-6(5))

#### Review of user privileges (AC-6(7))

- The [System owner] shall review [Fill in: the frequency at which to review the privileges assigned to roles or classes of users. Typical: quarterly for privileged roles and at least annually for all other roles] the privileges assigned to [Fill in: roles or classes of users to which privileges are assigned. Typical: all roles and classes of users on the system] to validate the need for them. (AC-6(7)(a))
- The [Account manager] shall reassign or remove privileges the review finds are not needed for the user's mission and business functions. (AC-6(7)(b))

#### Log use of privileged functions (AC-6(9))

- The [System owner] shall ensure the system logs the execution of privileged functions. (AC-6(9))

#### Prohibit non-privileged users from executing privileged functions (AC-6(10))

- The [System owner] shall ensure the system prevents non-privileged users from executing privileged functions. (AC-6(10))

#### Unsuccessful logon attempts (AC-7)

- The [System owner] shall ensure the system enforces a limit of [Fill in: the number of consecutive invalid logon attempts by a user allowed during a time period. Typical: 3] consecutive invalid logon attempts by a user during [Fill in: the time period to which the number of consecutive invalid logon attempts by a user is limited. Typical: 15 minutes]. (AC-7a)
- The [System owner] shall ensure the system automatically takes the following action when the limit is exceeded: [Select one or more: lock the account or node for [Assignment: organization-defined time period]; lock the account or node until released by an administrator; delay next logon prompt per [Assignment: organization-defined delay algorithm]; notify system administrator; take other [Assignment: organization-defined action]. Typical: lock the account or node for 30 minutes, or until released by an administrator for privileged accounts]. (AC-7b)

#### System use notification (AC-8)

> **Guidance:** The banner text is usually approved once by legal counsel and reused on every system. The four notices listed in AC-8a are written for U.S. Government systems; the statements below keep the ones that apply to any organization and move the two government-only notices to the federal section.

- The [System owner] shall ensure the system displays [Fill in: system use notification message or banner to be displayed by the system to users before granting access to the system. Typical: the organization's approved logon banner] to users before granting access. (AC-8a)
- The notice shall state that system usage may be monitored, recorded and subject to audit; that unauthorized use of the system is prohibited; and that use of the system indicates consent to monitoring and recording. (AC-8a)
- The [System owner] shall ensure the notice remains on the screen until users acknowledge the usage conditions and take explicit action to log on to or further access the system. (AC-8b)
- For publicly accessible systems, the [System owner] shall ensure the system displays system use information [Fill in: conditions for system use to be displayed by the system before granting further access. Typical: on the landing page, before users submit any information], before granting further access. (AC-8c.1)
- For publicly accessible systems, the [System owner] shall ensure any references to monitoring, recording or auditing are consistent with the privacy accommodations for such systems. (AC-8c.2)
- For publicly accessible systems, the [System owner] shall ensure the notice describes the authorized uses of the system. (AC-8c.3)

##### Federal systems

SP 800-53 Rev. 5 AC-8a requires the notice on federal systems to state two more things ([AC-8](https://kston83.github.io/nist-guide/controls/ac/ac-8/)).

- The notice shall state that users are accessing a U.S. Government system. (AC-8a.1)
- The notice shall state that unauthorized use of the system is subject to criminal and civil penalties. (AC-8a.3)

#### Concurrent session control (AC-10)

- The [System owner] shall ensure the system limits the number of concurrent sessions for [Fill in: accounts and/or account types for which to limit the number of concurrent sessions. Typical: privileged accounts] to [Fill in: the number of concurrent sessions to be allowed for each account and/or account type. Typical: one]. (AC-10)

#### Device lock (AC-11)

- The [System owner] shall ensure the system prevents further access by [Select one or more: initiating a device lock after [Assignment: organization-defined time period] of inactivity; requiring the user to initiate a device lock before leaving the system unattended. Typical: initiating a device lock after 15 minutes of inactivity, and requiring the user to initiate a device lock before leaving the system unattended]. (AC-11a)
- The [System owner] shall ensure the device lock remains until the user reestablishes access using the established identification and authentication procedures. (AC-11b)

#### Pattern-hiding displays (AC-11(1))

- The [System owner] shall ensure the device lock conceals information previously visible on the display with a publicly viewable image. (AC-11(1))

#### Session termination (AC-12)

- The [System owner] shall ensure the system automatically terminates a user session after [Fill in: conditions or trigger events requiring session disconnect. Typical: 30 minutes of inactivity for remote and web sessions, or at the end of the maximum session lifetime]. (AC-12)

#### Permitted actions without identification or authentication (AC-14)

- The [System owner] shall identify [Fill in: user actions that can be performed on the system without identification or authentication. Typical: viewing public web pages and the logon page] as the only user actions that can be performed on the system without identification or authentication. (AC-14a)
- The [System owner] shall document those actions, with the supporting rationale, in the system security plan. (AC-14b)

#### Remote access (AC-17)

> **Guidance:** The [remote access standard](https://kston83.github.io/nist-guide/templates/standards/remote-access-standard/) is where the CISO documents the usage restrictions, configuration and connection requirements and implementation guidance for each allowed method (AC-17a), along with the AC-17(1) to AC-17(4) requirements. Each system's security plan records which of those methods the system owner has authorized (AC-17b).

- The [Chief Information Security Officer] shall establish and document usage restrictions, configuration and connection requirements, and implementation guidance for each type of remote access allowed. (AC-17a)
- The [System owner] shall authorize each type of remote access to the system before allowing such connections. (AC-17b)

#### Remote access monitoring and control (AC-17(1))

- The [System owner] shall employ automated mechanisms to monitor and control remote access methods. (AC-17(1))

#### Protection of confidentiality and integrity using encryption (AC-17(2))

- The [System owner] shall ensure cryptographic mechanisms protect the confidentiality and integrity of remote access sessions. (AC-17(2))

#### Managed access control points (AC-17(3))

- The [System owner] shall ensure remote access is routed through authorized and managed network access control points. (AC-17(3))

#### Remote privileged commands and access (AC-17(4))

- The [System owner] shall authorize the execution of privileged commands via remote access only for [Fill in: needs requiring execution of privileged commands via remote access. Typical: emergency administration outside business hours and administration of cloud-hosted components], and only in a format that provides assessable evidence. (AC-17(4)(a))
- The [System owner] shall authorize access to security-relevant information via remote access only for [Fill in: needs requiring access to security-relevant information via remote access. Typical: investigation of security incidents], and only in a format that provides assessable evidence. (AC-17(4)(a))
- The [System owner] shall document the rationale for such remote access in the system security plan. (AC-17(4)(b))

#### Wireless access (AC-18)

- The [Chief Information Security Officer] shall establish configuration requirements, connection requirements and implementation guidance for each type of wireless access. (AC-18a)
- The [System owner] shall authorize each type of wireless access to the system before allowing such connections. (AC-18b)

#### Wireless authentication and encryption (AC-18(1))

- The [System owner] shall protect wireless access to the system using authentication of [Select one or more: users; devices. Typical: users and devices] and encryption. (AC-18(1))

#### Disable wireless networking (AC-18(3))

- The [System owner] shall ensure wireless networking capabilities embedded in system components are disabled before issuance and deployment when not intended for use. (AC-18(3))

#### Restrict configurations by users (AC-18(4))

- The [System owner] shall identify and explicitly authorize the users allowed to independently configure wireless networking capabilities. (AC-18(4))

#### Antennas and transmission power levels (AC-18(5))

- The [System owner] shall select radio antennas and calibrate transmission power levels to reduce the probability that signals from wireless access points can be received outside organization-controlled boundaries. (AC-18(5))

#### Access control for mobile devices (AC-19)

- The [Chief Information Security Officer] shall establish configuration requirements, connection requirements and implementation guidance for organization-controlled mobile devices, including when devices are outside controlled areas. (AC-19a)
- The [System owner] shall authorize the connection of mobile devices to the system. (AC-19b)

#### Full device or container-based encryption (AC-19(5))

- The [Chief Information Security Officer] shall require [Select one: full-device encryption; container-based encryption. Typical: full-device encryption] to protect the confidentiality and integrity of information on [Fill in: mobile devices on which to employ encryption. Typical: all organization-controlled mobile devices]. (AC-19(5))

#### Use of external systems (AC-20)

- Before authorized individuals access the system from an external system, or process, store or transmit organization-controlled information on one, the [Chief Information Security Officer] shall [Select one or more: establish [Assignment: organization-defined terms and conditions]; identify [Assignment: organization-defined controls asserted]. Typical: establish terms and conditions in a signed agreement with the organization that owns the external system], consistent with the trust relationship with the organization that owns, operates or maintains the external system. (AC-20a)
- Users shall not use [Fill in: types of external systems prohibited from use. Typical: personally owned devices that the organization does not manage, and public or shared computers] to access the system or to process, store or transmit organization-controlled information. (AC-20b)

#### Limits on authorized use (AC-20(1))

- The [System owner] shall permit authorized individuals to use an external system to access the system, or to process, store or transmit organization-controlled information, only after the controls on the external system are verified against the organization's policies and plans, or an approved connection or processing agreement is in place with its owner. (AC-20(1))

#### Portable storage devices: restricted use (AC-20(2))

- Authorized individuals shall use organization-controlled portable storage devices on external systems only under [Fill in: restrictions on the use of organization-controlled portable storage devices by authorized individuals on external systems. Typical: use only of encrypted, organization-issued devices, and only for approved business purposes]. (AC-20(2))

#### Information sharing (AC-21)

- The [System owner] shall enable authorized users to determine whether the access authorizations of a sharing partner match the information's access and use restrictions for [Fill in: information-sharing circumstances where user discretion is required to determine whether access authorizations assigned to a sharing partner match the information’s access and use restrictions. Typical: sharing sensitive or contract-restricted information with partners outside the organization]. (AC-21a)
- The [System owner] shall employ [Fill in: automated mechanisms or manual processes that assist users in making information-sharing and collaboration decisions. Typical: information labels and a data-sharing checklist] to assist users in making information sharing and collaboration decisions. (AC-21b)

#### Publicly accessible content (AC-22)

- The [System owner] shall designate the individuals authorized to make information publicly accessible. (AC-22a)
- The [System owner] shall ensure those individuals are trained to keep nonpublic information out of publicly accessible content. (AC-22b)
- The designated individuals shall review proposed content for nonpublic information before posting it on the publicly accessible system. (AC-22c)
- The designated individuals shall review the content on the publicly accessible system for nonpublic information [Fill in: the frequency at which to review the content on the publicly accessible system for non-public information. Typical: quarterly]. (AC-22d)
- The designated individuals shall remove nonpublic information when a review discovers it. (AC-22d)

### Awareness and Training (AT)

#### Literacy training and awareness (AT-2)

> **Guidance:** Literacy training is the course every user takes; awareness is what keeps the message alive between courses. Assessors compare completion records with account creation dates, so require the initial course before access (AC-2) and track it for employees, contractors and executives alike. The [training plan](https://kston83.github.io/nist-guide/templates/plans/security-and-privacy-training-plan/) sets out the courses and schedule.

- The [Chief Information Security Officer] shall provide security literacy training to all system users, including managers, senior executives and contractors, as part of initial training before they are given access, and [Fill in: the frequency at which to provide security literacy training to system users (including managers, senior executives, and contractors) after initial training. Typical: annually] thereafter. (AT-2a.1)
- The [Senior privacy official] shall provide privacy literacy training to all system users, including managers, senior executives and contractors, as part of initial training before they are given access, and [Fill in: the frequency at which to provide privacy literacy training to system users (including managers, senior executives, and contractors) after initial training. Typical: annually] thereafter. (AT-2a.1)
- The [Chief Information Security Officer] shall provide security literacy training when system changes require it, and following [Fill in: events that require security literacy training for system users. Typical: a significant system change, or an incident caused by user error]. (AT-2a.2)
- The [Senior privacy official] shall provide privacy literacy training when system changes require it, and following [Fill in: events that require privacy literacy training for system users. Typical: a significant change in how the organization processes personally identifiable information, or a privacy breach]. (AT-2a.2)
- The [Chief Information Security Officer] shall increase users' security and privacy awareness through [Fill in: techniques to be employed to increase the security and privacy awareness of system users. Typical: phishing simulations, short awareness messages and posters]. (AT-2b)
- The [Chief Information Security Officer] shall update literacy training and awareness content [Fill in: the frequency at which to update literacy training and awareness content. Typical: annually] and following [Fill in: events that would require literacy training and awareness content to be updated. Typical: a significant incident, or a significant change in threats]. (AT-2c)
- The [Chief Information Security Officer] shall incorporate lessons learned from internal and external security incidents and breaches into literacy training and awareness techniques. (AT-2d)

##### Federal systems

[5 CFR 930.301](https://www.ecfr.gov/current/title-5/chapter-I/subchapter-B/part-930/subpart-C/section-930.301) (OPM) requires that all users of federal information systems be exposed to security awareness materials at least annually, and that new employees receive awareness material before they are allowed access. [44 U.S.C. § 3554(b)(4)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim) requires security awareness training for personnel, including contractors and other users. [OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf) (July 28, 2016), Appendix II, section 5.g, requires mandatory agency-wide privacy awareness and training for all employees and contractors. Checked September 2026.

- The [Chief Information Security Officer] shall give new employees security awareness material before they are allowed access to federal information systems. (AT-2a.1)
- The [Chief Information Security Officer] shall expose every user of federal information systems, including contractors, to security awareness materials at least annually. (AT-2a.1)
- The [Senior privacy official] shall maintain mandatory privacy awareness and training for all employees and contractors, as OMB Circular A-130 Appendix II requires. (AT-2a.1)

#### Insider threat (AT-2(2))

> **Guidance:** Teach users what potential insider threat indicators look like, such as attempts to get access beyond one's job, unexplained removal of information, or ignoring security rules repeatedly, and where to report them. Keep the reporting channel the same one the insider threat program (PM-12) uses.

- The [Chief Information Security Officer] shall include in literacy training how to recognize and report potential indicators of insider threat. (AT-2(2))

#### Social engineering and mining (AT-2(3))

> **Guidance:** Social engineering tricks people into giving up information or access, by email, phone, text or in person; social mining gathers information about the organization from public sources and social media to plan an attack. Phishing simulations (AT-2b) are a common way to practice recognizing it.

- The [Chief Information Security Officer] shall include in literacy training how to recognize and report potential and actual instances of social engineering and social mining. (AT-2(3))

#### Role-based training (AT-3)

> **Guidance:** Role-based training goes beyond what every user learns: administrators learn secure configuration, developers secure coding, authorizing officials how to weigh risk. List each role and its courses in the [training plan](https://kston83.github.io/nist-guide/templates/plans/security-and-privacy-training-plan/). The NICE Workforce Framework for Cybersecurity ([SP 800-181 Rev. 1](https://csrc.nist.gov/pubs/sp/800/181/r1/final), with its [components](https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center/nice-framework-current-versions) at v2.2.0 as of September 2026) describes work roles and the knowledge and skills each needs, a useful starting point for the course list. Incident response training is covered by IR-2 and contingency training by CP-3.

- The [Chief Information Security Officer] shall provide role-based security training to personnel with these roles and responsibilities: [Fill in: roles and responsibilities for role-based security training. Typical: system administrators, developers, security staff, incident responders, system owners and authorizing officials]. (AT-3a)
- The [Senior privacy official] shall provide role-based privacy training to personnel with these roles and responsibilities: [Fill in: roles and responsibilities for role-based privacy training. Typical: staff who handle personally identifiable information as part of their duties, the privacy office, and owners of systems that process it]. (AT-3a)
- Role-based training shall be completed before the person is authorized to access the system or information, or to perform the assigned duties, and [Fill in: the frequency at which to provide role-based security and privacy training to assigned personnel after initial training. Typical: annually] thereafter. (AT-3a.1)
- Role-based training shall also be provided when system changes require it. (AT-3a.2)
- The [Chief Information Security Officer] and the [Senior privacy official] shall update role-based training content [Fill in: the frequency at which to update role-based training content. Typical: annually] and following [Fill in: events that require role-based training content to be updated. Typical: a significant incident, a change in a role's tools or duties, or a new legal or policy requirement]. (AT-3b)
- The [Chief Information Security Officer] and the [Senior privacy official] shall incorporate lessons learned from internal and external security incidents and breaches into role-based training. (AT-3c)

##### Federal systems

[5 CFR 930.301](https://www.ecfr.gov/current/title-5/chapter-I/subchapter-B/part-930/subpart-C/section-930.301) (OPM) requires agencies to identify employees with significant information security responsibilities and give them role-specific training in accordance with NIST standards and guidance; refresher training as often as the agency determines necessary, based on the sensitivity of the information; and training when the system environment or procedures change significantly, or when an employee enters a position that needs more role-specific training. [OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix II, section 5.g, requires role-based privacy training, before access or assigned duties, for employees and contractors with privacy roles, including managers. Checked September 2026.

- The [Chief Information Security Officer] shall identify employees with significant information security responsibilities and give them role-specific training in accordance with NIST standards and guidance. (AT-3a)
- The [Chief Information Security Officer] shall provide role-specific training when an employee enters a position that requires more of it, and when the system environment or procedures change significantly. (AT-3a.2)
- The [Senior privacy official] shall provide role-based privacy training to employees and contractors with privacy roles, including managers, before they are authorized to access federal information or systems or to perform their duties. (AT-3a.1)

#### Training records (AT-4)

> **Guidance:** Keep records in the learning management system where possible, and in the [training record log](https://kston83.github.io/nist-guide/templates/forms/training-record-log/) for training given outside it. Monitoring means someone checks the records for overdue training and acts on it, not just that the records exist.

- The [Chief Information Security Officer] shall document security and privacy training activities, including literacy training, awareness activities and role-based training, for each person. (AT-4a)
- The [Chief Information Security Officer] shall monitor training records for training that is overdue, and report overdue training to the person's supervisor. (AT-4a)
- The [Chief Information Security Officer] shall retain individual training records for [Fill in: time period for retaining individual training records. Typical: 3 years after completion, or longer where a law, the records retention schedule or a business need requires it]. (AT-4b)

##### Federal systems

The NARA [General Records Schedule 2.6](https://www.archives.gov/files/records-mgmt/grs/grs02-6.pdf), Employee Training Records (Transmittal 35, May 2024), item 030, covers individual employee training records: "Destroy when superseded, 3 years old, or 1 year after separation, whichever comes first, but longer retention is authorized if required for business use." Checked September 2026.

- The [Chief Information Security Officer] shall retain and dispose of individual training records as GRS 2.6 item 030, or the agency's own approved records schedule, requires. (AT-4b)

### Audit and Accountability (AU)

#### Event logging (AU-2)

> **Guidance:** AU-2 asks for two lists: every event type the system can log, and the subset you actually log, with a reason the subset is enough to investigate an incident. Keep both in the [audit logging standard](https://kston83.github.io/nist-guide/templates/standards/audit-logging-standard/) so every system starts from the same list: section 3 holds the organization-wide list and Part B each system's own. Assessors ask for the rationale (AU-2d) more often than any other item.

- The [System owner] shall identify [Fill in: the event types that the system is capable of logging in support of the audit function. Typical: logons and logoffs, account and privilege changes, use of privileged functions, access to security-relevant files, configuration changes, and security tool events] as the event types the system is capable of logging in support of the audit function. (AU-2a)
- The [Chief Information Security Officer] shall coordinate the event logging function with the other organizational entities that need audit-related information, to inform which events are logged. (AU-2b)
- The [System owner] shall specify [Fill in: event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type. Typical: the event types listed in the audit logging standard, each logged whenever it occurs] for logging within the system. (AU-2c)
- The [System owner] shall document why the event types selected for logging are adequate to support after-the-fact investigation of incidents. (AU-2d)
- The [System owner] shall review and update the event types selected for logging [Fill in: the frequency of event types selected for logging are reviewed and updated. Typical: annually and after a significant incident or system change]. (AU-2e)

#### Content of audit records (AU-3)

- The [System owner] shall ensure audit records establish what type of event occurred, when and where it occurred, its source, its outcome, and the identity of any individuals, subjects or objects associated with it. (AU-3)

#### Additional audit information (AU-3(1))

- The [System owner] shall ensure the system generates audit records that also contain [Fill in: additional information to be included in audit records. Typical: session and request identifiers, source and destination addresses, and the full command line for privileged commands]. (AU-3(1))

#### Audit log storage capacity (AU-4)

- The [System owner] shall allocate audit log storage capacity to accommodate [Fill in: audit log retention requirements. Typical: the retention period set under AU-11, with room for a year of growth]. (AU-4)

#### Response to audit logging process failures (AU-5)

- The [System owner] shall ensure the system alerts [Fill in: personnel or roles receiving audit logging process failure alerts. Typical: the system administrators and the security operations team] within [Fill in: time period for personnel or roles receiving audit logging process failure alerts. Typical: 1 hour] of an audit logging process failure. (AU-5a)
- When an audit logging process fails, the [System owner] shall [Fill in: additional actions to be taken in the event of an audit logging process failure. Typical: restore logging and record the gap in the audit trail; for high-impact systems, stop processing that cannot be logged]. (AU-5b)

#### Storage capacity warning (AU-5(1))

- The [System owner] shall ensure the system warns [Fill in: personnel, roles, and/or locations to be warned when allocated audit log storage volume reaches a percentage of repository maximum audit log storage capacity. Typical: the system administrators and the security operations team] within [Fill in: time period for defined personnel, roles, and/or locations to be warned when allocated audit log storage volume reaches a percentage of repository maximum audit log storage capacity. Typical: 1 hour] when allocated audit log storage reaches [Fill in: percentage of repository maximum audit log storage capacity. Typical: 75 percent] of the repository's maximum capacity. (AU-5(1))

#### Real-time alerts (AU-5(2))

- The [System owner] shall ensure the system alerts [Fill in: personnel, roles, and/or locations to be alerted in real time when audit failure events occur. Typical: the security operations team] within [Fill in: real-time period requiring alerts when audit failure events occur. Typical: 15 minutes] when any of these audit failure events occur: [Fill in: audit logging failure events requiring real-time alerts. Typical: loss of log forwarding from any component, and failure of the central log repository]. (AU-5(2))

#### Audit record review, analysis and reporting (AU-6)

> **Guidance:** Most findings under AU-6 are about evidence, not effort: the review happened but left no record. Keep a dated record of each review with what was looked at, what was found and who it was reported to. The [log review procedure](https://kston83.github.io/nist-guide/templates/procedures/log-review-procedure/) lists the activity the review looks for in its section 3 and names the record each step leaves.

- The [Security operations team] shall review and analyze system audit records [Fill in: frequency at which system audit records are reviewed and analyzed. Typical: continuously through automated alerting, with a documented manual review at least weekly] for indications of [Fill in: inappropriate or unusual activity. Typical: the activity listed in the log review procedure, such as repeated failed logons, privilege escalation and access outside normal patterns] and its potential impact. (AU-6a)
- The [Security operations team] shall report findings to [Fill in: personnel or roles to receive findings from reviews and analyses of system records. Typical: the system owner and the incident response team]. (AU-6b)
- The [Security operations team] shall adjust the level of audit record review, analysis and reporting when law enforcement information, intelligence information or other credible sources indicate a change in risk. (AU-6c)

#### Automated process integration (AU-6(1))

- The [Security operations team] shall integrate audit record review, analysis and reporting processes using [Fill in: automated mechanisms used for integrating audit record review, analysis, and reporting processes. Typical: a security information and event management (SIEM) platform]. (AU-6(1))

#### Correlate audit record repositories (AU-6(3))

- The [Security operations team] shall analyze and correlate audit records across repositories to gain organization-wide situational awareness. (AU-6(3))

#### Integrated analysis of audit records (AU-6(5))

- The [Security operations team] shall integrate analysis of audit records with analysis of [Select one or more: vulnerability scanning information; performance data; system monitoring information; [Assignment: organization-defined data/information collected from other sources]. Typical: vulnerability scanning information and system monitoring information] to improve the identification of inappropriate or unusual activity. (AU-6(5))

#### Correlation with physical monitoring (AU-6(6))

- The [Security operations team] shall correlate information from audit records with information from physical access monitoring to identify suspicious, inappropriate, unusual or malevolent activity. (AU-6(6))

#### Audit record reduction and report generation (AU-7)

- The [System owner] shall provide and implement an audit record reduction and report generation capability that supports on-demand review, analysis and reporting and after-the-fact investigation of incidents. (AU-7a)
- The [System owner] shall ensure that capability does not alter the original content or time ordering of audit records. (AU-7b)

#### Automatic processing (AU-7(1))

- The [System owner] shall provide and implement the capability to process, sort and search audit records for events of interest based on [Fill in: fields within audit records that can be processed, sorted, or searched. Typical: event type, time, source and destination, user identity, outcome and system component]. (AU-7(1))

#### Time stamps (AU-8)

- The [System owner] shall ensure the system uses internal system clocks to generate time stamps for audit records. (AU-8a)
- The [System owner] shall ensure audit record time stamps meet a granularity of [Fill in: granularity of time measurement for audit record timestamps. Typical: one second or finer] and use Coordinated Universal Time, a fixed offset from it, or include the local offset in the time stamp. (AU-8b)

#### Protection of audit information (AU-9)

- The [System owner] shall protect audit information and audit logging tools from unauthorized access, modification and deletion. (AU-9a)
- The [System owner] shall ensure [Fill in: personnel or roles to be alerted upon detection of unauthorized access, modification, or deletion of audit information. Typical: the security operations team and the system owner] are alerted when unauthorized access, modification or deletion of audit information is detected. (AU-9b)

#### Store on separate physical systems or components (AU-9(2))

- The [System owner] shall ensure audit records are stored [Fill in: the frequency of storing audit records in a repository. Typical: in near real time] in a repository on a physically different system or component than the one being audited. (AU-9(2))

#### Cryptographic protection of audit information (AU-9(3))

- The [System owner] shall ensure cryptographic mechanisms protect the integrity of audit information and audit tools. (AU-9(3))

#### Access by subset of privileged users (AU-9(4))

- The [System owner] shall authorize access to management of audit logging functionality only for [Fill in: a subset of privileged users or roles authorized to access management of audit logging functionality. Typical: the security operations administrators, who do not administer the systems being audited]. (AU-9(4))

#### Non-repudiation (AU-10)

- The [System owner] shall ensure the system provides irrefutable evidence that an individual, or a process acting on behalf of an individual, has performed [Fill in: actions to be covered by non-repudiation. Typical: approving access and changes, signing records, and administering security settings]. (AU-10)

#### Audit record retention (AU-11)

- The [System owner] shall retain audit records for [Fill in: a time period to retain audit records that is consistent with the records retention policy. Typical: at least one year, or longer where the records retention schedule or a law requires it] to support after-the-fact investigation of incidents and to meet regulatory and organizational retention requirements. (AU-11)

##### Federal systems

[OMB M-26-14](https://www.whitehouse.gov/wp-content/uploads/2026/05/M-26-14-Ensuring-Effective-and-Efficient-Agency-Logging-and-Network-Visibility-to-Defend-Against-Evolving-Cyber-Threats.pdf), Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats (May 22, 2026), rescinded OMB M-21-31. Its Appendix B requires retained logs to be actively searchable for at least 6 months after creation and retrievable for a year after creation, and notes that meeting these minimums does not relieve agencies of other requirements, such as those set by agency-specific or government-wide records schedules. It does not apply to national security systems. As of September 2026.

- The [System owner] shall keep audit records actively searchable for at least 6 months after creation, and retrievable for at least one year after creation, as OMB M-26-14 requires. (AU-11)

#### Audit record generation (AU-12)

- The [System owner] shall ensure [Fill in: system components that provide an audit record generation capability for the events types. Typical: all servers, network devices, security tools, databases and applications in the system boundary] provide an audit record generation capability for the event types identified under AU-2a. (AU-12a)
- The [System owner] shall allow only [Fill in: personnel or roles allowed to select the event types that are to be logged by specific components of the system. Typical: the system administrators, with the security operations team approving changes] to select the event types logged by specific components of the system. (AU-12b)
- The [System owner] shall ensure the system generates audit records for the event types specified under AU-2c, with the content required by AU-3. (AU-12c)

#### System-wide and time-correlated audit trail (AU-12(1))

- The [System owner] shall compile audit records from [Fill in: system components from which audit records are to be compiled into a system-wide (logical or physical) audit trail. Typical: all components that generate audit records] into a system-wide audit trail that is time-correlated to within [Fill in: level of tolerance for the relationship between timestamps of individual records in the audit trail. Typical: one second]. (AU-12(1))

#### Changes by authorized individuals (AU-12(3))

- The [System owner] shall provide and implement the capability for [Fill in: individuals or roles authorized to change the logging on system components. Typical: the security operations administrators] to change the logging performed on [Fill in: system components on which logging is to be performed. Typical: all components in the system boundary] based on [Fill in: selectable event criteria with which change logging is to be performed. Typical: the event types in the audit logging standard, and additional detail for a user or component under investigation] within [Fill in: time thresholds in which logging actions are to change. Typical: 1 hour]. (AU-12(3))

### Assessment, Authorization, and Monitoring (CA)

#### Control assessments (CA-2)

> **Guidance:** CA-2 is the formal control assessment: an assessor tests whether each control is implemented correctly, operating as intended and producing the desired outcome. The [assessment plan](https://kston83.github.io/nist-guide/templates/plans/security-and-privacy-assessment-plan/) is approved before testing starts, and the [assessment report](https://kston83.github.io/nist-guide/templates/reports/security-and-privacy-assessment-report/) goes to the people who decide on the system's authorization (CA-6). The assessment procedures are usually the objectives and methods (examine, interview, test) in NIST SP 800-53A Rev. 5 ([January 2022](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final), updated by release 5.2.0 in August 2025; current as of September 2026), shown on each control page. After the first authorization, the yearly assessment can reuse results from continuous monitoring (CA-7) that are still current and were obtained with enough independence.

- The [Chief Information Security Officer] shall select, for each assessment, an assessor or assessment team with the skills and technical knowledge the type of assessment and the system's technologies call for. (CA-2a)
- The assessor shall develop an assessment plan that names the controls and control enhancements under assessment. (CA-2b.1)
- The assessment plan shall describe the assessment procedures used to determine control effectiveness. (CA-2b.2)
- The assessment plan shall describe the assessment environment, the assessment team, and the assessment roles and responsibilities. (CA-2b.3)
- The [System owner] shall obtain the review and approval of the assessment plan by the authorizing official or the authorizing official's designated representative before the assessment begins. (CA-2c)
- The assessor shall assess the controls in the system and its environment of operation before the system's initial authorization, and [Fill in: the frequency at which to assess controls in the system and its environment of operation. Typical: annually for a subset of controls set by the system's continuous monitoring strategy, so every control is assessed at least every three years and within the authorization period] after it, to determine whether the controls are implemented correctly, operating as intended and producing the desired outcome with respect to the system's security and privacy requirements. (CA-2d)
- The assessor shall produce an assessment report that documents the results of the assessment, including whether each control assessed is satisfied or other than satisfied, and the evidence for each result. (CA-2e)
- The assessor shall provide the results of each control assessment to [Fill in: individuals or roles to whom control assessment results are to be provided. Typical: the authorizing official, the system owner and the Chief Information Security Officer]. (CA-2f)
- For a system that processes personally identifiable information, the assessor shall also provide the results of the privacy control assessment to the [Senior privacy official]. (CA-2f)

> **Guidance:** Common controls are assessed once by the organization that provides them, and each system that inherits them reuses that assessment. Record each "other than satisfied" result in the system's plan of action and milestones (CA-5), unless the authorizing official accepts the risk (RA-7).

##### Federal systems

The Federal Information Security Modernization Act requires each agency's information security program to include periodic testing and evaluation of the effectiveness of its information security policies, procedures and practices, "to be performed with a frequency depending on risk, but no less than annually", including testing of the management, operational and technical controls of every information system in the agency's inventory, and using automated tools ([44 U.S.C. § 3554(b)(5)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim)). [OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.c(13) and (14), requires agencies to conduct and document assessments of all selected and implemented security and privacy controls, before a system operates and periodically thereafter, at the frequency the agency's information security continuous monitoring and privacy continuous monitoring strategies set. As of September 2026.

- The [Chief Information Security Officer] shall ensure the controls of every system in the agency's system inventory are tested and evaluated at a frequency that depends on risk, and no less than annually, using automated tools where they apply, as 44 U.S.C. § 3554(b)(5) requires. (CA-2d)
- The [Chief Information Security Officer] shall ensure the assessment frequency set under CA-2d is consistent with the agency's information security continuous monitoring and privacy continuous monitoring strategies and its risk tolerance, as OMB Circular A-130, Appendix I, section 4.c(14), requires. (CA-2d)

#### Independent assessors (CA-2(1))

> **Guidance:** An independent assessor has no actual or perceived conflict of interest with the system: they do not build, run or manage it, do not assess their own work, and do not advocate for the organization they assess. Independence can come from a separate internal team or a third-party assessor, provided the system owner cannot influence the assessor's work or findings. In a small organization where every possible assessor is in the system owner's chain, NIST's CA-2(1) discussion allows an independent team of experts to review and validate the assessment results instead.

- The [Chief Information Security Officer] shall employ independent assessors or assessment teams to conduct control assessments. (CA-2(1))
- The assessor shall be free of any actual or perceived conflict of interest regarding the development, operation, sustainment or management of the system under assessment. (CA-2(1))
- The authorizing official shall determine the level of assessor independence the system needs, based on its security category and risk, and confirm it before approving the assessment plan. (CA-2(1))

#### Specialized assessments (CA-2(2))

> **Guidance:** Specialized assessments go beyond the standard examine, interview and test methods to exercise the organization's defenses as an adversary or insider would. NIST's CA-2(2) discussion has the authorizing official approve the methods, in coordination with the organization's risk executive function. Unannounced assessments test detection and response more realistically but need tighter rules of engagement, so organizations often start with announced ones.

- The assessor shall include [Select one: announced; unannounced. Typical: announced] [Select one or more: in-depth monitoring; security instrumentation; automated security test cases; vulnerability scanning; malicious user testing; insider threat assessment; performance and load testing; data leakage or data loss assessment; [Assignment: organization-defined other forms of assessment]. Typical: vulnerability scanning, malicious user testing, insider threat assessment, and data leakage or data loss assessment] as part of control assessments, [Fill in: frequency at which to include specialized assessments as part of the control assessment. Typical: at least annually]. (CA-2(2))
- The authorizing official shall approve the specialized assessment methods, and their rules of engagement, before they are used. (CA-2(2))
- The [System owner] shall enter each vulnerability that a specialized assessment finds into the system's vulnerability remediation process (RA-5). (CA-2(2))

#### Information exchange (CA-3)

> **Guidance:** CA-3 covers every exchange of information with a system outside the authorization boundary, whether over a dedicated connection, an application programming interface or a file transfer. The [information exchange agreement](https://kston83.github.io/nist-guide/templates/forms/information-exchange-agreement/) records what is exchanged, how it is protected and who is responsible on each side. NIST SP 800-47 Rev. 1, Managing the Security of Information Exchanges ([July 2021](https://csrc.nist.gov/pubs/sp/800/47/r1/final), current as of September 2026), describes how to plan, establish, maintain and end exchanges and their agreements. NIST's CA-3 discussion notes that when both systems have the same authorizing official, no separate agreement is needed: the security and privacy plans describe the interface instead.

- The authorizing official shall approve each exchange of information between the system and another system before the exchange begins. (CA-3a)
- The [System owner] shall manage each exchange of information between the system and other systems using [Select one or more: interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service level agreements; user agreements; non-disclosure agreements; [Assignment: organization-defined type of agreement]. Typical: interconnection security agreements or information exchange security agreements, and service level agreements or contract terms with the same content for external services]. (CA-3a)
- The [System owner] shall record each exchange and the agreement that approves it in the system security plan. (CA-3a)
- Each exchange agreement shall document the interface characteristics, the security and privacy requirements, the controls and the responsibilities for each system, and the impact level of the information communicated. (CA-3b)
- The [System owner] shall review and update each exchange agreement [Fill in: the frequency at which to review and update agreements. Typical: at least annually, and when either system makes a significant change that affects the exchange]. (CA-3c)
- The [System owner] shall end an exchange, and close its agreement, when it is no longer needed or when the other party no longer meets the agreement's security and privacy requirements. (CA-3a)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.c(16), requires agencies to obtain approval from the authorizing official for connections from an information system, as defined by its authorization boundary, to other information systems, based on the risk to the agency's operations and assets, individuals, other organizations and the Nation. Section 4.j(2)(f) requires agreements, such as memoranda of understanding, interconnection security agreements or contracts, for interfaces between agency-owned or operated systems and information systems that contractors or other entities use or operate on behalf of the Federal Government. As of September 2026.

- The authorizing official shall base the approval of each connection to another system on the risk to agency operations and assets, individuals, other organizations and the Nation, as OMB Circular A-130, Appendix I, section 4.c(16), requires. (CA-3a)
- The [System owner] shall ensure a written agreement is in place for each interface between the system and a system that a contractor or other entity uses or operates on behalf of the agency, as OMB Circular A-130, Appendix I, section 4.j(2)(f), requires. (CA-3a)

#### Transfer authorizations (CA-3(6))

> **Guidance:** Transfer authorization checks the sender, not only the connection: before the system accepts data from an interconnected system, it confirms that the person or system sending it is permitted to write that data. Service accounts used for transfers are the usual gap; give each one only the write permissions its exchange agreement names.

- The [System owner] shall ensure the system verifies that individuals or systems transferring data between interconnecting systems have the requisite authorizations, such as write permissions or privileges, before it accepts the data. (CA-3(6))
- Each exchange agreement shall name the accounts or systems authorized to transfer data under it and the permissions each holds. (CA-3(6))

#### Plan of action and milestones (CA-5)

> **Guidance:** The plan of action and milestones (POA&M) records every known weakness until it is fixed or formally accepted. It connects assessments to remediation, and assessors read it closely because it shows whether the organization acts on what it finds. The [POA&M template](https://kston83.github.io/nist-guide/templates/forms/plan-of-action-and-milestones/) lists the fields. Weaknesses in inherited common controls belong on the POA&M of the organization that provides them.

- The [System owner] shall develop a plan of action and milestones for the system that documents the planned remediation actions to correct weaknesses or deficiencies noted during control assessments and to reduce or eliminate known vulnerabilities in the system. (CA-5a)
- Each item in the plan of action and milestones shall record the weakness and its source, the responsible person or team, the resources required, the milestones and the scheduled completion date. (CA-5a)
- The [System owner] shall update the plan of action and milestones [Fill in: the frequency at which to update an existing plan of action and milestones based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities. Typical: at least monthly, and whenever an assessment, audit, scan or monitoring activity finds a new weakness], based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities. (CA-5b)
- The [System owner] shall record the reason for each change to a scheduled completion date, and close an item only with evidence that the weakness is corrected. (CA-5b)
- The [Chief Information Security Officer] shall review items past their scheduled completion date each month, and report them to the authorizing official. (CA-5b)

> **Guidance:** A weakness the organization decides not to fix goes through risk acceptance (RA-7), within the tolerance the risk management strategy sets. Record the acceptance and its review date against the item, so an assessor can trace every finding to either a fix or a decision.

##### Federal systems

The Federal Information Security Modernization Act requires each agency's information security program to include "a process for planning, implementing, evaluating, and documenting remedial action to address any deficiencies in the information security policies, procedures, and practices of the agency" ([44 U.S.C. § 3554(b)(6)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim)). [OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.c(15), requires agencies to use POA&Ms to record and manage the mitigation and remediation of identified weaknesses and deficiencies not associated with accepted risks, and to make them available to OMB, DHS, inspectors general and the U.S. Government Accountability Office on request. Section 4.k requires agencies to correct deficiencies identified through assessments, continuous monitoring and audits, and to track and manage their remediation through the POA&M process, with material deficiencies also reported in the annual Federal Managers Financial Integrity Act report. As of September 2026.

- The [System owner] shall record in the plan of action and milestones each weakness and deficiency not associated with an accepted risk, including those found by OMB reviews and internal or external audits, as OMB Circular A-130, Appendix I, sections 4.c(15) and 4.k, requires. (CA-5a)
- The [Chief Information Security Officer] shall make plans of action and milestones available to OMB, DHS, the inspector general and the U.S. Government Accountability Office on request, as OMB Circular A-130, Appendix I, section 4.c(15), requires. (CA-5b)

#### Authorization (CA-6)

> **Guidance:** Authorization is a senior official's decision to accept the risk of operating a system, based on the authorization package: the system security plan, the [assessment report](https://kston83.github.io/nist-guide/templates/reports/security-and-privacy-assessment-report/) and the plan of action and milestones. The authorizing official should have budget or mission responsibility for the system, so the person who accepts the risk also owns its consequences. Ongoing authorization replaces the fixed termination date with decisions made from continuous monitoring results; it needs an initial authorization and a working continuous monitoring program (CA-7) first.

- The [Senior leader] shall assign a senior official, with budget or mission responsibility for the system, as the authorizing official for the system. (CA-6a)
- The [Senior leader] shall assign a senior official as the authorizing official for the common controls available for inheritance by organizational systems. (CA-6b)
- The [System owner] shall ensure that, before the system begins operating, the authorizing official for the system accepts the use of the common controls the system inherits. (CA-6c.1)
- The [System owner] shall ensure that the authorizing official authorizes the system to operate, based on the authorization package, before the system begins operating. (CA-6c.2)
- The authorizing official's decision shall be recorded in a signed authorization decision document that states the decision, any terms and conditions, and the authorization termination date or that the system is under ongoing authorization. (CA-6c.2)
- The [Chief Information Security Officer] shall ensure that the authorizing official for common controls authorizes the use of those controls for inheritance by organizational systems. (CA-6d)
- The authorizing official shall update the authorization [Fill in: frequency at which to update the authorizations. Typical: at least every three years and after a significant change, or on the time- or event-driven basis the continuous monitoring strategy sets once the authorizing official moves the system to ongoing authorization]. (CA-6e)
- When the authorizing official changes, the new authorizing official shall review the current authorization and either accept the documented risk in a new signed decision or begin a reauthorization. (CA-6e)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.d(1) to (4), requires agencies to designate senior Federal officials to authorize systems and agency-designated common controls; to complete an initial authorization to operate for each system and all agency-designated common controls, based on an explicit acceptance of risk, before operation; to move systems and common controls to an ongoing authorization process when eligible and with the authorizing official's formal approval; and to reauthorize them as needed, on a time- or event-driven basis, in line with agency risk tolerance. Section 5.f states that only Federal Government personnel may serve as an authorizing official, and that the agency must consider the Senior Agency Official for Privacy's input in the authorization decision. Section 5.h sets two conditions for ongoing authorization: an initial authorization to operate, and continuous monitoring programs that monitor all implemented security and privacy controls at the frequencies the strategies set; until the authorizing official formally approves the transition, the system keeps a specific authorization termination date. NIST SP 800-37 Rev. 2 ([December 2018](https://csrc.nist.gov/pubs/sp/800/37/r2/final), current as of September 2026) describes the authorization tasks. As of September 2026.

- The [Senior leader] shall assign only Federal Government personnel as authorizing officials, as OMB Circular A-130, Appendix I, section 5.f, requires. (CA-6a)
- For a system that processes personally identifiable information, the authorizing official shall consider the input and recommendations of the Senior Agency Official for Privacy before making the authorization decision, as OMB Circular A-130, Appendix I, section 5.f, requires. (CA-6c.2)
- The [System owner] shall move the system to ongoing authorization only after an initial authorization to operate, with a continuous monitoring program that meets the conditions of OMB Circular A-130, Appendix I, section 5.h, and with the authorizing official's formal approval. (CA-6e)

#### Continuous monitoring (CA-7)

> **Guidance:** Continuous monitoring keeps the authorization current between full assessments. The system's [Continuous Monitoring Strategy](https://kston83.github.io/nist-guide/templates/plans/continuous-monitoring-strategy/) follows the organization-wide strategy (PM-31) and sets what is measured, how often each control is monitored and assessed, how results are analyzed and acted on, and how often the system's status is reported. A common approach assigns each control a frequency by how often it changes: vulnerability management monthly, physical security annually. NIST SP 800-137 ([September 2011](https://csrc.nist.gov/pubs/sp/800/137/final), current as of September 2026) describes information security continuous monitoring.

- The [System owner] shall develop a system-level continuous monitoring strategy that follows the organization-wide continuous monitoring strategy, and implement continuous monitoring in accordance with it. (CA-7)
- The system-level strategy shall establish the following system-level metrics to be monitored: [Fill in: system-level metrics to be monitored. Typical: open vulnerabilities by severity and age, configuration compliance rate, plan of action and milestones items past due, and unauthorized components found]. (CA-7a)
- The system-level strategy shall establish that control effectiveness is monitored [Fill in: frequencies at which to monitor control effectiveness. Typical: continuously for automated controls, and at least monthly for vulnerability, configuration and account data]. (CA-7b)
- The system-level strategy shall establish that control effectiveness is assessed at [Fill in: frequencies at which to assess control effectiveness. Typical: the schedule in the system's continuous monitoring strategy, assessing a third of the controls each year so every control is assessed at least every three years]. (CA-7b)
- The [System owner] shall ensure ongoing control assessments are carried out in accordance with the continuous monitoring strategy. (CA-7c)
- The [System owner] shall ensure the system-level and organization-defined metrics are monitored on an ongoing basis in accordance with the continuous monitoring strategy. (CA-7d)
- The [System owner] shall correlate and analyze the information that control assessments and monitoring produce. (CA-7e)
- The [System owner] shall take response actions to address the results of that analysis, recording weaknesses in the plan of action and milestones (CA-5) and raising risks above tolerance with the authorizing official. (CA-7f)
- The [System owner] shall report the security status of the system to [Fill in: personnel or roles to whom the security status of the system is reported. Typical: the authorizing official and the Chief Information Security Officer], [Fill in: frequency at which the security status of the system is reported. Typical: at least quarterly]. (CA-7g)
- For a system that processes personally identifiable information, the [System owner] shall report the privacy status of the system to [Fill in: personnel or roles to whom the privacy status of the system is reported. Typical: the authorizing official and the senior privacy official], [Fill in: frequency at which the privacy status of the system is reported. Typical: at least quarterly]. (CA-7g)
- The [System owner] shall review and update the system-level strategy when the system changes significantly, when the organization-wide strategy changes, and at least annually. (CA-7)

> **Guidance:** Give the system owner the metrics monthly, even when the authorizing official receives a quarterly report, so action is not left to the formal report. The organization-wide strategy (PM-31) may need each system's data monthly for its own reports. The frequencies set here should also match the assessment frequency under CA-2d, since the yearly assessment is usually the continuous monitoring assessments of that year.

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.d(5) to (8), requires agencies to develop and maintain an information security continuous monitoring (ISCM) strategy, update it at an organization-defined frequency, ensure all selected and implemented controls are addressed in it and effectively monitored on an ongoing basis, and keep an ISCM program with metrics that give meaningful indications of security status and trend analysis at every risk management tier. Section 4.d(9) adds a privacy continuous monitoring (PCM) strategy; footnote 85 allows the two strategies to be combined into one. Section 5.c says that, after the authorization decision, agencies monitor the controls in each system on an ongoing basis, as described in NIST SP 800-137, including assessing control effectiveness, documenting changes, analyzing their security impact and reporting the system's security state to designated officials. As of September 2026.

- The [System owner] shall ensure every control selected and implemented for the system is addressed in the system-level strategy and monitored on an ongoing basis, as OMB Circular A-130, Appendix I, section 4.d(7), requires. (CA-7c)
- The [System owner] shall ensure the system-level strategy follows the agency's ISCM strategy and, for a system that processes personally identifiable information, its PCM strategy, or the single strategy that combines them. (CA-7)

#### Independent assessment (CA-7(1))

> **Guidance:** The independence rules of CA-2(1) apply to ongoing assessments too. Automated monitoring data can come from the system's own tools, but the people who assess what the data shows should not be the system's administrators. Common ways to meet it are a continuous monitoring team in the security office or the same third-party assessor that performs the yearly assessment.

- The [Chief Information Security Officer] shall employ independent assessors or assessment teams to monitor the controls in the system on an ongoing basis. (CA-7(1))
- The ongoing assessors shall meet the independence the authorizing official set for the system under CA-2(1). (CA-7(1))

#### Risk monitoring (CA-7(4))

> **Guidance:** Risk monitoring ties continuous monitoring to the risk tolerance in the risk management strategy (PM-9). Effectiveness monitoring asks whether the risk responses work, compliance monitoring asks whether they are in place, and change monitoring looks for changes that could alter the risk. Change monitoring usually draws on configuration change control (CM-3), security impact analyses (CM-4) and the component inventory (CM-8).

- The [System owner] shall make risk monitoring an integral part of the system's continuous monitoring strategy, informed by the organization's risk tolerance. (CA-7(4))
- The strategy shall include effectiveness monitoring, to determine whether the implemented risk response measures remain effective. (CA-7(4)(a))
- The strategy shall include compliance monitoring, to verify that required risk response measures are implemented and that security and privacy requirements are satisfied. (CA-7(4)(b))
- The strategy shall include change monitoring, to identify changes to the system and its environment of operation that may affect security and privacy risk. (CA-7(4)(c))

#### Penetration testing (CA-8)

> **Guidance:** Penetration testing goes beyond automated vulnerability scanning: skilled testers try to exploit weaknesses the way an adversary would, within agreed limits of time, scope and method. Written rules of engagement, approved before testing, set the scope, times, methods allowed, contacts and how a test is stopped. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment ([September 2008](https://csrc.nist.gov/pubs/sp/800/115/final), current as of September 2026), describes planning and running penetration tests.

- The [Chief Information Security Officer] shall conduct penetration testing [Fill in: frequency at which to conduct penetration testing on systems or system components. Typical: at least annually, and after a significant change to the system] on [Fill in: systems or system components on which penetration testing is to be conducted. Typical: the system's internet-facing components and applications, and a sample of its internal components]. (CA-8)
- The authorizing official shall approve written rules of engagement, covering scope, timing, methods, contacts and how testing is stopped, before each penetration test begins. (CA-8)
- The [System owner] shall enter each weakness a penetration test finds into the system's plan of action and milestones or vulnerability remediation process. (CA-8)

#### Independent penetration testing agent or team (CA-8(1))

> **Guidance:** An independent penetration testing team is one with no conflict of interest in the system, as for independent assessors under CA-2(1). It can be an internal red team outside the system's chain of command or an outside firm.

- The [Chief Information Security Officer] shall employ an independent penetration testing agent or team to perform penetration testing on the system or system components. (CA-8(1))

#### Internal system connections (CA-9)

> **Guidance:** Internal connections are connections between the system and its own separate components, such as printers or mobile devices, rather than other systems (CA-3). NIST's CA-9 discussion lets the organization authorize a whole class of components with a common configuration instead of each device, which is the usual approach. Record each authorized class in the system security plan.

- The [System owner] shall authorize internal connections of [Fill in: system components or classes of components requiring internal connections to the system. Typical: classes of components that connect to the system from inside its boundary, such as printers, scanners, copiers, sensors, and mobile devices with the approved baseline configuration] to the system. (CA-9a)
- The [System owner] shall document, for each internal connection or class of connection, the interface characteristics, the security and privacy requirements, and the nature of the information communicated, in the system security plan. (CA-9b)
- The [System owner] shall terminate an internal system connection when [Fill in: conditions requiring termination of internal connections. Typical: the component is retired or reassigned, fails a compliance check, is involved in an incident, or no longer needs the connection]. (CA-9c)
- The [System owner] shall review [Fill in: frequency at which to review the continued need for each internal connection. Typical: at least annually] the continued need for each internal connection, based on whether it supports the organization's missions or business functions. (CA-9d)

### Configuration Management (CM)

#### Baseline configuration (CM-2)

- The [System owner] shall develop, document and maintain under configuration control a current baseline configuration of the system. (CM-2a)
- The [System owner] shall review and update the baseline configuration [Fill in: the frequency of baseline configuration review and update. Typical: at least annually]. (CM-2b.1)
- The [System owner] shall review and update the baseline configuration 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]. (CM-2b.2)
- The [System owner] shall review and update the baseline configuration when system components are installed or upgraded. (CM-2b.3)

#### Automation support for accuracy and currency (CM-2(2))

- The [System owner] shall maintain the currency, completeness, accuracy and availability of the baseline configuration 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))

#### Retention of previous configurations (CM-2(3))

- The [System owner] shall retain [Fill in: the number of previous baseline configuration versions to be retained. Typical: at least the two most recent] previous versions of the baseline configuration to support rollback. (CM-2(3))

#### Configure systems and components for high-risk areas (CM-2(7))

- The [Chief Information Security Officer] shall ensure individuals traveling to locations the organization deems to be of significant risk are 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]. (CM-2(7)(a))
- When those individuals return, the [Chief Information Security Officer] shall ensure the following controls are applied to the devices: [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]. (CM-2(7)(b))

#### Configuration change control (CM-3)

> **Guidance:** CM-3 is where most programs either show discipline or show a gap. Keep one change record per change, with the request, the impact analysis (CM-4), the decision, the test result and the implementation date. Assessors sample changes from the system and trace each back to an approved record.

- The [System owner] shall determine and document the types of changes to the system that are configuration-controlled. (CM-3a)
- The [System owner] shall review proposed configuration-controlled changes and approve or disapprove them with explicit consideration of security and privacy impact analyses. (CM-3b)
- The [System owner] shall document configuration change decisions for the system. (CM-3c)
- The [System owner] shall implement only approved configuration-controlled changes. (CM-3d)
- The [System owner] shall retain records of configuration-controlled changes 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)
- The [System owner] shall monitor and review activities associated with configuration-controlled changes. (CM-3f)
- Configuration change control activities shall be 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)

#### Automated documentation, notification and prohibition of changes (CM-3(1))

- The [System owner] shall use [Fill in: mechanisms used to automate configuration change control. Typical: the change management system integrated with the deployment pipeline] to document proposed changes to the system. (CM-3(1)(a))
- The [System owner] shall use those mechanisms 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] of proposed changes and request approval. (CM-3(1)(b))
- The [System owner] shall use those mechanisms 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]. (CM-3(1)(c))
- The [System owner] shall use those mechanisms to prohibit changes until the designated approvals are received. (CM-3(1)(d))
- The [System owner] shall use those mechanisms to document all changes to the system. (CM-3(1)(e))
- The [System owner] shall use those mechanisms 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)(f))

#### Testing, validation and documentation of changes (CM-3(2))

- The [System owner] shall test, validate and document changes before finalizing their implementation. (CM-3(2))

#### Security and privacy representatives (CM-3(4))

- The [System owner] shall require [Fill in: security and privacy representatives. Typical: a representative of the security team and, where the system processes personal information, of the privacy office] to be 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))

#### Cryptography management (CM-3(6))

- The [System owner] shall ensure the cryptographic mechanisms that provide [Fill in: controls provided by cryptographic mechanisms that are to be under configuration management. Typical: encryption in transit and at rest, digital signatures and authentication (SC-8, SC-13, SC-28, IA-5)] are under configuration management. (CM-3(6))

#### Impact analyses (CM-4)

- The [System owner] shall analyze changes to the system to determine potential security and privacy impacts before the changes are implemented. (CM-4)

#### Separate test environments (CM-4(1))

- The [System owner] shall analyze changes in a separate test environment, before implementation in the operational environment, for security and privacy impacts from flaws, weaknesses, incompatibility or intentional malice. (CM-4(1))

#### Verification of controls (CM-4(2))

- After a system change, the [System owner] shall verify that the impacted controls are implemented correctly, operating as intended and producing the desired outcome. (CM-4(2))

#### Access restrictions for change (CM-5)

- The [System owner] shall define, document, approve and enforce physical and logical access restrictions associated with changes to the system. (CM-5)

#### Automated access enforcement and audit records (CM-5(1))

- The [System owner] shall enforce access restrictions for change using [Fill in: mechanisms used to automate the enforcement of access restrictions. Typical: role-based permissions in the deployment pipeline and the configuration management tools]. (CM-5(1)(a))
- The [System owner] shall ensure audit records of the enforcement actions are generated automatically. (CM-5(1)(b))

#### Configuration settings (CM-6)

> **Guidance:** Pick a published secure configuration for each component type rather than writing your own: vendor security baselines and checklists from the NIST National Checklist Program ([SP 800-70 Rev. 5](https://csrc.nist.gov/pubs/sp/800/70/r5/final), May 2026) are common starting points. Record each deviation with its reason and approval; assessors compare scan results against the baseline and ask for the approval of every difference.

- The [System owner] shall establish and document configuration settings for system components that reflect the most restrictive mode consistent with operational requirements, 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]. (CM-6a)
- The [System owner] shall implement the configuration settings. (CM-6b)
- The [System owner] shall identify, document and approve any deviation from the established settings for [Fill in: system components for which approval of deviations is needed. Typical: all system components], 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)
- The [System owner] shall monitor and control changes to the configuration settings in accordance with this policy and its procedures. (CM-6d)

#### Automated management, application and verification (CM-6(1))

- The [System owner] shall manage, apply and verify configuration settings for [Fill in: system components for which to manage, apply, and verify configuration settings. Typical: all servers, workstations and network devices] using [Fill in: automated mechanisms. Typical: configuration management tools and compliance scanning]. (CM-6(1))

#### Respond to unauthorized changes (CM-6(2))

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

#### Least functionality (CM-7)

- The [System owner] shall configure the system to provide only [Fill in: mission-essential capabilities for the system. Typical: the capabilities documented in the system security plan]. (CM-7a)
- The [System owner] shall prohibit or restrict 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]. (CM-7b)

#### Periodic review (CM-7(1))

- The [System owner] shall review the system [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] 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]. (CM-7(1)(b))

#### Prevent program execution (CM-7(2))

- The [System owner] shall ensure the system prevents program execution in accordance with [Select one or more: [Assignment: organization-defined policies, rules of behavior, and/or access agreements regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage. Typical: the software rules in this policy, the rules of behavior and the access agreements]. (CM-7(2))

#### Authorized software: allow by exception (CM-7(5))

- The [System owner] shall identify [Fill in: software programs authorized to execute on the system. Typical: the software on the approved software list for the system] as the software programs authorized to execute on the system. (CM-7(5)(a))
- The [System owner] shall employ a deny-all, permit-by-exception policy to allow only authorized software programs to execute. (CM-7(5)(b))
- The [System owner] shall review and update the list of authorized software programs [Fill in: frequency at which to review and update the list of authorized software programs. Typical: at least quarterly]. (CM-7(5)(c))

#### System component inventory (CM-8)

- The [System owner] shall develop and document an inventory of system components that accurately reflects the system and includes all its components. (CM-8a.1, a.2)
- The [System owner] shall ensure the inventory has no duplicate accounting of components and no components assigned to another system. (CM-8a.3)
- The [System owner] shall ensure the inventory is at the level of granularity needed for tracking and reporting. (CM-8a.4)
- The [System owner] shall ensure the inventory includes [Fill in: information deemed necessary to achieve effective system component accountability. Typical: name, type, manufacturer and model, serial number or asset tag, software version, location, network address, owner and administrator] for each component. (CM-8a.5)
- The [System owner] shall review and update the inventory [Fill in: frequency at which to review and update the system component inventory. Typical: at least quarterly]. (CM-8b)

#### Updates during installation and removal (CM-8(1))

- The [System owner] shall update the component inventory as part of component installations, removals and system updates. (CM-8(1))

#### Automated maintenance (CM-8(2))

- The [System owner] shall maintain the currency, completeness, accuracy and availability of the component inventory using [Fill in: automated mechanisms. Typical: asset discovery and endpoint management tools that feed the inventory]. (CM-8(2))

#### Automated unauthorized component detection (CM-8(3))

- The [System owner] shall detect the presence of unauthorized hardware, software and firmware components using [Fill in: automated mechanisms. Typical: network access control, asset discovery scans and endpoint management tools] [Fill in: frequency at which automated mechanisms are used to detect the presence of unauthorized system components within the system. Typical: continuously, and at least weekly by scan]. (CM-8(3)(a))
- When unauthorized components are detected, the [System owner] shall [Select one or more: disable network access by unauthorized components; isolate unauthorized components; notify [Assignment: organization-defined personnel or roles]. Typical: disable network access by unauthorized components, and notify the security operations team]. (CM-8(3)(b))

#### Accountability information (CM-8(4))

- The [System owner] shall ensure the component inventory identifies, by [Select one or more: name; position; role. Typical: role], the individuals responsible and accountable for administering each component. (CM-8(4))

#### Configuration management plan (CM-9)

- The [System owner] shall develop, document and implement a configuration management plan for the system that addresses roles, responsibilities, and configuration management processes and procedures. (CM-9a)
- The [System owner] shall ensure the plan establishes a process for identifying configuration items throughout the system development life cycle and for managing their configuration. (CM-9b)
- The [System owner] shall ensure the plan defines the configuration items for the system and places them under configuration management. (CM-9c)
- The plan shall be reviewed and 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)
- The [System owner] shall protect the plan from unauthorized disclosure and modification. (CM-9e)

#### Software usage restrictions (CM-10)

- Users shall use software and its documentation in accordance with contract agreements and copyright laws. (CM-10a)
- The [System owner] shall track the use of software and documentation protected by quantity licenses to control copying and distribution. (CM-10b)
- The [System owner] shall control and document the use of peer-to-peer file sharing technology so that it is not used for unauthorized distribution, display, performance or reproduction of copyrighted work. (CM-10c)

#### User-installed software (CM-11)

- The [Chief Information Security Officer] shall establish the following rules for software installation by users: [Fill in: policies governing the installation of software by users. Typical: users may install only software from the organization's approved software catalog; all other installation requires approval by the system owner]. (CM-11a)
- The [System owner] shall enforce those rules through [Fill in: methods used to enforce software installation policies. Typical: removing local administrator rights and using an application allow list]. (CM-11b)
- The [System owner] shall monitor compliance with those rules [Fill in: frequency with which to monitor compliance. Typical: at least monthly]. (CM-11c)

#### Information location (CM-12)

- The [System owner] shall identify and document the location of [Fill in: information for which the location is to be identified and documented. Typical: the information types listed in the system security plan] and the specific components on which it is processed and stored. (CM-12a)
- The [System owner] shall identify and document the users who have access to the system and components where that information is processed and stored. (CM-12b)
- The [System owner] shall document changes to the location where that information is processed and stored. (CM-12c)

#### Automated tools to support information location (CM-12(1))

- The [System owner] shall use automated tools to identify [Fill in: information to be protected is defined by information type. Typical: personal information and other sensitive information types listed in the system security plan] on [Fill in: system components where the information is located. Typical: file shares, databases, cloud storage and endpoints] to confirm controls are in place to protect organizational information and individual privacy. (CM-12(1))

### Contingency Planning (CP)

#### Contingency plan (CP-2)

> **Guidance:** The contingency plan says how a system is kept going, or brought back, after a disruption, compromise or failure. Base it on a [business impact analysis](https://kston83.github.io/nist-guide/templates/reports/business-impact-analysis/), which sets the recovery objectives. The [Information System Contingency Plan template](https://kston83.github.io/nist-guide/templates/plans/contingency-plan/) follows NIST SP 800-34 Rev. 1 and covers each element of CP-2a.

- Each [System owner] shall develop a contingency plan for the system that identifies essential mission and business functions and the contingency requirements that go with them. (CP-2a.1)
- The contingency plan shall provide recovery objectives, restoration priorities and metrics. (CP-2a.2)
- The contingency plan shall set out contingency roles and responsibilities, and the assigned individuals with their contact information. (CP-2a.3)
- The contingency plan shall address maintaining essential mission and business functions despite a system disruption, compromise or failure. (CP-2a.4)
- The contingency plan shall address eventual, full system restoration without deterioration of the controls originally planned and implemented. (CP-2a.5)
- The contingency plan shall address the sharing of contingency information. (CP-2a.6)
- The contingency plan shall be reviewed by [Fill in: personnel or roles to review a contingency plan. Typical: the system owner and the system security officer] and approved by [Fill in: personnel or roles to approve a contingency plan. Typical: the authorizing official, or the business owner the authorizing official names]. (CP-2a.7)
- The [System owner] shall distribute copies of the contingency plan to [Fill in: key contingency personnel (identified by name and/or by role) to whom copies of the contingency plan are distributed. Typical: the contingency team members, by role] and to [Fill in: key contingency organizational elements to which copies of the contingency plan are distributed. Typical: the operations, facilities and communications functions]. (CP-2b)
- The [System owner] shall coordinate contingency planning activities with incident handling activities. (CP-2c)
- The [System owner] shall review the contingency plan [Fill in: frequency of contingency plan review. Typical: annually]. (CP-2d)
- The [System owner] shall update the contingency plan to address changes to the organization, the system or its environment of operation, and problems found when the plan is carried out or tested. (CP-2e)
- The [System owner] shall communicate contingency plan changes to [Fill in: key contingency personnel (identified by name and/or by role) to communicate changes to. Typical: the contingency team members, by role] and to [Fill in: key contingency organizational elements to communicate changes to. Typical: the operations, facilities and communications functions]. (CP-2f)
- The [System owner] shall incorporate lessons learned from contingency plan testing, training and actual contingency activities into contingency testing and training. (CP-2g)
- The [System owner] shall protect the contingency plan from unauthorized disclosure and modification. (CP-2h)

#### Coordinate with related plans (CP-2(1))

> **Guidance:** Related plans include the business continuity plan, the continuity of operations plan, the disaster recovery plan, the incident response plan and the crisis communications plan. Coordination means the plans agree on priorities, recovery times, contacts and who declares what.

- The [System owner] shall coordinate contingency plan development with the organizational elements responsible for related plans. (CP-2(1))

#### Capacity planning (CP-2(2))

- The [System owner] shall conduct capacity planning so that the processing, telecommunications and environmental support capacity needed during contingency operations exists. (CP-2(2))

#### Resume mission and business functions (CP-2(3))

- The [System owner] shall plan for the resumption of [Select one: all; essential. Typical: essential] mission and business functions within [Fill in: the contingency plan activation time period within which to resume mission and business functions. Typical: the recovery time objective set in the contingency plan from the business impact analysis] of contingency plan activation. (CP-2(3))

#### Continue mission and business functions (CP-2(5))

- The [System owner] shall plan for the continuance of [Select one: all; essential. Typical: essential] mission and business functions with minimal or no loss of operational continuity, sustained until full system restoration at the primary processing or storage sites. (CP-2(5))

#### Identify critical assets (CP-2(8))

> **Guidance:** Critical assets are the components, services and people the functions cannot run without. The criticality analysis (RA-9) and the business impact analysis are the usual sources.

- The [System owner] shall identify the critical system assets that support [Select one: all; essential. Typical: essential] mission and business functions. (CP-2(8))

#### Contingency training (CP-3)

> **Guidance:** Contingency training teaches people with a role in the plan what they do and how: who declares a disruption, how to restore from backup, how to fail over to the alternate site. Users without a contingency role need only know where to get instructions, which literacy training (AT-2) can cover.

- The [System owner] shall provide contingency training, consistent with assigned roles and responsibilities, to system users within [Fill in: the time period within which to provide contingency training after assuming a contingency role or responsibility. Typical: 30 days] of their assuming a contingency role or responsibility. (CP-3a.1)
- The [System owner] shall provide that training when system changes require it. (CP-3a.2)
- The [System owner] shall provide that training [Fill in: frequency at which to provide training to system users with a contingency role or responsibility. Typical: annually] thereafter. (CP-3a.3)
- The [System owner] shall review and update contingency training content [Fill in: frequency at which to review and update contingency training content. Typical: annually] and following [Fill in: events necessitating review and update of contingency training. Typical: a change to the contingency plan, and lessons learned from a test or an actual contingency event]. (CP-3b)

#### Simulated events (CP-3(1))

- The [System owner] shall incorporate simulated events into contingency training so personnel practice an effective response to crisis situations. (CP-3(1))

#### Contingency plan testing (CP-4)

> **Guidance:** A tabletop exercise checks that people know the plan; a functional test checks that recovery actually works. NIST SP 800-84 describes both. Plan each test with the [test plan template](https://kston83.github.io/nist-guide/templates/plans/contingency-plan-test-plan/), record the results in an [after-action report](https://kston83.github.io/nist-guide/templates/reports/contingency-plan-after-action-report/), and track corrective actions to closure.

- The [System owner] shall test the contingency plan [Fill in: frequency of testing the contingency plan for the system. Typical: annually], using [Fill in: tests for determining the effectiveness of the contingency plan. Typical: a functional test that restores the system, or a representative part of it, from backup] to determine the plan's effectiveness and [Fill in: tests for determining readiness to execute the contingency plan. Typical: a tabletop exercise that walks the contingency team through the plan] to determine readiness to execute it. (CP-4a)
- The [System owner] shall review the contingency plan test results. (CP-4b)
- The [System owner] shall initiate corrective actions where the results show they are needed, and track them in the plan of action and milestones. (CP-4c)

#### Coordinate with related plans (CP-4(1))

- The [System owner] shall coordinate contingency plan testing with the organizational elements responsible for related plans. (CP-4(1))

#### Alternate processing site (CP-4(2))

- The [System owner] shall test the contingency plan at the alternate processing site to familiarize contingency personnel with the facility and its resources. (CP-4(2)(a))
- The [System owner] shall test the contingency plan at the alternate processing site to evaluate the site's capability to support contingency operations. (CP-4(2)(b))

#### Alternate storage site (CP-6)

> **Guidance:** The alternate storage site holds the backups needed to recover the system. For a system in the cloud, a separate region or availability zone from the same provider can serve as the alternate site, if it meets the separation and control requirements below and the provider agreement supports it.

- The [System owner] shall establish an alternate storage site, including the agreements needed to permit the storage and retrieval of system backup information. (CP-6a)
- The [System owner] shall ensure the alternate storage site provides controls equivalent to those of the primary site. (CP-6b)

#### Separation from primary site (CP-6(1))

- The [System owner] shall identify an alternate storage site sufficiently separated from the primary storage site to reduce susceptibility to the same threats. (CP-6(1))

#### Recovery time and recovery point objectives (CP-6(2))

- The [System owner] shall configure the alternate storage site to support recovery operations in accordance with the recovery time and recovery point objectives. (CP-6(2))

#### Accessibility (CP-6(3))

- The [System owner] shall identify potential problems with access to the alternate storage site in an area-wide disruption or disaster, and set out explicit mitigation actions. (CP-6(3))

#### Alternate processing site (CP-7)

> **Guidance:** The alternate processing site is where the system runs when the primary site cannot. For a system in the cloud, a separate region or availability zone from the same provider can serve as the alternate site, if it meets the separation and control requirements below and the provider agreement supports it.

- The [System owner] shall establish an alternate processing site, including the agreements needed to permit the transfer and resumption of [Fill in: system operations for essential mission and business functions. Typical: the system operations that support essential mission and business functions] for essential mission and business functions within [Fill in: time period consistent with recovery time and recovery point objectives. Typical: the recovery time objective set in the contingency plan from the business impact analysis] when the primary processing capabilities are unavailable. (CP-7a)
- The [System owner] shall make available at the alternate processing site the equipment and supplies needed to transfer and resume operations, or put contracts in place to deliver them to the site within that time period. (CP-7b)
- The [System owner] shall provide controls at the alternate processing site equivalent to those at the primary site. (CP-7c)

#### Separation from primary site (CP-7(1))

- The [System owner] shall identify an alternate processing site sufficiently separated from the primary processing site to reduce susceptibility to the same threats. (CP-7(1))

#### Accessibility (CP-7(2))

- The [System owner] shall identify potential problems with access to the alternate processing site in an area-wide disruption or disaster, and set out explicit mitigation actions. (CP-7(2))

#### Priority of service (CP-7(3))

- The [System owner] shall ensure alternate processing site agreements contain priority-of-service provisions in accordance with the system's availability requirements, including recovery time objectives. (CP-7(3))

#### Preparation for use (CP-7(4))

- The [System owner] shall prepare the alternate processing site so that it can serve as the operational site supporting essential mission and business functions. (CP-7(4))

#### Telecommunications services (CP-8)

> **Guidance:** Alternate telecommunications keep the system reachable when the primary network or internet service fails, at the primary site or at the alternate sites: for example a second internet provider, a wireless backup link, or a provider-managed network with diverse paths.

- The [System owner] shall establish alternate telecommunications services, including the agreements needed to permit the resumption of [Fill in: system operations to be resumed for essential mission and business functions. Typical: the system operations that support essential mission and business functions] for essential mission and business functions within [Fill in: time period within which to resume essential mission and business functions when the primary telecommunications capabilities are unavailable. Typical: the recovery time objective set in the contingency plan from the business impact analysis] when the primary telecommunications capabilities are unavailable at the primary or alternate processing or storage sites. (CP-8)

#### Priority of service provisions (CP-8(1))

- The [System owner] shall ensure primary and alternate telecommunications service agreements contain priority-of-service provisions in accordance with the system's availability requirements, including recovery time objectives. (CP-8(1)(a))
- Where the primary or alternate telecommunications services are provided by a common carrier, the [System owner] shall request Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness. (CP-8(1)(b))

##### Federal systems

[Telecommunications Service Priority](https://www.cisa.gov/resources-tools/services/telecommunications-service-priority-tsp) is an FCC program, managed by CISA, which requires service providers to prioritize provisioning and restoration of voice and data circuits for organizations with national security and emergency preparedness missions (checked September 2026). CISA's priority services are open to all levels of government and to organizations in the critical infrastructure sectors.

- The [System owner] shall register the system's national security and emergency preparedness circuits in the Telecommunications Service Priority program. (CP-8(1)(b))

#### Single points of failure (CP-8(2))

- The [System owner] shall obtain alternate telecommunications services that reduce the likelihood of sharing a single point of failure with the primary telecommunications services. (CP-8(2))

#### Separation of primary and alternate providers (CP-8(3))

- The [System owner] shall obtain alternate telecommunications services from providers separated from the primary service providers, to reduce susceptibility to the same threats. (CP-8(3))

#### Provider contingency plan (CP-8(4))

- The [System owner] shall require primary and alternate telecommunications service providers to have contingency plans. (CP-8(4)(a))
- The [System owner] shall review provider contingency plans to ensure they meet the organization's contingency requirements. (CP-8(4)(b))
- The [System owner] shall obtain evidence of contingency testing by providers [Fill in: frequency at which to obtain evidence of contingency testing by providers. Typical: annually], and of contingency training by providers [Fill in: frequency at which to obtain evidence of contingency training by providers. Typical: annually]. (CP-8(4)(c))

#### System backup (CP-9)

> **Guidance:** Set backup frequencies from the recovery point objectives in the contingency plan: how much data the business can afford to lose. Keep at least one copy that ransomware on the production network cannot reach or change, such as an immutable or offline copy.

- The [System owner] shall ensure backups of user-level information in [Fill in: system components for which to conduct backups of user-level information. Typical: all servers and cloud storage that hold user data] are made [Fill in: frequency at which to conduct backups of user-level information consistent with recovery time and recovery point objectives. Typical: daily incremental and weekly full, or more often where the recovery point objective requires it]. (CP-9a)
- The [System owner] shall ensure backups of system-level information are made [Fill in: frequency at which to conduct backups of system-level information consistent with recovery time and recovery point objectives. Typical: daily incremental and weekly full, or more often where the recovery point objective requires it]. (CP-9b)
- The [System owner] shall ensure backups of system documentation, including security- and privacy-related documentation, are made [Fill in: frequency at which to conduct backups of system documentation consistent with recovery time and recovery point objectives. Typical: on each change]. (CP-9c)
- The [System owner] shall protect the confidentiality, integrity and availability of backup information. (CP-9d)

#### Testing for reliability and integrity (CP-9(1))

- The [System owner] shall test backup information [Fill in: frequency at which to test backup information for media reliability. Typical: quarterly] to verify media reliability. (CP-9(1))
- The [System owner] shall test backup information [Fill in: frequency at which to test backup information for information integrity. Typical: quarterly] to verify information integrity. (CP-9(1))

#### Test restoration using sampling (CP-9(2))

- The [System owner] shall use a sample of backup information to restore selected system functions as part of contingency plan testing. (CP-9(2))

#### Separate storage for critical information (CP-9(3))

- The [System owner] shall store backup copies of [Fill in: critical system software and other security-related information backups to be stored in a separate facility. Typical: system software, configuration baselines, and security-related information such as cryptographic key backups] in a separate facility, or in a fire-rated container not collocated with the operational system. (CP-9(3))

#### Transfer to alternate storage site (CP-9(5))

- The [System owner] shall transfer system backup information to the alternate storage site [Fill in: time period consistent with recovery time and recovery point objectives. Typical: daily], at [Fill in: transfer rate consistent with recovery time and recovery point objectives. Typical: a rate that keeps the alternate copy within the recovery point objective]. (CP-9(5))

#### Cryptographic protection (CP-9(8))

> **Guidance:** Encrypt backups with the cryptography the organization approves under SC-13, and keep the keys where a loss of the primary site does not take them too.

- The [System owner] shall implement cryptographic mechanisms to prevent unauthorized disclosure and modification of [Fill in: backup information to protect against unauthorized disclosure and modification. Typical: all backup information]. (CP-9(8))

##### Federal systems

Federal systems use cryptographic modules validated by the NIST Cryptographic Module Validation Program, as SC-13 requires. The CMVP's [FIPS 140-3 transition page](https://csrc.nist.gov/projects/fips-140-3-transition-effort) sets the schedule for moving FIPS 140-2 validations to the Historical List in September 2026, and says that modules on the Historical List remain supported for existing systems (as of September 2026).

- The [System owner] shall encrypt backup information with CMVP-validated cryptographic modules. (CP-9(8))

#### System recovery and reconstitution (CP-10)

> **Guidance:** Recovery brings the system back into operation; reconstitution returns it to its fully operational, secure state, with its controls working and checked. After a compromise, recover from backups known to be clean.

- The [System owner] shall provide for the recovery of the system to a known state within [Fill in: time period consistent with recovery time and recovery point objectives for the recovery of the system. Typical: the recovery time objective set in the contingency plan from the business impact analysis] after a disruption, compromise or failure. (CP-10)
- The [System owner] shall provide for the reconstitution of the system to a known state within [Fill in: time period consistent with recovery time and recovery point objectives for the reconstitution of the system. Typical: the reconstitution time set in the contingency plan] after a disruption, compromise or failure. (CP-10)

#### Transaction recovery (CP-10(2))

- The [System owner] shall implement transaction recovery for a transaction-based system. (CP-10(2))

#### Restore within time period (CP-10(4))

- The [System owner] shall provide the capability to restore system components within [Fill in: restoration time period within which to restore system components to a known, operational state. Typical: the recovery time objective set for each component in the contingency plan] from configuration-controlled and integrity-protected information representing a known, operational state for the components. (CP-10(4))

### Identification and Authentication (IA)

#### Identification and authentication (organizational users) (IA-2)

> **Guidance:** The [identification and authentication standard](https://kston83.github.io/nist-guide/templates/standards/identification-and-authentication-standard/) makes the IA-2 statements measurable: the assurance level for each group of users, the approved authenticators, which are required for privileged and non-privileged access, and a part where each system records how its users authenticate.

- The [System owner] shall ensure the system uniquely identifies and authenticates organizational users. (IA-2)
- The [System owner] shall ensure the system associates that unique identification with processes acting on behalf of those users. (IA-2)

#### Multi-factor authentication to privileged accounts (IA-2(1))

- The [System owner] shall implement multi-factor authentication for access to privileged accounts. (IA-2(1))

#### Multi-factor authentication to non-privileged accounts (IA-2(2))

- The [System owner] shall implement multi-factor authentication for access to non-privileged accounts. (IA-2(2))

#### Individual authentication with group authentication (IA-2(5))

- Where shared accounts or authenticators are used, the [System owner] shall require users to authenticate individually before granting access to the shared account or resource. (IA-2(5))

#### Access to accounts: replay resistant (IA-2(8))

- The [System owner] shall implement replay-resistant authentication mechanisms for access to [Select one or more: privileged accounts; non-privileged accounts. Typical: privileged accounts and non-privileged accounts]. (IA-2(8))

#### Acceptance of PIV credentials (IA-2(12))

> **Guidance:** Personal Identity Verification (PIV) is the U.S. federal smart card credential. An organization outside the federal government meets this enhancement where it relies on PIV or PIV-interoperable credentials; if it uses none, record the enhancement as not applicable in the system security plan with that reason.

- Where the organization issues or relies on Personal Identity Verification (PIV)-compliant credentials, the [System owner] shall ensure the system accepts and electronically verifies them. (IA-2(12))

##### Federal systems

Federal employees and contractors are issued PIV credentials under Homeland Security Presidential Directive 12 (HSPD-12) and [FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final), Personal Identity Verification (PIV) of Federal Employees and Contractors (January 2022).

- The [System owner] shall ensure the system accepts and electronically verifies PIV credentials for organizational users. (IA-2(12))

#### Device identification and authentication (IA-3)

- The [System owner] shall ensure the system uniquely identifies and authenticates [Fill in: devices and/or types of devices to be uniquely identified and authenticated before establishing a connection. Typical: all organization-managed endpoints, servers and network devices] before establishing a [Select one or more: local; remote; network. Typical: remote and network] connection. (IA-3)

#### Identifier management (IA-4)

- The [Account manager] shall assign an individual, group, role, service or device identifier only with authorization from [Fill in: personnel or roles from whom authorization must be received to assign an identifier. Typical: the system owner, through the approved access request]. (IA-4a)
- The [Account manager] shall select an identifier that identifies the individual, group, role, service or device. (IA-4b)
- The [Account manager] shall assign the identifier to the intended individual, group, role, service or device. (IA-4c)
- The [Account manager] shall prevent reuse of identifiers for [Fill in: a time period for preventing reuse of identifiers. Typical: at least two years]. (IA-4d)

#### Identify user status (IA-4(4))

- The [Account manager] shall manage individual identifiers so that each individual is uniquely identified as [Fill in: characteristics used to identify individual status. Typical: employee, contractor, or foreign national]. (IA-4(4))

#### Authenticator management (IA-5)

> **Guidance:** For passwords, [NIST SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final) (July 2025) says verifiers shall not require periodic changes, and shall force a change when there is evidence of compromise. Set the change periods below by authenticator type, and keep scheduled changes for secrets such as shared or service account keys. The [identification and authentication standard](https://kston83.github.io/nist-guide/templates/standards/identification-and-authentication-standard/) carries the procedures these statements call for: identity checks before issue and reset, binding, recovery, loss and revocation.

- The [Account manager] shall verify the identity of the individual, group, role, service or device receiving an authenticator as part of its initial distribution. (IA-5a)
- The [Account manager] shall establish the initial content of any authenticator the organization issues. (IA-5b)
- The [Chief Information Security Officer] shall ensure authenticators have sufficient strength of mechanism for their intended use. (IA-5c)
- The [Chief Information Security Officer] shall establish administrative procedures for initial authenticator distribution, for lost, compromised or damaged authenticators, and for revoking authenticators. (IA-5d)
- The [Account manager] shall implement those procedures. (IA-5d)
- The [System owner] shall ensure default authenticators are changed before first use. (IA-5e)
- The [Account manager] shall change or refresh authenticators as follows: [Fill in: a time period for changing or refreshing authenticators by authenticator type. Typical: no scheduled change for user passwords; certificates at expiry; shared and service account secrets at least annually]. (IA-5f)
- The [Account manager] shall change or refresh authenticators when [Fill in: events that trigger the change or refreshment of authenticators. Typical: evidence or suspicion of compromise, and departure of a person who knew a shared authenticator] occur. (IA-5f)
- The [System owner] shall protect authenticator content from unauthorized disclosure and modification. (IA-5g)
- Users shall protect their authenticators as the rules of behavior require. (IA-5h)
- The [System owner] shall ensure devices implement the controls that protect authenticators. (IA-5h)
- The [Account manager] shall change the authenticators of group or role accounts when membership of those accounts changes. (IA-5i)

#### Password-based authentication (IA-5(1))

> **Guidance:** The typical values follow [NIST SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final) (July 2025): a minimum of 15 characters for a password used alone and 8 when it is one factor of several, no other composition rules, at least 64 characters allowed, and a check against a list of common and breached passwords. Section 7 of the [identification and authentication standard](https://kston83.github.io/nist-guide/templates/standards/identification-and-authentication-standard/) sets out the full password rules.

- The [System owner] shall maintain a list of commonly used, expected or compromised passwords, and update it [Fill in: the frequency at which to update the list of commonly used, expected, or compromised passwords. Typical: at least monthly, and whenever a relevant breach corpus is published] and when organizational passwords are suspected to have been compromised. (IA-5(1)(a))
- The [System owner] shall ensure the system verifies, when users create or update passwords, that the passwords are not on that list. (IA-5(1)(b))
- The [System owner] shall ensure passwords are transmitted only over cryptographically protected channels. (IA-5(1)(c))
- The [System owner] shall ensure passwords are stored using an approved salted key derivation function, preferably using a keyed hash. (IA-5(1)(d))
- The [System owner] shall ensure the system requires immediate selection of a new password upon account recovery. (IA-5(1)(e))
- The [System owner] shall ensure the system allows long passwords and passphrases, including spaces and all printable characters. (IA-5(1)(f))
- The [System owner] shall employ automated tools to help users select strong passwords. (IA-5(1)(g))
- The [System owner] shall ensure the system enforces these composition and complexity rules: [Fill in: authenticator composition and complexity rules. Typical: a minimum length of 15 characters for passwords used as the only factor and 8 for passwords used with another factor, and no other composition rules]. (IA-5(1)(h))

#### Public key-based authentication (IA-5(2))

- For public key-based authentication, the [System owner] shall ensure the system enforces authorized access to the corresponding private key. (IA-5(2)(a)(1))
- For public key-based authentication, the [System owner] shall ensure the system maps the authenticated identity to the account of the individual or group. (IA-5(2)(a)(2))
- When public key infrastructure is used, the [System owner] shall ensure the system validates certificates by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status. (IA-5(2)(b)(1))
- When public key infrastructure is used, the [System owner] shall ensure the system keeps a local cache of revocation data to support path discovery and validation. (IA-5(2)(b)(2))

#### Protection of authenticators (IA-5(6))

- The [System owner] shall protect authenticators commensurate with the security category of the information that their use gives access to. (IA-5(6))

#### Authentication feedback (IA-6)

- The [System owner] shall ensure the system obscures feedback of authentication information during authentication, so it cannot be exploited by unauthorized individuals. (IA-6)

#### Cryptographic module authentication (IA-7)

- The [System owner] shall implement mechanisms for authentication to a cryptographic module that meet the laws, executive orders, directives, policies, regulations, standards and guidelines that apply to such authentication. (IA-7)

#### Identification and authentication (non-organizational users) (IA-8)

- The [System owner] shall ensure the system uniquely identifies and authenticates non-organizational users and processes acting on their behalf. (IA-8)

#### Acceptance of PIV credentials from other agencies (IA-8(1))

> **Guidance:** This enhancement applies where federal employees or contractors from other agencies use the system. Outside that case, record it as not applicable in the system security plan with that reason.

- Where users from federal agencies access the system, the [System owner] shall ensure it accepts and electronically verifies their Personal Identity Verification (PIV)-compliant credentials. (IA-8(1))

#### Acceptance of external authenticators (IA-8(2))

- The [System owner] shall ensure the system accepts only external authenticators that are NIST-compliant, such as those meeting [NIST SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final) (July 2025). (IA-8(2)(a))
- The [System owner] shall document and maintain a list of accepted external authenticators. (IA-8(2)(b))

#### Use of defined profiles (IA-8(4))

- The [System owner] shall ensure the system conforms to [Fill in: identity management profiles. Typical: the federation profiles the organization publishes for its identity provider, such as SAML 2.0 or OpenID Connect] for identity management. (IA-8(4))

#### Re-authentication (IA-11)

- The [System owner] shall ensure the system requires users to re-authenticate when [Fill in: circumstances or situations requiring re-authentication. Typical: a session timeout, a change of role or privilege, a privileged action, or a change of authenticators]. (IA-11)

#### Identity proofing (IA-12)

- The [Account manager] shall identity proof users who require accounts for logical access, at the identity assurance level the applicable standards require, such as the NIST SP 800-63-4 digital identity guidelines. (IA-12a)
- The [Account manager] shall resolve each user identity to a unique individual. (IA-12b)
- The [Account manager] shall collect, validate and verify identity evidence. (IA-12c)

#### Identity evidence (IA-12(2))

- The [Account manager] shall require evidence of individual identification to be presented to the registration authority. (IA-12(2))

#### Identity evidence validation and verification (IA-12(3))

- The [Account manager] shall require presented identity evidence to be validated and verified through [Fill in: methods of validation and verification of identity evidence. Typical: checking the evidence against its issuing or an authoritative source, and confirming the applicant is the person it describes]. (IA-12(3))

#### In-person validation and verification (IA-12(4))

- The [Account manager] shall require validation and verification of identity evidence to be conducted in person before a designated registration authority. (IA-12(4))

#### Address confirmation (IA-12(5))

- The [Account manager] shall require a [Select one: registration code; notice of proofing. Typical: registration code] to be delivered through an out-of-band channel to verify the user's address of record, physical or digital. (IA-12(5))

### Incident Response (IR)

#### Incident response training (IR-2)

- The [Incident response team] shall provide incident response training, consistent with assigned roles and responsibilities, to system users within [Fill in: a time period within which incident response training is to be provided to system users assuming an incident response role or responsibility. Typical: 30 days] of their assuming an incident response role or responsibility or acquiring system access. (IR-2a.1)
- The [Incident response team] shall provide that training when system changes require it. (IR-2a.2)
- The [Incident response team] shall provide that training [Fill in: frequency at which to provide incident response training to users. Typical: annually] thereafter. (IR-2a.3)
- The [Incident response team] shall review and update incident response training content [Fill in: frequency at which to review and update incident response training content. Typical: annually] and following [Fill in: events that initiate a review of the incident response training content. Typical: a change to the incident response plan, and lessons learned from an incident or exercise]. (IR-2b)

#### Simulated events (IR-2(1))

- The [Incident response team] shall incorporate simulated events into incident response training so personnel practice the required response to crisis situations. (IR-2(1))

#### Automated training environments (IR-2(2))

- The [Incident response team] shall provide an incident response training environment using [Fill in: automated mechanisms used in an incident response training environment. Typical: a cyber range or isolated lab that replays realistic attack activity]. (IR-2(2))

#### Incident response testing (IR-3)

- The [Incident response team] shall test the effectiveness of the incident response capability for the system [Fill in: frequency at which to test the effectiveness of the incident response capability for the system. Typical: annually] using [Fill in: tests used to test the effectiveness of the incident response capability for the system. Typical: a tabletop exercise based on a realistic scenario, and a functional test of notification and escalation]. (IR-3)

#### Coordination with related plans (IR-3(2))

- The [Incident response team] shall coordinate incident response testing with the organizational elements responsible for related plans, such as contingency, continuity and crisis communications plans. (IR-3(2))

#### Incident handling (IR-4)

> **Guidance:** IR-4a names the phases of the incident handling life cycle from NIST SP 800-61 Rev. 2. Its successor, [SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) (April 2025), organizes incident response around the CSF 2.0 Functions instead; the Incident Response Plan template follows Rev. 3 and still covers every IR-4a phase. Assessors ask for records of recent incidents that show each phase, and for evidence that a lesson learned changed a procedure.

- The [Incident response team] shall implement an incident handling capability, consistent with the incident response plan, that includes preparation, detection and analysis, containment, eradication and recovery. (IR-4a)
- The [Incident response team] shall coordinate incident handling activities with contingency planning activities. (IR-4b)
- The [Incident response team] shall incorporate lessons learned from incident handling into incident response procedures, training and testing, and implement the resulting changes. (IR-4c)
- The [Chief Information Security Officer] shall ensure the rigor, intensity, scope and results of incident handling are comparable and predictable across the organization. (IR-4d)

#### Automated incident handling processes (IR-4(1))

- The [Incident response team] shall support the incident handling process using [Fill in: automated mechanisms used to support the incident handling process. Typical: the case management system and automated playbooks in the security operations platform]. (IR-4(1))

#### Information correlation (IR-4(4))

- The [Incident response team] shall correlate incident information and individual incident responses to achieve an organization-wide perspective on incident awareness and response. (IR-4(4))

#### Integrated incident response team (IR-4(11))

- The [Chief Information Security Officer] shall establish and maintain an integrated incident response team that can be deployed to any location the organization identifies within [Fill in: the time period within which an integrated incident response team can be deployed. Typical: 24 hours]. (IR-4(11))

#### Incident monitoring (IR-5)

- The [Incident response team] shall track and document incidents. (IR-5)

#### Automated tracking, data collection and analysis (IR-5(1))

- The [Incident response team] shall track incidents and collect and analyze incident information using [Fill in: automated mechanisms. Typical: the incident case management system integrated with the security operations platform]. (IR-5(1))

#### Incident reporting (IR-6)

- All personnel shall report suspected incidents to the [Incident response team] within [Fill in: time period for personnel to report suspected incidents to the organizational incident response capability. Typical: 1 hour of discovery]. (IR-6a)
- The [Incident response team] shall report incident information to [Fill in: authorities to whom incident information is to be reported. Typical: senior leadership, legal counsel, and any regulator, customer or partner that law or contract requires be notified]. (IR-6b)

##### Federal systems

Federal agencies notify the Cybersecurity and Infrastructure Security Agency (CISA) of incidents under FISMA (44 U.S.C. §§ 3553 and 3554). As of September 2026, the [CISA Federal Incident Notification Guidelines](https://www.cisa.gov/federal-incident-notification-guidelines) (effective April 1, 2017) set the time frame: within one hour of the incident being identified by the agency's top-level incident response team, security operations center or IT department.

- The [Incident response team] shall report incidents to CISA within one hour of identification, as the CISA Federal Incident Notification Guidelines require. (IR-6b)

#### Automated reporting (IR-6(1))

- The [Incident response team] shall report incidents using [Fill in: automated mechanisms used for reporting incidents. Typical: the incident report form and case management system, which notify the incident response team automatically]. (IR-6(1))

#### Supply chain coordination (IR-6(3))

- The [Incident response team] shall provide incident information to the provider of the product or service, and to other organizations in the supply chain, for system components related to an incident. (IR-6(3))

#### Incident response assistance (IR-7)

- The [Incident response team] shall provide an incident response support resource, as part of the incident response capability, that offers system users advice and assistance with handling and reporting incidents. (IR-7)

#### Automation support for availability of information and support (IR-7(1))

- The [Incident response team] shall increase the availability of incident response information and support using [Fill in: automated mechanisms used to increase the availability of incident response information and support. Typical: a self-service reporting portal and an incident response page on the intranet]. (IR-7(1))

#### Incident response plan (IR-8)

- The [Chief Information Security Officer] shall develop an incident response plan that provides a roadmap for implementing the incident response capability. (IR-8a.1)
- The plan shall describe the structure and organization of the incident response capability. (IR-8a.2)
- The plan shall describe at a high level how the incident response capability fits into the overall organization. (IR-8a.3)
- The plan shall meet the organization's unique requirements related to its mission, size, structure and functions. (IR-8a.4)
- The plan shall define reportable incidents. (IR-8a.5)
- The plan shall provide metrics for measuring the incident response capability. (IR-8a.6)
- The plan shall define the resources and management support needed to maintain and mature the incident response capability. (IR-8a.7)
- The plan shall address the sharing of incident information. (IR-8a.8)
- The plan shall be reviewed and approved by [Fill in: personnel or roles that review and approve the incident response plan. Typical: the Chief Information Security Officer] [Fill in: the frequency at which to review and approve the incident response plan. Typical: annually]. (IR-8a.9)
- The plan shall explicitly designate responsibility for incident response to [Fill in: entities, personnel, or roles with designated responsibility for incident response. Typical: the incident response team, led by its designated lead]. (IR-8a.10)
- The [Chief Information Security Officer] shall distribute copies of the plan to [Fill in: incident response personnel (identified by name and/or by role) to whom copies of the incident response plan are to be distributed. Typical: the incident response team members, by role] and [Fill in: organizational elements to which copies of the incident response plan are to be distributed. Typical: the security operations, legal, communications and human resources functions]. (IR-8b)
- The [Chief Information Security Officer] shall update the plan to address system and organizational changes, and problems found during its implementation, execution or testing. (IR-8c)
- The [Chief Information Security Officer] shall communicate changes to the plan to [Fill in: incident response personnel (identified by name and/or by role) and organizational elements. Typical: everyone who received the plan]. (IR-8d)
- The [Chief Information Security Officer] shall protect the plan from unauthorized disclosure and modification. (IR-8e)

### Maintenance (MA)

#### Controlled maintenance (MA-2)

> **Guidance:** MA-2 covers every kind of maintenance, repair and replacement, on site or remote, including printers, scanners and copiers, which NIST's MA-2 discussion names. The information recorded for each activity is the list NIST's discussion gives, plus the approval and the control check that MA-2b and MA-2e ask for. The [maintenance log](https://kston83.github.io/nist-guide/templates/forms/maintenance-log/) holds these records. Sanitize media before they leave for repair as the media sanitization procedure sets out (MP-6), following NIST SP 800-88 Rev. 2, [Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final) (September 2025, final; as of September 2026), and record it in the [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/). Assessors sample maintenance records against the schedule and ask for the removal approvals and sanitization records.

- The [System owner] shall schedule maintenance, repair and replacement of system components in accordance with manufacturer or vendor specifications and organizational requirements. (MA-2a)
- The [System owner] shall document each maintenance, repair and replacement activity in the system's maintenance records. (MA-2a)
- The [System owner] shall review the maintenance records at least quarterly against the maintenance schedule and the system's change records. (MA-2a)
- The [System owner] shall approve each maintenance activity before it starts, whether it is performed on site or remotely and whether components are serviced on site or removed to another location. (MA-2b)
- The [System owner] shall ensure each maintenance activity is monitored while it is performed, by an escort or by review of the session and its records. (MA-2b)
- Maintenance that changes the system's configuration shall also follow the change control process (CM-3). (MA-2b)
- The [System owner] shall require [Fill in: personnel or roles required to explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance or repairs. Typical: the system owner] to explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance, repair or replacement. (MA-2c)
- The [System owner] shall ensure equipment is sanitized to remove [Fill in: information to be removed from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement. Typical: all organizational information, including personally identifiable information, credentials and cryptographic keys] from associated media before it is removed from organizational facilities for off-site maintenance, repair or replacement. (MA-2d)
- Where storage media cannot be sanitized, such as a failed drive, the [System owner] shall keep the media within the organization and sanitize or destroy them there, rather than release them. (MA-2d)
- After each maintenance, repair or replacement action, the [System owner] shall check all potentially impacted controls to verify that they are still functioning properly. (MA-2e)
- The [System owner] shall include [Fill in: information to be included in organizational maintenance records. Typical: the date and time, the system and component, a description of the maintenance performed, the names and organization of the individuals performing it, the escort's name, the components or equipment removed or replaced, the approval, and the result of the post-maintenance control check] in the organization's maintenance records. (MA-2f)

> **Guidance:** Replacement components bring supply chain risk, which NIST's MA-2 discussion asks organizations to consider: obtain them from the original manufacturer or its authorized channel, or from a source the supply chain risk management plan allows. The post-maintenance check can use the change's security impact analysis (CM-4) to decide which controls to verify.

#### Automated maintenance activities (MA-2(2))

> **Guidance:** MA-2(2) is in the High baseline. An IT service management or maintenance management system that schedules work orders, and management tools that carry out and report the work, give the timely, accurate and complete records NIST's discussion describes. Records of requested and scheduled work, not only completed work, are what distinguish this enhancement from MA-2.

- The [System owner] shall schedule maintenance, repair and replacement actions for the system using [Fill in: automated mechanisms used to schedule maintenance, repair, and replacement actions for the system. Typical: the organization's IT service management system]. (MA-2(2)(a))
- The [System owner] shall conduct maintenance, repair and replacement actions for the system using [Fill in: automated mechanisms used to conduct maintenance, repair, and replacement actions for the system. Typical: the endpoint and configuration management tools that deploy updates, firmware and configuration changes], where the action can be automated. (MA-2(2)(a))
- The [System owner] shall document maintenance, repair and replacement actions for the system using [Fill in: automated mechanisms used to document maintenance, repair, and replacement actions for the system. Typical: the organization's IT service management system, fed by the endpoint and configuration management tools]. (MA-2(2)(a))
- The [System owner] shall ensure those mechanisms produce up-to-date, accurate and complete records of all maintenance, repair and replacement actions requested, scheduled, in process and completed. (MA-2(2)(b))

#### Maintenance tools (MA-3)

> **Guidance:** Maintenance tools are the diagnostic and repair tools that are not part of the system: diagnostic test equipment, packet sniffers, vendor utilities brought in on media or downloaded, and cloud-based diagnostic services. NIST's MA-3 discussion notes they can carry malicious code into a facility and a system, and excludes utilities built into the system, such as ping or a switch's monitoring port. Keep the approved tools list in the [maintenance log](https://kston83.github.io/nist-guide/templates/forms/maintenance-log/). The periodic review withdraws approval for tools that are outdated, unsupported or no longer used, as NIST's discussion describes.

- The [System owner] shall approve each maintenance tool before it is used on the system, and record it on the system's approved maintenance tools list. (MA-3a)
- The [System owner] shall control the use of maintenance tools, so that only approved tools are used, only by authorized maintenance personnel. (MA-3a)
- The [System owner] shall monitor the use of maintenance tools, through escort or session supervision and the audit records of privileged tool use (AU-2). (MA-3a)
- The [System owner] shall review previously approved system maintenance tools [Fill in: frequency at which to review previously approved system maintenance tools. Typical: at least annually], and withdraw approval for tools that are outdated, unsupported, no longer needed or no longer used. (MA-3b)

#### Inspect tools (MA-3(1))

> **Guidance:** Inspection means checking that a tool is the approved one, in the approved version, with no sign of tampering: for hardware, its seals, serial number and condition; for software, a hash or signature check against the vendor's published value. NIST's discussion of this enhancement has an improperly modified tool, or one containing malicious code, handled as an incident.

- The [System owner] shall ensure the maintenance tools that maintenance personnel bring into the facility or download are inspected for improper or unauthorized modifications before each use on the system. (MA-3(1))
- Personnel shall report a tool found to be modified improperly, or to contain malicious code, as a security incident under the incident response plan (IR-6). (MA-3(1))

#### Inspect media (MA-3(2))

> **Guidance:** Scan the media on a workstation that is not connected to the system, with the organization's malicious code protection (SI-3), and record the scan in the maintenance log. NIST's discussion of this enhancement has malicious code found on the media handled as an incident.

- The [System owner] shall ensure media containing diagnostic and test programs are checked for malicious code before the media are used in the system. (MA-3(2))
- Personnel shall report malicious code found on such media as a security incident under the incident response plan (IR-6), and the media shall not be used. (MA-3(2))

#### Prevent unauthorized removal (MA-3(3))

> **Guidance:** MA-3(3) covers maintenance equipment, such as a vendor's diagnostic laptop or analyzer, that may have picked up organizational information during the work. Organizational information includes information the organization holds as a steward for others, as NIST's discussion of this enhancement says. The four measures are alternatives; the maintenance log records which one was used. Sanitize as the media sanitization procedure sets out (MP-6), and record it in the [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/).

- The [System owner] shall prevent the removal of maintenance equipment containing organizational information from the facility by verifying that there is no organizational information on the equipment, sanitizing or destroying the equipment, retaining the equipment within the facility, or obtaining a written exemption from [Fill in: personnel or roles who can authorize removal of equipment from the facility. Typical: the Chief Information Security Officer] explicitly authorizing its removal. (MA-3(3))
- The [System owner] shall record in the maintenance records which of these four measures was used for each piece of maintenance equipment. (MA-3(3))
- Maintenance contracts shall allow the organization to keep, sanitize or destroy maintenance equipment or its storage media that contain organizational information. (MA-3(3))

##### Federal systems

Under [32 CFR 2002.14(f)(2)](https://www.ecfr.gov/current/title-32/section-2002.14), agencies that destroy controlled unclassified information (CUI), including in electronic form, must make it unreadable, indecipherable and irrecoverable. They must use any destruction method specifically required by law, regulation or Government-wide policy for that CUI; otherwise they must use the destruction guidance in NIST SP 800-53 and SP 800-88, or a method approved for classified national security information under 32 CFR 2001.47. As of September 2026.

- Where maintenance equipment containing CUI is destroyed to prevent its removal, the [System owner] shall destroy it by a method that 32 CFR 2002.14(f)(2) permits. (MA-3(3)(b))

#### Nonlocal maintenance (MA-4)

> **Guidance:** Nonlocal maintenance is maintenance or diagnosis by someone who connects over a network, internal or external, rather than being physically present. It is remote access, so the AC-17 requirements apply as well: a managed access control point (AC-17(3)), encryption (AC-17(2)) and remote privileged commands only as AC-17(4) allows. NIST's MA-4 discussion ties strong authentication to IA-2: replay-resistant, multi-factor authenticators, such as a PKI certificate on a token protected by a PIN. The common finding is a vendor's always-on remote support tool or account that nobody approved; enabling a maintenance account only for each approved session and disabling it afterward closes that gap. The [maintenance log](https://kston83.github.io/nist-guide/templates/forms/maintenance-log/) records each session.

- The [System owner] shall approve each nonlocal maintenance and diagnostic session before it starts. (MA-4a)
- The [System owner] shall ensure each nonlocal maintenance and diagnostic session is monitored while it is in progress, through session supervision or live review of its audit records. (MA-4a)
- The [System owner] shall allow the use of nonlocal maintenance and diagnostic tools only as this policy permits and as documented in the system security plan, which shall name each tool and the connection it uses. (MA-4b)
- Nonlocal maintenance connections shall pass through the organization's managed remote access service, and not through a tool or connection that the maintenance provider controls on its own. (MA-4b)
- The [System owner] shall ensure nonlocal maintenance and diagnostic sessions are established with strong authentication: multi-factor authentication with a replay-resistant authenticator, as required for network access to the system's accounts (IA-2(1), IA-2(2), IA-2(8)). (MA-4c)
- The [Account manager] shall keep each account used by an external maintenance provider disabled except during an approved session. (MA-4c)
- The [System owner] shall maintain records of each nonlocal maintenance and diagnostic session, including who performed it, when it started and ended, what was done and who approved it. (MA-4d)
- The person performing nonlocal maintenance shall terminate the session and network connections when the maintenance is completed, and the [System owner] shall ensure the system also ends them when the approved session ends. (MA-4e)

##### Federal systems

[OMB M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf), Moving the U.S. Government Toward Zero Trust Cybersecurity Principles (January 26, 2022), requires phishing-resistant multi-factor authentication for agency staff, contractors and partners, enforced at the application layer. [OMB M-19-17](https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf) (May 21, 2019), Section III, item 2, requires Personal Identity Verification (PIV) credentials, where applicable in accordance with OPM requirements, as the primary means of identification and authentication to Federal information systems by Federal employees and contractors. [OMB M-26-18](https://www.whitehouse.gov/wp-content/uploads/2026/08/M-26-18-Scaling-Use-of-Login.gov-to-Deliver-a-Universal-Sign-on-for-Public-Services.pdf) (August 31, 2026), footnote 5, lists both memoranda as existing OMB policy. CISA [Binding Operational Directive 23-02](https://www.cisa.gov/news-events/directives/binding-operational-directive-23-02), Mitigating the Risk from Internet-Exposed Management Interfaces (June 13, 2023), covers the networked management interfaces of routers, switches, firewalls, VPN concentrators, proxies, load balancers and out-of-band server management interfaces that are reachable from the public internet, but not the management portals and APIs of cloud service offerings. Within 14 days of discovering such an interface, or of notice from CISA, agencies must either make it reachable only from an internal enterprise network or put access to it behind a zero trust policy enforcement point separate from the interface. As of September 2026.

- The [System owner] shall require phishing-resistant multi-factor authentication for nonlocal maintenance sessions by agency staff, contractors and partners, as OMB M-22-09 requires, using a PIV or derived PIV credential where the person holds one, as OMB M-19-17 requires. (MA-4c)
- For each device within the scope of BOD 23-02, the [System owner] shall ensure its management interface is reachable only from an internal enterprise network, or only through a policy enforcement point separate from the interface, and shall correct any exposed interface within 14 days of its discovery or of notice from CISA. (MA-4b)

#### Comparable security and sanitization (MA-4(3))

> **Guidance:** MA-4(3) is in the High baseline. Comparable security means the controls on the system, tools and equipment used for the maintenance are at least as comprehensive as those on the system being serviced, as NIST's discussion of this enhancement puts it. For an external provider, get that assurance in the maintenance contract and check it the way the external service review checks any provider (SA-9). Where no provider can show it, use the second option: take the component out, sanitize it, and inspect and sanitize it again before it goes back.

- The [System owner] shall require that nonlocal maintenance and diagnostic services be performed from a system that implements a security capability comparable to the capability implemented on the system being serviced. (MA-4(3)(a))
- The [System owner] shall record, for each provider of nonlocal maintenance, the basis for concluding that its capability is comparable, such as its authorization or an independent attestation. (MA-4(3)(a))
- Where comparable capability cannot be shown, the [System owner] shall remove the component to be serviced from the system and sanitize it of organizational information before the nonlocal service, and inspect it and sanitize it of potentially malicious software after the service and before reconnecting it to the system. (MA-4(3)(b))

#### Maintenance personnel (MA-5)

> **Guidance:** MA-5 covers the people who maintain the system's hardware and software; physical access to the facility for them is PE-2, recorded in the [physical access list](https://kston83.github.io/nist-guide/templates/forms/physical-access-list/) or, for visitors, the [visitor log](https://kston83.github.io/nist-guide/templates/forms/visitor-log/). Unescorted maintenance personnel need the same access authorizations as anyone with that access: screening (PS-3), a signed access agreement (PS-6) and, for a contractor, the external personnel requirements of the [Personnel Security Policy](https://kston83.github.io/nist-guide/templates/policies/ps/) (PS-7). NIST's MA-5 discussion allows temporary credentials, for one use or a very limited time, for vendors who must work with little notice. The [maintenance log](https://kston83.github.io/nist-guide/templates/forms/maintenance-log/) holds the authorized list and records each escort.

- The [System owner] shall establish a process for authorizing maintenance personnel, in which the system owner approves each maintenance organization and each individual before they perform maintenance. (MA-5a)
- The [System owner] shall maintain a list of authorized maintenance organizations and personnel for the system, and review it at least quarterly. (MA-5a)
- Maintenance contracts shall require the provider to notify the organization within 24 hours when a person on the authorized list leaves the provider or no longer supports the organization, as for other external personnel (PS-7). (MA-5a)
- The [System owner] shall verify that non-escorted personnel performing maintenance on the system possess the required access authorizations before the work starts. (MA-5b)
- The [System owner] shall designate organizational personnel with the required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations. (MA-5c)
- The designated supervisor shall remain with the maintenance personnel, or supervise the session, for the whole activity, and shall be recorded as the escort in the maintenance records. (MA-5c)
- Where maintenance personnel not on the authorized list need access with little notice, the [Account manager] shall issue temporary credentials valid for one use or for the approved maintenance period only, and disable them when it ends. (MA-5)

#### Individuals without appropriate access (MA-5(1))

> **Guidance:** MA-5(1) is in the High baseline. NIST's discussion of this enhancement says these procedures are meant to deny visual and electronic access to classified or controlled unclassified information on the system, and that they can be documented in the system security plan. Outside government, apply them to maintenance personnel who lack the screening, citizenship or other access approvals the system's information requires, such as export-controlled information. Systems that process classified information add MA-5(2) to MA-5(4), which are in no baseline.

- The [System owner] shall implement procedures, documented in the system security plan, for the use of maintenance personnel who lack the security clearances, citizenship or formal access approvals the system's information requires. (MA-5(1)(a))
- Those maintenance personnel shall be escorted and supervised during the performance of maintenance and diagnostic activities on the system by approved organizational personnel who hold the required clearances and access authorizations and are technically qualified. (MA-5(1)(a)(1))
- Before such personnel begin maintenance or diagnostic activities, the [System owner] shall ensure all volatile information storage components within the system are sanitized, and all nonvolatile storage media are removed or physically disconnected from the system and secured. (MA-5(1)(a)(2))
- Where a system component cannot be sanitized, removed or disconnected from the system, the [System owner] shall develop and implement [Fill in: alternate controls to be developed and implemented in the event that a system component cannot be sanitized, removed, or disconnected from the system. Typical: continuous supervision by an escort who has the required access authorizations, is technically qualified and can end the activity at any time; screens, ports and data on the component kept out of the maintenance person's view and reach; and review of the audit records of the activity afterward]. (MA-5(1)(b))

#### Timely maintenance (MA-6)

> **Guidance:** MA-6 makes sure a failed component can be fixed in time. NIST's MA-6 discussion has the organization pick the components whose failure raises risk, and names having contracts in place as one way to obtain support. Take the components and time from the [business impact analysis](https://kston83.github.io/nist-guide/templates/reports/business-impact-analysis/) and the [contingency plan](https://kston83.github.io/nist-guide/templates/plans/contingency-plan/), so the maintenance support and the recovery time objective agree (CP-2, CP-10). For cloud services, the provider's service level agreement covers its components; record that in the [external service review](https://kston83.github.io/nist-guide/templates/forms/external-service-review/).

- The [System owner] shall obtain maintenance support or spare parts for [Fill in: system components for which maintenance support and/or spare parts are obtained. Typical: the components that support essential mission and business functions, as the business impact analysis identifies them, and the security components that protect them] within [Fill in: time period within which maintenance support and/or spare parts are to be obtained after a failure. Typical: the recovery time objective set in the contingency plan from the business impact analysis] of failure. (MA-6)
- The [System owner] shall keep maintenance contracts, with response and repair times that meet that time, or spare parts on hand, for each of those components, and record the contracts in the contingency plan's vendor contact list. (MA-6)
- The [System owner] shall review the maintenance contracts and spare parts each time the contingency plan is reviewed, and before a contract expires. (MA-6)

### Media Protection (MP)

#### Media access (MP-2)

> **Guidance:** MP-2 restricts who may access media; MP-7 restricts which media may be used on systems, a distinction NIST's MP-7 discussion draws. NIST's MP-2 discussion covers digital media (flash drives, tapes, external drives, optical discs) and non-digital media (paper and microfilm). The usual way to restrict access is to keep media where only authorized people can reach them (MP-4) and to encrypt digital media so that only holders of the key can read them, as the [encryption and key management standard](https://kston83.github.io/nist-guide/templates/standards/encryption-and-key-management-standard/) requires for removable media (SC-28(1)). Assessors ask who can get into the media library or cabinets, and compare that list with the people authorized for the information.

- The [System owner] shall restrict access to [Fill in: types of digital media to which access is restricted. Typical: removable and portable storage media (flash drives, external drives, memory cards and optical discs), backup media, and storage removed from service] to [Fill in: personnel or roles authorized to access digital media. Typical: personnel whose access authorizations for the system permit access to the information on the media]. (MP-2)
- The [System owner] shall restrict access to [Fill in: types of non-digital media to which access is restricted. Typical: paper and microfilm containing information not approved for public release, including printed system output] to [Fill in: personnel or roles authorized to access non-digital media. Typical: personnel whose access authorizations permit access to the information on the media]. (MP-2)
- The [System owner] shall enforce these restrictions by storing the media in controlled areas (MP-4) and, for digital media, by encryption whose keys only authorized personnel can use (SC-28(1)). (MP-2)
- The [System owner] shall review the list of people with access to each media library or storage area at least annually, and remove those who no longer need it. (MP-2)

#### Media marking (MP-3)

> **Guidance:** MP-3 is in the Moderate and High baselines. Marking means a human-readable label on the media or its container that shows how the information must be handled, as NIST's MP-3 discussion describes. NIST's discussion also says markings are generally not required for media holding only information approved for public release. The exemption in MP-3b suits media that never leave a controlled area and are handled by automated equipment, such as tapes in a tape library; once such media leave, they are marked.

- The [System owner] shall mark system media to indicate the distribution limitations, handling caveats and applicable security markings, if any, of the information they contain. (MP-3a)
- Markings shall use the handling labels defined in [Fill in: the organization's information classification or handling standard], together with any marking that a law, regulation or contract requires for the information. (MP-3a)
- Digital media shall carry the marking on the media themselves where they are large enough, and otherwise on their container. (MP-3a)
- The [System owner] shall exempt [Fill in: types of system media exempt from marking when remaining in controlled areas. Typical: backup media and drives held in automated tape libraries, storage arrays and server enclosures] from marking only while the media remain within [Fill in: controlled areas where media is exempt from marking. Typical: the data center and the media library, where physical access is limited to authorized personnel (PE-3)], and shall mark them before they leave. (MP-3b)

##### Federal systems

Under [32 CFR 2002.20(a)(1)](https://www.ecfr.gov/current/title-32/section-2002.20), agencies and authorized holders must uniformly and conspicuously apply CUI markings to all controlled unclassified information (CUI), in accordance with 32 CFR Part 2002 and the CUI Registry, unless that part or the CUI Executive Agent specifically permits otherwise. Under 2002.20(a)(7), a missing marking does not exempt an authorized holder from the handling requirements. Under 2002.20(a)(8), when marking CUI individually is impractical because of its quantity or nature, or under a limited marking waiver, authorized holders must make recipients aware of its CUI status by an alternate method that is readily apparent, such as signs in storage areas or on containers. As of October 2026.

- The [System owner] shall mark system media containing CUI with CUI markings in accordance with 32 CFR 2002.20 and the CUI Registry. (MP-3a)
- The [System owner] shall not apply the MP-3b exemption to media containing CUI unless their CUI status is shown by an alternate marking method that 32 CFR 2002.20(a)(8) permits, such as signs in the storage area or on the container. (MP-3b)

#### Media storage (MP-4)

> **Guidance:** MP-4 is in the Moderate and High baselines. NIST's MP-4 discussion describes physical control as inventories, check-out and return procedures, and accountability for stored media, and secure storage as a locked drawer, desk or cabinet or a controlled media library, matched to the security category of the information. MP-4b covers media until they are sanitized or destroyed, so failed drives and retired equipment waiting for sanitization stay in a controlled area and on the inventory. The [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/) closes each item out.

- The [System owner] shall physically control [Fill in: types of digital media to be physically controlled. Typical: removable and portable storage media, backup media, and storage removed from service and awaiting sanitization] and [Fill in: types of non-digital media to be physically controlled. Typical: paper and microfilm containing information not approved for public release]. (MP-4a)
- The [System owner] shall securely store [Fill in: types of digital media to be securely stored. Typical: removable and portable storage media, backup media, and storage removed from service and awaiting sanitization] within [Fill in: controlled areas within which to securely store digital media. Typical: the data center, the media library, or a locked container in an area with physical access control, with access limited to authorized personnel]. (MP-4a)
- The [System owner] shall securely store [Fill in: types of non-digital media to be securely stored. Typical: paper and microfilm containing information not approved for public release] within [Fill in: controlled areas within which to securely store non-digital media. Typical: locked cabinets, drawers or rooms with access limited to authorized personnel]. (MP-4a)
- The [System owner] shall keep an inventory of the digital media in each media library or store, with check-out and return records, and reconcile it at least quarterly. (MP-4a)
- Digital media stored outside the data center shall be encrypted as the encryption and key management standard requires for removable media (SC-28(1)). (MP-4a)
- The [System owner] shall protect these media until they are destroyed or sanitized using approved equipment, techniques and procedures, keeping media that are awaiting sanitization in the same controlled areas and on the inventory until the sanitization is recorded. (MP-4b)

##### Federal systems

Under [32 CFR 2002.14(c)](https://www.ecfr.gov/current/title-32/section-2002.14), authorized holders of controlled unclassified information (CUI) must take reasonable precautions against its unauthorized disclosure, including establishing and using controlled environments in which to protect it from unauthorized access or disclosure, and, when it is outside a controlled environment, keeping it under the authorized holder's direct control or protecting it with at least one physical barrier. As of October 2026.

- The [System owner] shall store media containing CUI only in controlled environments that meet 32 CFR 2002.14(c), and shall keep such media under an authorized holder's direct control, or behind at least one physical barrier such as a locked container, whenever they are outside a controlled environment. (MP-4a)

#### Media transport (MP-5)

> **Guidance:** MP-5 is in the Moderate and High baselines. NIST's MP-5 discussion names cryptography and locked containers as transport protections, and describes accountability as restricting transport to authorized personnel and tracking or obtaining records of the media as they move, to prevent and detect loss, destruction or tampering. Couriers may be external to the organization. Common cases are backup media going to the alternate storage site (CP-6, CP-9), drives going to a destruction provider, and media sent to another organization under an information exchange agreement. Keep the transport records with the system's records; for drives sent for destruction, record the transport in the [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/).

- The [System owner] shall protect and control [Fill in: types of system media to protect and control during transport outside of controlled areas. Typical: all digital and non-digital media containing information not approved for public release] during transport outside of controlled areas using [Fill in: controls used to protect system media outside of controlled areas. Typical: encryption of digital media under the encryption and key management standard, and sealed, tamper-evident packaging or locked containers] and [Fill in: controls used to control system media outside of controlled areas. Typical: transport only by authorized personnel or by a courier service with tracking and a signature on delivery, and a chain-of-custody record from release to receipt]. (MP-5a)
- Digital media shall be encrypted before they leave a controlled area, as the encryption and key management standard requires for removable media, and the key or password shall not travel with the media. (MP-5a)
- The [System owner] shall maintain accountability for system media during transport, so that each item can be traced from its release to its receipt. (MP-5b)
- The sender shall confirm receipt of each shipment, and shall report a shipment that does not arrive when expected, or arrives with its packaging opened or damaged, as a security incident under the incident response plan (IR-6). (MP-5b)
- The [System owner] shall document each transport of system media: the media and their identifiers, who released them, the carrier, the recipient, the tracking number where there is one, and the dates of release and receipt. (MP-5c)
- The [System owner] shall designate the personnel authorized to release, carry and receive system media, and shall use external couriers only under a contract or agreement that requires tracking and a signature on delivery. (MP-5d)

##### Federal systems

Under [32 CFR 2002.14(d)](https://www.ecfr.gov/current/title-32/section-2002.14), authorized holders sending controlled unclassified information (CUI) may use the United States Postal Service, any commercial delivery service, or interoffice or interagency mail; should use in-transit automated tracking and accountability tools; and must mark packages that contain CUI as 32 CFR Part 2002 and the CUI Executive Agent's guidance require (see 32 CFR 2002.20). As of October 2026.

- When shipping media containing CUI, the [System owner] shall use the United States Postal Service, a commercial delivery service, or interoffice or interagency mail, with in-transit automated tracking, and shall mark the packages as 32 CFR 2002.14(d) and 2002.20 require. (MP-5a)

#### Media sanitization (MP-6)

> **Guidance:** NIST's MP-6 discussion applies sanitization to all digital and non-digital media subject to disposal or reuse, removable or not, and names the storage in scanners, copiers, printers, notebook computers, workstations, network components and mobile devices. [NIST SP 800-88 Rev. 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final), Guidelines for Media Sanitization (September 2025, final; as of October 2026), defines three methods: clear (logical techniques against simple, non-invasive recovery), purge (recovery infeasible with state-of-the-art laboratory techniques, media possibly reusable) and destroy (recovery infeasible and the media unusable). It says purge should be used instead of clear when possible, and that the decision rests on the confidentiality of the information rather than the type of media; it points to the IEEE 2883 series for technique by media type. For cloud and other virtual storage, it notes that cryptographic erase may be the only purge option. It also advises against shredding or pulverizing storage devices for anything but the lowest security categories, since denser, harder media can survive them; paper can be shredded.
>
> The media sanitization procedure named below is the organization's: a table of the media types in use with the method, technique, tool and verification for each, which the [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/) provides. SP 800-88 Rev. 2 section 4.6 recommends a certificate of sanitization for each item, and the record's register holds those details. Keep the values consistent with the [Maintenance policy](https://kston83.github.io/nist-guide/templates/policies/ma/): equipment leaving for repair is sanitized first (MA-2d), and media that cannot be sanitized, such as a failed drive, stay with the organization.

- The [System owner] shall sanitize [Fill in: system media to be sanitized prior to disposal. Typical: all digital and non-digital system media, including the storage in workstations, laptops, servers, network devices, mobile devices, printers, copiers and scanners] prior to disposal using [Fill in: sanitization techniques and procedures to be used for sanitization prior to disposal. Typical: purge or destroy for digital media, and destruction by shredding or incineration for paper and other hard copy, as the media sanitization procedure sets out following NIST SP 800-88 Rev. 2]. (MP-6a)
- The [System owner] shall sanitize [Fill in: system media to be sanitized prior to release from organizational control. Typical: all digital and non-digital system media, including media returned to a lessor or vendor, exchanged under warranty, or sent off site for repair] prior to release out of organizational control using [Fill in: sanitization techniques and procedures to be used for sanitization prior to release from organizational control. Typical: purge, including cryptographic erase where its conditions are met, as the media sanitization procedure sets out following NIST SP 800-88 Rev. 2; media that cannot be purged and verified are destroyed, not released]. (MP-6a)
- The [System owner] shall sanitize [Fill in: system media to be sanitized prior to release for reuse. Typical: all digital system media reissued to another user, system or part of the organization] prior to release for reuse using [Fill in: sanitization techniques and procedures to be used for sanitization prior to release for reuse. Typical: clear for reuse within the same system or by users with the same access authorizations, and purge for other reuse, as the media sanitization procedure sets out following NIST SP 800-88 Rev. 2]. (MP-6a)
- The [Chief Information Security Officer] shall maintain a media sanitization procedure that follows NIST SP 800-88 Rev. 2 and names, for each media type in use, the sanitization method (clear, purge or destroy), the technique and tool, and how the result is verified. (MP-6a)
- Before media are sanitized, the [System owner] shall confirm that the information on them is not subject to a records retention requirement or legal hold that has not yet been met (SI-12). (MP-6a)
- Storage media that cannot be sanitized by the method the procedure requires, including failed drives, shall be kept within the organization and destroyed, and shall not be released out of organizational control. (MP-6a)
- Each sanitization shall be verified and recorded in the media sanitization record, including the media's identifiers, the method and technique, who performed and verified it, and the date. (MP-6a)
- Where an external provider sanitizes or destroys media, its contract shall specify the method, require a certificate listing each item by serial number, and allow the organization to witness or verify the work. (MP-6a)
- The [System owner] shall employ sanitization mechanisms whose strength and integrity are commensurate with the security category of the information, choosing the method by the confidentiality of the information as NIST SP 800-88 Rev. 2 describes. (MP-6b)
- Clear shall be used only for media that remain under organizational control, and then only for reuse within the same system or by users with the same access authorizations, for low-impact information, or for moderate-impact information where the [System owner] has accepted the residual risk in writing. (MP-6b)
- Storage devices holding moderate- or high-impact information shall be destroyed by disintegration, incineration or melting, or purged first, rather than only shredded or pulverized. (MP-6b)
- Cryptographic erase shall be used only where the media's encryption and key management meet the conditions in NIST SP 800-88 Rev. 2 section 3.2, and the keys are managed under the encryption and key management standard (SC-12). (MP-6b)

##### Federal systems

Under [32 CFR 2002.14(f)](https://www.ecfr.gov/current/title-32/section-2002.14), authorized holders may destroy controlled unclassified information (CUI) when the agency no longer needs it and records disposition schedules published or approved by NARA allow. Agencies destroying CUI, including in electronic form, must make it unreadable, indecipherable and irrecoverable, using any destruction method specifically required by law, regulation or Government-wide policy for that CUI; otherwise, the destruction guidance in NIST SP 800-53 and SP 800-88, or a method approved for classified national security information under 32 CFR 2001.47. Under 2002.14(e)(2), when CUI is reproduced on printers, copiers, scanners or fax machines, the equipment must not retain data, or the agency must sanitize it in accordance with NIST SP 800-53. [NIST SP 800-88 Rev. 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final), section 3.2, states that federal agencies must use encryption modules validated to the current FIPS 140 standard to have assurance in cryptographic erase on self-encrypting drives. As of October 2026.

- The [System owner] shall destroy CUI only when the agency no longer needs it and NARA-approved records disposition schedules allow, and only by a method that 32 CFR 2002.14(f)(2) permits. (MP-6a)
- The [System owner] shall ensure printers, copiers, scanners and fax machines used to reproduce CUI do not retain data, or are sanitized in accordance with NIST SP 800-53, as 32 CFR 2002.14(e)(2) requires. (MP-6a)
- Cryptographic erase shall rely only on encryption modules validated to the current FIPS 140 standard. (MP-6b)

#### Review, approve, track, document and verify (MP-6(1))

> **Guidance:** MP-6(1) is in the High baseline. NIST's discussion of this enhancement has organizations review and approve media for sanitization to ensure compliance with records retention policies, and lists what to document: who reviewed and approved the action, the types of media, the files stored on them, the method, the date and time, who sanitized them, the verification and who did it, and the disposal action. [NIST SP 800-88 Rev. 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final) section 4.5 separates verification (checking the technique completed, by inspecting destruction remnants or the tool's completion status) from validation (deciding whether the result is acceptable, or repeating with a different technique or a stronger method). The [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/) holds every field.

- The [System owner] shall review and approve each media sanitization and disposal action before it is performed, confirming that records retention requirements are met. (MP-6(1))
- The [System owner] shall track each item of media from its removal from service to its final disposition, so that every item removed has a recorded outcome. (MP-6(1))
- The [System owner] shall document each media sanitization and disposal action in the media sanitization record, including who reviewed and approved it, the type of media, the files or information stored on them, the sanitization method, the date and time, who performed it, the verification and who performed it, and the disposal action taken. (MP-6(1))
- The [System owner] shall verify that the sanitization was effective before the media are disposed of; a result that is not accepted shall be repeated with a different technique or a stronger method. (MP-6(1))

#### Equipment testing (MP-6(2))

> **Guidance:** MP-6(2) is in the High baseline. NIST's discussion of this enhancement allows the testing to be done by qualified and authorized external entities, including federal agencies or external service providers. A test shows the intended sanitization is achieved: a degausser's field strength checked against the coercivity of the media it is used on, a shredder's output checked against the particle size the procedure sets, and a sample of cleared or purged media read back with a forensic tool. [NIST SP 800-88 Rev. 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final) section 4.5.2 lists improperly calibrated equipment among the reasons a sanitization may not be effective. Record the tests in the [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/).

- The [System owner] shall test sanitization equipment [Fill in: frequency with which to test sanitization equipment. Typical: at least annually, and after the equipment is repaired, relocated or updated] to ensure that the intended sanitization is being achieved. (MP-6(2))
- The [System owner] shall test sanitization procedures [Fill in: frequency with which to test sanitization procedures. Typical: at least annually, and when a new media type, tool or sanitization provider is introduced] to ensure that the intended sanitization is being achieved. (MP-6(2))
- Equipment that fails a test shall not be used until it is repaired and passes a new test, and media sanitized with it since its last passing test shall be sanitized again. (MP-6(2))
- Where an external provider performs sanitization, the contract shall require the provider to test its equipment and procedures at least as often, and to provide the results. (MP-6(2))

#### Nondestructive techniques (MP-6(3))

> **Guidance:** MP-6(3) is in the High baseline. NIST's discussion of this enhancement explains that portable storage devices from untrustworthy sources can carry malicious code, and that sanitization gives more assurance than scanning alone. It names the two circumstances in the typical value: devices bought from manufacturers or vendors before first use, and devices whose positive chain of custody the organization cannot maintain. A nondestructive technique, such as clear or purge, leaves the device usable.

- The [System owner] shall apply nondestructive sanitization techniques to portable storage devices prior to connecting them to the system under the following circumstances: [Fill in: circumstances requiring sanitization of portable storage devices. Typical: before first use of a device newly purchased or received from outside the organization, and whenever the organization cannot maintain a positive chain of custody for the device]. (MP-6(3))
- Portable storage devices shall also be scanned for malicious code before they are connected to the system (SI-3). (MP-6(3))

#### Media use (MP-7)

> **Guidance:** NIST's MP-7 discussion contrasts it with MP-2: MP-2 restricts who may access media, while MP-7 restricts which media may be used on systems. It lists the usual technical controls: disabling ports or the ability to read or write to devices, limiting use to approved, organization-provided devices that are not personally owned, and blocking writes to portable devices. Requiring an identifiable owner, MP-7b, lets the organization assign responsibility for a device's known vulnerabilities. The typical values match the [Access Control Policy](https://kston83.github.io/nist-guide/templates/policies/ac/), which allows only encrypted, organization-issued devices on external systems (AC-20(2)), and the encryption and key management standard, which requires encryption of removable media (SC-28(1)). Choose "prohibit" for systems whose risk does not justify any portable storage.

- The [System owner] shall [Select one: restrict; prohibit. Typical: restrict] the use of [Fill in: types of system media to be restricted or prohibited from use on systems or system components. Typical: writable portable storage devices, such as USB flash drives, external hard drives and memory cards, and writable optical media] on [Fill in: systems or system components on which the use of specific types of system media to be restricted or prohibited. Typical: all organizational workstations, laptops and servers] using [Fill in: controls to restrict or prohibit the use of specific types of system media on systems or system components. Typical: endpoint device control that blocks portable storage devices other than encrypted, organization-issued devices assigned to a named owner, with exceptions approved by the system owner and recorded]. (MP-7a)
- Personally owned portable storage devices shall not be connected to organizational systems. (MP-7a)
- The [System owner] shall prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner. (MP-7b)
- Each organization-issued portable storage device shall be recorded with its owner in the component inventory (CM-8), and personnel shall turn in any device they find whose owner is unknown, without connecting it, to the [Security operations team]. (MP-7b)

### Physical and Environmental Protection (PE)

#### Physical access authorizations (PE-2)

> **Guidance:** PE-2 covers who may enter the facility where the system resides; PE-3 enforces it at the doors. NIST's PE-2 discussion says physical access authorizations apply to employees and visitors, that people with permanent credentials are not visitors, and that credentials include ID badges, identification cards and smart cards, with their strength set by applicable laws and policies. Areas designated as publicly accessible may not need an authorization. The [physical access list](https://kston83.github.io/nist-guide/templates/forms/physical-access-list/) holds the list, the credential issued, the approval and each review. Where the system runs entirely in a cloud service or a provider's data center, the provider meets PE-2 for its facility and the system security plan records it as inherited; the organization still applies PE-2 to its own offices and any rooms that hold its equipment. Assessors compare the list with recent departures and transfers, so tie removals to the [onboarding, transfer and termination checklist](https://kston83.github.io/nist-guide/templates/forms/onboarding-transfer-and-termination-checklist/).

- The [Facilities manager] shall develop, approve and maintain a list of individuals with authorized access to each facility where the system resides, showing for each person the areas they may enter. (PE-2a)
- Physical access shall be granted only on a request from the individual's supervisor, approved by the [Facilities manager] and, for areas that contain system components, also by the [System owner]. (PE-2a)
- The [Facilities manager] shall issue an authorization credential, such as an identification badge or access card, to each individual on the list, and record the credential against their entry. (PE-2b)
- The [Facilities manager] shall review the access list detailing authorized facility access by individuals [Fill in: frequency at which to review the access list detailing authorized facility access by individuals. Typical: at least quarterly for areas that contain system components, such as data centers, server rooms, wiring closets and media storage areas, and at least annually for the rest of the facility], with the supervisors or area owners confirming that each person still needs the access. (PE-2c)
- The [Facilities manager] shall remove individuals from the facility access list, and disable their credentials, when access is no longer required, and for a termination within the time the Personnel Security Policy sets for disabling system access (PS-4). (PE-2d)
- When an individual transfers, the [Facilities manager] shall remove physical access the new position does not need as part of the transfer actions (PS-5). (PE-2d)

##### Federal systems

[FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final) (January 2022) defines the Personal Identity Verification (PIV) Card as the common identity credential for federal employees and contractors for access to federally controlled facilities and information systems (section 1.2), and requires the PIV Card to be terminated when, among other circumstances, a federal employee separates from federal service or a contractor no longer needs access to federal buildings or systems (section 2.9.4). As of October 2026.

- For federal employees and contractors who hold a PIV Card, the authorization credential for access to a federally controlled facility shall be that PIV Card, registered in the physical access control system; anyone else receives a temporary or visitor credential that cannot be mistaken for a PIV Card. (PE-2b)
- When a PIV Card is terminated under FIPS 201-3 section 2.9.4, the [Facilities manager] shall remove its registration from the physical access control system. (PE-2d)

#### Physical access control (PE-3)

> **Guidance:** PE-3 enforces the authorizations PE-2 grants. NIST's PE-3 discussion says physical access control applies to employees and visitors; that controls for publicly accessible areas may include logs, guards, or devices and barriers that stop movement from public to non-public areas; that physical access devices include keys, locks, combinations, biometric readers and card readers; and that audit logs can be procedural, automated or both. Access points can be the facility's doors, interior doors to areas that need extra control, or both. Escorts here match the maintenance escorts in the Maintenance Policy (MA-5), and the [visitor log](https://kston83.github.io/nist-guide/templates/forms/visitor-log/) records who escorted each visitor. The [physical access list](https://kston83.github.io/nist-guide/templates/forms/physical-access-list/) holds the inventory of keys, combinations and badges. For a system hosted in a cloud service or colocation data center, the provider's controls are inherited for its facility, and the system security plan says so; PE-3 still applies to the organization's own offices and equipment rooms.

- The [Facilities manager] shall enforce physical access authorizations at [Fill in: entry and exit points to the facility in which the system resides. Typical: every entry and exit point of the facility, and of each area within it that contains system components] by verifying each individual's access authorization before granting access to the facility. (PE-3a.1)
- The [Facilities manager] shall control ingress and egress to the facility using [Select one or more: [Assignment: organization-defined systems or devices]; guards. Typical: an electronic physical access control system with badge readers at each controlled entry point, and guards or staffed reception at the main entrance during business hours]. (PE-3a.2)
- Each person shall badge in individually at controlled entry points and shall not hold a controlled door open for others; tailgating shall be reported to the [Facilities manager]. (PE-3a.2)
- The [Facilities manager] shall maintain physical access audit logs for [Fill in: entry or exit points for which physical access logs are maintained. Typical: every controlled entry point to the facility and to each area that contains system components], and protect them from alteration and unauthorized access (AU-9). (PE-3b)
- The [Facilities manager] shall control access to areas within the facility designated as publicly accessible by implementing [Fill in: physical access controls to control access to areas within the facility designated as publicly accessible. Typical: a staffed reception or guard post, locked or badge-controlled doors between public and non-public areas, and no unattended system components or live network jacks in public areas]. (PE-3c)
- Visitors shall be escorted, and their activity controlled, [Fill in: circumstances requiring visitor escorts and control of visitor activity. Typical: at all times in non-public areas, for every visitor and for anyone without a physical access authorization for the area, including maintenance personnel who are not on the authorized maintenance list]; the escort shall stay with the visitor until they leave the non-public area. (PE-3d)
- Visitor and temporary badges shall look different from permanent badges, shall be valid only for the day or the approved period, and shall be returned on departure. (PE-3d)
- The [Facilities manager] shall secure keys, combinations and other physical access devices, keeping unissued devices locked away and limiting knowledge of combinations to the people authorized to use them. (PE-3e)
- The [Facilities manager] shall inventory [Fill in: physical access devices to be inventoried. Typical: keys, lock combinations, and badges and access cards, including unissued, temporary and visitor badges] [Fill in: frequency at which to inventory physical access devices. Typical: at least annually], and investigate any device that cannot be accounted for. (PE-3f)
- The [Facilities manager] shall change combinations [Fill in: frequency at which to change combinations. Typical: at least annually], change keys [Fill in: frequency at which to change keys. Typical: at least every five years, and sooner when an inventory cannot account for an issued key], and change both when keys are lost, combinations are compromised, or individuals possessing the keys or combinations are transferred or terminated. (PE-3g)
- A lost or stolen badge or key shall be reported to the [Facilities manager] at once, and the badge disabled the same day. (PE-3g)

##### Federal systems

[FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final) (January 2022), section 6.3.1, lists the PIV authentication mechanisms for physical access and the assurance each provides, marks visual inspection (VIS) and SYM-CAK as deprecated, and states that "The selection of authentication assurance levels SHALL be made in accordance with the applicable policies for a facility's security level", pointing to the Interagency Security Committee's standard and to SP 800-116. [NIST SP 800-116 Rev. 1](https://csrc.nist.gov/pubs/sp/800/116/r1/final) (June 2018), section 4.3, recommends a risk-based selection organized by Controlled, Limited and Exclusion areas, with a minimum of one, two and three authentication factors respectively (Table 4-3). The Interagency Security Committee's [The Risk Management Process: An Interagency Security Committee Standard](https://www.cisa.gov/publication/risk-management-process), 2024 Edition, states that it applies to federally owned or leased facilities regularly occupied by executive branch employees or contract workers for nonmilitary activities, and has the tenant make the final Facility Security Level (FSL) determination, from Level I to Level V (section 8.1.1). As of October 2026.

- The [Facilities manager] shall designate each area of a federally controlled facility as Controlled, Limited or Exclusion, consistent with the facility's FSL determination, and record the designation in the physical access list. (PE-3a)
- The physical access control system shall authenticate PIV Cards electronically, using mechanisms that provide at least one authentication factor for Controlled areas, two for Limited areas and three for Exclusion areas, as SP 800-116 Rev. 1 Table 4-3 recommends, and shall not rely on visual inspection of the card alone. (PE-3a.1)

#### System access (PE-3(1))

> **Guidance:** PE-3(1) is in the High baseline. NIST's discussion of this enhancement says controlling physical access to the system adds protection for areas within facilities where system components are concentrated. In practice it is a second, separately authorized door: a badge that opens the building does not open the server room. Record those areas and who may enter them in the [physical access list](https://kston83.github.io/nist-guide/templates/forms/physical-access-list/).

- The [Facilities manager] shall enforce physical access authorizations to the system, in addition to the physical access controls for the facility, at [Fill in: physical spaces containing one or more components of the system. Typical: data centers, server rooms, wiring closets and media storage areas that contain components of the system]. (PE-3(1))
- Access to those spaces shall be authorized separately from facility access, approved by the [System owner], and limited to individuals whose duties require it. (PE-3(1))

#### Access control for transmission (PE-4)

> **Guidance:** PE-4 is in the Moderate and High baselines. NIST's PE-4 discussion says these controls prevent accidental damage, disruption and physical tampering, and may also be needed to prevent eavesdropping on or modification of unencrypted transmissions; it lists disconnected or locked spare jacks, locked wiring closets, cabling in conduit or cable trays, and wiretapping sensors. Encryption in transit (SC-8) reduces the eavesdropping risk but not damage or disruption, so PE-4 still applies. In shared buildings, the landlord's riser and telecommunications rooms are often outside the organization's control; record who controls them and what the lease or agreement requires.

- The [Facilities manager] shall control physical access to [Fill in: system distribution and transmission lines requiring physical access controls. Typical: the network and telephone cabling, fiber, patch panels and wireless access points that carry the system's communications, and the wiring closets and cable runs that hold them] within organizational facilities using [Fill in: security controls to be implemented to control physical access to system distribution and transmission lines within the organizational facility. Typical: locked wiring closets and telecommunications rooms with access limited to authorized staff, cabling in conduit or enclosed cable trays where it passes through public or shared areas, and unused network jacks disconnected at the patch panel or disabled on the switch]. (PE-4)
- The [System owner] shall identify, in the system security plan, the distribution and transmission lines that serve the system and who controls the spaces they pass through, including spaces controlled by a landlord or provider. (PE-4)
- Wiring closets and telecommunications rooms shall be included in the physical access list, and entry to them recorded in the physical access logs. (PE-4)

#### Access control for output devices (PE-5)

> **Guidance:** PE-5 is in the Moderate and High baselines. NIST's PE-5 discussion lists the ways to control output: output devices in locked rooms or secured areas with keypad or card reader access, devices placed where personnel can monitor them, monitor or screen filters, and headphones. Its examples of output devices are monitors, printers, scanners, audio devices, fax machines and copiers. Secure print release, where a job prints only after the user authenticates at the device, is the usual way to meet PE-5 for shared printers. The storage inside multifunction printers and copiers is media, sanitized under the Media Protection Policy before the device leaves (MP-6).

- The [System owner] and the [Facilities manager] shall control physical access to output from [Fill in: output devices that require physical access control to output. Typical: printers, copiers, scanners and fax machines in shared areas, and monitors that display information not approved for public release in areas visitors can see] to prevent unauthorized individuals from obtaining the output. (PE-5)
- Shared printers and copiers that output information not approved for public release shall release a job only after the user authenticates at the device, or shall be placed in a room limited to authorized individuals. (PE-5)
- Monitors in reception and other areas visitors can see shall be positioned away from them or fitted with privacy filters. (PE-5)
- Users shall collect output promptly; uncollected output shall be removed and destroyed at least daily. (PE-5)

#### Monitoring physical access (PE-6)

> **Guidance:** NIST's PE-6 discussion says monitoring includes publicly accessible areas, and gives guards, video surveillance and sensors as examples. It lists suspicious physical access activity: accesses outside normal work hours, repeated accesses to areas not normally accessed, accesses for unusual lengths of time, and out-of-sequence accesses. Where the physical access control system logs electronically, its logs can feed the security operations team's monitoring (AU-2, AU-6). The investigation of a physical security incident is handled under the [incident response plan](https://kston83.github.io/nist-guide/templates/plans/incident-response-plan/). For a system hosted by a provider, its monitoring of its facility is inherited and recorded in the system security plan.

- The [Facilities manager] shall monitor physical access to the facility where the system resides, including publicly accessible areas, to detect and respond to physical security incidents. (PE-6a)
- The [Facilities manager] shall review physical access logs [Fill in: the frequency at which to review physical access logs. Typical: at least monthly] and upon occurrence of [Fill in: events or potential indication of events requiring physical access logs to be reviewed. Typical: a physical security incident or alarm, a lost or stolen badge or key, reported tailgating, access attempts outside normal working hours, and a request from the incident response team], looking for accesses outside normal working hours, repeated accesses to areas not normally accessed, accesses of unusual length and out-of-sequence accesses. (PE-6b)
- Each review shall be recorded with its date, the reviewer, the period covered and the anomalies found. (PE-6b)
- The [Facilities manager] shall coordinate the results of reviews and investigations with the [Incident response team], and report suspected physical security incidents under the incident response plan (IR-6). (PE-6c)

#### Intrusion alarms and surveillance equipment (PE-6(1))

> **Guidance:** PE-6(1) is in the Moderate and High baselines. NIST's discussion of this enhancement says intrusion alarms alert security personnel when unauthorized access is attempted, working with barriers, access control systems and guards by triggering a response when they are breached; sensors include motion, contact and glass-break sensors, and surveillance equipment includes cameras at strategic locations. Keep video only as long as the records schedule allows, and treat recordings as personally identifiable information.

- The [Facilities manager] shall monitor physical access to the facility where the system resides using physical intrusion alarms and surveillance equipment. (PE-6(1))
- Intrusion alarms shall cover the facility's entry points and each area that contains system components when it is unoccupied, and shall alert guards, a monitoring service or designated staff who respond. (PE-6(1))
- Surveillance cameras shall cover the entry points to the facility and to each area that contains system components, and recordings shall be kept for the period the records schedule sets, with access limited to authorized staff. (PE-6(1))
- The [Facilities manager] shall test the alarms and check the cameras at least annually, and repair faults promptly. (PE-6(1))

#### Monitoring physical access to systems (PE-6(4))

> **Guidance:** PE-6(4) is in the High baseline. NIST's discussion of this enhancement says it adds monitoring for areas where system components are concentrated, such as server rooms, media storage areas and communications centers, and that physical access monitoring can be coordinated with intrusion detection and system monitoring. Use the same spaces as PE-3(1), so every area with its own access control also has its own monitoring.

- The [Facilities manager] shall monitor physical access to the system, in addition to the physical access monitoring of the facility, at [Fill in: physical spaces containing one or more components of the system. Typical: data centers, server rooms, wiring closets and media storage areas that contain components of the system]. (PE-6(4))
- Physical access events for those spaces shall be sent to the [Security operations team] and correlated with system monitoring. (PE-6(4))

#### Visitor access records (PE-8)

> **Guidance:** NIST's PE-8 discussion lists what visitor access records include: names and organizations of visitors, visitor signatures, forms of identification, dates of access, entry and departure times, purpose of visits, and names and organizations of the individuals visited. It says reviews determine whether access authorizations are current and still required, and that records are not required for publicly accessible areas. Where the organization adopts the Privacy baseline, PE-8(3) limits these elements to those the privacy risk assessment identifies. The [visitor log](https://kston83.github.io/nist-guide/templates/forms/visitor-log/) holds the fields, the reviews and the anomalies reported. Assessors pick a few dates and ask for that day's records, then for the last review.

- The [Facilities manager] shall maintain visitor access records to the facility where the system resides for [Fill in: time period for which to maintain visitor access records for the facility where the system resides. Typical: 2 years, or longer where the organization's records retention schedule requires]. (PE-8a)
- Each visitor record shall include the visitor's name and organization, the form of identification checked, the date, entry and departure times, the purpose of the visit, the name of the person visited, the badge issued and the escort, subject to the limits PE-8(3) sets where it applies. (PE-8a)
- The [Facilities manager] shall review visitor access records [Fill in: the frequency at which to review visitor access records. Typical: at least monthly], checking for visitors with no departure time, badges not returned, visits outside normal hours, repeated visits that suggest the person needs a PE-2 authorization instead, and visits without an escort. (PE-8b)
- The [Facilities manager] shall report anomalies in visitor access records to [Fill in: personnel to whom visitor access records anomalies are reported to. Typical: the facilities manager and the security operations team], and the security operations team shall handle any that suggest an incident under the incident response plan (IR-6). (PE-8c)

##### Federal systems

The National Archives and Records Administration's [General Records Schedule 5.6](https://www.archives.gov/files/records-mgmt/grs/grs05-6.pdf), Security Management Records (GRS Transmittal 35, May 2024), covers visitor processing records, such as registers or logs of visitors, contractors and service personnel. Item 110, for areas requiring the highest level of security awareness, including areas the Interagency Security Committee designates as Facility Security Level V, says destroy when 5 years old; item 111, for all other facility security areas, including Facility Security Levels I to IV, says destroy when 2 years old. Both allow longer retention if required for business use. As of October 2026.

- Visitor access records shall be kept for at least 5 years for areas at Facility Security Level V and at least 2 years for other areas, as GRS 5.6 items 110 and 111 set, unless the agency's own approved records schedule sets a different period. (PE-8a)

#### Automated records maintenance and review (PE-8(1))

> **Guidance:** PE-8(1) is in the High baseline. NIST's discussion of this enhancement says visitor access records may be kept in a database accessible to organizational personnel, and that automated access makes regular reviews easier. An electronic visitor management system that prints the visitor badge and records the escort meets the maintenance half; the review half needs reports, such as open visits and badges not returned, that someone reads on the PE-8 schedule.

- The [Facilities manager] shall maintain visitor access records using [Fill in: automated mechanisms used to maintain visitor access records. Typical: an electronic visitor management system]. (PE-8(1))
- The [Facilities manager] shall review visitor access records using [Fill in: automated mechanisms used to review visitor access records. Typical: the visitor management system's reports, compared with the physical access control system's logs]. (PE-8(1))

#### Power equipment and cabling (PE-9)

> **Guidance:** PE-9 is in the Moderate and High baselines. NIST's PE-9 discussion has organizations decide the protection needed for power equipment and cabling inside and outside their facilities, such as internal cabling and uninterruptible power supplies in offices or data centers, and generators and power cabling outside buildings. For a system hosted by a provider, PE-9 is inherited for the provider's facility.

- The [Facilities manager] shall protect power equipment and power cabling for the system from damage and destruction. (PE-9)
- Power distribution units, uninterruptible power supplies, transfer switches and generators that serve the system shall be in locked rooms or enclosures with access limited to authorized staff, and outdoor equipment shall be fenced or otherwise protected from vehicles and tampering. (PE-9)
- Power cabling shall be routed and labeled so that it is protected from accidental damage, kept separate from data cabling where practical, and not run across walkways. (PE-9)
- Power equipment shall be maintained as the manufacturer specifies, and the maintenance recorded. (PE-9)

#### Emergency shutoff (PE-10)

> **Guidance:** PE-10 is in the Moderate and High baselines. NIST's PE-10 discussion says emergency power shutoff applies mainly to facilities with concentrations of system resources, such as data centers, mainframe rooms, server rooms and areas with computer-controlled machinery. An office with no server room usually has nothing to which PE-10 applies beyond the building's own electrical controls; say so in the system security plan rather than leaving it blank. Accidental activation is the common finding: an unguarded button beside a door that someone mistakes for a door release.

- The [Facilities manager] shall provide the capability of shutting off power to [Fill in: system or individual system components that require the capability to shut off power in emergency situations. Typical: the equipment in each data center and server room, including servers, storage, network equipment and their cooling] in emergency situations. (PE-10a)
- The [Facilities manager] shall place emergency shutoff switches or devices [Fill in: location of emergency shutoff switches or devices by system or system component. Typical: beside the main exit of each data center and server room, clearly labeled] to facilitate access for authorized personnel. (PE-10b)
- The [Facilities manager] shall protect the emergency power shutoff capability from unauthorized activation, with protective covers on the switches, placement inside the access-controlled area, and an alarm or camera that records activation. (PE-10c)
- Staff who work in those areas shall be shown the shutoff locations and told when to use them. (PE-10b)

#### Emergency power (PE-11)

> **Guidance:** PE-11 is in the Moderate and High baselines. NIST's PE-11 discussion describes an uninterruptible power supply (UPS) as near-instantaneous protection from power interruptions, from batteries, supercapacitors or flywheels, with a short duration that gives time to start a standby source such as a generator or to shut the system down properly. Choose the selection from the [business impact analysis](https://kston83.github.io/nist-guide/templates/reports/business-impact-analysis/): if the system's recovery time objective tolerates waiting for power to return, an orderly shutdown is enough; if not, the UPS must carry the load until long-term alternate power takes over, and the [contingency plan](https://kston83.github.io/nist-guide/templates/plans/contingency-plan/) should say how. High systems add PE-11(1). For a system hosted by a provider, PE-11 is inherited.

- The [Facilities manager] shall provide an uninterruptible power supply to facilitate [Select one: an orderly shutdown of the system; transition of the system to long-term alternate power. Typical: an orderly shutdown of the system] in the event of a primary power source loss. (PE-11)
- Where the contingency plan's recovery time objective cannot be met by restarting the system after primary power returns, the [Facilities manager] shall also provide long-term alternate power, such as a generator, to which the uninterruptible power supply transitions the system. (PE-11)
- The [System owner] shall configure the system's components to shut down in order, automatically where they support it, before the uninterruptible power supply's batteries are exhausted. (PE-11)
- The [Facilities manager] shall test the uninterruptible power supply and any generator at least annually, replace batteries as the manufacturer specifies, and confirm the runtime still covers the load. (PE-11)

#### Alternate power supply — minimal operational capability (PE-11(1))

> **Guidance:** PE-11(1) is in the High baseline. NIST's discussion of this enhancement says it can be met by a secondary commercial power supply or another external power supply. A generator with an automatic transfer switch is the usual way; size it and its fuel for the minimally required operational capability the contingency plan defines.

- The [Facilities manager] shall provide an alternate power supply for the system that is activated [Select one: manually; automatically. Typical: automatically] and that can maintain minimally required operational capability in the event of an extended loss of the primary power source. (PE-11(1))
- The [System owner] shall define the minimally required operational capability in the contingency plan, and the [Facilities manager] shall keep fuel or supply contracts sufficient to sustain it for the outage duration the plan assumes. (PE-11(1))

#### Emergency lighting (PE-12)

> **Guidance:** NIST's PE-12 discussion says emergency lighting applies mainly to facilities with concentrations of system resources, such as data centers, server rooms and mainframe rooms; that emergency lighting provisions are described in the organization's contingency plan; and that if emergency lighting fails or cannot be provided, organizations consider alternate processing sites for power-related contingencies. Building and fire codes usually require emergency lighting already; PE-12 asks that it cover the rooms that hold the system and be maintained.

- The [Facilities manager] shall employ and maintain automatic emergency lighting for the system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility. (PE-12)
- The [Facilities manager] shall test emergency lighting at least annually, and repair failures promptly. (PE-12)
- The [System owner] shall describe the emergency lighting provisions for the system in the contingency plan (CP-2). (PE-12)

#### Fire protection (PE-13)

> **Guidance:** NIST's PE-13 discussion says fire detection and suppression applies mainly to facilities with concentrations of system resources, such as data centers, server rooms and mainframe rooms; that systems that may need an independent energy source include sprinkler systems and smoke detectors; and that an independent energy source, such as a microgrid, is one separate, or separable, from the sources powering the rest of the facility. Building and fire codes and the local fire authority set most of the details; the policy makes sure the rooms that hold the system are covered and the systems are maintained. For a system hosted by a provider, PE-13 is inherited.

- The [Facilities manager] shall employ and maintain fire detection and suppression systems, supported by an independent energy source, that cover each area containing system components. (PE-13)
- Fire detection and suppression systems shall be inspected, tested and maintained as the applicable fire code and the manufacturer require, and the records kept. (PE-13)
- Where the suppression system could itself damage equipment, such as water sprinklers in a server room, the [Facilities manager] shall record the choice and the reason, with the system owner's agreement. (PE-13)

#### Detection systems — automatic activation and notification (PE-13(1))

> **Guidance:** PE-13(1) is in the Moderate and High baselines. NIST's discussion of this enhancement says organizations can name personnel, roles and emergency responders when people on the notification list need access authorizations or clearances to enter restricted facilities, and that notification mechanisms may need independent energy sources so a fire does not disable them. Check the notification path in the annual fire system test.

- The [Facilities manager] shall employ fire detection systems that activate automatically and notify [Fill in: personnel or roles to be notified in the event of a fire. Typical: the facilities manager and the operations staff on duty for the facility] and [Fill in: emergency responders to be notified in the event of a fire. Typical: the local fire department, through a monitored fire alarm service] in the event of a fire. (PE-13(1))
- The notification path shall have power independent of the facility's main supply, and shall be tested with the fire detection system. (PE-13(1))

#### Suppression systems — automatic activation and notification (PE-13(2))

> **Guidance:** PE-13(2) is in the High baseline. NIST's discussion of this enhancement matches PE-13(1)'s: name personnel and responders where access authorizations are needed to enter, and give the notification mechanism an independent energy source. Use the same notification list as PE-13(1).

- The [Facilities manager] shall employ fire suppression systems that activate automatically and notify [Fill in: personnel or roles to be notified in the event of a fire. Typical: the facilities manager and the operations staff on duty for the facility] and [Fill in: emergency responders to be notified in the event of a fire. Typical: the local fire department, through a monitored fire alarm service]. (PE-13(2)(a))
- The [Facilities manager] shall employ an automatic fire suppression capability when the facility is not staffed on a continuous basis. (PE-13(2)(b))

#### Environmental controls (PE-14)

> **Guidance:** NIST's PE-14 discussion says environmental controls apply mainly to facilities with concentrations of system resources, such as data centers, mainframe rooms and server rooms, and that insufficient controls, especially in harsh environments, can significantly affect the availability of systems that support mission and business functions. Pressure and radiation matter only in special environments; add them, or another control such as dust, where the site needs it. A server room cooled by the building's office air conditioning, which shuts off at night or on weekends, is a common finding. For a system hosted by a provider, PE-14 is inherited.

- The [Facilities manager] shall maintain [Select one or more: temperature; humidity; pressure; radiation; [Assignment: organization-defined environmental control]. Typical: temperature and humidity] levels within the facility where the system resides at [Fill in: acceptable levels for environmental controls. Typical: the operating ranges the equipment manufacturers specify, recorded in the system security plan]. (PE-14a)
- The [Facilities manager] shall monitor environmental control levels [Fill in: frequency at which to monitor environmental control levels. Typical: continuously, with automated alerts when a level leaves its range]. (PE-14b)
- Alerts shall go to staff who can respond at any hour, and an alert that is not resolved within the time the contingency plan allows shall start the contingency plan's notification procedures (CP-2). (PE-14b)
- Cooling for areas that contain system components shall run independently of the building's office schedule, with enough capacity or redundancy that the loss of one unit does not take the room out of range. (PE-14a)

#### Water damage protection (PE-15)

> **Guidance:** NIST's PE-15 discussion says water damage protection applies mainly to facilities with concentrations of system resources, such as data centers, server rooms and mainframe rooms, and that isolation valves can be used in addition to, or instead of, master shutoff valves to shut off water in specific areas without affecting the whole organization. Assessors ask staff where the valve is and check that it is labeled and reachable. For a system hosted by a provider, PE-15 is inherited.

- The [Facilities manager] shall protect the system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel. (PE-15)
- The valves shall be labeled, shown on a facility plan kept with the contingency plan, kept clear of obstructions, and exercised at least annually. (PE-15)
- Key personnel, including the staff who work in areas that contain system components, shall be shown the valve locations and how to operate them. (PE-15)
- Water pipes shall not run above system components where it can be avoided; where they do, the [Facilities manager] shall record the risk and the protection used, such as drip trays or leak detection. (PE-15)

#### Automation support (PE-15(1))

> **Guidance:** PE-15(1) is in the High baseline. NIST's discussion of this enhancement lists notification systems, water detection sensors and alarms as automated mechanisms. Alert the same people as the environmental monitoring in PE-14, so one on-call path covers both.

- The [Facilities manager] shall detect the presence of water near the system and alert [Fill in: personnel or roles to be alerted when the presence of water is detected near the system. Typical: the facilities manager and the operations staff on duty for the facility] using [Fill in: automated mechanisms used to detect the presence of water near the system. Typical: water detection sensors under raised floors, near cooling units and below any pipes in areas that contain system components, connected to the building management or environmental monitoring system]. (PE-15(1))
- The water detection sensors and their alerts shall be tested at least annually. (PE-15(1))

#### Delivery and removal (PE-16)

> **Guidance:** NIST's PE-16 discussion says enforcing authorizations for components entering and leaving the facility may require restricting access to delivery areas and isolating them from the system and media libraries. PE-16 is where the other families' removal rules meet the door: a component leaving for repair needs the system owner's approval and sanitized media under the Maintenance Policy (MA-2), media leaving a controlled area travel under the Media Protection Policy (MP-5), and arriving components are checked against the order and recorded in the component inventory (CM-8) before they are connected. Assessors pick a recent delivery and a recent removal and follow each through the records.

- The [Facilities manager] shall authorize and control [Fill in: types of system components to be authorized and controlled when entering the facility. Typical: all system components, including servers, network devices, storage devices and media, and end-user devices such as laptops] entering the facility, receiving them only in a delivery area that is separated from areas that contain system components and media libraries. (PE-16a)
- Arriving components shall be checked against the purchase order or shipping record and for signs of tampering before they are moved out of the delivery area, and reported under the incident response plan if they show any. (PE-16a)
- The [Facilities manager] shall authorize and control [Fill in: types of system components to be authorized and controlled when exiting the facility. Typical: all system components, including servers, network devices, storage devices and media, and end-user devices such as laptops] exiting the facility, letting a component leave only with the [System owner]'s approval and, for a component with storage, a record that its media were sanitized or removed (MA-2, MP-6). (PE-16a)
- The [Facilities manager] shall maintain records of the system components entering and exiting the facility: the item and serial number, the date, who delivered or carried it, who authorized it, and where it went. (PE-16b)
- Laptops and other devices issued to individuals may leave and return with their assigned user without a record of each trip, as long as they are recorded in the component inventory against that user. (PE-16a)

#### Alternate work site (PE-17)

> **Guidance:** PE-17 is in the Moderate and High baselines. NIST's PE-17 discussion says alternate work sites include government facilities and employees' private residences; that they are distinct from alternate processing sites but can serve as alternate locations during contingency operations; and that organizations can set different controls for different types of site. The controls here should match the [Rules of Behavior](https://kston83.github.io/nist-guide/templates/forms/rules-of-behavior/), which every user signs, and the remote access requirements of the Access Control Policy (AC-17). [NIST SP 800-46 Rev. 2](https://csrc.nist.gov/pubs/sp/800/46/r2/final) (July 2016), Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security, covers securing telework and remote access; Rev. 2 is the final version; a Rev. 3 pre-draft call for comments closed in October 2020, and csrc.nist.gov lists no later draft as of October 2026. Assessing effectiveness at homes is usually done through a self-assessment checklist and the endpoint management data for the devices used there, not site visits.

- The [Chief Information Security Officer] shall determine and document [Fill in: alternate work sites allowed for use by employees. Typical: employees' homes, under an approved telework agreement, and other organization facilities] as the alternate work sites allowed for use by employees, and the [Supervisor] shall approve each employee's use of them. (PE-17a)
- The following controls shall be employed at alternate work sites: [Fill in: controls to be employed at alternate work sites. Typical: organization-issued devices, or personally owned devices the organization has approved and manages under its external system terms (AC-19, AC-20), connected through the approved remote access methods (AC-17), with full-disk encryption and screen lock (AC-11); a workspace where screens and conversations are not overseen or overheard; paper and media kept secured and not left unattended; and no printing of information not approved for public release on personal printers]. (PE-17b)
- The [Chief Information Security Officer] shall assess the effectiveness of controls at alternate work sites at least annually, through an employee self-assessment and the device compliance data from endpoint management, and act on the gaps found. (PE-17c)
- The [Chief Information Security Officer] shall provide a means for employees at alternate work sites to communicate with information security and privacy personnel in case of incidents, available at all hours, and employees shall report incidents through it as the Rules of Behavior require (IR-6). (PE-17d)

##### Federal systems

Under [5 U.S.C. § 6502](https://www.govinfo.gov/link/uscode/5/6502?link-type=html), each executive agency's telework policy must require a written agreement between an agency manager and each employee authorized to telework, outlining the specific work arrangement, which is mandatory for any employee to telework (subsection (b)(2)); must be part of the agency's continuity of operations plans (subsection (b)(5)); and must enumerate when employees may temporarily work from approved overseas locations (subsection (b)(6)). Text checked in the United States Code, 2024 edition, as of October 2026.

- No employee shall telework without the written telework agreement 5 U.S.C. § 6502(b)(2) requires, and the agreement shall reference the alternate work site controls in this policy. (PE-17a)
- Work from an overseas location shall be allowed only in the circumstances the agency's telework policy enumerates under 5 U.S.C. § 6502(b)(6). (PE-17a)

#### Location of system components (PE-18)

> **Guidance:** PE-18 is in the High baseline. NIST's PE-18 discussion lists physical and environmental hazards, including floods, fires, tornadoes, earthquakes, hurricanes, terrorism, vandalism, an electromagnetic pulse and electrical interference, and asks organizations to consider entry points where unauthorized individuals, though not granted access, might be near systems, which can increase the risk of interception with wireless sniffers or microphones. Server rooms on a basement level below a water source, or beside a public corridor or loading dock, are the usual examples.

- The [Facilities manager] and the [System owner] shall position system components within the facility to minimize potential damage from [Fill in: physical and environmental hazards that could result in potential damage to system components within the facility. Typical: flooding, fire, water leaks from pipes and cooling, power disturbances and electrical interference, and the other hazards the risk assessment identifies for the site] and to minimize the opportunity for unauthorized access. (PE-18)
- Areas that contain system components shall not adjoin public areas, delivery areas or exterior walls at ground level where an alternative exists, and the reasons for any exception shall be recorded with the risk assessment (RA-3). (PE-18)

### Planning (PL)

#### System security and privacy plans (PL-2)

> **Guidance:** PL-2 lists fifteen things a system's security and privacy plans must contain. The [System Security Plan template](https://kston83.github.io/nist-guide/templates/plans/system-security-plan/) has a section for each, so the statements below require the plan and point to its contents rather than repeating all fifteen. A system that processes personally identifiable information can keep its privacy plan as part of the security plan or as a separate document; either way, both must meet PL-2.

- Each [System owner] shall develop a security plan and a privacy plan for the system, as one document or two, that contain every element PL-2a.1 to a.14 lists. (PL-2a)
- The plans shall identify the security- and privacy-related activities affecting the system that require planning and coordination with [Fill in: individuals or groups with whom security and privacy-related activities affecting the system that require planning and coordination. Typical: the system's stakeholders, the common control providers, and the security and privacy teams]. (PL-2a.14)
- The [System owner] shall have the plans reviewed and approved by the authorizing official, or a designated representative, before the plans are implemented. (PL-2a.15)
- The [System owner] shall distribute copies of the plans, and communicate later changes to them, to [Fill in: personnel or roles to receive distributed copies of the system security and privacy plans. Typical: the authorizing official, the system owner, the system security officer and the assessor]. (PL-2b)
- The [System owner] shall review the plans [Fill in: frequency to review system security and privacy plans. Typical: annually]. (PL-2c)
- The [System owner] shall update the plans to address changes to the system and its environment of operation, and problems found during plan implementation or control assessments. (PL-2d)
- The [System owner] shall protect the plans from unauthorized disclosure and modification. (PL-2e)

#### Rules of behavior (PL-4)

> **Guidance:** The [Rules of Behavior template](https://kston83.github.io/nist-guide/templates/forms/rules-of-behavior/) gives the rules, a signature block and a register of acknowledgments. Assessors sample new accounts and check that each acknowledgment is dated before access was granted.

- The [Chief Information Security Officer] shall establish rules that describe the responsibilities and expected behavior of individuals for information and system usage, security and privacy. (PL-4a)
- The [Chief Information Security Officer] shall provide the rules to each individual who requires access to the system. (PL-4a)
- The [Account manager] shall receive a documented acknowledgment from each individual, stating that they have read, understand and agree to abide by the rules, before authorizing access to information and the system. (PL-4b)
- The [Chief Information Security Officer] shall review and update the rules of behavior [Fill in: frequency for reviewing and updating the rules of behavior. Typical: annually]. (PL-4c)
- The [Chief Information Security Officer] shall require individuals who acknowledged a previous version of the rules to read and re-acknowledge them [Select one or more: [Assignment: organization-defined frequency]; when the rules are revised or updated. Typical: annually, and when the rules are revised or updated]. (PL-4d)

#### Social media and external site and application usage restrictions (PL-4(1))

- The rules of behavior shall restrict the use of social media, social networking sites, and external sites and applications. (PL-4(1)(a))
- The rules of behavior shall restrict the posting of organizational information on public websites. (PL-4(1)(b))
- The rules of behavior shall restrict the use of organization-provided identifiers, such as email addresses, and authentication secrets, such as passwords, to create accounts on external sites and applications. (PL-4(1)(c))

#### Security and privacy architectures (PL-8)

> **Guidance:** The architectures describe how the system is built to protect information and to limit privacy risk: the protection approach, the trust boundaries, and what the system assumes about the services it relies on. Most systems keep them as a section of the system security plan with a diagram, rather than as a separate document.

- Each [System owner] shall develop a security architecture and a privacy architecture for the system. (PL-8a)
- The architectures shall describe the requirements and approach for protecting the confidentiality, integrity and availability of organizational information. (PL-8a.1)
- The architectures shall describe the requirements and approach for processing personally identifiable information so as to minimize privacy risk to individuals. (PL-8a.2)
- The architectures shall describe how they are integrated into and support the enterprise architecture. (PL-8a.3)
- The architectures shall describe any assumptions about, and dependencies on, external systems and services. (PL-8a.4)
- The [System owner] shall review and update the architectures [Fill in: frequency for review and update to reflect changes in the enterprise architecture. Typical: annually, and whenever the enterprise architecture changes] to reflect changes in the enterprise architecture. (PL-8b)
- The [System owner] shall reflect planned architecture changes in the security and privacy plans, the concept of operations, the criticality analysis, organizational procedures, and procurements and acquisitions. (PL-8c)

#### Baseline selection (PL-10)

> **Guidance:** Pick the baseline from the system's security categorization: SP 800-53B defines Low, Moderate and High security baselines and a Privacy baseline. Record the choice, and any overlay applied, in the system security plan (PL-2a.11).

- Each [System owner] shall select a control baseline for the system, based on its security categorization, and record the selection in the system security plan. (PL-10)
- A system that processes personally identifiable information shall also apply the privacy control baseline. (PL-10)

##### Federal systems

Federal systems select the SP 800-53B security baseline that matches the system's impact level: the highest impact level for confidentiality, integrity and availability under [FIPS 199](https://csrc.nist.gov/pubs/fips/199/final), as [FIPS 200](https://csrc.nist.gov/pubs/fips/200/final) specifies.

- The [System owner] shall select the baseline that matches the system's FIPS 199 impact level. (PL-10)

#### Baseline tailoring (PL-11)

> **Guidance:** Tailoring adjusts the baseline to the system: identifying common controls, scoping out controls that do not apply, setting parameter values, adding controls for specific threats, and applying overlays. Assessors look for a documented reason for every control removed or marked not applicable.

- Each [System owner] shall tailor the selected control baseline by applying specified tailoring actions. (PL-11)
- The [System owner] shall document each tailoring decision, with its rationale, in the system security plan, and have the authorizing official approve it with the plan. (PL-11)

### Program Management (PM)

#### Information security program plan (PM-1)

> **Guidance:** Assessors ask to see the approved plan, its approval date and evidence of the last review. A plan can be one document or a set of documents, as long as the set is identified. The plan lists the common controls the program provides, so system owners can mark them as inherited in each system security plan.

- The [Chief Information Security Officer] shall develop, maintain and disseminate an organization-wide information security program plan. (PM-1a)
- The plan shall give an overview of the requirements for the security program, and describe the program management controls and common controls in place or planned to meet them. (PM-1a.1)
- The plan shall identify and assign roles and responsibilities, and describe management commitment, coordination among organizational entities, and compliance. (PM-1a.2)
- The plan shall reflect the coordination among the organizational entities responsible for information security. (PM-1a.3)
- The [Senior leader], as the senior official accountable for the risk the organization incurs, shall approve the plan. (PM-1a.4)
- The [Chief Information Security Officer] shall disseminate the approved plan to every system owner and authorizing official and to the leaders of the functions named under Coordination. (PM-1a)
- The [Chief Information Security Officer] shall review and update the plan [Fill in: the frequency at which to review and update the organization-wide information security program plan. Typical: annually] and following [Fill in: events that trigger the review and update of the organization-wide information security program plan. Typical: a significant change to the organization's mission, structure, risk tolerance or systems, a major incident, or a finding from an assessment or audit of the program]. (PM-1b)
- The [Chief Information Security Officer] shall protect the plan from unauthorized disclosure and modification by limiting who can change it and keeping each approved version. (PM-1c)

##### Federal systems

For federal agencies, this policy carries out the agency-wide information security program required by the Federal Information Security Modernization Act of 2014 ([44 U.S.C. § 3554(b)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim)) and [OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, Responsibilities for Protecting and Managing Federal Information Resources.

- The program plan shall carry out the agency-wide information security program that 44 U.S.C. § 3554(b) requires. (PM-1a)

#### Information security program leadership role (PM-2)

> **Guidance:** PM-2 asks for one named senior official who owns the security program. Assessors look for the appointment in writing (a delegation memo or charter) and for evidence that the official has budget and staff, not just a title.

- The [Senior leader] shall appoint a [Chief Information Security Officer] to coordinate, develop, implement and maintain the organization-wide information security program. (PM-2)
- The [Senior leader] shall record the appointment in writing and give the [Chief Information Security Officer] the mission and resources the role needs. (PM-2)

##### Federal systems

FISMA requires the agency head to delegate to the Chief Information Officer the authority to ensure compliance, including designating a senior agency information security officer who has information security duties as that official's primary duty and heads an office with the mission and resources to assist in ensuring compliance ([44 U.S.C. § 3554(a)(3)(A)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim)).

- The [Chief Information Security Officer] shall be the senior agency information security officer designated under 44 U.S.C. § 3554(a)(3)(A), with information security duties as that official's primary duty. (PM-2)

#### Information security and privacy resources (PM-3)

> **Guidance:** PM-3 ties the programs to the budget. Evidence is the security and privacy line items in each capital planning or investment request, and a record of any request that left them out and why.

- The [Chief Information Security Officer] and the [Senior privacy official] shall identify the resources the information security and privacy programs need, for each capital planning and investment request. (PM-3a)
- The [Senior leader] shall include those resources in capital planning and investment requests, and document every exception. (PM-3a)
- The [Chief Information Security Officer] and the [Senior privacy official] shall prepare the security and privacy documentation that capital planning and investment requests require under applicable laws, regulations, policies and standards. (PM-3b)
- The [Senior leader] shall make the planned information security and privacy resources available for expenditure. (PM-3c)

#### Plan of action and milestones process (PM-4)

> **Guidance:** PM-4 is the organization-level process; CA-5 is each system's plan of action and milestones (POA&M). Use one format across systems, such as the [POA&M template](https://kston83.github.io/nist-guide/templates/forms/plan-of-action-and-milestones/), so the program can roll items up and compare them against the risk management strategy.

- The [Chief Information Security Officer] shall maintain a process that ensures plans of action and milestones are developed and maintained for the information security, privacy and supply chain risk management programs and for each organizational system. (PM-4a.1)
- Each plan of action and milestones shall document the remedial actions planned to respond to risk to organizational operations and assets, individuals, other organizations and the Nation. (PM-4a.2)
- The [Chief Information Security Officer] shall report plans of action and milestones to the [Senior leader] [Fill in: how often, for example quarterly], and to regulators and customers as laws and contracts require. (PM-4a.3)
- The [Chief Information Security Officer] shall review plans of action and milestones for consistency with the risk management strategy and the organization-wide priorities for risk response. (PM-4b)

#### System inventory (PM-5)

> **Guidance:** The system inventory is the list of systems the program is responsible for: each with an owner, a categorization, an authorization status and its boundary. CM-8 is the component inventory inside each system. Start from the [System Inventory template](https://kston83.github.io/nist-guide/templates/forms/system-inventory/). An assessor compares the inventory with the authorization records, so keep both in step.

- The [Chief Information Security Officer] shall maintain an inventory of organizational systems and update it [Fill in: the frequency at which to update the inventory of organizational systems. Typical: quarterly, and whenever a system is authorized, significantly changed or retired]. (PM-5)
- Each [System owner] shall add a system to the inventory before it is authorized or placed in operation. (PM-5)

##### Federal systems

The Paperwork Reduction Act requires each agency head to maintain an inventory of major information systems, updated at least annually ([44 U.S.C. § 3505(c)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3505&num=0&edition=prelim)).

- The [Chief Information Security Officer] shall update the inventory at least annually and whenever the agency adds, significantly changes or retires a major information system. (PM-5)

#### Inventory of personally identifiable information (PM-5(1))

- The [Senior privacy official] shall establish, maintain and update [Fill in: the frequency at which to update the inventory of systems, applications, and projects that process personally identifiable information. Typical: at least annually, and whenever a privacy impact assessment is completed or updated] an inventory of all systems, applications and projects that process personally identifiable information. (PM-5(1))

#### Measures of performance (PM-6)

> **Guidance:** Choose a few measures that show whether the programs work, such as the share of systems with a current authorization, overdue plan of action items, and remediation within the required times. Report the same measures each period so trends show.

- The [Chief Information Security Officer] shall develop, monitor and report on measures of performance for the information security program. (PM-6)
- The [Senior privacy official] shall develop, monitor and report on measures of performance for the privacy program. (PM-6)
- The [Chief Information Security Officer] and the [Senior privacy official] shall report the results to the [Senior leader]. (PM-6)

#### Enterprise architecture (PM-7)

- The [Chief Information Security Officer] shall ensure the enterprise architecture is developed and maintained with consideration for information security, privacy and the resulting risk to organizational operations and assets, individuals, other organizations and the Nation. (PM-7)
- The [Senior privacy official] shall review changes to the enterprise architecture that affect the processing of personally identifiable information. (PM-7)

#### Offloading (PM-7(1))

- Each [System owner] shall offload [Fill in: non-essential functions or services to be offloaded. Typical: non-essential services, such as email, file sharing and public web hosting, on systems that support mission-essential functions] to other systems, system components or an external provider. (PM-7(1))

#### Critical infrastructure plan (PM-8)

> **Guidance:** PM-8 applies where the organization owns or operates critical infrastructure or key resources, or helps protect them. If it does neither, keep the heading and record that decision in the program plan.

- The [Chief Information Security Officer] and the [Senior privacy official] shall address information security and privacy issues when the organization develops, documents and updates its critical infrastructure and key resources protection plan. (PM-8)

#### Risk management strategy (PM-9)

> **Guidance:** The risk management strategy says how the organization frames, assesses, responds to and monitors risk, including its risk tolerance (PM-28). Every authorization decision should be traceable to it. Start from the [Risk Management Strategy template](https://kston83.github.io/nist-guide/templates/plans/risk-management-strategy/).

- The [Chief Information Security Officer] shall develop an organization-wide risk management strategy for security risk to organizational operations and assets, individuals, other organizations and the Nation from the operation and use of organizational systems. (PM-9a.1)
- The strategy shall also address privacy risk to individuals from the authorized processing of personally identifiable information, developed with the [Senior privacy official]. (PM-9a.2)
- The [Senior leader] shall approve the strategy. (PM-9a)
- The [Chief Information Security Officer] shall implement the strategy consistently across the organization. (PM-9b)
- The [Chief Information Security Officer] shall review and update the strategy [Fill in: the frequency at which to review and update the risk management strategy. Typical: annually], and whenever organizational changes require it. (PM-9c)

#### Authorization process (PM-10)

> **Guidance:** PM-10 makes authorization an organization-wide process rather than a one-off per system. The program plan should name who may serve as an authorizing official and how their decisions feed the risk management strategy.

- The [Chief Information Security Officer] shall manage the security and privacy state of organizational systems, and the environments they operate in, through an authorization process. (PM-10a)
- The [Senior leader] shall designate the individuals who fill the roles in the risk management process, including an authorizing official for each system. (PM-10b)
- The [Chief Information Security Officer] shall integrate the authorization process into the organization-wide risk management program. (PM-10c)

#### Mission and business process definition (PM-11)

- The [Senior leader] shall ensure the organization's mission and business processes are defined with consideration for information security, privacy and the resulting risk to organizational operations and assets, individuals, other organizations and the Nation. (PM-11a)
- The [Chief Information Security Officer] and the [Senior privacy official] shall determine the information protection and personally identifiable information processing needs that arise from those processes. (PM-11b)
- The [Senior leader] shall review and revise the mission and business processes [Fill in: the frequency at which to review and revise the mission and business processes. Typical: annually, and whenever the organization changes its mission, structure or major services]. (PM-11c)

#### Insider threat program (PM-12)

> **Guidance:** An insider threat program brings together information that security, human resources, legal and privacy each hold, so that concerning behavior is noticed and handled consistently. Involve the privacy official from the start: the program handles personal information about the workforce.

- The [Chief Information Security Officer] shall implement an insider threat program. (PM-12)
- The program shall include a cross-discipline insider threat incident handling team, with members from at least security, human resources, legal and privacy. (PM-12)

##### Federal systems

[Executive Order 13587](https://www.federalregister.gov/documents/2011/10/13/2011-26729/structural-reforms-to-improve-the-security-of-classified-networks-and-the-responsible-sharing-and) (October 7, 2011), section 2.1(b), requires the heads of agencies that operate or access classified computer networks to "implement an insider threat detection and prevention program consistent with guidance and standards developed by the Insider Threat Task Force" that section 6 establishes.

- If the agency operates or accesses classified computer networks, the insider threat program shall meet Executive Order 13587, section 2.1(b), and the guidance and standards of the Insider Threat Task Force. (PM-12)

#### Security and privacy workforce (PM-13)

- The [Chief Information Security Officer] and the [Senior privacy official] shall establish a security and privacy workforce development and improvement program. (PM-13)
- The program shall define the knowledge and skills each security and privacy role needs, and the training and development that build them. (PM-13)

#### Testing, training and monitoring (PM-14)

- The [Chief Information Security Officer] shall maintain a process that ensures the organization's plans for security and privacy testing, training and monitoring of organizational systems are developed and maintained. (PM-14a.1)
- The [Chief Information Security Officer] shall track that those plans continue to be carried out. (PM-14a.2)
- The [Chief Information Security Officer] shall review the testing, training and monitoring plans for consistency with the risk management strategy and the organization-wide priorities for risk response. (PM-14b)

#### Security and privacy groups and associations (PM-15)

- The [Chief Information Security Officer] shall establish and maintain contact with selected security and privacy groups and associations, and record which ones. (PM-15)
- The organization shall use those contacts to support ongoing security and privacy education and training for its personnel. (PM-15a)
- The organization shall use those contacts to stay current with recommended security and privacy practices, techniques and technologies. (PM-15b)
- The organization shall use those contacts to share current security and privacy information, including threats, vulnerabilities and incidents. (PM-15c)

#### Threat awareness program (PM-16)

- The [Chief Information Security Officer] shall implement a threat awareness program. (PM-16)
- The program shall include a capability to share threat intelligence with other organizations. (PM-16)

#### Automated means for sharing threat intelligence (PM-16(1))

- The [Security operations team] shall use automated mechanisms to share threat intelligence, such as machine-readable feeds exchanged with sharing partners. (PM-16(1))

#### Protecting controlled unclassified information on external systems (PM-17)

> **Guidance:** Controlled unclassified information (CUI) is information the U.S. government creates or owns that a law, regulation or government-wide policy requires to be protected. PM-17 applies wherever the organization shares CUI with external systems, or holds CUI under a contract or agreement. If it handles no CUI, keep the heading and record that decision in the program plan.

- The [Chief Information Security Officer] shall establish policy and procedures to ensure that requirements for protecting controlled unclassified information processed, stored or transmitted on external systems are implemented in accordance with applicable laws, regulations, policies and standards. (PM-17a)
- The [Chief Information Security Officer] shall review and update that policy [Fill in: the frequency at which to review and update the policy. Typical: annually]. (PM-17b)
- The [Chief Information Security Officer] shall review and update those procedures [Fill in: the frequency at which to review and update the procedures. Typical: annually]. (PM-17b)

##### Federal systems

Under [32 CFR 2002.14(h)(2)](https://www.ecfr.gov/current/title-32/section-2002.14), agencies must use NIST SP 800-171 when establishing security requirements to protect CUI's confidentiality on non-federal information systems. [32 CFR 2002.2](https://www.ecfr.gov/current/title-32/section-2002.2) still incorporates the June 2015 edition of SP 800-171 by reference, while NIST's current revision is [SP 800-171 Rev. 3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) (May 2024), so each agreement should name the revision it requires. As of October 2026.

- Each agreement that shares CUI with a non-federal organization shall require the recipient to protect it as 32 CFR 2002.14(h) requires, and shall name the revision of NIST SP 800-171 that applies. (PM-17a)

#### Privacy program plan (PM-18)

> **Guidance:** The privacy program plan is the privacy counterpart of the information security program plan (PM-1). Many organizations keep them as two chapters of one program document; assessors accept that if each chapter meets its own control.

- The [Senior privacy official] shall develop and disseminate an organization-wide privacy program plan that gives an overview of the privacy program. (PM-18a)
- The plan shall describe the structure of the privacy program and the resources dedicated to it. (PM-18a.1)
- The plan shall give an overview of the requirements for the privacy program, and describe the privacy program management controls and common controls in place or planned to meet them. (PM-18a.2)
- The plan shall include the role of the [Senior privacy official], and identify the roles and responsibilities of other privacy officials and staff. (PM-18a.3)
- The plan shall describe management commitment, compliance, and the strategic goals and objectives of the privacy program. (PM-18a.4)
- The plan shall reflect coordination among the organizational entities responsible for the different aspects of privacy. (PM-18a.5)
- The [Senior leader], as the senior official accountable for the privacy risk the organization incurs, shall approve the plan. (PM-18a.6)
- The [Senior privacy official] shall update the plan [Fill in: the frequency of updates to the privacy program plan. Typical: annually], and to address changes in privacy law and policy, organizational changes, and problems found during plan implementation or privacy control assessments. (PM-18b)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix II, requires each agency to develop, maintain and update an organization-wide privacy program plan.

- The plan shall address the changes in federal privacy laws and policy that apply to the agency. (PM-18b)

#### Privacy program leadership role (PM-19)

- The [Senior leader] shall appoint a [Senior privacy official] with the authority, mission, accountability and resources to coordinate, develop and implement applicable privacy requirements and manage privacy risk through the organization-wide privacy program. (PM-19)
- The [Senior leader] shall record the appointment in writing. (PM-19)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf) (July 28, 2016) requires each agency head to designate a Senior Agency Official for Privacy.

- The [Senior privacy official] shall be the Senior Agency Official for Privacy the agency head designates under OMB Circular A-130. (PM-19)

#### Dissemination of privacy program information (PM-20)

- The [Senior privacy official] shall maintain a privacy webpage on the organization's principal public website as the central source of information about the privacy program. (PM-20)
- The page shall give the public information about the organization's privacy activities and a way to contact the [Senior privacy official]. (PM-20a)
- The page shall make the organization's privacy practices and reports publicly available. (PM-20b)
- The page shall list a public email address or phone line for feedback and questions to the privacy office. (PM-20c)

##### Federal systems

[OMB M-23-22](https://www.whitehouse.gov/wp-content/uploads/2023/09/M-23-22-Delivering-a-Digital-First-Public-Experience.pdf), Delivering a Digital-First Public Experience (September 2023), requires each agency's privacy program page to be located at `www.[agency].gov/privacy`, as of September 2026.

- The privacy webpage shall be located at the address M-23-22 requires, `www.[agency].gov/privacy`. (PM-20)

#### Privacy policies on websites, applications and digital services (PM-20(1))

- The [Senior privacy official] shall ensure a privacy policy is posted on every external-facing website, mobile application and other digital service. (PM-20(1))
- Each privacy policy shall be written in plain language and organized so that it is easy to understand and navigate. (PM-20(1)(a))
- Each privacy policy shall give the public the information it needs to decide whether and how to interact with the organization. (PM-20(1)(b))
- Each privacy policy shall be updated whenever the organization makes a substantive change to the practices it describes, and shall show the date of the latest change. (PM-20(1)(c))

#### Accounting of disclosures (PM-21)

> **Guidance:** The retention period in PM-21b is fixed by NIST's control text, not a parameter. Keep the accounting where it can be searched by individual, so a request under PM-21c can be answered.

- The [Senior privacy official] shall ensure an accurate accounting is kept of each disclosure of personally identifiable information, recording the date, nature and purpose of the disclosure. (PM-21a.1)
- The accounting shall record the name and address, or other contact information, of the individual or organization that received the disclosure. (PM-21a.2)
- The accounting shall be kept for as long as the personally identifiable information is maintained or five years after the disclosure, whichever is longer. (PM-21b)
- The [Senior privacy official] shall make the accounting available, on request, to the individual the information is about. (PM-21c)

##### Federal systems

For records in a Privacy Act system of records, [5 U.S.C. § 552a(c)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title5-section552a&num=0&edition=prelim) sets this accounting. It excludes disclosures to agency employees who need the record for their duties (subsection (b)(1)) and disclosures the Freedom of Information Act requires (subsection (b)(2)). It does not require the accounting to be shown to the individual for law enforcement disclosures under subsection (b)(7).

- The [Senior privacy official] shall keep the accounting of disclosures from each system of records as 5 U.S.C. § 552a(c) requires. (PM-21)

#### Personally identifiable information quality management (PM-22)

- The [Senior privacy official] shall develop and document organization-wide policies and procedures for reviewing personally identifiable information for accuracy, relevance, timeliness and completeness across the information life cycle. (PM-22a)
- The [Senior privacy official] shall develop and document organization-wide policies and procedures for correcting or deleting inaccurate or outdated personally identifiable information. (PM-22b)
- The [Senior privacy official] shall develop and document organization-wide policies and procedures for notifying individuals or other appropriate entities of corrected or deleted personally identifiable information. (PM-22c)
- The [Senior privacy official] shall develop and document organization-wide policies and procedures for appeals of adverse decisions on correction or deletion requests. (PM-22d)

#### Data governance body (PM-23)

- The [Senior leader] shall establish a data governance body made up of [Fill in: the roles of a Data Governance Body. Typical: the chief data officer (chair), the chief information officer, the chief information security officer, the senior privacy official, the records manager and the owners of major data sets], with responsibility for [Fill in: the responsibilities of a Data Governance Body. Typical: setting data governance policy, approving data sharing agreements, and resolving data quality and access issues]. (PM-23)

#### Data integrity board (PM-24)

> **Guidance:** A matching program is a computerized comparison of records about individuals, typically to establish or check eligibility for a benefit; the term comes from the U.S. Privacy Act. The steps for each matching program are in PT-8, in the [PII Processing and Transparency Policy](https://kston83.github.io/nist-guide/templates/policies/pt/). If the organization runs no matching programs, keep the heading and record that decision in the program plan.

- Where [Organization name] conducts or takes part in a matching program, the [Senior leader] shall establish a data integrity board. (PM-24)
- The board shall review each proposal to conduct or take part in a matching program before the organization commits to it. (PM-24a)
- The board shall review, each year, every matching program the organization took part in. (PM-24b)

##### Federal systems

The Privacy Act requires every agency that conducts or participates in a matching program to establish a Data Integrity Board, which reviews matching proposals and reviews all of the agency's matching programs each year ([5 U.S.C. § 552a(u)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title5-section552a&num=0&edition=prelim)).

- The data integrity board shall be established, staffed and run as 5 U.S.C. § 552a(u) requires. (PM-24)

#### Minimization of personally identifiable information used in testing, training and research (PM-25)

- The [Senior privacy official] shall develop, document and implement policies and procedures for using personally identifiable information in internal testing, training and research. (PM-25a)
- Internal testing, training and research shall use no more personally identifiable information than the purpose needs, and shall use synthetic or de-identified data wherever it serves the purpose. (PM-25b)
- The [Senior privacy official] shall authorize each use of personally identifiable information for internal testing, training or research before it begins. (PM-25c)
- The [Senior privacy official] shall review those policies [Fill in: the frequency for reviewing policies that address the use of personally identifiable information for internal testing, training, and research. Typical: annually] and update them [Fill in: the frequency for updating policies that address the use of personally identifiable information for internal testing, training, and research. Typical: annually, and whenever the review finds a change is needed]. (PM-25d)
- The [Senior privacy official] shall review those procedures [Fill in: the frequency for reviewing procedures that address the use of personally identifiable information for internal testing, training, and research. Typical: annually] and update them [Fill in: the frequency for updating procedures that address the use of personally identifiable information for internal testing, training, and research. Typical: annually, and whenever the review finds a change is needed]. (PM-25d)

#### Complaint management (PM-26)

- The [Senior privacy official] shall implement a process for receiving and responding to complaints, concerns and questions from individuals about the organization's security and privacy practices. (PM-26)
- The process shall offer ways to file that are easy to use and readily accessible to the public. (PM-26a)
- The process shall tell individuals all the information they need to file a complaint successfully. (PM-26b)
- The process shall track each complaint so that it is reviewed within [Fill in: the time period in which complaints (including concerns or questions) from individuals are to be reviewed. Typical: 5 business days] and addressed within [Fill in: the time period in which complaints (including concerns or questions) from individuals are to be addressed. Typical: 30 days]. (PM-26c)
- The [Senior privacy official] shall acknowledge receipt of each complaint, concern or question within [Fill in: the time period for acknowledging the receipt of complaints. Typical: 3 business days]. (PM-26d)
- The [Senior privacy official] shall respond to each complaint, concern or question within [Fill in: the time period for responding to complaints. Typical: 30 days]. (PM-26e)

#### Privacy reporting (PM-27)

- The [Senior privacy official] shall develop [Fill in: privacy reports. Typical: an annual privacy program report, summaries of privacy impact assessments, and breach reports]. (PM-27a)
- The [Senior privacy official] shall disseminate the reports to [Fill in: privacy oversight bodies. Typical: the board of directors or its audit committee, and regulators where law requires], to demonstrate accountability with statutory, regulatory and policy privacy mandates. (PM-27a.1)
- The [Senior privacy official] shall disseminate the reports to [Fill in: officials responsible for monitoring privacy program compliance. Typical: the senior leader, the chief information security officer and general counsel] and other personnel responsible for monitoring privacy program compliance. (PM-27a.2)
- The [Senior privacy official] shall review and update the reports [Fill in: the frequency for reviewing and updating privacy reports. Typical: annually]. (PM-27b)

#### Risk framing (PM-28)

> **Guidance:** Risk framing is the context every risk decision uses: the assumptions, constraints, priorities and risk tolerance. Most organizations record it as a section of the risk management strategy (PM-9).

- The [Chief Information Security Officer] shall identify and document the assumptions affecting risk assessment, risk response and risk monitoring. (PM-28a.1)
- The [Chief Information Security Officer] shall identify and document the constraints affecting risk assessment, risk response and risk monitoring. (PM-28a.2)
- The [Chief Information Security Officer] shall identify and document the priorities and trade-offs the organization considers in managing risk. (PM-28a.3)
- The [Senior leader] shall set and document the organization's risk tolerance. (PM-28a.4)
- The [Chief Information Security Officer] shall distribute the results of risk framing to [Fill in: the personnel to receive the results of risk framing activities. Typical: authorizing officials, system owners, information owners, the leaders of mission and business functions, the senior privacy official, and the senior accountable official for risk management]. (PM-28b)
- The [Chief Information Security Officer] shall review and update the risk framing [Fill in: the frequency for reviewing and updating risk framing considerations. Typical: annually, with the risk management strategy]. (PM-28c)

#### Risk management program leadership roles (PM-29)

- The [Senior leader] shall appoint a senior accountable official for risk management to align the organization's information security and privacy management processes with its strategic, operational and budgetary planning. (PM-29a)
- The [Senior leader] shall establish a risk executive function to view and analyze risk from an organization-wide perspective and keep risk management consistent across the organization. (PM-29b)

#### Supply chain risk management strategy (PM-30)

> **Guidance:** The supply chain risk management strategy is organization-wide; the supply chain risk management plan (SR-2) applies it to systems. NIST SP 800-161 Rev. 1 describes both ([Update 1, November 2024](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final), current as of September 2026).

- The [Chief Information Security Officer] shall develop an organization-wide strategy for managing supply chain risks associated with the development, acquisition, maintenance and disposal of systems, system components and system services. (PM-30a)
- The [Chief Information Security Officer] shall implement the supply chain risk management strategy consistently across the organization. (PM-30b)
- The [Chief Information Security Officer] shall review and update the supply chain risk management strategy [Fill in: the frequency for reviewing and updating the supply chain risk management strategy. Typical: annually], and whenever organizational changes require it. (PM-30c)

#### Suppliers of critical or mission-essential items (PM-30(1))

- The [Chief Information Security Officer] shall identify and prioritize the suppliers of critical or mission-essential technologies, products and services. (PM-30(1))
- The [Chief Information Security Officer] shall assess each of those suppliers for supply chain risk. (PM-30(1))

#### Continuous monitoring strategy (PM-31)

> **Guidance:** The organization-wide strategy sets the metrics and frequencies each system's continuous monitoring (CA-7) follows. The [Continuous Monitoring Strategy](https://kston83.github.io/nist-guide/templates/plans/continuous-monitoring-strategy/) template holds both levels. NIST SP 800-137 ([September 2011](https://csrc.nist.gov/pubs/sp/800/137/final), current as of September 2026) describes how to build it.

- The [Chief Information Security Officer] shall develop an organization-wide continuous monitoring strategy and implement continuous monitoring programs that follow it. (PM-31)
- The programs shall monitor these organization-wide metrics: [Fill in: the metrics for organization-wide continuous monitoring. Typical: systems with a current authorization, plan of action items past due, vulnerabilities remediated within the required times, and staff with current security awareness training]. (PM-31a)
- The programs shall monitor control effectiveness [Fill in: the frequencies for monitoring. Typical: continuously for automated controls, and at least monthly for vulnerability, configuration and account data]. (PM-31b)
- The programs shall assess control effectiveness [Fill in: the frequencies for assessing control effectiveness. Typical: a third of each system's controls each year, so every control is assessed at least every three years]. (PM-31b)
- The programs shall monitor the organization-wide metrics on an ongoing basis, as the strategy sets out. (PM-31c)
- The programs shall correlate and analyze the information that control assessments and monitoring produce. (PM-31d)
- The programs shall take response actions to address the results of that analysis. (PM-31e)
- The [Chief Information Security Officer] shall report the security status of organizational systems to [Fill in: the personnel or roles for reporting the security status of organizational systems to. Typical: the senior leader and the authorizing officials] [Fill in: the frequency at which to report the security status of organizational systems. Typical: monthly]. (PM-31f)
- The [Senior privacy official] shall report the privacy status of organizational systems to [Fill in: the personnel or roles for reporting the privacy status of organizational systems to. Typical: the senior leader and the authorizing officials] [Fill in: the frequency at which to report the privacy status of organizational systems. Typical: quarterly]. (PM-31f)

#### Purposing (PM-32)

- The [Chief Information Security Officer] shall analyze [Fill in: the systems or system components supporting mission-essential services or functions. Typical: the systems and components that support mission-essential functions, as the business impact analysis identifies them] to ensure their information resources are used consistently with their intended purpose. (PM-32)

### Personnel Security (PS)

#### Position risk designation (PS-2)

> **Guidance:** A risk designation rates each position by the harm a person in it could do through misconduct, usually low, moderate or high. Positions with privileged access, control of money or access to large amounts of sensitive information rate higher. The designation sets the screening each position needs (PS-3), so write the screening criteria for each level in one table.

- The [Human resources office] shall assign a risk designation to every organizational position, in consultation with the [Chief Information Security Officer]. (PS-2a)
- The [Human resources office] shall establish screening criteria for the individuals who fill each position, according to its risk designation. (PS-2b)
- The [Human resources office] shall review and update position risk designations [Fill in: the frequency at which to review and update position risk designations. Typical: at least every 3 years, and whenever a position's duties change]. (PS-2c)

##### Federal systems

[5 CFR 731.106](https://www.ecfr.gov/current/title-5/section-731.106) (OPM; last amended June 30, 2026) requires the agency head to designate every covered position, including positions filled by contractor employees, "at high, moderate, or low risk level" by the position's potential for adverse impact to the efficiency or integrity of the service. Each such position also gets a sensitivity designation: Special-Sensitive, Critical-Sensitive, Noncritical-Sensitive or Non-sensitive (731.106(c)(2)); [5 CFR 1400.201](https://www.ecfr.gov/current/title-5/section-1400.201) defines the levels for national security positions. OPM and the Defense Counterintelligence and Security Agency provide the [Position Designation Tool](https://www.opm.gov/suitability/suitability-executive-agent/position-designation-tool/) for making these designations. Checked September 2026.

- The [Human resources office] shall designate each covered position, including positions filled by contractor employees, at a high, moderate or low risk level, as 5 CFR 731.106(a) requires. (PS-2a)
- The [Human resources office] shall give each covered position a sensitivity designation under 5 CFR 731.106(c)(2) and 5 CFR part 1400. (PS-2a)

#### Personnel screening (PS-3)

> **Guidance:** Screening is what the position's risk designation calls for: identity and employment checks at the low level, and more, such as criminal history checks, at higher levels. Employment and privacy laws limit what may be checked and how, and they vary by country and state, so settle the screening criteria with legal counsel. Assessors compare screening completion dates with account creation dates.

- The [Human resources office] shall screen each individual, according to the screening criteria for their position, before the individual is authorized to access a system. (PS-3a)
- The [Human resources office] shall rescreen individuals when [Fill in: conditions requiring rescreening of individuals. Typical: the individual moves to a position with a higher risk designation, or information comes to light that raises a concern about their suitability], and, where the screening criteria call for periodic rescreening, [Fill in: the frequency of rescreening individuals where it is so indicated. Typical: every 5 years for positions designated high risk]. (PS-3b)

##### Federal systems

[5 CFR 731.106](https://www.ecfr.gov/current/title-5/section-731.106) (as amended June 30, 2026) requires a background investigation for each individual entering a covered position, initiated before appointment where possible (731.106(c)(1)), and bars criminal or credit history inquiries before a conditional offer of employment, with limited exceptions (731.106(g)). Rescreening is now continuous vetting: "Continuous vetting for an individual in a public trust position satisfies the requirement for a periodic reinvestigation" (731.106(d)(1)), and an upgraded investigation for a move to a higher risk level "should be initiated within 14 days" (731.106(e)). [FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final) (January 2022), section 2.2, requires the FBI National Criminal History Check to be completed and favorably adjudicated before a PIV Card is issued to someone with no prior investigation. Checked September 2026.

- The [Human resources office] shall initiate the background investigation the position's risk level requires before the individual is appointed, or as soon as possible where it was not initiated in time. (PS-3a)
- The [Human resources office] shall not ask an applicant about criminal or credit history before a conditional offer of employment, except as 5 CFR 731.106(g) allows. (PS-3a)
- The [Human resources office] shall ensure the FBI National Criminal History Check is completed and favorably adjudicated before a PIV Card is issued to an individual with no prior investigation. (PS-3a)
- The [Human resources office] shall ensure individuals in positions subject to investigation are continuously vetted under 5 CFR 731.106(d) and the standards OPM issues. (PS-3b)
- The [Human resources office] shall notify each covered employee of the continuous vetting requirements. (PS-3b)
- The [Human resources office] shall initiate any upgraded investigation within 14 days after an individual's move to a higher position risk level is final. (PS-3b)

#### Personnel termination (PS-4)

> **Guidance:** Termination is the most tested personnel control: assessors take a list of recent departures and check when each account was disabled. The time period should agree with the notice time in AC-2h.2. NIST notes that for a termination for cause, organizations consider disabling accounts before the individual is told, and that an exit interview is not always possible. The [onboarding, transfer and termination checklist](https://kston83.github.io/nist-guide/templates/forms/onboarding-transfer-and-termination-checklist/) lists each step with its owner.

- The [Account manager] shall disable the individual's system access within [Fill in: a time period within which to disable system access. Typical: 24 hours, or the same day for privileged users; for an involuntary termination, no later than when the individual is told] of the termination of their employment. (PS-4a)
- The [Account manager] shall terminate or revoke every authenticator and credential associated with the individual, including tokens, certificates and building passes. (PS-4b)
- The [Human resources office] shall conduct an exit interview with the individual that includes a discussion of [Fill in: information security topics to be discussed when conducting exit interviews. Typical: the individual's continuing duty not to disclose organizational information, the return of all organizational property and information, and that former credentials must not be used]. (PS-4c)
- The [Supervisor] shall retrieve all security-related organizational property from the individual, such as devices, authentication tokens, keys, identification cards and building passes. (PS-4d)
- The [Supervisor] shall ensure the organization keeps access to the organizational information and systems the individual controlled. (PS-4e)

##### Federal systems

[FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final) (January 2022), section 2.9.4, requires a PIV Card to be terminated when, among other circumstances, "A federal employee separates (voluntarily or involuntarily) from federal service" or "A contractor changes positions and no longer needs access to federal buildings or systems." Checked September 2026.

- The [Human resources office] shall ensure the PIV Card issuer terminates the individual's PIV Card in each circumstance FIPS 201-3 section 2.9.4 lists, including separation from federal service. (PS-4b)

#### Automated actions (PS-4(2))

> **Guidance:** The usual mechanism is a feed from the human resources system to the identity provider, which disables the accounts and sends the notices when a termination is recorded. PS-4(2) is in the High baseline.

- The [System owner] shall use [Fill in: automated mechanisms to notify personnel or roles of individual termination actions and/or to disable access to system resources. Typical: the identity governance system, triggered by the termination record in the human resources system] to [Select one or more: notify [Assignment: organization-defined personnel or roles] of individual termination actions; disable access to system resources. Typical: notify the account managers and system owners of individual termination actions, and disable access to system resources]. (PS-4(2))

#### Personnel transfer (PS-5)

> **Guidance:** A transfer is where access accumulates: people keep what they had and gain what the new job needs. PS-5 applies to reassignments that are permanent or long enough to warrant the actions. The notice time should agree with AC-2h.2. The [onboarding, transfer and termination checklist](https://kston83.github.io/nist-guide/templates/forms/onboarding-transfer-and-termination-checklist/) has a transfer section.

- The [Supervisor] shall review and confirm the ongoing operational need for an individual's current logical and physical access authorizations to systems and facilities when the individual is reassigned or transferred to another position within the organization. (PS-5a)
- The [Human resources office] shall initiate [Fill in: transfer or reassignment actions to be initiated following transfer or reassignment. Typical: a review of the individual's access by the losing and gaining supervisors, removal of access the new position does not need, and the return or issue of keys, badges and equipment] within [Fill in: the time period within which transfer or reassignment actions must occur following transfer or reassignment. Typical: 5 business days] following the formal transfer action. (PS-5b)
- The [Account manager] shall modify the individual's access authorizations to match any change in operational need caused by the reassignment or transfer. (PS-5c)
- The [Human resources office] shall notify [Fill in: personnel or roles to be notified when individuals are reassigned or transferred to other positions within the organization. Typical: the account managers and system owners of the systems the individual has access to] of the reassignment or transfer within [Fill in: time period within which to notify organization-defined personnel or roles when individuals are reassigned or transferred to other positions within the organization. Typical: 24 hours]. (PS-5d)

#### Access agreements (PS-6)

> **Guidance:** Access agreements include nondisclosure agreements, acceptable use agreements, rules of behavior and conflict-of-interest agreements (SP 800-53 PS-6 discussion). The [access agreement](https://kston83.github.io/nist-guide/templates/forms/access-agreement/) template covers nondisclosure and acceptable use, and takes in the [Rules of Behavior](https://kston83.github.io/nist-guide/templates/forms/rules-of-behavior/) by reference; keeping both on the same annual cycle means one signature event a year. Electronic signatures are acceptable unless organizational policy prohibits them. PS-6 is also in the Privacy baseline.

- The [Chief Information Security Officer] shall develop and document access agreements for organizational systems. (PS-6a)
- The [Chief Information Security Officer] shall review and update the access agreements [Fill in: the frequency at which to review and update access agreements. Typical: annually]. (PS-6b)
- The [Account manager] shall verify that each individual who requires access to organizational information and systems has signed the appropriate access agreements before granting access. (PS-6c.1)
- The [Account manager] shall verify that each individual re-signs the access agreements when they are updated, and [Fill in: the frequency at which to re-sign access agreements to maintain access to organizational information. Typical: annually], to keep access to organizational systems. (PS-6c.2)
- The [Account manager] shall suspend the access of an individual who does not re-sign an updated access agreement until the individual signs it. (PS-6c.2)

#### External personnel security (PS-7)

> **Guidance:** External providers include contractors, service bureaus, and organizations providing development, IT, assessment or security services. Put these requirements in the contract: screening to the same criteria as employees in comparable positions, signed access agreements, required training, and the notice of transfers and terminations. Monitor compliance by comparing the provider's staff roster with the accounts and badges issued to its people.

- The [Chief Information Security Officer] shall establish personnel security requirements, including security roles and responsibilities, for external providers. (PS-7a)
- The [Chief Information Security Officer] shall require external providers to comply with the organization's personnel security policies and procedures. (PS-7b)
- The [Chief Information Security Officer] shall document personnel security requirements for external providers in their contracts or agreements. (PS-7c)
- The [Chief Information Security Officer] shall require external providers to notify [Fill in: personnel or roles to be notified of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges or who have system privileges. Typical: the organization's contract manager for the provider, and the account managers of the systems the individual has access to] within [Fill in: time period within which third-party providers are required to notify organization-defined personnel or roles of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges or who have system privileges. Typical: 24 hours] of any transfer or termination of their personnel who hold organizational credentials or badges, or who have system privileges. (PS-7d)
- The [Chief Information Security Officer] shall monitor external provider compliance with personnel security requirements. (PS-7e)

#### Personnel sanctions (PS-8)

> **Guidance:** Sanctions are usually part of the general human resources disciplinary process; this policy makes security and privacy violations subject to it and names who is told. Describe the sanctions in the access agreement and the rules of behavior so people know them before they sign. NIST advises consulting legal counsel on sanctions matters.

- The [Human resources office] shall employ a formal sanctions process for individuals who fail to comply with the organization's information security and privacy policies and procedures. (PS-8a)
- The [Human resources office] shall notify [Fill in: personnel or roles to be notified when a formal employee sanctions process is initiated. Typical: the Chief Information Security Officer, and the senior privacy official when the violation concerns privacy] within [Fill in: the time period within which organization-defined personnel or roles must be notified when a formal employee sanctions process is initiated. Typical: 2 business days] when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction. (PS-8b)

#### Position descriptions (PS-9)

> **Guidance:** Every position description should carry the general duties all users have, such as following the rules of behavior and reporting incidents. Positions with security or privacy roles, such as system administrators, system security officers and privacy officers, need those roles written in, which also tells the training plan who needs role-based training (AT-3).

- The [Human resources office] shall incorporate security and privacy roles and responsibilities into organizational position descriptions. (PS-9)

### Risk Assessment (RA)

#### Security categorization (RA-2)

> **Guidance:** Categorization rates how badly a loss of confidentiality, integrity or availability of the system and its information would hurt the organization, and it drives the choice of baseline (PL-10). Work it out with the [Security Categorization Worksheet](https://kston83.github.io/nist-guide/templates/forms/security-categorization-worksheet/) and record the result in the categorization section of the [System Security Plan template](https://kston83.github.io/nist-guide/templates/plans/system-security-plan/).

- Each [System owner] shall categorize the system and the information it processes, stores and transmits. (RA-2a)
- The [System owner] shall document the categorization results, with the supporting rationale, in the system security plan. (RA-2b)
- The [System owner] shall have the authorizing official, or a designated representative, review and approve the categorization decision. (RA-2c)
- The [System owner] shall review the categorization whenever the system, the information it handles or its environment of operation changes significantly. (RA-2a)

##### Federal systems

Federal systems categorize information and systems under [FIPS 199](https://csrc.nist.gov/pubs/fips/199/final), Standards for Security Categorization of Federal Information and Information Systems (February 2004), and identify information types from [NIST SP 800-60 Rev. 1](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final) (August 2008; Volume 2 lists the types). A [Rev. 2 initial working draft](https://csrc.nist.gov/pubs/sp/800/60/r2/iwd) (January 2024) is not final, as of September 2026.

- The [System owner] shall identify the system's information types using NIST SP 800-60. (RA-2a)
- The [System owner] shall categorize the system under FIPS 199, using the highest impact level of its information types for each security objective. (RA-2a)

#### Risk assessment (RA-3)

> **Guidance:** A system risk assessment identifies threats and vulnerabilities, then estimates the likelihood and impact of harm, to the organization and, where the system processes personally identifiable information, to individuals. Use the method and scales the risk management strategy sets (PM-9, PM-28), so results from different systems can be compared. NIST SP 800-30 Rev. 1 is the usual reference for the method. Start from the [Risk Assessment Report template](https://kston83.github.io/nist-guide/templates/reports/risk-assessment-report/) and record each risk in the [risk register](https://kston83.github.io/nist-guide/templates/forms/risk-register/). Risks found here feed the plan of action and milestones (CA-5) and the risk response (RA-7).

- Each [System owner] shall conduct a risk assessment of the system that identifies threats to and vulnerabilities in the system. (RA-3a.1)
- The risk assessment shall determine the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification or destruction of the system, the information it processes, stores or transmits, and any related information. (RA-3a.2)
- For a system that processes personally identifiable information, the risk assessment shall determine the likelihood and impact of adverse effects on individuals arising from that processing. (RA-3a.3)
- The [System owner] shall integrate the organization's risk management strategy, risk framing and mission or business process risk decisions into the system risk assessment. (RA-3b)
- The [System owner] shall document the risk assessment results in the [Select one: security and privacy plans; risk assessment report; [Assignment: organization-defined document]. Typical: risk assessment report]. (RA-3c)
- The [System owner] shall review the risk assessment results [Fill in: the frequency to review risk assessment results. Typical: annually]. (RA-3d)
- The [System owner] shall share the risk assessment results with [Fill in: personnel or roles to whom risk assessment results are to be disseminated. Typical: the authorizing official, the system owner and the Chief Information Security Officer]. (RA-3e)
- The [System owner] shall update the risk assessment [Fill in: the frequency to update the risk assessment. Typical: at least every three years], and whenever there are significant changes to the system, its environment of operation, or other conditions that may affect its security or privacy state. (RA-3f)

#### Supply chain risk assessment (RA-3(1))

> **Guidance:** The supply chain risk assessment looks at the suppliers, products and services a system depends on: where they come from, how they are built and delivered, and what happens if one fails or is compromised. It applies the organization's supply chain risk management strategy (PM-30) and plan (SR-2) to the system.

- The [System owner] shall assess the supply chain risks associated with [Fill in: systems, system components, and system services to assess supply chain risks. Typical: each system, the components and services the criticality analysis (RA-9) identifies as critical, and the external services the system depends on]. (RA-3(1)(a))
- The [System owner] shall update the supply chain risk assessment [Fill in: the frequency at which to update the supply chain risk assessment. Typical: annually], when there are significant changes to the relevant supply chain, and when changes to the system, its environment of operation or other conditions call for it. (RA-3(1)(b))

#### Vulnerability monitoring and scanning (RA-5)

> **Guidance:** Monitoring means watching for newly announced vulnerabilities that affect the system's components; scanning means testing the components themselves. Set remediation times by risk, and move known exploited vulnerabilities to the front. A vulnerability not fixed in time becomes a plan of action and milestones item (CA-5) or an approved risk acceptance (RA-7). Standards for naming and scoring vulnerabilities include CVE, CPE and CVSS. The [Vulnerability Management Standard](https://kston83.github.io/nist-guide/templates/standards/vulnerability-management-standard/) sets the coverage, frequencies and remediation times in detail.

- Each [System owner] shall ensure the system and its hosted applications are monitored for vulnerabilities [Fill in: frequency for monitoring systems and hosted applications for vulnerabilities. Typical: continuously, through vendor advisories, vulnerability feeds and the CISA Known Exploited Vulnerabilities Catalog]. (RA-5a)
- The [System owner] shall ensure the system and its hosted applications are scanned for vulnerabilities [Fill in: frequency for scanning systems and hosted applications for vulnerabilities. Typical: at least monthly for infrastructure, and before each major release for applications], and when new vulnerabilities potentially affecting the system are identified and reported. (RA-5a)
- The [Chief Information Security Officer] shall provide vulnerability monitoring tools that use standards for enumerating platforms, software flaws and improper configurations, for formatting checklists and test procedures, and for measuring vulnerability impact. (RA-5b)
- The [Chief Information Security Officer] shall provide vulnerability monitoring tools that can readily update the vulnerabilities to be scanned. (RA-5f)
- The [System owner] shall analyze vulnerability scan reports and the results of vulnerability monitoring, and record any finding judged a false positive with the reason. (RA-5c)
- The [System owner] shall remediate legitimate vulnerabilities within [Fill in: response times to remediate legitimate vulnerabilities in accordance with an organizational assessment of risk. Typical: known exploited: as soon as possible, within days; critical and high: 30 days; moderate: 90 days; low: 180 days], in accordance with an organizational assessment of risk. (RA-5d)
- The [System owner] shall share information obtained from vulnerability monitoring and control assessments with [Fill in: personnel or roles with whom information obtained from the vulnerability scanning process and control assessments is to be shared. Typical: the owners of similar systems and the security operations team], to help eliminate similar vulnerabilities in other systems. (RA-5e)

##### Federal systems

CISA binding operational directives set minimums for federal civilian agencies (as of September 2026). [BOD 26-04](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk), Prioritizing Security Updates Based on Risk (June 10, 2026), sets remediation deadlines by exposure, KEV status, whether exploitation can be automated, and technical impact; its clock starts when CISA adds a vulnerability to the KEV catalog or the agency identifies it, whichever is first. [BOD 23-01](https://www.cisa.gov/news-events/directives/bod-23-01-improving-asset-visibility-and-vulnerability-detection-federal-networks), Improving Asset Visibility and Vulnerability Detection on Federal Networks (October 3, 2022), requires automated asset discovery every 7 days and vulnerability enumeration across discovered assets every 14 days.

- The [System owner] shall remediate vulnerabilities no later than the deadlines CISA BOD 26-04 sets. (RA-5d)
- The [System owner] shall ensure the system's assets are covered by automated asset discovery at least every 7 days and by vulnerability enumeration at least every 14 days, as CISA BOD 23-01 requires. (RA-5a)

#### Update vulnerabilities to be scanned (RA-5(2))

- The [System owner] shall ensure the vulnerabilities the scanning tools check for are updated [Select one or more: [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported. Typical: prior to a new scan]. (RA-5(2))

#### Discoverable information (RA-5(4))

> **Guidance:** Discoverable information is what an outsider can learn about the system without authorized access: banners and version strings, public DNS and certificate records, code repositories, job postings and documents on public sites. Check it the way an attacker would, as part of scanning or a penetration test.

- The [System owner] shall determine what information about the system is discoverable. (RA-5(4))
- The [System owner] shall take the following corrective actions for discoverable information: [Fill in: corrective actions to be taken if information about the system is discoverable. Typical: removing or restricting the information where possible, and treating any that exposes a weakness as a finding for the plan of action and milestones]. (RA-5(4))

#### Privileged access (RA-5(5))

> **Guidance:** Scans that log in find far more missing patches and weak settings than scans that only probe from the network. The scanning accounts are privileged accounts, so manage them under AC-2 and AC-6 like any other.

- The [System owner] shall authorize privileged access to [Fill in: system components to which privileged access is authorized for selected vulnerability scanning activities. Typical: operating systems, databases and web applications] for [Fill in: vulnerability scanning activities selected for privileged access authorization to system components. Typical: credentialed (authenticated) vulnerability scans]. (RA-5(5))

#### Public disclosure program (RA-5(11))

> **Guidance:** A public reporting channel lets researchers and others tell the organization about vulnerabilities they find. It is usually a published vulnerability disclosure policy that says which systems are in scope, how to report, what the organization will do with a report, and that good-faith research is authorized.

- The [Chief Information Security Officer] shall establish a public reporting channel for receiving reports of vulnerabilities in organizational systems and system components. (RA-5(11))
- The [Chief Information Security Officer] shall publish how to use the reporting channel and which systems it covers. (RA-5(11))
- The [Security operations team] shall acknowledge, analyze and track each report received through the channel. (RA-5(11))

##### Federal systems

[CISA BOD 20-01](https://www.cisa.gov/news-events/directives/bod-20-01-develop-and-publish-vulnerability-disclosure-policy), Develop and Publish a Vulnerability Disclosure Policy (September 2, 2020), requires federal civilian agencies to publish a vulnerability disclosure policy (in effect as of September 2026).

- The [Chief Information Security Officer] shall publish and maintain a vulnerability disclosure policy that meets CISA BOD 20-01. (RA-5(11))

#### Risk response (RA-7)

> **Guidance:** Every finding from an assessment, monitoring or audit needs a decision: fix it, avoid it, share or transfer it, or accept it. The risk management strategy sets the organization's risk tolerance and the roles the authorizing official consults before accepting risk at each level (PM-9, PM-28). Fixes that take time go in the plan of action and milestones (CA-5); every response, including acceptance, goes in the [risk register](https://kston83.github.io/nist-guide/templates/forms/risk-register/).

- Each [System owner] shall respond to findings from security and privacy assessments, monitoring and audits in accordance with the organizational risk tolerance set in the risk management strategy. (RA-7)
- The [System owner] shall record each response as a remediation, a plan of action and milestones item, or a risk acceptance. (RA-7)
- A risk to an authorized system shall be accepted only by its authorizing official, after consulting the roles the risk management strategy names for that risk level. (RA-7)

#### Criticality analysis (RA-9)

> **Guidance:** A criticality analysis finds the components and functions whose failure or compromise would stop the system's mission or business functions. The results focus supply chain protections (RA-3(1), SR family) and engineering effort on what matters most.

- The [System owner] shall identify critical system components and functions by performing a criticality analysis for [Fill in: systems, system components, or system services to be analyzed for criticality. Typical: each Moderate and High system, and the components and services that support its critical functions] at [Fill in: decision points in the system development life cycle when a criticality analysis is to be performed. Typical: during design, before acquiring major components or services, and when the architecture changes significantly]. (RA-9)

### System and Services Acquisition (SA)

#### Allocation of resources (SA-2)

> **Guidance:** SA-2 makes security and privacy part of the business case for each system, not a cost found later. NIST's SA-2 discussion includes funding for acquisition, sustainment and supply chain risk across the whole life cycle. Evidence is the requirements in the planning documents and a separate security and privacy line in the budget request; the organization-wide side of this is PM-3.

- The [System owner] shall determine the high-level information security and privacy requirements for the system or system service during mission and business process planning, before an acquisition or development begins. (SA-2a)
- The [System owner] shall determine and document the resources required to protect the system or system service, including acquisition, sustainment and supply chain risk management costs across the system development life cycle, as part of the organization's capital planning and investment control process. (SA-2b)
- The [Senior leader] shall allocate the documented resources through the capital planning and investment control process, and record the reason for any shortfall. (SA-2b)
- The [Chief Information Security Officer] and the [Senior privacy official] shall ensure a discrete line item for information security and a discrete line item for privacy are established in the organization's programming and budgeting documentation for the system. (SA-2c)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.b(1) to (3), requires agencies to identify and plan for the resources needed to implement information security and privacy programs; to ensure that security and privacy are addressed throughout the life cycle of each agency information system, with security and privacy activities and costs identified and included in IT investment capital plans and budgetary requests; and to plan and budget to upgrade, replace or retire any system for which protections commensurate with risk cannot be effectively implemented. Section 4.e(6) requires the Senior Agency Official for Privacy to review IT capital investment plans and budgetary requests so that privacy requirements, and their costs, are explicitly identified and included. As of September 2026.

- The [System owner] shall identify the system's security and privacy activities and costs in its IT investment capital plan and budgetary requests, as OMB Circular A-130, Appendix I, section 4.b(2), requires. (SA-2b)
- For a system that processes personally identifiable information, the [Senior privacy official] shall review the system's IT capital investment plan and budgetary requests to confirm that privacy requirements and their costs are explicitly identified and included, as OMB Circular A-130, Appendix I, section 4.e(6), requires. (SA-2c)

#### System development life cycle (SA-3)

> **Guidance:** The system development life cycle (SDLC) is where the Risk Management Framework's tasks happen: NIST SP 800-37 Rev. 2 ([December 2018](https://csrc.nist.gov/pubs/sp/800/37/r2/final), current as of September 2026) ties each RMF task to an SDLC phase, using the phase names in the typical value. NIST's SA-3 discussion calls for qualified security and privacy staff in SDLC processes and role-based training for them (AT-3). SA-3 leaves the life cycle model to the organization, iterative or sequential; what an assessor checks is that each phase has defined security and privacy activities and someone accountable for them.

- The [System owner] shall acquire, develop and manage the system using [Fill in: system development life cycle. Typical: the organization's documented system development life cycle, with security and privacy activities and a review gate in each phase: initiation, development or acquisition, implementation and assessment, operations and maintenance, and disposal] that incorporates information security and privacy considerations. (SA-3a)
- The [Chief Information Security Officer] and the [Senior privacy official] shall define and document the information security and privacy roles and responsibilities for each phase of the system development life cycle. (SA-3b)
- The [System owner] shall identify, in the system security plan, the individuals who hold information security and privacy roles and responsibilities for the system. (SA-3c)
- The [System owner] shall integrate the organization's information security and privacy risk management process into the system development life cycle, so that categorization, control selection, implementation, assessment, authorization and monitoring take place in the phases the risk management process assigns them to. (SA-3d)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.b(2), requires agencies to ensure that information security and privacy are addressed throughout the life cycle of each agency information system. As of September 2026.

- The [System owner] shall ensure information security and privacy are addressed in every phase of the system's life cycle, from planning and acquisition through operation, maintenance and disposal, as OMB Circular A-130, Appendix I, section 4.b(2), requires. (SA-3a)

#### Acquisition process (SA-4)

> **Guidance:** SA-4 puts the security and privacy requirements into the contract, where a supplier is bound by them. NIST's SA-4 discussion derives the functional requirements from the high-level requirements set under SA-2, and points to NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems ([November 2022](https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final), current as of September 2026), for requirements engineering. Standard clauses keep contracts consistent; each acquisition still needs its own requirements, controls and acceptance criteria. Assessors sample recent contracts for a system and check each item a to i is present, in the text or by reference. The [acquisition security requirements](https://kston83.github.io/nist-guide/templates/standards/acquisition-security-requirements/) standard gives the standard contract requirements and the checklist for the solicitation review.

- The [System owner] shall include the following requirements, descriptions and criteria, explicitly or by reference, using [Select one or more: standardized contract language; [Assignment: organization-defined contract language]. Typical: standardized contract language that the procurement office maintains and the Chief Information Security Officer and senior privacy official approve, with system-specific requirements added for each acquisition], in the acquisition contract for each system, system component or system service. (SA-4)
- The contract shall state the security and privacy functional requirements. (SA-4a)
- The contract shall state the strength of mechanism requirements, such as resistance to tampering, bypass and direct attack. (SA-4b)
- The contract shall state the security and privacy assurance requirements, including the development processes and the evidence from development and assessment that the supplier provides. (SA-4c)
- The contract shall state the controls needed to satisfy the security and privacy requirements, with any control parameter values the supplier must meet. (SA-4d)
- The contract shall state the security and privacy documentation requirements (SA-5). (SA-4e)
- The contract shall state the requirements for protecting security and privacy documentation. (SA-4f)
- The contract shall describe the system development environment and the environment in which the system is intended to operate. (SA-4g)
- The contract shall allocate responsibility for, or identify the parties responsible for, information security, privacy and supply chain risk management. (SA-4h)
- The contract shall state the acceptance criteria for the system, component or service. (SA-4i)
- The [Chief Information Security Officer] shall review each solicitation for a system, system component or system service for these requirements before it is issued, and the [Senior privacy official] shall review each one for a system that processes personally identifiable information. (SA-4)

> **Guidance:** NIST's SA-4 discussion also suggests other requirements that support security and operations: the responsibilities of the organization and the developer, and notice and timing for support, maintenance and updates. Add the time within which a supplier must report an incident or a vulnerability in its product, and how long it will provide security updates, since both drive IR-6 and SA-22.

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.j(1), requires agencies to ensure that the terms and conditions of contracts and other agreements involving Federal information incorporate security and privacy requirements sufficient to meet Federal and agency-specific requirements for its protection; section 4.j(5) requires them to include provisions for Federal Government notification and access, and for cooperation with agency personnel and Inspectors General. [OMB M-26-05](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf), Adopting a Risk-based Approach to Software and Hardware Security (January 23, 2026), rescinds M-22-18 and M-23-16, so agencies are no longer required to collect the Secure Software Development Attestation Form. It requires agencies to develop software and hardware assurance policies and processes that match their risk determinations, and lets them use the attestation form, and contract terms requiring a current software bill of materials on request, where they choose to. As of September 2026.

- The [System owner] shall ensure each contract or agreement involving Federal information incorporates the security and privacy requirements that apply to that information, and provisions for Federal Government notification and access and for cooperation with agency personnel and the Inspector General, as OMB Circular A-130, Appendix I, sections 4.j(1) and 4.j(5), require. (SA-4)
- The [Chief Information Security Officer] shall decide, for each acquisition of software or hardware and based on a risk assessment, whether to require a secure software development attestation or a software bill of materials, following the agency's assurance policy under OMB M-26-05. (SA-4c)

<!-- TODO(verify): FAR contract requirements for IT security. The FAR as codified on acquisition.gov (FAC 2026-01, effective March 13, 2026) has 39.101(c), requiring agencies to include the appropriate information technology security policies and requirements, including use of common security configurations from NIST, in IT acquisitions, and the 52.239-1 clause at 39.106. Many agencies (for example GSA, Treasury, DOL and HUD) have issued Revolutionary FAR Overhaul class deviations for Part 39, and whether the deviation text keeps these requirements was not confirmed on 2026-09-29. Cite the FAR here once it is clear which text governs. -->

#### Functional properties of controls (SA-4(1))

> **Guidance:** Functional properties are what a control does as seen at its interfaces: the security or privacy functions a user, administrator or other component can call on, not how the control works inside. NIST's SA-4(1) discussion excludes internal functions and data structures. The description lets the system owner check that each control the contract requires is actually delivered, and gives assessors something to test against.

- The [System owner] shall require the developer of the system, system component or system service, in the acquisition contract, to provide a description of the functional properties of the controls to be implemented. (SA-4(1))
- The [System owner] shall accept the description only when it covers every control the contract allocates to the developer. (SA-4(1))

#### Design and implementation information for controls (SA-4(2))

> **Guidance:** NIST's SA-4(2) discussion describes the levels: high-level design is expressed in subsystems and the interfaces between them, low-level design in modules, and source code or hardware schematics are the implementation itself. Most commercial products provide interface and high-level design information only; ask for more where the system's risk warrants it, and say so in the solicitation. The discussion adds that the information can include the manufacturer, version, serial number, verification hash, software libraries used, and the date and source of purchase or download.

- The [System owner] shall require the developer of the system, system component or system service, in the acquisition contract, to provide design and implementation information for the controls that includes [Select one or more: security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design and implementation information]. Typical: security-relevant external system interfaces and high-level design, and for High systems also low-level design] at [Fill in: level of detail. Typical: enough detail to show, for each subsystem and interface, which controls it implements and how]. (SA-4(2))
- The [System owner] shall protect the design and implementation information according to the system's security category, as the contract's documentation protection requirements set (SA-4f). (SA-4(2))

#### System, component and service configurations (SA-4(5))

> **Guidance:** Delivering secure configurations saves hardening each component after it arrives, and keeps reinstallation from quietly restoring insecure defaults. NIST's SA-4(5) discussion gives as examples the U.S. Government Configuration Baseline (USGCB), Security Technical Implementation Guides (STIGs), limits on functions, ports, protocols and services, and changed default passwords. Use the same baselines as configuration settings (CM-6), so delivered components pass the same checks as the rest of the system.

- The [System owner] shall require the developer of the system, system component or system service to deliver it with [Fill in: security configurations for the system, component, or service. Typical: the secure configuration baselines named in the baseline configuration standard for that type of component, with default passwords changed and the functions, ports, protocols and services not needed disabled] implemented. (SA-4(5)(a))
- The [System owner] shall require the developer to use those configurations as the default for any later reinstallation or upgrade of the system, component or service. (SA-4(5)(b))

#### Functions, ports, protocols and services in use (SA-4(9))

> **Guidance:** Knowing the functions, ports, protocols and services a product needs before it is bought lets the organization refuse risky ones early, instead of retrofitting controls later, as NIST's SA-4(9) discussion notes. The developer's list becomes the starting point for least functionality (CM-7) and for boundary protection rules (SC-7). For external services the matching requirement is SA-9(2).

- The [System owner] shall require the developer of the system, system component or system service to identify, early in the system development life cycle, the functions, ports, protocols and services intended for organizational use. (SA-4(9))
- The [System owner] shall review the list against the organization's prohibited and restricted functions, ports, protocols and services (CM-7) before the design or product is accepted, and record it in the system security plan. (SA-4(9))

#### Use of approved PIV products (SA-4(10))

> **Guidance:** Personal Identity Verification (PIV) is the U.S. federal smart card credential, and the FIPS 201 Approved Products List names the products tested against its standard. An organization outside the federal government meets this enhancement where it implements PIV or PIV-interoperable capability; if the system implements none, record the enhancement as not applicable in the system security plan with that reason, as for IA-2(12).

- Where the system implements Personal Identity Verification (PIV) capability, the [System owner] shall employ only information technology products on the FIPS 201-approved products list for that capability. (SA-4(10))
- The [System owner] shall record the approved products list entry for each PIV product in the system's component inventory, and replace a product that is moved to the removed products list. (SA-4(10))

##### Federal systems

[FIPS 201-3](https://csrc.nist.gov/pubs/fips/201-3/final), Personal Identity Verification (PIV) of Federal Employees and Contractors (January 2022), states in its preamble (item 7) that FIPS 201 compliance of PIV components and subsystems is provided through products and services from the General Services Administration's approved products and services list, and in Appendix A.5 that products evaluated and approved under GSA's FIPS 201 Evaluation Program are placed on the [FIPS 201 Approved Products List](https://www.idmanagement.gov/fips201/) to promote the procurement of conformant products by agencies. As of September 2026.

- The [System owner] shall acquire PIV card products, readers and physical access control system products for the system only from the FIPS 201 Approved Products List that GSA maintains. (SA-4(10))

<!-- TODO(verify): FAR 4.1302(a) as codified on acquisition.gov (FAC 2026-01, effective March 13, 2026) reads "In order to comply with FIPS PUB 201, agencies must purchase only approved personal identity verification products and services." Confirm whether the Revolutionary FAR Overhaul deviation text for Part 4 keeps this before citing it here. -->

#### System documentation (SA-5)

> **Guidance:** Administrator and user documentation is how the people who run and use a system learn to operate its security and privacy functions correctly. NIST's SA-5 discussion names system owners, system security officers and system administrators as the people who need it, and says the organization may need to recreate documentation it cannot obtain when that documentation is essential to operating the controls. Protect documentation that describes vulnerabilities more strictly than the rest.

- The [System owner] shall obtain or develop administrator documentation for the system, system component or system service that describes its secure configuration, installation and operation. (SA-5a.1)
- The administrator documentation shall describe the effective use and maintenance of the security and privacy functions and mechanisms. (SA-5a.2)
- The administrator documentation shall describe known vulnerabilities regarding the configuration and use of administrative or privileged functions. (SA-5a.3)
- The [System owner] shall obtain or develop user documentation that describes the user-accessible security and privacy functions and mechanisms, and how to use them effectively. (SA-5b.1)
- The user documentation shall describe methods of user interaction that let individuals use the system, component or service more securely and protect individual privacy. (SA-5b.2)
- The user documentation shall describe users' responsibilities for maintaining the security of the system, component or service and the privacy of individuals. (SA-5b.3)
- When documentation is unavailable or does not exist, the [System owner] shall document the attempts made to obtain it and [Fill in: actions to take when system, system component, or system service documentation is either unavailable or nonexistent. Typical: ask the manufacturer or supplier again and search its published material; where the documentation is essential to operating a control, write it in-house; and record any remaining gap as a risk in the risk register]. (SA-5c)
- The [System owner] shall distribute the documentation to [Fill in: personnel or roles to distribute system documentation to. Typical: the system owner, the system security officer and the system administrators]. (SA-5d)
- The [System owner] shall protect the documentation according to the system's security category, restricting documentation that describes vulnerabilities to those who need it. (SA-5)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.i(6), requires agencies to protect administrator, user and system documentation related to the design, development, testing, operation, maintenance and security of the hardware, firmware and software components of information systems. As of September 2026.

- The [System owner] shall protect the administrator, user and system documentation for the system's hardware, firmware and software components, as OMB Circular A-130, Appendix I, section 4.i(6), requires. (SA-5)

#### Security and privacy engineering principles (SA-8)

> **Guidance:** NIST's SA-8 discussion lists examples of engineering principles: layered protections, security and privacy requirements built into the life cycle, clear physical and logical boundaries, developers trained to build secure software, and threat modeling. NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems ([November 2022](https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final), current as of September 2026), describes 30 design principles in Appendix E, and says they are a basis for reasoning about a design, not rules to be complied with. For privacy, NIST IR 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems ([January 2017](https://csrc.nist.gov/pubs/ir/8062/final), current as of September 2026), sets out three privacy engineering objectives.

- The [System owner] shall apply the following systems security and privacy engineering principles in the specification, design, development, implementation and modification of the system and system components: [Fill in: systems security and privacy engineering principles. Typical: for security, the principles for trustworthy secure design in NIST SP 800-160 Vol. 1 Rev. 1, Appendix E, that the system's security architecture selects; for privacy, the objectives of predictability, manageability and disassociability from NIST IR 8062, and minimization (SA-8(33))]. (SA-8)
- The [System owner] shall record in the security and privacy architectures (PL-8) the principles applied to the system, and the reason for any principle not applied. (SA-8)
- For an existing system, the [System owner] shall apply the principles to upgrades and modifications to the extent feasible, given the current state of its hardware, software and firmware. (SA-8)

#### External system services (SA-9)

> **Guidance:** External system services are cloud platforms, software as a service, hosting, managed security and other services the system relies on but does not run. NIST's SA-9 discussion keeps the responsibility for their risk with the authorizing official, and has the organization document the basis of its trust in each provider so the relationship can be monitored. A shared responsibility matrix for each service, recorded in the system security plan as inherited, shared or system-owned controls, shows who does what. The [information exchange agreement](https://kston83.github.io/nist-guide/templates/forms/information-exchange-agreement/) (CA-3) covers the connection; this clause covers the provider. The [external service review](https://kston83.github.io/nist-guide/templates/forms/external-service-review/) records the review of each service before use and at each annual review, with a register of every external service.

- The [System owner] shall require that providers of external system services comply with the organization's security and privacy requirements and employ [Fill in: controls to be employed by external system service providers. Typical: the controls of the system's baseline that the provider is responsible for, per the shared responsibility matrix, with evidence from an independent attestation]. (SA-9a)
- The [System owner] shall record those requirements in the contract or service agreement before the service is used. (SA-9a)
- The [System owner] shall define and document the organization's oversight roles and responsibilities, and the user roles and responsibilities, for each external system service, including a shared responsibility matrix. (SA-9b)
- The [System owner] shall employ [Fill in: processes, methods, and techniques employed to monitor control compliance by external service providers. Typical: annual review of independent attestation reports, review of the provider's continuous monitoring or status reports, and contract service reviews] to monitor the provider's control compliance on an ongoing basis. (SA-9c)
- The [System owner] shall follow up each exception in a provider's attestation report, and each customer control the report expects the organization to operate, and record weaknesses that affect the system in its plan of action and milestones (CA-5). (SA-9c)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.j(2)(a) and (b), requires agencies to provide oversight of information systems used or operated by contractors or other entities on behalf of the Federal Government, including documented oversight policies and procedures and ensuring that the security and privacy controls of those systems and services are effectively implemented and comply with NIST standards and guidelines and agency requirements. Under [OMB M-24-15](https://www.fedramp.gov/2026/authority/m-24-15/), Modernizing the Federal Risk and Authorization Management Program (July 25, 2024), agencies must obtain and maintain a FedRAMP authorization for cloud products and services that create, collect, process, store or maintain federal information on the agency's behalf, unless the memo places them out of scope. As of September 2026.

- The [System owner] shall ensure each cloud product or service within the scope of OMB M-24-15 has a FedRAMP authorization before it processes federal information, and that the agency issues its own authorization to use it. (SA-9a)
- The [System owner] shall document the agency's oversight of each system a contractor or other entity operates on its behalf, and verify that its controls are effectively implemented, as OMB Circular A-130, Appendix I, section 4.j(2), requires. (SA-9c)

#### Identification of functions, ports, protocols and services (SA-9(2))

> **Guidance:** A provider's list of the functions, ports, protocols and services its service needs lets the organization weigh the trade-offs of blocking or restricting them, as NIST's SA-9(2) discussion notes. Use the list to set the boundary protection rules for the connection (SC-7) and to spot anything the service needs that the organization prohibits (CM-7).

- The [System owner] shall require providers of [Fill in: external system services that require the identification of functions, ports, protocols, and other services. Typical: all external system services that connect to the system] to identify the functions, ports, protocols and other services required for the use of those services. (SA-9(2))
- The [System owner] shall record each provider's list with the service in the system security plan, and update it when the provider changes the service. (SA-9(2))

#### Developer configuration management (SA-10)

> **Guidance:** SA-10 applies configuration management to the developer, whether an outside supplier or an in-house team. NIST's SA-10 discussion treats the quality of the developer's configuration management as direct evidence that the controls work, and lists the configuration items to protect: design specifications, source code and hardware schematics, the running object code, comparison tools, and test fixtures and documentation. NIST's Secure Software Development Framework, SP 800-218 ([February 2022](https://csrc.nist.gov/pubs/sp/800/218/final), version 1.1; version 1.2 is a December 2025 draft; as of September 2026), cites SA-10 for practice PS.1, protecting all forms of code from unauthorized access and tampering.

- The [System owner] shall require the developer of the system, system component or system service to perform configuration management during [Select one or more: design; development; implementation; operation; disposal. Typical: design, development, implementation and operation]. (SA-10a)
- The [System owner] shall require the developer to document, manage and control the integrity of changes to [Fill in: configuration items under configuration management. Typical: design specifications, source code, build scripts and pipeline configuration, infrastructure and configuration as code, test scripts and results, and each released executable]. (SA-10b)
- The [System owner] shall require the developer to implement only organization-approved changes to the system, component or service. (SA-10c)
- The [System owner] shall require the developer to document approved changes and their potential security and privacy impacts. (SA-10d)
- The [System owner] shall require the developer to track security flaws and flaw resolution within the system, component or service, and report findings to [Fill in: personnel to whom security flaws and flaw resolutions within the system, component, or service are reported. Typical: the system owner and the Chief Information Security Officer]. (SA-10e)
- The [System owner] shall ensure developer changes to an operational system go through the system's configuration change control (CM-3). (SA-10c)

#### Developer testing and evaluation (SA-11)

> **Guidance:** Developer testing finds flaws before the system reaches the assessor or the adversary. NIST's SA-11 discussion names the approaches: manual code review, security architecture review, penetration testing, and static, dynamic and binary analysis, with instrumentation and fuzzing. It defines depth as the rigor and detail of testing and coverage as the number and type of artifacts tested, and has contracts set acceptance criteria for the plans, the flaw remediation process and the evidence. NIST's Secure Software Development Framework, SP 800-218 ([February 2022](https://csrc.nist.gov/pubs/sp/800/218/final), version 1.1; as of September 2026), cites SA-11 for practices PW.7, reviewing and analyzing human-readable code, and PW.8, testing executable code.

- The [System owner] shall require the developer of the system, system component or system service, at all post-design stages of the system development life cycle, to develop and implement a plan for ongoing security and privacy control assessments. (SA-11a)
- The [System owner] shall require the developer to perform [Select one or more: unit; integration; system; regression. Typical: unit, integration, system and regression] testing and evaluation [Fill in: frequency at which to conduct the selected unit, integration, system or regression testing/evaluation. Typical: with each build for automated tests, and before each release to production for system and regression testing] at [Fill in: depth and coverage of the selected unit, integration, system or regression testing/evaluation. Typical: static analysis of all custom code, analysis of third-party and open-source components for known vulnerabilities, dynamic testing of every externally reachable interface, and a test for each security and privacy requirement]. (SA-11b)
- The [System owner] shall require the developer to produce evidence of the execution of the assessment plan and of the results of the testing and evaluation. (SA-11c)
- The [System owner] shall require the developer to implement a verifiable flaw remediation process. (SA-11d)
- The [System owner] shall require the developer to correct flaws identified during testing and evaluation, and shall not accept a release with an unresolved flaw unless the risk is accepted (RA-7). (SA-11e)
- For a system that processes personally identifiable information, the [System owner] shall ensure the developer's tests use test data prepared under SI-12(2), not live personally identifiable information, unless the [Senior privacy official] approves otherwise. (SA-11b)

#### Development process, standards and tools (SA-15)

> **Guidance:** SA-15 asks for a development process that is written down, addresses security and privacy, and keeps its own tools under control, since a compromised build tool compromises everything it builds. NIST's SA-15 discussion says reviews of the process can use maturity models, and that controlling changes to tools supports supply chain risk management. NIST's Secure Software Development Framework, SP 800-218 ([February 2022](https://csrc.nist.gov/pubs/sp/800/218/final), version 1.1; version 1.2 is a December 2025 draft; as of September 2026), cites SA-15 for its Prepare the Organization practices, including PO.1, defining security requirements for software development, and PO.3, implementing supporting toolchains. The organization's own secure development policy and standard, based on the SSDF, are Phase 4 templates.

- The [System owner] shall require the developer of the system, system component or system service to follow a documented development process that explicitly addresses security and privacy requirements. (SA-15a.1)
- The documented process shall identify the standards and tools used in the development process. (SA-15a.2)
- The documented process shall document the specific tool options and tool configurations used in the development process. (SA-15a.3)
- The documented process shall document, manage and ensure the integrity of changes to the process and the tools used in development. (SA-15a.4)
- The [System owner] shall review the development process, standards, tools, tool options and tool configurations [Fill in: frequency at which to review the development process, standards, tools, tool options, and tool configurations. Typical: at least annually, and before a new development tool or a major change to the development process is adopted] to determine whether they can satisfy [Fill in: security and privacy requirements. Typical: the security requirements in the acquisition contract (SA-4) and the organization's secure software development practices, and the privacy requirements recorded in the system's privacy impact assessment]. (SA-15b)
- The [System owner] shall record each review's findings, and track any shortfall to correction in the plan of action and milestones. (SA-15b)

##### Federal systems

[OMB M-26-05](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf), Adopting a Risk-based Approach to Software and Hardware Security (January 23, 2026), rescinds OMB M-22-18 and M-23-16. It states that each agency should validate provider security using secure development principles and a comprehensive risk assessment, requires agencies to develop software and hardware assurance policies and processes that match their risk determinations and mission needs, and names NIST SP 800-218 as a reference. As of September 2026.

- The [Chief Information Security Officer] shall base the security requirements used under SA-15b on the agency's software and hardware assurance policy under OMB M-26-05, and on a risk assessment of the system. (SA-15b)

#### Criticality analysis (SA-15(3))

> **Guidance:** The developer's criticality analysis feeds the organization's own (RA-9), which often cannot see inside commercial products. NIST's SA-15(3) discussion says developer input is especially important for supply chain criticality analyses and for systems designated as high value assets. The decision points here match those in the RA-9 clause, so both analyses are updated together.

- The [System owner] shall require the developer of the system, system component or system service to perform a criticality analysis at [Fill in: decision points in the system development life cycle. Typical: during design, before acquiring major components or services, and when the architecture changes significantly]. (SA-15(3)(a))
- The [System owner] shall require the developer's criticality analysis to cover the following breadth and depth: [Fill in: breadth and depth of criticality analysis. Typical: the components and functions that support the system's critical functions, including third-party and open-source components, analyzed down to the component and software module level and naming the supplier of each critical component]. (SA-15(3)(b))
- The [System owner] shall use the developer's results in the organization's criticality analysis (RA-9). (SA-15(3))

#### Developer-provided training (SA-16)

> **Guidance:** Controls work only if the people who operate them know how. NIST's SA-16 discussion applies this to both external and in-house developers, lists web-based, classroom and hands-on training, and notes that the organization can instead ask for training materials to run its own. Record completions in the training records (AT-4) with the rest of role-based training.

- The [System owner] shall require the developer of the system, system component or system service to provide [Fill in: training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms provided by the developer of the system, system component, or system service. Typical: role-based training for the system's administrators and security staff on configuring, operating and monitoring the security and privacy functions the developer provides, before the system goes into operation and after each major release, with materials the organization may reuse for in-house training] on the correct use and operation of the implemented security and privacy functions, controls and mechanisms. (SA-16)
- The [System owner] shall ensure the personnel who operate those functions complete the training before they are given the related privileges. (SA-16)

#### Developer security and privacy architecture and design (SA-17)

> **Guidance:** SA-17 is the developer's side of PL-8: NIST's SA-17 discussion directs it at external developers, while PL-8 has the organization build its own security and privacy architecture into the enterprise architecture. The distinction matters most when development is outsourced and the organization must show the delivered design is consistent with its architecture. NIST's discussion points to NIST SP 800-160 Vol. 1 Rev. 1 and ISO/IEC 15408 for security architecture and design.

- The [System owner] shall require the developer of the system, system component or system service to produce a design specification and security and privacy architecture that is consistent with the organization's security and privacy architecture, as an integral part of the organization's enterprise architecture (PL-8). (SA-17a)
- The design specification and architecture shall accurately and completely describe the required security and privacy functionality, and the allocation of controls among physical and logical components. (SA-17b)
- The design specification and architecture shall express how the individual security and privacy functions, mechanisms and services work together to provide the required security and privacy capabilities and a unified approach to protection. (SA-17c)
- The [System owner] shall have the design specification and architecture reviewed by the security architect and, for a system that processes personally identifiable information, the [Senior privacy official], before the design is accepted. (SA-17)

#### Developer screening (SA-21)

> **Guidance:** Developer screening is directed at external developers; in-house developers are screened under PS-3, as NIST's SA-21 discussion notes. The discussion lists clearances, background checks, citizenship and nationality as criteria, and says trustworthiness can also cover the company's ownership and relationships. It adds that the developer provides a list of all individuals authorized to do development work, so the organization can check each has been screened. Outside the federal government, "official government duties" reads as the duties the organization assigns.

- The [System owner] shall require that the developer of [Fill in: the system, systems component, or system service that the developer has access to. Typical: the system and any of its components where the developer has privileged access, access to source code or build systems, or access to the information the system processes] has appropriate access authorizations, as determined by assigned [Fill in: official government duties assigned to the developer. Typical: the duties assigned to each developer's personnel, designated at the same position risk or sensitivity level as organizational staff with equivalent access (PS-2)]. (SA-21a)
- The [System owner] shall require that the developer satisfies the following additional personnel screening criteria: [Fill in: additional personnel screening criteria for the developer. Typical: screening to the same criteria as organizational staff in comparable positions (PS-3), and a current list of every individual authorized to perform development work, provided before work starts and when it changes]. (SA-21b)
- The [System owner] shall put these requirements in the development contract, and check the developer's list of authorized individuals against the screening records before granting access. (SA-21)

#### Unsupported system components (SA-22)

> **Guidance:** An unsupported component gets no security updates, so each new vulnerability in it stays open. NIST's SA-22 discussion allows exceptions only where no newer technology exists for a critical capability or the system is too isolated to replace, and suggests isolation, such as no connection to public or uncontrolled networks, to reduce the risk. Track each component's end-of-support date in the component inventory (CM-8), and treat an unsupported component as a flaw under the [patch and flaw remediation standard](https://kston83.github.io/nist-guide/templates/standards/patch-and-flaw-remediation-standard/) until it is replaced.

- The [System owner] shall replace system components when support for them is no longer available from the developer, vendor or manufacturer. (SA-22a)
- The [System owner] shall plan and budget each replacement before the component's announced end-of-support date. (SA-22a)
- Where a component cannot be replaced by its end-of-support date, the [System owner] shall provide the following options for alternative sources of continued support: [Select one or more: in-house support; [Assignment: organization-defined support from external providers]. Typical: support from an external provider under contract, such as extended vendor support or a third-party support provider; in-house support only for an isolated component whose replacement is scheduled]. (SA-22b)
- The authorizing official shall approve each continued use of an unsupported component, for a set period, with the compensating measures recorded and the replacement tracked in the plan of action and milestones. (SA-22b)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.i(8), requires agencies to prohibit the use of unsupported information systems and system components, and to give systems and components that cannot be appropriately protected a high priority for upgrade or replacement; section 5.p allows the same exceptions as NIST's SA-22 discussion, with in-house or contracted support for them. CISA [Binding Operational Directive 26-02](https://www.cisa.gov/news-events/directives/bod-26-02-mitigating-risk-end-support-edge-devices), Mitigating Risk From End-of-Support Edge Devices (February 5, 2026), covers edge devices: devices on the boundary of an agency's network that are reachable from the public internet. It requires agencies to update supported devices running end-of-support software immediately; to inventory devices on CISA's end-of-support edge device list within 3 months; to decommission listed devices and report to CISA within 12 months; to decommission every end-of-support edge device within 18 months; and, within 24 months, to keep a continuous discovery process and inventory and decommission each edge device by its end-of-support date. As of September 2026.

- The [System owner] shall not use an unsupported system component except under an exception that OMB Circular A-130, Appendix I, section 5.p, allows, approved by the authorizing official. (SA-22a)
- The [System owner] shall inventory the system's edge devices, replace or decommission each one that is end of support, and report each decommission to CISA, by the deadlines BOD 26-02 sets. (SA-22a)
- From the directive's 24-month deadline, the [System owner] shall decommission each edge device on or before its end-of-support date, as BOD 26-02 requires. (SA-22a)

### System and Communications Protection (SC)

#### Separation of system and user functionality (SC-2)

> **Guidance:** Keep administration interfaces apart from the interfaces users see: separate administrative consoles, ports or network segments, separate administrator accounts, and management planes not reachable from user networks or the internet.

- The [System owner] shall ensure the system separates user functionality, including user interface services, from system management functionality. (SC-2)

#### Security function isolation (SC-3)

> **Guidance:** Security functions include access enforcement, authentication, audit and cryptographic key management. Isolation is usually provided by the operating system, hypervisor or cloud platform and by running security services on dedicated components. SC-3 is in the High baseline.

- The [System owner] shall ensure the system isolates security functions from nonsecurity functions. (SC-3)

#### Information in shared system resources (SC-4)

> **Guidance:** This control is about residual information: memory, storage and caches reused by another user or process must not reveal what the last one left. Operating systems and cloud platforms usually provide it; the system owner confirms it and covers any shared resources the application manages itself.

- The [System owner] shall ensure the system prevents unauthorized and unintended information transfer through shared system resources. (SC-4)

#### Denial-of-service protection (SC-5)

> **Guidance:** Most organizations meet this through their internet or cloud provider's denial-of-service protection, plus rate limiting and autoscaling for their own services. Record which protections are inherited and which the system provides.

- The [System owner] shall ensure the system can [Select one: protect against; limit. Typical: protect against] the effects of the following types of denial-of-service events: [Fill in: types of denial-of-service events to be protected against or limited. Typical: network floods, protocol attacks and application-layer floods against internet-facing services]. (SC-5a)
- The [System owner] shall employ the following controls to achieve the denial-of-service objective: [Fill in: controls to achieve the denial-of-service objective by type of denial-of-service event. Typical: an upstream or cloud denial-of-service protection service for internet-facing services, rate limiting at load balancers and application gateways, and capacity that scales automatically]. (SC-5b)

#### Boundary protection (SC-7)

> **Guidance:** Every external connection goes through a managed interface, such as a firewall, cloud security group, gateway or proxy, and public-facing components sit in their own subnetwork. The boundary diagram in the system security plan is where assessors start. The [Boundary Protection Standard](https://kston83.github.io/nist-guide/templates/standards/boundary-protection-standard/) sets the managed interfaces, rule sets, allowed flows and review cycle.

- The [System owner] shall monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system. (SC-7a)
- The [System owner] shall implement subnetworks for publicly accessible system components that are [Select one: physically; logically. Typical: logically] separated from internal organizational networks. (SC-7b)
- The [System owner] shall connect the system to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with the organization's security and privacy architecture. (SC-7c)

##### Federal systems

Federal civilian agencies secure their network connections under CISA's [Trusted Internet Connections (TIC) 3.0](https://www.cisa.gov/resources-tools/programs/trusted-internet-connections-tic) program, which implements OMB M-19-26, Update to the Trusted Internet Connections (TIC) Initiative (September 12, 2019). TIC 3.0 is set out in CISA's core guidance documents and use cases (as of September 2026).

- The [System owner] shall implement the system's external connections in accordance with the agency's TIC 3.0 architecture and the TIC 3.0 use cases that apply to the system. (SC-7c)

#### Access points (SC-7(3))

- The [System owner] shall limit the number of external network connections to the system. (SC-7(3))

#### External telecommunications services (SC-7(4))

> **Guidance:** Control plane traffic is the routing and signaling traffic between networks, such as BGP route announcements. Items (f) to (h) usually fall to the network or internet service team: route filtering, and publishing the organization's address space and routing policy so others can detect hijacked routes.

- The [System owner] shall implement a managed interface for each external telecommunication service. (SC-7(4)(a))
- The [System owner] shall establish a traffic flow policy for each managed interface. (SC-7(4)(b))
- The [System owner] shall protect the confidentiality and integrity of the information transmitted across each interface. (SC-7(4)(c))
- The [System owner] shall document each exception to the traffic flow policy with the mission or business need that supports it and the duration of that need. (SC-7(4)(d))
- The [System owner] shall review exceptions to the traffic flow policy [Fill in: the frequency at which to review exceptions to traffic flow policy. Typical: at least annually, and when the system changes], and remove exceptions that an explicit mission or business need no longer supports. (SC-7(4)(e))
- The [System owner] shall prevent unauthorized exchange of control plane traffic with external networks. (SC-7(4)(f))
- The [System owner] shall publish information that enables remote networks to detect unauthorized control plane traffic from internal networks. (SC-7(4)(g))
- The [System owner] shall filter unauthorized control plane traffic from external networks. (SC-7(4)(h))

#### Deny by default, allow by exception (SC-7(5))

- The [System owner] shall ensure network communications traffic is denied by default and allowed by exception [Select one or more: at managed interfaces; for [Assignment: organization-defined systems]. Typical: at managed interfaces]. (SC-7(5))

#### Split tunneling for remote devices (SC-7(7))

> **Guidance:** Split tunneling lets a remote device reach the internet directly while connected to the organization's network, bypassing its boundary protections. Where a zero trust access service replaces the virtual private network, record how its design meets the intent.

- The [System owner] shall prevent split tunneling for remote devices connecting to organizational systems, except where the split tunnel is securely provisioned using these safeguards: [Fill in: safeguards to securely provision split tunneling. Typical: none; split tunneling is disabled for organization-managed remote devices]. (SC-7(7))

#### Route traffic to authenticated proxy servers (SC-7(8))

- The [System owner] shall route [Fill in: internal communications traffic to be routed to external networks. Typical: outbound web traffic from internal users] to [Fill in: external networks to which internal communications traffic is to be routed. Typical: the internet] through authenticated proxy servers at managed interfaces. (SC-7(8))

#### Fail secure (SC-7(18))

> **Guidance:** SC-7(18) is in the High baseline. A boundary device that fails should block traffic, not pass it; confirm the setting for each firewall, gateway and proxy, and test it.

- The [System owner] shall prevent the system from entering an unsecure state when a boundary protection device fails. (SC-7(18))

#### Isolation of system components (SC-7(21))

> **Guidance:** SC-7(21) is in the High baseline. Isolation is usually a separate network segment or cloud account with its own boundary rules.

- The [System owner] shall employ boundary protection mechanisms to isolate [Fill in: system components to be isolated by boundary protection mechanisms. Typical: components that process the most sensitive information, and security management components such as identity, key management and logging services] supporting [Fill in: missions and/or business functions to be supported by system components isolated by boundary protection mechanisms. Typical: the essential mission and business functions named in the business impact analysis]. (SC-7(21))

#### Transmission confidentiality and integrity (SC-8)

> **Guidance:** Protect information while it moves, inside the system as well as across its boundary. At Moderate and High, SC-8(1) makes that protection cryptographic, using the cryptography SC-13 requires.

- The [System owner] shall ensure the system protects the [Select one or more: confidentiality; integrity. Typical: confidentiality and integrity] of transmitted information. (SC-8)

##### Federal systems

CISA [Binding Operational Directive 18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), Enhance Email and Web Security (October 16, 2017), requires that "All publicly accessible Federal websites and web services provide service through a secure connection (HTTPS-only, with HSTS)", that internet-facing mail servers offer STARTTLS, and that SSLv2, SSLv3, 3DES and RC4 are disabled on mail servers. CISA's directive page does not mark it revoked (as of September 2026).

- The [System owner] shall ensure each publicly accessible website and web service of the system provides service only through HTTPS, with HTTP Strict Transport Security. (SC-8)
- The [System owner] shall ensure each internet-facing mail server of the system offers STARTTLS. (SC-8)
- The [System owner] shall ensure SSLv2, SSLv3 and the 3DES and RC4 ciphers are disabled on the system's mail servers. (SC-8)

#### Cryptographic protection (SC-8(1))

> **Guidance:** In practice: TLS 1.2 or later for web, API and database connections, SSH for administration, IPsec or TLS for virtual private networks, and encryption on internal service-to-service traffic. Cleartext protocols such as Telnet and unencrypted FTP are disabled.

- The [System owner] shall implement cryptographic mechanisms to [Select one or more: prevent unauthorized disclosure of information; detect changes to information. Typical: prevent unauthorized disclosure of information and detect changes to information] during transmission. (SC-8(1))

#### Network disconnect (SC-10)

> **Guidance:** SC-10 ends the network connection; AC-12 ends the user's session. Keep the two times consistent: the typical value here matches the 30 minutes AC-12 sets for remote and web sessions.

- The [System owner] shall ensure the system terminates the network connection associated with a communications session at the end of the session or after [Fill in: a time period of inactivity after which the system terminates a network connection associated with a communication session. Typical: 30 minutes] of inactivity. (SC-10)

#### Cryptographic key establishment and management (SC-12)

> **Guidance:** Key management is where encryption usually fails: keys stored with the data, or usable by every administrator. NIST SP 800-57 Part 1 is the usual reference for key management requirements. Cloud key management services and hardware security modules handle most of it; the system owner decides who can use and administer each key. The [Encryption and Key Management Standard](https://kston83.github.io/nist-guide/templates/standards/encryption-and-key-management-standard/) sets the key generation, storage, access, replacement and destruction requirements this clause refers to.

- The [System owner] shall establish and manage cryptographic keys, wherever the system employs cryptography, in accordance with [Fill in: requirements for key generation, distribution, storage, access, and destruction. Typical: the requirements for key generation, distribution, storage, access and destruction in the encryption and key management standard]. (SC-12)

#### Availability (SC-12(1))

> **Guidance:** SC-12(1) is in the High baseline. Key escrow or recovery keys held by the organization, such as the recovery keys for full-disk encryption, keep information available when a user loses a key.

- The [System owner] shall maintain the availability of information when users lose cryptographic keys. (SC-12(1))

#### Cryptographic protection (SC-13)

> **Guidance:** SC-13 does not require cryptography by itself; SC-8, SC-28, IA-5 and AC-17 do. It sets the standard that cryptography must meet wherever those controls call for it. The cryptographic uses match those under configuration management in CM-3(6). The [Encryption and Key Management Standard](https://kston83.github.io/nist-guide/templates/standards/encryption-and-key-management-standard/) lists the approved algorithms, protocols and modules for each use.

- The [Chief Information Security Officer] shall determine the cryptographic uses for the organization's systems, which include [Fill in: cryptographic uses. Typical: encryption in transit and at rest, digital signatures and authentication]. (SC-13a)
- The [System owner] shall implement the following types of cryptography for each cryptographic use: [Fill in: types of cryptography for each specified cryptographic use. Typical: NIST-approved algorithms in cryptographic modules validated under FIPS 140-3 (or FIPS 140-2 for existing systems)]. (SC-13b)

##### Federal systems

[FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final) (March 22, 2019) "is applicable to all Federal agencies that use cryptography-based security systems to protect sensitive information", and modules validated under NIST's Cryptographic Module Validation Program (CMVP) are considered to conform to it (sections 6 and 9). The CMVP's [FIPS 140-3 transition page](https://csrc.nist.gov/projects/fips-140-3-transition-effort) sets the schedule for moving FIPS 140-2 validations to the Historical List in September 2026; modules on the Historical List remain supported for existing systems, but the standard notes that the Historical List "should not be used for procurement decisions" (as of September 2026).

- The [System owner] shall use cryptographic modules validated by the CMVP wherever the system uses cryptography to protect sensitive information. (SC-13b)
- The [System owner] shall select FIPS 140-3 validated modules for new systems and new purchases. (SC-13b)

#### Collaborative computing devices and applications (SC-15)

> **Guidance:** Collaborative computing devices include cameras, microphones, networked whiteboards and conferencing applications. The point is that nobody can switch on a camera or microphone remotely without the people in the room knowing.

- The [System owner] shall prohibit remote activation of collaborative computing devices and applications, with these exceptions: [Fill in: exceptions where remote activation is to be allowed. Typical: none, except conference room equipment that support staff activate for maintenance with the room owner's approval]. (SC-15a)
- The [System owner] shall ensure collaborative computing devices and applications give an explicit indication of use to users physically present at the devices. (SC-15b)

#### Public key infrastructure certificates (SC-17)

> **Guidance:** Most organizations obtain certificates for public services from a public certificate authority, which counts as an approved service provider, and run an internal certificate authority under their own certificate policy for internal services. Trust stores should hold only the trust anchors the organization approves.

- The [Chief Information Security Officer] shall ensure public key certificates are issued under [Fill in: a certificate policy for issuing public key certificates. Typical: the organization's certificate policy], or obtained from an approved service provider. (SC-17a)
- The [System owner] shall include only approved trust anchors in trust stores or certificate stores the organization manages. (SC-17b)

#### Mobile code (SC-18)

> **Guidance:** Mobile code is software sent from a remote system and run on a local one, such as JavaScript, macros in office documents and browser plug-ins. Define what is acceptable by technology, for example signed macros only and no browser plug-ins, and enforce it through browser and office application settings.

- The [Chief Information Security Officer] shall define acceptable and unacceptable mobile code and mobile code technologies. (SC-18a)
- The [System owner] shall authorize, monitor and control the use of mobile code within the system. (SC-18b)

#### Secure name and address resolution service (authoritative source) (SC-20)

> **Guidance:** In practice this is DNSSEC signing for the zones the organization publishes, often a setting at the managed DNS provider. [NIST SP 800-81 Rev. 3](https://csrc.nist.gov/pubs/sp/800/81/r3/final), Secure Domain Name System (DNS) Deployment Guide (March 2026), is the NIST guide to deploying DNS securely, including DNSSEC.

- The [System owner] shall ensure the system provides additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data it returns in response to external name and address resolution queries. (SC-20a)
- When the system operates as part of a distributed, hierarchical namespace, the [System owner] shall ensure it provides the means to indicate the security status of child zones and, if a child supports secure resolution services, to enable verification of a chain of trust among parent and child domains. (SC-20b)

#### Secure name and address resolution service (recursive or caching resolver) (SC-21)

> **Guidance:** In practice this is DNSSEC validation turned on at the resolvers the system uses, or a DNS service that validates.

- The [System owner] shall ensure the system requests and performs data origin authentication and data integrity verification on the name and address resolution responses it receives from authoritative sources. (SC-21)

#### Architecture and provisioning for name and address resolution service (SC-22)

> **Guidance:** Fault tolerance means at least two name servers in different network locations. Role separation means internal and external name servers are separate, so internal names are not published to the internet.

- The [System owner] shall ensure the systems that together provide name and address resolution service for the organization are fault-tolerant and implement internal and external role separation. (SC-22)

#### Session authenticity (SC-23)

> **Guidance:** Session authenticity protects against session hijacking and replay: TLS with certificate validation, session identifiers that are random and expire, and invalidating session identifiers at logout.

- The [System owner] shall ensure the system protects the authenticity of communications sessions. (SC-23)

#### Fail in known state (SC-24)

> **Guidance:** SC-24 is in the High baseline.

- The [System owner] shall ensure system components fail to [Fill in: known system state to which system components fail in the event of a system failure. Typical: a state that denies access through the affected components] for the following failures: [Fill in: types of system failures for which the system components fail to a known state. Typical: failure of a boundary protection device, an authentication service or a database]. (SC-24)
- The [System owner] shall ensure the system preserves [Fill in: system state information to be preserved in the event of a system failure. Typical: transactions in progress, audit records and configuration settings] when those failures occur. (SC-24)

#### Protection of information at rest (SC-28)

> **Guidance:** Protect stored information on servers, in databases and storage services, in backups and on end-user devices. At Moderate and High, SC-28(1) makes the protection cryptographic.

- The [System owner] shall ensure the system protects the [Select one or more: confidentiality; integrity. Typical: confidentiality and integrity] of [Fill in: information at rest requiring protection. Typical: all information stored by the system, including backups]. (SC-28)

#### Cryptographic protection (SC-28(1))

> **Guidance:** Encryption at rest protects against lost devices, stolen media and direct access to storage; it does not protect against someone who can sign in to the application. Keep keys apart from the data they protect.

- The [System owner] shall implement cryptographic mechanisms to prevent unauthorized disclosure and modification of [Fill in: information requiring cryptographic protection. Typical: all organizational information] at rest on [Fill in: system components or media requiring cryptographic protection. Typical: servers, databases, storage services, backups, end-user devices and removable media]. (SC-28(1))

#### Process isolation (SC-39)

> **Guidance:** Modern operating systems, hypervisors and container platforms provide separate execution domains; this control is usually inherited. Confirm it for any component that does not, such as some embedded or legacy systems.

- The [System owner] shall ensure the system maintains a separate execution domain for each executing system process. (SC-39)

### System and Information Integrity (SI)

#### Flaw remediation (SI-2)

> **Guidance:** SI-2 is the fixing half of vulnerability management: RA-5 finds the flaws, and SI-2 installs the updates that correct them. The installation times here count from the release of the update, while the RA-5 remediation times count from when a finding is reported, so keep the two sets of values consistent. The [Patch and Flaw Remediation Standard](https://kston83.github.io/nist-guide/templates/standards/patch-and-flaw-remediation-standard/) sets the test groups, deployment rings and schedules. NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (April 2022, current as of September 2026), describes how to plan patching as routine preventive maintenance.

- The [System owner] shall identify system flaws from vulnerability scanning and monitoring, vendor security advisories, assessments and incident analysis. (SI-2a)
- The [System owner] shall report identified flaws that affect the system to the [Security operations team] and record each in the system's flaw tracking. (SI-2a)
- The [System owner] shall correct identified system flaws. (SI-2a)
- The [System owner] shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installing them in production. (SI-2b)
- The [System owner] shall install security-relevant software and firmware updates within [Fill in: time period within which to install security-relevant software updates after the release of the updates. Typical: known exploited: as soon as possible, within days; critical and high: 30 days; moderate: 90 days; low: 180 days] of the release of the updates. (SI-2c)
- The [System owner] shall enter any security-relevant update that cannot be installed in time in the system's plan of action and milestones, with a planned date and any compensating measures, before its installation time ends. (SI-2c)
- The [System owner] shall incorporate flaw remediation into the organization's configuration management process, recording routine updates as standard changes and urgent updates as emergency changes. (SI-2d)

> **Guidance:** Unsupported software and firmware cannot be fixed. Record each unsupported component as a flaw, with a replacement date in the plan of action and milestones, until it is removed (SA-22).

##### Federal systems

CISA [BOD 26-04](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk), Prioritizing Security Updates Based on Risk (June 10, 2026), sets remediation deadlines for federal civilian agencies by whether an asset is publicly exposed, whether the vulnerability is in CISA's Known Exploited Vulnerabilities (KEV) catalog, whether exploitation can be automated, and its technical impact, from 3 days to "fix on system upgrade". Its clock starts when CISA adds a vulnerability to the KEV catalog or the agency identifies it, whichever is first. It revoked BOD 22-01 and BOD 19-02. It does not apply to national security systems. As of September 2026.

- The [System owner] shall set the SI-2c installation times no longer than the deadlines CISA BOD 26-04 sets, and install security updates within those deadlines. (SI-2c)

#### Automated flaw remediation status (SI-2(2))

> **Guidance:** Patch compliance reports from the patch management tool, checked against authenticated vulnerability scans, show which components are missing updates. Components the tools cannot reach, such as appliances, need a manual check on the same schedule.

- The [System owner] shall determine whether system components have applicable security-relevant software and firmware updates installed, using [Fill in: automated mechanisms to determine if applicable security-relevant software and firmware updates are installed on system components. Typical: the patch management and vulnerability scanning tools], [Fill in: the frequency at which to determine if applicable security-relevant software and firmware updates are installed on system components. Typical: at least weekly]. (SI-2(2))

##### Federal systems

CISA [BOD 23-01](https://www.cisa.gov/news-events/directives/bod-23-01-improving-asset-visibility-and-vulnerability-detection-federal-networks), Improving Asset Visibility and Vulnerability Detection on Federal Networks (October 3, 2022), requires federal civilian agencies to perform automated asset discovery every 7 days and to initiate vulnerability enumeration across all discovered assets, including roaming devices such as laptops, every 14 days. As of September 2026.

- The [System owner] shall ensure the system's assets are covered by automated asset discovery at least every 7 days and by vulnerability enumeration at least every 14 days, as CISA BOD 23-01 requires. (SI-2(2))

#### Malicious code protection (SI-3)

> **Guidance:** Endpoint detection and response on servers and workstations, together with malware scanning in the email and web gateways, usually covers system entry and exit points. Non-signature-based means behavior or reputation analysis, which catches malware no signature yet describes. Enterprise tools are often common controls; the system owner makes sure every component that can run an agent has one.

- The [System owner] shall implement [Select one or more: signature-based; non-signature-based. Typical: signature-based and non-signature-based] malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code. (SI-3a)
- The [System owner] shall ensure malicious code protection mechanisms update automatically as new releases are available, in accordance with the organization's configuration management policy and procedures. (SI-3b)
- The [System owner] shall configure malicious code protection mechanisms to perform periodic scans of the system [Fill in: the frequency at which malicious code protection mechanisms perform scans. Typical: at least weekly]. (SI-3c.1)
- The [System owner] shall configure malicious code protection mechanisms to perform real-time scans of files from external sources at [Select one or more: endpoint; network entry and exit points. Typical: endpoint and network entry and exit points] as the files are downloaded, opened or executed. (SI-3c.1)
- The [System owner] shall configure malicious code protection mechanisms to [Select one or more: block malicious code; quarantine malicious code; take [Assignment: organization-defined action]. Typical: block and quarantine malicious code] and to send an alert to [Fill in: personnel or roles to be alerted when malicious code is detected. Typical: the security operations team] when malicious code is detected. (SI-3c.2)
- The [Security operations team] shall review reported false positives, approve any scan exclusion with a documented reason and an expiry date, and record the effect of false positives on the availability of the system. (SI-3d)

#### System monitoring (SI-4)

> **Guidance:** System monitoring takes in the audit records reviewed under AU-6 and adds endpoint, network and cloud detection. The [System Monitoring Standard](https://kston83.github.io/nist-guide/templates/standards/system-monitoring-standard/) sets the log sources, detection coverage, alert handling and reporting. Legal review of monitoring (SI-4f) is usually done once for the organization's monitoring program and repeated when monitoring changes, with a system use notification under AC-8.

- The [Security operations team] shall monitor the system to detect attacks and indicators of potential attacks in accordance with the following monitoring objectives: [Fill in: monitoring objectives to detect attacks and indicators of potential attacks on the system. Typical: detecting attacks, malware, unauthorized access, privilege misuse and data exfiltration]. (SI-4a.1)
- The [Security operations team] shall monitor the system to detect unauthorized local, network and remote connections. (SI-4a.2)
- The [Security operations team] shall identify unauthorized use of the system through [Fill in: techniques and methods used to identify unauthorized use of the system. Typical: log correlation in the security information and event management (SIEM) platform, endpoint detection and response, network intrusion detection and user behavior analytics]. (SI-4b)
- The [System owner] shall ensure monitoring capabilities are deployed strategically within the system to collect the essential information the monitoring objectives call for, including at the managed interfaces under SC-7. (SI-4c.1)
- The [System owner] shall ensure monitoring capabilities can be deployed at ad hoc locations within the system to track specific types of transactions of interest to the organization. (SI-4c.2)
- The [Security operations team] shall analyze detected events and anomalies, and refer suspected incidents to the [Incident response team]. (SI-4d)
- The [Chief Information Security Officer] shall adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations or the Nation. (SI-4e)
- The [Chief Information Security Officer] shall obtain a legal opinion on system monitoring activities before they begin and whenever they change significantly. (SI-4f)
- The [Security operations team] shall provide [Fill in: system monitoring information to be provided to personnel or roles. Typical: alerts and monitoring reports] to [Fill in: personnel or roles to whom system monitoring information is to be provided. Typical: the system owner and the incident response team], [Select one or more: as needed; [Assignment: organization-defined frequency]. Typical: as needed, and at least monthly]. (SI-4g)

##### Federal systems

[OMB M-26-14](https://www.whitehouse.gov/wp-content/uploads/2026/05/M-26-14-Ensuring-Effective-and-Efficient-Agency-Logging-and-Network-Visibility-to-Defend-Against-Evolving-Cyber-Threats.pdf), Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats (May 22, 2026), rescinded M-21-31. It directs agencies to prioritize two logging objectives, continuous event monitoring and threat hunting, investigation, response and forensics, for all information systems owned or operated by the agency or by third parties on its behalf, and to adhere to CISA's [Logging Reference Architecture](https://www.cisa.gov/resources-tools/resources/logging-reference-architecture) (published August 20, 2026). Its Appendix B requires logs that support monitoring for suspicious activity identified by security tooling, known indicators of compromise and anomalous system or user activity, with automated alerts, and that are readily available to the agency's top-level security operations center. It does not apply to national security systems. As of September 2026.

- The [System owner] shall ensure the system's logs are readily available to the agency's top-level security operations center, as OMB M-26-14 requires. (SI-4c.1)
- The [Security operations team] shall use the system's logs to monitor for suspicious activity identified by security tooling, known indicators of compromise and anomalous system or user activity, and generate automated alerts for them, as OMB M-26-14 Appendix B requires. (SI-4a.1)
- In the event of a known or suspected compromise, the [Chief Information Security Officer] shall provide logs and other relevant data to CISA and the FBI on request, to the extent consistent with applicable law, as OMB M-26-14 requires. (SI-4g)

#### Automated tools and mechanisms for real-time analysis (SI-4(2))

> **Guidance:** Correlation rules and analytics in the SIEM, and the detection engines in endpoint and network tools, are the automated tools. Near real-time means minutes, not the next day's review.

- The [Security operations team] shall employ automated tools and mechanisms, such as correlation rules in the SIEM platform and endpoint detection and response, to support near real-time analysis of events. (SI-4(2))

#### Inbound and outbound communications traffic (SI-4(4))

> **Guidance:** Outbound monitoring is where data exfiltration and command-and-control traffic show up. Threat intelligence feeds supply the known malicious sources and destinations; a baseline of normal volumes supplies the unusual ones.

- The [Security operations team] shall determine and document criteria for unusual or unauthorized activities or conditions for inbound and outbound communications traffic. (SI-4(4)(a))
- The [Security operations team] shall monitor inbound communications traffic [Fill in: the frequency at which to monitor inbound communications traffic for unusual or unauthorized activities or conditions. Typical: continuously] for [Fill in: unusual or unauthorized activities or conditions that are to be monitored in inbound communications traffic. Typical: connections from known malicious sources, unapproved protocols and ports, and scanning or password-guessing patterns]. (SI-4(4)(b))
- The [Security operations team] shall monitor outbound communications traffic [Fill in: the frequency at which to monitor outbound communications traffic for unusual or unauthorized activities or conditions. Typical: continuously] for [Fill in: unusual or unauthorized activities or conditions that are to be monitored in outbound communications traffic. Typical: connections to known malicious destinations, unusual data volumes, unapproved protocols and regular beaconing to external hosts]. (SI-4(4)(b))

#### System-generated alerts (SI-4(5))

- The [System owner] shall ensure the system alerts [Fill in: personnel or roles to be alerted when indications of compromise or potential compromise occur. Typical: the security operations team] when the following system-generated indications of compromise or potential compromise occur: [Fill in: compromise indicators. Typical: indicators of compromise from the detection tools and threat intelligence feeds]. (SI-4(5))

#### Visibility of encrypted communications (SI-4(10))

> **Guidance:** Most traffic is encrypted, so monitoring tools see little unless it is decrypted at a proxy or gateway, or the tools read it at the endpoint. Decryption raises privacy and legal questions: decide the exempt categories with legal counsel and the senior privacy official, and protect the decryption keys under SC-12.

- The [System owner] shall make provisions so that [Fill in: encrypted communications traffic to be made visible to system monitoring tools and mechanisms. Typical: encrypted traffic crossing the internet connection and the public-facing subnetwork, except categories exempted after legal and privacy review, such as health and financial sites] is visible to [Fill in: system monitoring tools and mechanisms to be provided access to encrypted communications traffic. Typical: the intrusion detection and prevention systems and data loss prevention tools at the boundary]. (SI-4(10))

#### Automated organization-generated alerts (SI-4(12))

- The [Security operations team] shall alert [Fill in: personnel or roles to be alerted when indications of inappropriate or unusual activity with security or privacy implications occur. Typical: the security operations team and the system owner] using [Fill in: automated mechanisms used to alert personnel or roles. Typical: the security information and event management (SIEM) platform] when the following indications of inappropriate or unusual activities with security or privacy implications occur: [Fill in: activities that trigger alerts to personnel or. Typical: use of privileged accounts outside approved change windows, bulk downloads or exports of sensitive information, disabled security tools, and new administrative accounts]. (SI-4(12))

#### Wireless intrusion detection (SI-4(14))

> **Guidance:** A wireless intrusion detection system covers the facilities where the system's components are located, including those with no approved wireless network, since rogue access points are the main concern there.

- The [System owner] shall employ a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises or breaches to the system. (SI-4(14))

#### Privileged users (SI-4(20))

- The [Security operations team] shall implement the following additional monitoring of privileged users: [Fill in: additional monitoring of privileged users. Typical: recording of privileged sessions, alerts on high-risk privileged commands, and a review of privileged activity at least weekly]. (SI-4(20))

#### Unauthorized network services (SI-4(22))

- The [Security operations team] shall detect network services that have not been authorized or approved by [Fill in: authorization or approval processes for network services. Typical: the change control process and the approved ports, protocols and services list]. (SI-4(22)(a))
- When unauthorized network services are detected, the [Security operations team] shall [Select one or more: audit; alert [Assignment: organization-defined personnel or roles]. Typical: audit, and alert the security operations team and the system owner]. (SI-4(22)(b))

#### Security alerts, advisories and directives (SI-5)

> **Guidance:** Subscribing to the CISA advisories and the vendor security bulletins for every product in the component inventory (CM-8) is the usual starting point. The value is in routing: each alert reaches the people who run the affected component, with a due date.

- The [Security operations team] shall receive system security alerts, advisories and directives from [Fill in: external organizations from whom system security alerts, advisories, and directives are to be received on an ongoing basis. Typical: CISA, the vendors of the system's components, and the organization's information sharing and analysis center] on an ongoing basis. (SI-5a)
- The [Security operations team] shall generate internal security alerts, advisories and directives as deemed necessary. (SI-5b)
- The [Security operations team] shall disseminate security alerts, advisories and directives to [Select one or more: [Assignment: organization-defined personnel or roles]; [Assignment: organization-defined elements]; [Assignment: organization-defined external organizations]. Typical: system owners and system administrators, the security operations and incident response teams, and the service providers who operate systems for the organization, where an alert affects them]. (SI-5c)
- The [System owner] shall implement security directives in accordance with their established time frames, or notify the issuing organization of the degree of noncompliance. (SI-5d)

##### Federal systems

The Federal Information Security Modernization Act requires the head of each agency to comply with the binding operational directives and emergency directives the Secretary of Homeland Security issues under 44 U.S.C. § 3553(b) and (h) ([44 U.S.C. § 3554(a)(1)(B)(ii) and (v)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim)). CISA publishes them on its [Cybersecurity Directives](https://www.cisa.gov/directives) page; they do not apply to national security systems. As of September 2026.

- The [Chief Information Security Officer] shall track each CISA binding operational directive and emergency directive that applies to the agency, and ensure system owners complete its required actions and reports within the time frames it sets. (SI-5d)

#### Automated alerts and advisories (SI-5(1))

- The [Security operations team] shall broadcast security alert and advisory information throughout the organization using [Fill in: automated mechanisms used to broadcast security alert and advisory information throughout the organization. Typical: the ticketing system, which assigns each alert to the owners of the affected components, and the security team's distribution lists]. (SI-5(1))

#### Security and privacy function verification (SI-6)

> **Guidance:** Verification can be built-in self-tests, configuration compliance checks that confirm security settings are still in force, or scripted tests that attempt a blocked action and confirm it fails. Shutting a system down on every failed test is rarely acceptable, so most organizations choose an alternative action.

- The [System owner] shall verify the correct operation of the following security functions: [Fill in: security functions to be verified for correct operation. Typical: access enforcement, authentication, audit logging, encryption and malicious code protection]. (SI-6a)
- The [System owner] shall verify the correct operation of the following privacy functions: [Fill in: privacy functions to be verified for correct operation. Typical: consent recording, de-identification and the scheduled deletion of personally identifiable information]. (SI-6a)
- The [System owner] shall perform the verification [Select one or more: [Assignment: organization-defined system transitional states]; upon command by user with appropriate privilege; [Assignment: organization-defined frequency]. Typical: at system startup and restart, upon command by a user with appropriate privilege, and at least monthly]. (SI-6b)
- The [System owner] shall ensure [Fill in: personnel or roles to be alerted of failed security and privacy verification tests. Typical: the system owner and the security operations team] are alerted to failed security and privacy verification tests. (SI-6c)
- When anomalies are discovered, the [System owner] shall [Select one or more: shut the system down; restart the system; [Assignment: organization-defined alternative action(s)]. Typical: isolate the affected component and open an incident]. (SI-6d)

#### Software, firmware and information integrity (SI-7)

> **Guidance:** File integrity monitoring, signed and verified container images, secure boot and measured boot are the usual integrity verification tools. Changes approved under CM-3 are expected; integrity verification finds the ones that were not.

- The [System owner] shall employ integrity verification tools to detect unauthorized changes to the following software: [Fill in: software requiring integrity verification tools to be employed to detect unauthorized changes. Typical: operating system files, installed applications, container images and security tool binaries]. (SI-7a)
- The [System owner] shall employ integrity verification tools to detect unauthorized changes to the following firmware: [Fill in: firmware requiring integrity verification tools to be employed to detect unauthorized changes. Typical: server, network device and endpoint firmware and boot components, where the platform supports verification]. (SI-7a)
- The [System owner] shall employ integrity verification tools to detect unauthorized changes to the following information: [Fill in: information requiring integrity verification tools to be employed to detect unauthorized changes. Typical: security configuration files, audit logs, and the critical data stores named in the system security plan]. (SI-7a)
- When unauthorized changes to software are detected, the [System owner] shall [Fill in: actions to be taken when unauthorized changes to software are detected. Typical: alert the security operations team, restore the approved version, and handle an unauthorized change as a suspected incident]. (SI-7b)
- When unauthorized changes to firmware are detected, the [System owner] shall [Fill in: actions to be taken when unauthorized changes to firmware are detected. Typical: alert the security operations team, restore the approved firmware, and handle an unauthorized change as a suspected incident]. (SI-7b)
- When unauthorized changes to information are detected, the [System owner] shall [Fill in: actions to be taken when unauthorized changes to information are detected. Typical: alert the security operations team and the information owner, restore the information from a trusted source or backup, and handle an unauthorized change as a suspected incident]. (SI-7b)

#### Integrity checks (SI-7(1))

- The [System owner] shall perform an integrity check of [Fill in: software on which an integrity check is to be performed. Typical: the software named for integrity verification under SI-7] [Select one or more: at startup; at [Assignment: organization-defined transitional states or security-relevant events]; [Assignment: organization-defined frequency]. Typical: at startup, after each update or change to the software, and at least weekly]. (SI-7(1))
- The [System owner] shall perform an integrity check of [Fill in: firmware on which an integrity check is to be performed. Typical: the firmware named for integrity verification under SI-7] [Select one or more: at startup; at [Assignment: organization-defined transitional states or security-relevant events]; [Assignment: organization-defined frequency]. Typical: at startup, after each firmware update, and at least monthly]. (SI-7(1))
- The [System owner] shall perform an integrity check of [Fill in: information on which an integrity check is to be performed. Typical: the information named for integrity verification under SI-7] [Select one or more: at startup; at [Assignment: organization-defined transitional states or security-relevant events]; [Assignment: organization-defined frequency]. Typical: after each authorized change to the information, and at least daily]. (SI-7(1))

#### Automated notifications of integrity violations (SI-7(2))

- The [System owner] shall employ automated tools that notify [Fill in: personnel or roles to whom notification is to be provided upon discovering discrepancies during integrity verification. Typical: the security operations team and the system owner] upon discovering discrepancies during integrity verification. (SI-7(2))

#### Automated response to integrity violations (SI-7(5))

- When integrity violations are discovered, the [System owner] shall ensure the system automatically takes the following action: [Select one or more: shut down the system; restart the system; implement [Assignment: organization-defined controls]. Typical: implement controls: block the changed component from running, isolate the affected host, and restore the approved version]. (SI-7(5))

#### Integration of detection and response (SI-7(7))

- The [System owner] shall incorporate the detection of the following unauthorized changes into the organization's incident response capability: [Fill in: security-relevant changes to the system. Typical: unauthorized changes to operating system and application files, security configuration settings, firmware and audit logging settings]. (SI-7(7))

#### Code authentication (SI-7(15))

> **Guidance:** Code signing verified by the operating system, package manager or container admission controller is the usual mechanism. Keep the list of trusted signers short, and treat an unsigned or wrongly signed component as a failed installation.

- The [System owner] shall implement cryptographic mechanisms to authenticate the following software and firmware components before installation: [Fill in: software or firmware components to be authenticated by cryptographic mechanisms prior to installation. Typical: operating system and application updates, firmware updates, drivers and container images]. (SI-7(15))

#### Spam protection (SI-8)

> **Guidance:** Spam protection sits in the email gateway or the cloud email service's filtering, and in some cases in web or messaging gateways. Publishing SPF, DKIM and DMARC records for the organization's own domains helps other organizations reject mail that spoofs them.

- The [System owner] shall employ spam protection mechanisms at system entry and exit points to detect and act on unsolicited messages. (SI-8a)
- The [System owner] shall update spam protection mechanisms when new releases are available, in accordance with the organization's configuration management policy and procedures. (SI-8b)

##### Federal systems

CISA [BOD 18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), Enhance Email and Web Security (October 16, 2017), requires federal civilian agencies to have valid SPF and DMARC records for all second-level agency domains, to set a DMARC policy of "reject" for all second-level domains and mail-sending hosts, and to add the address the directive designates (`reports@dmarc.cyber.dhs.gov`) as a recipient of DMARC aggregate reports. As of September 2026.

- The [System owner] shall ensure each second-level domain the system uses has valid SPF and DMARC records, with a DMARC policy of reject for the domain and its mail-sending hosts, as CISA BOD 18-01 requires. (SI-8a)
- The [System owner] shall include `reports@dmarc.cyber.dhs.gov` as a recipient of the domain's DMARC aggregate reports, as CISA BOD 18-01 requires. (SI-8a)

#### Automatic updates (SI-8(2))

- The [System owner] shall ensure spam protection mechanisms are updated automatically [Fill in: the frequency at which to automatically update spam protection mechanisms. Typical: as the vendor releases updates, and at least daily]. (SI-8(2))

#### Information input validation (SI-10)

> **Guidance:** Validate on the server, against an allow list of expected type, length, format and range, and keep data separate from commands (for example, parameterized database queries). Code review and application security testing (SA-11) are where assessors look for evidence.

- The [System owner] shall ensure the system checks the validity of [Fill in: information inputs to the system requiring validity checks. Typical: all inputs from users, external systems and interfaces, including web forms, API requests, file uploads and query parameters]. (SI-10)

#### Error handling (SI-11)

> **Guidance:** Users see a short message and a reference number; the detail, such as stack traces, database errors and internal paths, goes to the logs. Login and password reset messages should not reveal whether an account exists.

- The [System owner] shall ensure the system generates error messages that provide the information needed for corrective action without revealing information that could be exploited. (SI-11a)
- The [System owner] shall ensure the system reveals detailed error messages only to [Fill in: personnel or roles to whom error messages are to be revealed. Typical: system administrators and developers with a need to know, through the system's logs]. (SI-11b)

#### Information management and retention (SI-12)

> **Guidance:** Retention applies to everything the system holds or produces: records, logs, backups, reports and exports. Records management usually owns the retention schedule; the system owner makes the system follow it, including deletion at the end of the period. For personally identifiable information, the retention periods also go in the privacy impact assessment.

- The [System owner] shall manage and retain information within the system, and information output from the system, in accordance with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements. (SI-12)
- The [System owner] shall document the retention period and the authority for it for each type of information the system holds, drawn from the organization's records retention schedule. (SI-12)
- The [System owner] shall dispose of information when its retention period ends, unless a legal hold or an approved extension applies. (SI-12)

##### Federal systems

The head of each federal agency must "make and preserve records containing adequate and proper documentation" of the agency's functions ([44 U.S.C. § 3101](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3101&num=0&edition=prelim)), and federal records "may not be alienated or destroyed" except under chapter 33 of title 44 ([44 U.S.C. § 3314](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3314&num=0&edition=prelim)): that is, under records schedules approved by the Archivist of the United States, including the General Records Schedules the Archivist issues for records common to several or all agencies ([44 U.S.C. § 3303a(d)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3303a&num=0&edition=prelim)). As of September 2026.

- The [System owner] shall retain and dispose of federal records in the system only as an approved agency records schedule or a General Records Schedule allows. (SI-12)

#### Memory protection (SI-16)

> **Guidance:** Modern operating systems provide these protections by default; the evidence is a configuration baseline (CM-6) that keeps them enabled and a scan that shows no exceptions.

- The [System owner] shall implement the following controls to protect the system memory from unauthorized code execution: [Fill in: controls to be implemented to protect the system memory from unauthorized code execution. Typical: data execution prevention and address space layout randomization, enforced by the operating system and hardware]. (SI-16)

### Supply Chain Risk Management (SR)

#### Supply chain risk management plan (SR-2)

> **Guidance:** SR-2 asks for a plan, for each system, that covers supply chain risk across the whole life cycle. NIST's SR-2 discussion says the plan expresses the organization's supply chain risk tolerance, the acceptable mitigation strategies or controls, a process for evaluating and monitoring supply chain risk, how the plan is implemented and communicated, the justification for the mitigation measures taken, and the roles and responsibilities; it can stand alone or be part of the system security and privacy plans. [NIST SP 800-161 Rev. 1](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final), Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (May 2022, updated November 1, 2024; current as of October 2026) recommends a stand-alone plan, and says a plan incorporated into the system security plan must keep its supply chain parts clearly discernible (Appendix A, SR-2, and Appendix D.3). Its Appendix D.3.1 is a sample plan outline, and D.3.1.11 has the plan reviewed at least at life cycle milestones, gate reviews and significant contracting activities. The plan applies the organization-wide supply chain risk management strategy (PM-30) to one system. The [Supply Chain Risk Management Plan](https://kston83.github.io/nist-guide/templates/plans/supply-chain-risk-management-plan/) template follows that outline and the more detailed outline example NIST publishes with SP 800-18 Rev. 2 (June 2026). Assessors examine the plan, its review history and who can read and change it.

- The [System owner] shall develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of [Fill in: systems, system components, or system services for which a supply chain risk management plan is developed. Typical: each system, including the components and services the criticality analysis (RA-9) identifies as critical and the external services the system depends on]. (SR-2a)
- The plan shall be a stand-alone document or a clearly identifiable section of the system security plan. (SR-2a)
- The plan shall state the supply chain risk tolerance it applies from the organization's supply chain risk management strategy (PM-30), the supply chain controls selected for the system (SR-3), the process for evaluating and monitoring supply chain risk, how the plan is implemented and communicated, the justification for each mitigation measure, and the roles and responsibilities for each. (SR-2a)
- The plan shall list the system's critical components and services and their suppliers, drawing on the criticality analysis (RA-9) and the component inventory (CM-8). (SR-2a)
- The authorizing official shall approve the plan and each significant change to it. (SR-2a)
- The [System owner] shall review and update the plan [Fill in: the frequency at which to review and update the supply chain risk management plan. Typical: annually, and at each life cycle milestone or gate review and each significant contracting action, such as a new contract, a renewal or a change of supplier for a critical component or service], and whenever threat, organizational or environmental changes require it. (SR-2b)
- The [System owner] shall protect the plan from unauthorized disclosure and modification by marking it, limiting access to those who need it, and controlling changes to it. (SR-2c)

> **Guidance:** A plan that names critical components, suppliers and known weaknesses is useful to an adversary, which is why SR-2c asks for its protection. Handle it at least as carefully as the system security plan.

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 4.c(4), requires agencies to develop supply chain risk management plans as described in NIST SP 800-161 to ensure the integrity, security, resilience and quality of information systems. Under the Federal Acquisition Supply Chain Security Act of 2018, [41 U.S.C. § 1326](https://www.govinfo.gov/link/uscode/41/1326?link-type=html)(a) and (b) makes the head of each executive agency responsible for assessing the supply chain risk posed by the acquisition and use of covered articles, including developing an overall supply chain risk management strategy and implementation plan and policies and processes, and integrating supply chain risk management practices throughout the life cycle of the system, component, service or asset. The subchapter terminates on December 31, 2033 ([41 U.S.C. § 1328](https://www.govinfo.gov/link/uscode/41/1328?link-type=html)). Text checked in the United States Code, 2024 edition, as of October 2026.

- The [System owner] shall develop the system's supply chain risk management plan as NIST SP 800-161 Rev. 1 describes, as OMB Circular A-130, Appendix I, section 4.c(4), requires. (SR-2a)

#### Establish SCRM team (SR-2(1))

> **Guidance:** NIST's SR-2(1) discussion describes a team-based approach drawing on diverse roles, including the risk executive, information technology, contracting, information security, privacy, mission or business, legal, supply chain and logistics, acquisition and business continuity. It can be an extension of existing security and privacy risk management processes or part of an organizational risk management team. SP 800-161 Rev. 1 calls the central body a C-SCRM program management office. In a small organization the team may be a few people who meet as needed; what matters is that acquisition, security and legal decide together.

- The [Chief Information Security Officer] shall establish a supply chain risk management team consisting of [Fill in: the personnel, roles, and responsibilities of the supply chain risk management team. Typical: a lead the Chief Information Security Officer designates, and representatives of information security, privacy, acquisition and contracting, legal counsel, information technology, the mission or business owners, and business continuity, each with the responsibilities the team charter assigns] to lead and support the following supply chain risk management activities: [Fill in: supply chain risk management activities. Typical: maintaining the supply chain risk management strategy and plans, setting the criteria for supplier assessments and reviewing their results (SR-6), reviewing acquisitions of critical components and services before award, coordinating the response to supply chain compromise notifications (SR-8), and tracking supply chain risks until they are resolved]. (SR-2(1))
- The [Chief Information Security Officer] shall document the team's membership, roles, responsibilities and decision authority in a charter. (SR-2(1))
- The team shall meet at least quarterly, and whenever an acquisition or a supplier notification needs its review, and shall record its decisions. (SR-2(1))

#### Supply chain controls and processes (SR-3)

> **Guidance:** NIST's SR-3 discussion defines supply chain elements as the organizations, entities and tools involved in the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of systems and components. Supply chain processes include hardware, software and firmware development, shipping and handling, personnel and physical security programs, and the configuration management that maintains provenance. Weaknesses in either are potential vulnerabilities. SP 800-161 Rev. 1 points to its Section 2 and Appendix C for implementing SR-3. None of the SR-3 enhancements is in a baseline; the acquisition security requirements standard already requires suppliers to flow security requirements down to subcontractors, which is SR-3(3)'s aim.

- The [System owner] shall establish a process to identify and address weaknesses or deficiencies in the supply chain elements and processes of [Fill in: the system or system component requiring a process or processes to identify and address weaknesses or deficiencies. Typical: each system and the components and services the criticality analysis (RA-9) identifies as critical] in coordination with [Fill in: supply chain personnel with whom to coordinate the process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes. Typical: the supply chain risk management team (SR-2(1)), the procurement office, and the designated supply chain contacts of the suppliers and contractors involved]. (SR-3a)
- The process shall draw on supplier assessments, supplier notifications, inspection results, security advisories, incidents, and changes in a supplier's ownership, location or sources. (SR-3a)
- Each weakness or deficiency found shall be recorded in the risk register or the plan of action and milestones, with an owner, a response and a due date. (SR-3a)
- The [System owner] shall employ the following controls to protect against supply chain risks to the system, system component or system service and to limit the harm or consequences from supply chain-related events: [Fill in: supply chain controls employed to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events. Typical: the controls the supply chain risk management plan selects, including at least the supply chain terms of the acquisition security requirements standard (SA-4, SR-5), supplier assessments (SR-6), notification agreements (SR-8), inspection of components on receipt and after repair (SR-10), anti-counterfeit measures (SR-11) and controlled disposal (SR-12)]. (SR-3b)
- The [System owner] shall document the selected and implemented supply chain processes and controls in [Select one or more: security and privacy plans; supply chain risk management plan; [Assignment: organization-defined document]. Typical: the supply chain risk management plan, summarized and referenced in the security and privacy plans]. (SR-3c)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, section 3.b(8), requires agencies' information security and privacy programs to implement supply chain risk management principles to protect against the insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software, and poor manufacturing and development practices throughout the system development life cycle. [41 U.S.C. § 1326](https://www.govinfo.gov/link/uscode/41/1326?link-type=html)(b)(2) includes integrating supply chain risk management practices throughout the life cycle of the system, component, service or asset in each agency's responsibilities. Text checked in the United States Code, 2024 edition, as of October 2026.

- The [System owner] shall ensure the controls selected under SR-3b protect against the insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software, and poor manufacturing and development practices throughout the system development life cycle, as OMB Circular A-130, Appendix I, section 3.b(8), requires. (SR-3b)

#### Acquisition strategies, tools and methods (SR-5)

> **Guidance:** NIST's SR-5 discussion calls the acquisition process an important vehicle to protect the supply chain, and names tools such as obscuring the end use of a component, blind or filtered buys, tamper-evident packaging, and trusted or controlled distribution. It suggests incentives for suppliers that implement controls and are transparent about their practices, contract language prohibiting tainted or counterfeit components, and restricting purchases from untrustworthy suppliers, chosen in light of the supply chain risk assessment (RA-3(1)). Blind buys and controlled distribution suit high-threat environments; most organizations start with authorized sources, contract terms and supplier assessments. The contract terms themselves live in the [acquisition security requirements](https://kston83.github.io/nist-guide/templates/standards/acquisition-security-requirements/) standard (section 4.5); keep them in step with this clause. SP 800-161 Rev. 1, Section 3, covers supply chain risk management in the acquisition process.

- The [Chief Information Security Officer] shall employ the following acquisition strategies, contract tools and procurement methods to protect against, identify and mitigate supply chain risks: [Fill in: acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks. Typical: the supply chain terms of the acquisition security requirements standard, including identification of the origin of critical components and flow-down to subcontractors; contract language prohibiting counterfeit or tainted components; purchase of hardware and software only from original manufacturers, their authorized distributors or resellers, or suppliers the supply chain risk management team has assessed; a supplier risk assessment before award as part of source selection for critical components and services; and tamper-evident packaging and tracked delivery for hardware]. (SR-5)
- The [Chief Information Security Officer] shall ensure each acquisition of a component or service that the criticality analysis (RA-9) identifies as critical is reviewed by the supply chain risk management team before award. (SR-5)
- The results of the system's supply chain risk assessment (RA-3(1)) shall inform the strategies, tools and methods chosen for each such acquisition. (SR-5)

##### Federal systems

[OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), section 5.d(1)(a), requires agencies, when acquiring information technology, to analyze risks (including supply chain risks) associated with potential contractors and the products and services they provide, and to allocate risk responsibility between Government and contractor. Under [41 U.S.C. § 1323](https://www.govinfo.gov/link/uscode/41/1323?link-type=html)(c)(5) and (7), the Secretary of Homeland Security, the Secretary of Defense and the Director of National Intelligence may issue orders, on the Federal Acquisition Security Council's recommendation, excluding sources or covered articles from executive agency procurement actions or requiring the removal of covered articles from executive agency information systems, and requires executive agencies to comply with those orders; [41 CFR 201-1.304](https://www.ecfr.gov/current/title-41/section-201-1.304) repeats the duty and sets out how an agency requests an exception. [OMB M-26-05](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf), Adopting a Risk-based Approach to Software and Hardware Security (January 23, 2026), requires agencies to develop software and hardware assurance policies and processes that match their risk determinations and mission needs, and lets them choose to use the Secure Software Development Attestation Form and contract terms requiring a current software bill of materials on request; it names CISA's hardware bill of materials framework as a reference. Statute checked in the United States Code, 2024 edition, as of October 2026.

- The [Chief Information Security Officer] shall ensure each acquisition of information technology analyzes the supply chain risks associated with potential contractors and the products and services they provide, and allocates risk responsibility between the Government and the contractor, as OMB Circular A-130, section 5.d(1)(a), requires. (SR-5)
- The [Chief Information Security Officer] shall track the exclusion and removal orders issued under 41 U.S.C. § 1323(c)(5) that apply to the agency, ensure that procurement actions exclude the sources and covered articles they name, and ensure that system owners remove named covered articles from the agency's systems, as 41 U.S.C. § 1323(c)(7) and 41 CFR 201-1.304 require. (SR-5)
- The [Chief Information Security Officer] shall apply the agency's software and hardware assurance policy under OMB M-26-05 when choosing the strategies, tools and methods for each acquisition. (SR-5)

<!-- TODO(verify): FAR provisions that carry supply chain requirements into contracts, such as the clauses implementing exclusion orders under 41 U.S.C. § 1323 and the Section 889 telecommunications prohibition, were not checked. As for SA-4, it is not settled whether the codified FAR or the Revolutionary FAR Overhaul class deviations govern (see Open questions in PROGRESS.md). Cite the FAR here once that is resolved. -->

#### Supplier assessments and reviews (SR-6)

> **Guidance:** NIST's SR-6 discussion lists what a supplier review covers: security and supply chain risk management processes; foreign ownership, control or influence; and the supplier's ability to assess its own second- and third-tier suppliers. Reviews consider documented processes and controls, all-source intelligence and publicly available information, and may be done by the organization or an independent third party. SP 800-161 Rev. 1 adds that assessments should apply a consistent set of core factors and criteria, so suppliers can be compared with each other and over time, and that the sources of information should be documented; its Appendix D.4 is a sample supply chain risk assessment template. For a cloud or other external service, the [external service review](https://kston83.github.io/nist-guide/templates/forms/external-service-review/) (SA-9) and the provider's independent attestation supply much of the evidence. The [supplier assessment questionnaire](https://kston83.github.io/nist-guide/templates/forms/supplier-assessment-questionnaire/) rates the same core risk factors for every supplier and records the source of each finding.

- The [Chief Information Security Officer] shall assess and review the supply chain-related risks associated with suppliers or contractors and the systems, system components or system services they provide [Fill in: the frequency at which to assess and review the supply chain-related risks associated with suppliers or contractors and the systems, system components, or system services they provide. Typical: before each contract award or renewal, and annually for suppliers of critical components and services]. (SR-6)
- Each assessment shall cover the supplier's security and supply chain risk management processes, its foreign ownership, control or influence, its ability to assess its own second- and third-tier suppliers, its documented processes and controls, and publicly available information about it. (SR-6)
- The [Chief Information Security Officer] shall apply the same core risk factors and criteria to every supplier assessment, and record the sources of information each one relied on. (SR-6)
- A contract for a critical component or service shall not be awarded or renewed until its supplier assessment is complete and each risk found is accepted or has a planned response. (SR-6)
- The [Chief Information Security Officer] shall have the supply chain risk management team monitor publicly available information about the suppliers of critical components and services for indications of stolen information, poor development or quality control practices, information spillage or counterfeits. (SR-6)
- The [Chief Information Security Officer] shall share assessment and review results with other organizations only as applicable rules, policies, agreements or contracts allow or require. (SR-6)

##### Federal systems

[41 U.S.C. § 1326](https://www.govinfo.gov/link/uscode/41/1326?link-type=html)(a) makes the head of each executive agency responsible for assessing the supply chain risk posed by the acquisition and use of covered articles, and for prioritizing those assessments based on the criticality of the mission, system, component, service or asset. [NIST SP 800-161 Rev. 1](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final), Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (May 2022, updated November 1, 2024; current as of October 2026), Appendix E, gives federal agencies baseline risk factors (section E.2.2) to address, at a minimum, for assessments of critical sources and covered articles, and says (section E.2.1) that determining assessment priorities, evaluating impact and making risk response decisions are inherently governmental functions that cannot be outsourced, although a qualified, vetted third party may support research and documentation. Under [41 CFR 201-1.201(b)](https://www.ecfr.gov/current/title-41/section-201-1.201), an executive agency must expeditiously submit supply chain risk information to the Federal Acquisition Security Council's information sharing agency when the Council requests it, or when the agency determines there is a reasonable basis to conclude that a substantial supply chain risk exists in connection with a source or covered article. Statute checked in the United States Code, 2024 edition, and regulation in the eCFR, as of October 2026.

- The [Chief Information Security Officer] shall prioritize supplier assessments by the criticality of the mission, system, component, service or asset, as 41 U.S.C. § 1326(a)(2) requires. (SR-6)
- Assessments of critical sources and covered articles shall address every baseline risk factor in NIST SP 800-161 Rev. 1, Appendix E, section E.2.2. (SR-6)
- Agency officials shall set assessment priorities and make each risk response decision; a contractor may support the research and documentation but shall not make those decisions. (SR-6)
- When the agency determines there is a reasonable basis to conclude that a substantial supply chain risk exists in connection with a source or covered article, the [Chief Information Security Officer] shall submit the relevant supply chain risk information to the Federal Acquisition Security Council's information sharing agency, as 41 CFR 201-1.201(b) requires. (SR-6)

#### Notification agreements (SR-8)

> **Guidance:** NIST's SR-8 discussion says early notification of compromises and potential compromises in the supply chain is essential to responding to them, and that shared assessment or audit results can help a supply chain entity resolve a concern or improve its processes. SP 800-161 Rev. 1 adds that, at a minimum, organizations should require their suppliers to establish notification agreements with the entities in their own supply chains that have a role in a critical product or service. The notice times belong in the contract: the [acquisition security requirements](https://kston83.github.io/nist-guide/templates/standards/acquisition-security-requirements/) standard (section 4.6) sets them for incidents and vulnerabilities. Notification in the other direction, from the organization to its suppliers about an incident, is the IR-6(3) clause of the Incident Response Policy.

- The [Chief Information Security Officer] shall establish agreements and procedures with the entities involved in the supply chain for the system, system component or system service for [Select one or more: notification of supply chain compromises; [Assignment: organization-defined results of assessments or audits]. Typical: notification of supply chain compromises, and the results of assessments or audits]. (SR-8)
- Each contract for a critical component or service shall require the supplier to notify the organization of a compromise or suspected compromise in its supply chain that may affect the organization's systems, within the time the acquisition security requirements standard sets for incident notice. (SR-8)
- Each such contract shall require the supplier to establish notification agreements with the entities in its own supply chain that have a role in the critical component or service. (SR-8)
- The [Chief Information Security Officer] shall keep a current notification contact for each supplier of a critical component or service, and give each supplier the organization's contact for supply chain notices. (SR-8)
- The [Incident response team] shall receive each supplier notification of a compromise and handle it under the [incident response plan](https://kston83.github.io/nist-guide/templates/plans/incident-response-plan/), with the supply chain risk management team identifying the affected systems and components. (SR-8)

#### Tamper resistance and detection (SR-9)

> **Guidance:** SR-9 and SR-9(1) are in the High baseline only. NIST's SR-9 discussion says anti-tamper technologies protect against reverse engineering, modification and substitution, and that strong identification combined with tamper resistance or tamper detection is essential during distribution and in use. SP 800-161 Rev. 1 says to apply tamper resistance and detection to critical components at a minimum, using the criticality analysis (RA-9) to find them.

- The [Chief Information Security Officer] shall implement a tamper protection program for the system, system components and system services. (SR-9)
- The program shall cover, at a minimum, the components the criticality analysis (RA-9) identifies as critical. (SR-9)
- The program shall combine strong identification of components, such as serial numbers recorded in the component inventory and cryptographic device identities where components support them, with tamper resistance and tamper detection. (SR-9)
- The program shall protect components in distribution, with tamper-evident packaging and tracked or controlled delivery, and in use, with tamper-evident seals or chassis intrusion detection on critical hardware and verification of firmware and software integrity at startup or installation (SI-7). (SR-9)
- A component that shows evidence of tampering shall be kept out of service and reported as an incident under the incident response plan. (SR-9)

#### Multiple stages of system development life cycle (SR-9(1))

> **Guidance:** NIST's SR-9(1) discussion lists the life cycle phases, from research and development to disposal, and says organizations use a combination of hardware and software techniques, such as obfuscation and self-checking, to make reverse engineering and modification harder; customizing systems and components can make substitution easier to detect.

- The [System owner] shall employ anti-tamper technologies, tools and techniques throughout the system development life cycle: research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal. (SR-9(1))
- Contracts for custom or critical components shall state the anti-tamper requirements the developer or manufacturer must meet in each phase it performs. (SR-9(1))
- The supply chain risk management plan shall record which anti-tamper measures apply in each phase of the life cycle. (SR-9(1))

#### Inspection of systems or components (SR-10)

> **Guidance:** NIST's SR-10 discussion says inspection addresses physical and logical tampering and applies to systems and components removed from organization-controlled areas. It names the indications of a need for inspection: changes in packaging, specifications, factory location or the entity the part is bought from, and individuals returning from travel to high-risk locations. SP 800-161 Rev. 1 says to inspect critical systems and components at a minimum, before use and periodically after, and to put inspection requirements in contracts with suppliers, integrators and service providers, flowed down to subcontractors. The receipt check in the Physical and Environmental Protection Policy (PE-16) is the first inspection of every arriving component; the [component inventory](https://kston83.github.io/nist-guide/templates/forms/component-inventory/) records the result.

- The [System owner] shall inspect [Fill in: systems or system components that require inspection. Typical: the components the criticality analysis (RA-9) identifies as critical, and any component that has been outside organization-controlled areas, such as for off-site repair or travel] [Select one or more: at random; at [Assignment: organization-defined frequency]; upon [Assignment: organization-defined indications of need for inspection]. Typical: before first use and annually thereafter, and upon indications of a need for inspection] to detect tampering. (SR-10)
- Each inspection shall check for physical tampering, such as broken seals, altered packaging, missing or mismatched labels and serial numbers, and signs a case was opened, and for logical tampering, such as firmware or software that does not match the version and the hash or signature the manufacturer publishes. (SR-10)
- Each inspection shall be recorded with the component, the date, who inspected it and the result. (SR-10)
- A component that shows signs of tampering shall be kept out of service and reported under the incident response plan (IR-6). (SR-10)
- Contracts with the suppliers, integrators and service providers of critical components shall require them to inspect those components for tampering, and to flow the requirement down to their subcontractors. (SR-10)

#### Component authenticity (SR-11)

> **Guidance:** NIST's SR-11 discussion names manufacturers, developers, vendors and contractors as sources of counterfeit components, says anti-counterfeit policy and procedures support tamper resistance and protect against malicious code, and names CISA as an external reporting organization. SP 800-161 Rev. 1 says the policy and procedures need input from acquisition, information technology, security, legal and the supply chain risk management team, and should address contract clauses and counterfeit reporting processes, such as the Government-Industry Data Exchange Program (GIDEP), and, where appropriate, qualified bidders or manufacturers lists. The statements below are the anti-counterfeit policy; the procedure sets out the checks for each type of component. SR-11(3), anti-counterfeit scanning, is in no baseline.

- The [Chief Information Security Officer] shall develop and implement anti-counterfeit procedures that include the means to detect and prevent counterfeit components from entering the system. (SR-11a)
- Hardware, software and firmware shall be obtained only from the original manufacturer, its authorized distributors or resellers, or a source the supply chain risk management team has assessed and approved. (SR-11a)
- Each component shall be checked on receipt against the order and the manufacturer's identifiers, such as part and serial numbers, labels and packaging. (SR-11a)
- Software, firmware and updates shall be verified by digital signature or the manufacturer's published hash before installation. (SR-11a)
- A suspected counterfeit component shall be quarantined and kept out of the system until the investigation is complete, and shall not be returned to the seller before then. (SR-11a)
- A counterfeit component found installed in a system shall be handled as an incident under the incident response plan. (SR-11a)
- The [Chief Information Security Officer] shall report counterfeit system components to [Select one or more: source of counterfeit component; [Assignment: organization-defined external reporting organizations]; [Assignment: organization-defined personnel or roles]. Typical: the source of the counterfeit component, the original manufacturer and CISA, and the Chief Information Security Officer, the supply chain risk management team and the system owner]. (SR-11b)

#### Anti-counterfeit training (SR-11(1))

- The [Chief Information Security Officer] shall train [Fill in: personnel or roles requiring training to detect counterfeit system components (including hardware, software, and firmware). Typical: staff who receive, inspect, install or repair hardware, procurement staff who buy system components, and the supply chain risk management team] to detect counterfeit system components, including hardware, software and firmware. (SR-11(1))
- The training shall be part of role-based training (AT-3), completed before the person takes on the duties and annually thereafter. (SR-11(1))
- The training shall cover the organization's anti-counterfeit procedures, how to recognize counterfeit or altered hardware, packaging and software, and how to quarantine and report a suspect component. (SR-11(1))

> **Guidance:** NIST gives no discussion for SR-11(1). SP 800-161 Rev. 1 says the supply chain risk management team can help find training resources and decide who needs the training. Record completions in the training record log, as for other role-based training.

#### Configuration control for component service and repair (SR-11(2))

> **Guidance:** NIST gives no discussion for SR-11(2). SP 800-161 Rev. 1 says configuration control for component service and repair should be integrated into the organization's configuration control processes, and that component authenticity should be addressed in contracts for servicing and repair. The Maintenance Policy covers approval, sanitization and the check after repair (MA-2); this clause keeps a component under control while it is away and before it returns.

- The [System owner] shall maintain configuration control over [Fill in: system components requiring configuration control. Typical: all system components, including servers, network and security devices, storage devices and end-user devices] awaiting service or repair, and over serviced or repaired components awaiting return to service. (SR-11(2))
- A component awaiting service or repair, or awaiting return to service, shall be recorded in the component inventory with the status "under maintenance", and kept in a controlled area or in the custody of an authorized person. (SR-11(2))
- A component sent off site shall be tracked by serial number from departure to return, with the maintenance log recording who had custody of it. (SR-11(2))
- Before a serviced or repaired component returns to service, it shall be checked against its inventory record, inspected for tampering (SR-10), and have its firmware and software verified and its secure baseline configuration restored (CM-2, CM-6). (SR-11(2))
- Contracts for component service and repair shall require genuine replacement parts from the original manufacturer or its authorized channel. (SR-11(2))

#### Component disposal (SR-12)

> **Guidance:** NIST's SR-12 discussion says disposal can happen at any point in the life cycle, not only at retirement, and includes methods such as disk cleaning, removal of cryptographic keys and partial reuse of components. Disposal exposes paper and digital documentation, shipping and delivery records, memory sticks with code, and whole routers or servers with permanent media, and proper disposal keeps components out of the gray market. Sanitization itself follows the Media Protection Policy (MP-6); record it in the [media sanitization record](https://kston83.github.io/nist-guide/templates/forms/media-sanitization-record/), and keep the disposed component in the [component inventory](https://kston83.github.io/nist-guide/templates/forms/component-inventory/) with the status "disposed".

- The [System owner] shall dispose of [Fill in: data, documentation, tools, or system components to be disposed of. Typical: system components, media and devices that hold or have held organizational information, configurations or credentials; system, design and supply chain documentation, including shipping and delivery records; and development, test and maintenance tools] using the following techniques and methods: [Fill in: techniques and methods for disposing of data, documentation, tools, or system components. Typical: sanitization of storage by the method the media sanitization procedure sets for it (MP-6), removal of cryptographic keys, credentials and licenses, destruction of paper documentation by shredding or incineration, and transfer of hardware only to a disposal or recycling provider under contract that certifies destruction or recycling by serial number]. (SR-12)
- These techniques and methods shall apply whenever disposal happens in the life cycle, including during development, testing and maintenance. (SR-12)
- Each disposal of a component shall be recorded with the component's identifiers, the method, who performed and verified it, the date, and the media sanitization record or the provider's certificate. (SR-12)
- A component shall not be resold, donated or returned to a lessor or vendor unless its storage has been purged or destroyed as the Media Protection Policy requires and the [System owner] has approved its release. (SR-12)

## Review and update

- The [Fill in: an official to manage the information security and privacy policy and procedures. Typical: Chief Information Security Officer] shall review and update this policy [Fill in: the frequency at which the current information security and privacy policy is reviewed and updated. Typical: annually] and following [Fill in: events that would require the current information security and privacy policy to be reviewed and updated. Typical: assessment or audit findings, security incidents or breaches, and changes in applicable laws, executive orders, directives, regulations, policies, standards or guidelines]. (XX-1c.1)
- The [Fill in: an official to manage the information security and privacy policy and procedures. Typical: Chief Information Security Officer] shall review and update the procedures that implement this policy [Fill in: the frequency at which the current information security and privacy procedures are reviewed and updated. Typical: annually] and following [Fill in: events that would require procedures to be reviewed and updated. Typical: the same events as the policy, and changes to the systems, tools or services the procedures describe]. (XX-1c.2)

### Federal systems

For federal information systems, this policy also carries out the agency's information security responsibilities under the Federal Information Security Modernization Act of 2014 ([44 U.S.C. § 3554](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3554&num=0&edition=prelim), Federal agency responsibilities) and [OMB Circular A-130](https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf), Appendix I, Responsibilities for Protecting and Managing Federal Information Resources.

- Where the agency's organization-wide policy sets a value for a parameter in this policy, each system shall use that value or a stricter one. (XX-1a.1(b))