System and Services Acquisition Policy

Approval #

Revision History #

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

1. Purpose and Scope #

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

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

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

1.1 Program Objectives #

This policy covers security in what the Organization buys and builds, because weaknesses enter through acquisition and development as well as operations. Every solicitation must include security and privacy requirements. Developers must follow secure development under NIST SP 800-218 (SSDF). The Organization must apply the risk-based software and hardware assurance in OMB M-26-05, which rescinded the M-22-18 attestation regime. The Organization must require software bill of materials (SBOM) delivery that meets the Cybersecurity and Infrastructure Security Agency (CISA) 2026 minimum elements. Developers must test their products and provide evidence, and the Organization applies the engineering principles in SP 800-160 from design onward.

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

1.2 CSF 2.0 Alignment #

The controls in this policy support these CSF 2.0 categories:

• GV.SC — Cybersecurity Supply Chain Risk Management (Govern function)
• ID.AM — Asset Management (Identify function)

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

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

• SA-01 — Policy and Procedures
• SA-02 — Allocation of Resources
• SA-03 — System Development Life Cycle
• SA-04 — Acquisition Process
• SA-04(10) — Use of Approved PIV Products
• SA-05 — System Documentation
• SA-08 — Security and Privacy Engineering Principles
• SA-08(33) — Minimization
• SA-09 — External System Services
• SA-11 — Developer Testing and Evaluation
• SA-22 — Unsupported System Components

2. Authority and References #

The CISO issues this policy under the authority of:

• FISMA 2014 (44 U.S.C. § 3551 et seq.) — Statutory mandate for federal information security programs
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• OMB Circular A-130 — Managing Information as a Strategic Resource
• OMB Circular A-123 — Management’s Responsibility for Internal Control (revised March 10, 2026)
• NIST CSF 2.0 — Cybersecurity Framework (mandated by EO 13800 and OMB Circular A-130)
• EO 13800 — Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026.
• OMB M-17-12: Preparing for and Responding to a Breach of Personally Identifiable Information, May 22, 2017.
• OMB M-07-18: Ensuring New Acquisitions Include Common Security Configurations, June 1, 2007.
• OMB M-25-22: Driving Efficient Acquisition of Artificial Intelligence in Government, April 3, 2025.
• OMB M-26-04: Increasing Public Trust in Artificial Intelligence Through Unbiased AI Principles, December 11, 2025.
• Executive Order 14319: Preventing Woke AI in the Federal Government, July 23, 2025.
• OMB M-26-02: Ensuring Government Use of Secure Unmanned Aircraft Systems and Supporting United States Producers, November 21, 2025.
• FAR 52.204-21: Basic Safeguarding of Covered Contractor Information Systems, June 15, 2016.
• FAR 52.204-30: Federal Acquisition Supply Chain Security Act Orders — Prohibition (with FAR 52.204-29 representation and disclosures), December 4, 2023.
• FAR 52.204-25: Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment (Section 889; with FAR 52.204-24 and 52.204-26 representations), August 13, 2020.
• FAR Part 40: Information Security and Supply Chain Security, April 1, 2024.
• NIST SP 800-218: Secure Software Development Framework (SSDF), February 2022.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.

2.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the SA control family. They add to the NIST SP 800-53 control requirements in the Policy section.

NIST SP 800-218: Secure Software Development Framework (SSDF)

• The organization must follow the Secure Software Development Framework practice groups: prepare the organization (PO), protect the software (PS), produce well-secured software (PW), and respond to vulnerabilities (RV). (NIST SP 800-218, §4)

NIST SP 800-160: Engineering Trustworthy Secure Systems

• The organization must integrate systems security engineering into the full system lifecycle, applying principles of trustworthy secure design, development, and evaluation. Security must be engineered, not bolted on. (NIST SP 800-160v1r1, §3)

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

• The organization must ask a FedRAMP authorized provider for information or security requirements beyond FedRAMP’s rules only when the agency head or a delegate documents a demonstrable need and notifies FedRAMP. (FedRAMP Consolidated Rules for 2026, AGU-AGC-NAR)

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

• The organization must include SBOM delivery requirements in software acquisition and development contracts, and use available tooling to generate, ingest, and analyze machine-processable SBOM data to support risk-informed acquisition decisions. (CISA 2026 SBOM Minimum Elements, Machine-Processable Data)

OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security

• The organization must maintain a complete inventory of software and hardware, and establish software and hardware assurance policies and processes that match the organization’s risk determinations and mission needs. The producer self-attestation regime of the rescinded memos M-22-18 and M-23-16 no longer applies; do not require attestation forms as a blanket procurement gate. (OMB M-26-05)

OMB M-25-22: Driving Efficient Acquisition of Artificial Intelligence in Government

• The organization must update internal acquisition procedures so that Super Intelligence (SI) systems and services are procured fit for purpose, with attention to vendor sourcing, data portability, and interoperability to avoid vendor lock-in, with contractual terms that delineate government and contractor data ownership and intellectual-property rights, and with early and ongoing Senior Agency Official for Privacy involvement whenever the SI will handle personally identifiable information. Deadline: Solicitations on or after 2025-09-30; procedures updated by 2025-12-29. (OMB M-25-22, §3)

OMB M-17-12: Preparing for and Responding to a Breach of Personally Identifiable Information

• The organization must include in contracts the terms the Organization needs to respond to a breach, including that the contractor reports a suspected or confirmed breach in any medium and cooperates with the response. (OMB M-17-12, Section V)
• The organization must require contractors to train staff on breach reporting and to cooperate fully with the Organization’s breach investigations. (OMB M-17-12, Section V)

OMB M-24-15: Modernizing the Federal Risk and Authorization Management Program (FedRAMP)

• The organization must require FedRAMP authorization for each cloud product or service in FedRAMP’s scope before it creates, collects, processes, stores, or maintains federal information. (OMB M-24-15, §IV)

44 U.S.C. §§ 3607-3616: FedRAMP Authorization Act

• The organization must check the FedRAMP repository for an existing authorization before assessing a cloud product or service, and reuse that authorization package to the extent practicable. (44 U.S.C. § 3613)

Pub. L. 116-207: Internet of Things Cybersecurity Improvement Act of 2020

• The organization must buy or use only Internet of Things devices that meet NIST SP 800-213, unless the CIO grants a waiver the IoT Cybersecurity Improvement Act allows. (Pub. L. 116-207, § 7; 15 U.S.C. § 278g-3e)

29 U.S.C. § 794d: Section 508 of the Rehabilitation Act of 1973 (Electronic and Information Technology)

• The organization must ensure that information and communication technology the Organization develops, buys, maintains, or uses gives people with disabilities comparable access, unless an undue burden would result. (29 U.S.C. § 794d; FAR Subpart 39.2)

36 CFR Part 1194: Information and Communication Technology Standards and Guidelines (Revised 508 Standards, 36 CFR Part 1194)

• The organization must include the Revised 508 Standards in the requirements for every information and communication technology purchase, and evaluate offers against them. (36 CFR Part 1194; FAR 39.203)

OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6)

• The organization must include USGv6 (NIST SP 500-267B Rev. 1) capability requirements in solicitations for networked IT products and services, as FAR 11.002(g) requires. (OMB M-21-07; FAR 11.002(g))

FAR 52.224-2: Privacy Act

• The organization must include FAR 52.224-1 and 52.224-2 in contracts that require the contractor to design, develop, or operate a system of records on individuals. (FAR 24.104; FAR 52.224-1; FAR 52.224-2)

FAR 52.224-3: Privacy Training

• The organization must include FAR 52.224-3 when contractor employees will handle personally identifiable information or access, design, develop, maintain, or operate a system of records. (FAR 24.302; FAR 52.224-3)

FAR 52.239-1: Privacy or Security Safeguards

• The organization must include FAR 52.239-1 in contracts for information technology that require IT security or the design, development, or operation of a system of records. (FAR 39.107; FAR 52.239-1)

FAR 52.204-9: Personal Identity Verification of Contractor Personnel

• The organization must include FAR 52.204-9 in contracts that require contractor employees to have routine physical access to a federal facility or access to a federal information system. (FAR 4.1303; FAR 52.204-9)

OMB M-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management (ICAM)

• The organization must buy PIV and ICAM products and services that meet OMB policy and NIST standards, such as those on the GSA Approved Products List. (OMB M-19-17, §IV Acquisition 2)

32 CFR Part 2002: Controlled Unclassified Information

• The organization must use NIST SP 800-171 to set the security requirements for CUI on a contractor’s own systems, unless the CUI Registry or the agreement sets stronger protection. (32 CFR 2002.14(h)(2))
• The organization must require each contractor that receives CUI to handle it under Executive Order 13556, 32 CFR Part 2002, and the CUI Registry, and to report non-compliance to the agency. (32 CFR 2002.16(a)(5)-(6))

CUI Notice 2020-04: Assessing Security Requirements for CUI in Non-Federal Information Systems

• The organization must assess a contractor’s CUI protection only on the systems that hold the CUI and only against the contract, using NIST SP 800-171A, after telling the contractor the scope and methods. (CUI Notice 2020-04, paras. 6 and 9)

OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography

• The organization should use the CISA list of product categories for technologies that use post-quantum cryptography standards, and require PQC integration in every purchase that falls in a listed category. Ask FedRAMP-authorized cloud service providers to set out PQC migration duties within the shared responsibility model. (OMB M-26-15, §3.C.4 (Vendor and Third-Party Software))

OMB M-26-04: Increasing Public Trust in Artificial Intelligence Through Unbiased AI Principles

• The organization should include contractual requirements addressing the Unbiased AI Principles (truth-seeking and ideological neutrality) in every solicitation or order for a large language model, obtain enough vendor information to judge compliance, and maintain a process for users to report outputs that violate the principles. Deadline: Policies updated by 2026-03-11; memo sunsets 2027-12-11. (OMB M-26-04, Agency Actions)

OMB M-26-02: Ensuring Government Use of Secure Unmanned Aircraft Systems

• The organization should treat any unmanned aircraft system procurement as both an aircraft and an information technology system: complete a joint FIPS 199 impact assessment before procurement, document the minimum security capabilities the system will meet, and record any statutory exemption relied on in the system security plan and contract file. Deadline: Procurement policy by 2026-05-20. (OMB M-26-02, Appendix B)

FAR 52.204-21: Basic Safeguarding of Covered Contractor Information Systems

• The organization should flow FAR 52.204-21 basic safeguarding requirements into contracts where contractor information systems process, store, or transmit federal contract information, and require NIST SP 800-171 protections where the contractor handles CUI. (FAR 52.204-21)

OMB M-07-18: Ensuring New Acquisitions Include Common Security Configurations

• The organization should require in each solicitation for information technology that products work on the Organization’s approved secure configuration baselines, keep those settings when installed or patched, and run without administrator privileges for ordinary users. (OMB M-07-18)

NIST SP 800-213: IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements

• The organization should set cybersecurity requirements for each Internet of Things device purchase from the NIST SP 800-213 device capabilities, based on the system’s risk. (NIST SP 800-213, §§2-3)

3. Policy #

The Organization must implement and maintain its system and services acquisition controls to meet the following requirements:

SA-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)

Requirement:

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

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

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

2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;

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

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

Implementation guidance:

The Organization must keep a system and services acquisition policy and the procedures that put it into practice. The policy covers every purchase of systems, components, and services. It states its purpose and scope, assigns roles, records management’s commitment, and sets expectations for coordination and compliance. The CISO owns both documents. The CISO develops them, documents them, and sends each approved version to the Authorizing Official (AO), System Owners, Information System Security Officers (ISSOs), and key stakeholders. The CISO must review and update the policy and the procedures every year. The CISO must also update them sooner when the Organization identifies a new supply chain risk or when a federal requirement changes how it buys services or material. Under OMB M-26-05, the policy links every software and hardware purchase to the Organization’s complete inventory and to an assurance determination that matches the risk of the product and its use. Acquisition review and security review therefore run as one approval step.

SA-02 — Allocation of Resources #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)

Requirement:

1. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;
2. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and
3. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.

Implementation guidance:

System Owners must define the high-level information security and privacy requirements for each system or service during mission and business process planning. They must do this before the Organization issues a solicitation. The Chief Information Officer (CIO) must make sure the Organization identifies, documents, and allocates the resources needed to protect each system. This happens through the Organization’s capital planning and investment control process. The CISO must confirm that the allocation covers the documented protection requirements. The Organization must show information security and privacy as a separate line item in its programming and budgeting documents. This keeps the funding visible and traceable. The CIO must return any investment request that arrives without security and privacy resourcing to the System Owner for correction. The request must not compete for funds until the System Owner corrects it.

SA-03 — System Development Life Cycle #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)

Requirement:

1. Acquire, develop, and manage the system using [Assignment: organization-defined system-development life cycle — to be defined] that incorporates information security and privacy considerations;
2. Define and document information security and privacy roles and responsibilities throughout the system development life cycle;
3. Identify individuals having information security and privacy roles and responsibilities; and
4. Integrate the organizational information security and privacy risk management process into system development life cycle activities.

Implementation guidance:

The Organization must acquire, develop, and manage every system under the Organization system development life cycle (SDLC) standard operating procedure (SOP). The SOP builds information security and privacy work into each life cycle phase, from concept to disposal. System Owners must define and document the security and privacy roles for their systems at every life cycle stage. They must name the person who fills each role, so that no role is left empty between phases. The CISO must integrate the Organization’s security and privacy risk management process into life cycle activities. The CISO must use the systems security engineering approach in NIST SP 800-160v1r1. Under that approach, engineers design protection into the system during requirements and architecture work. The ISSO must not clear a phase gate until the security roles for that phase are staffed and its risk activities are complete.

SA-04 — Acquisition Process #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)

Requirement:

Include the following requirements, descriptions, and criteria, explicitly or by reference, using [Selection (one or more): standardized contract language; [Assignment: organization-defined contract language — to be defined] — to be defined] in the acquisition contract for the system, system component, or system service: a. Security and privacy functional requirements; b. Strength of mechanism requirements; c. Security and privacy assurance requirements; d. Controls needed to satisfy the security and privacy requirements. e. Security and privacy documentation requirements; f. Requirements for protecting security and privacy documentation; g. Description of the system development environment and environment in which the system is intended to operate; h. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and i. Acceptance criteria.

Implementation guidance:

The Organization must place its security and privacy requirements in every acquisition contract for a system, system component, or system service. These include functional, strength, and assurance requirements, plus documentation, configuration, and acceptance criteria. The CISO and the System Owner must define the requirements for each acquisition. Each acquisition must start as a request in the IT intake system, which the IT Intake Team reviews with the CISO’s office, the Privacy Officer, the Section 508 Program Manager, IT Operations, and the Application Development Team. The program office must write the requirements into the statement of work. The Contracting Officer must build the contract in the contract writing system and confirm before award that the Federal Acquisition Regulation (FAR) clauses that apply are present. Under OMB M-26-05, the CISO must set the risk-based assurance evidence each software or hardware purchase must carry, including secure development evidence aligned to NIST SP 800-218 where the risk warrants it. Each contract must require machine-processable SBOMs that meet the CISA 2026 SBOM Minimum Elements, on request for cloud platforms. Contracts must also carry the terms that apply to the purchase. These include FedRAMP authorization for cloud services under OMB M-24-15 and the Internet of Things device rules in the Internet of Things (IoT) Cybersecurity Improvement Act of 2020. They also include the Revised Section 508 Standards, the USGv6 profile for networked products, and the FAR privacy clauses. “Security and Privacy Contract Terms” in the System and Services Acquisition procedure lists each term.

SA-04(10) — Use of Approved PIV Products #

Baselines: Low / Moderate / High

Requirement:

Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.

Implementation guidance:

The Organization must use only information technology products on the Federal Information Processing Standards (FIPS) 201-approved products list for any PIV capability in its systems. The ISSO must verify that a product appears on the approved list before purchase. The System Owner must confirm that the deployed product matches the approved one. The System Owner must remove from service any PIV component that does not match an entry on the approved products list.

SA-05 — System Documentation #

Baselines: Low / Moderate / High

Requirement:

1. Obtain or develop administrator documentation for the system, system component, or system service that describes:

1. Secure configuration, installation, and operation of the system, component, or service;
2. Effective use and maintenance of security and privacy functions and mechanisms; and
3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;

2. Obtain or develop user documentation for the system, system component, or system service that describes:

1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;
2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and
3. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;

3. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take [Assignment: organization-defined actions — to be defined] in response; and
4. Distribute documentation to at a minimum, the ISSO (or similar role within the organization).

Implementation guidance:

For every system, component, and service, the System Owner must obtain or develop administrator documentation. It must cover secure setup and operation, the use and upkeep of security and privacy functions, and the known weaknesses around administrative and privileged functions. The System Owner must also obtain or develop user documentation. It must explain the security and privacy functions available to users, how to use the system securely, and what users are responsible for. If the System Owner cannot obtain the documentation, the System Owner must record each attempt and must have the material developed in-house or by a third party. The System Owner must distribute the documentation at minimum to the AO, the System Owner, the ISSO, and the System/Application Administrator. The System Owner must protect it according to the sensitivity of what it reveals.

SA-08 — Security and Privacy Engineering Principles #

Baselines: Low / Moderate / High CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)

Requirement:

Apply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: [Assignment: organization-defined systems security and privacy engineering principles — to be defined].

Implementation guidance:

The Organization must apply its adopted engineering principles to the specification, design, development, implementation, and modification of every system and component. The principles are zero-trust design, continuous monitoring planned with metrics from the start, and security testing and evaluation across the entire life cycle. System Owners must make sure engineers document, for each engineering decision, which principles they applied and how. This is consistent with the trustworthy design approach in NIST SP 800-160v1r1. For existing systems, System Owners must apply the principles to upgrades and modifications as far as the installed base allows and must document the limits. The CISO must review every engineering deviation from the principles. The Organization treats a deviation without a recorded rationale and CISO approval as a defect.

SA-08(33) — Minimization #

Baselines: Privacy

Requirement:

Implement the privacy principle of minimization using [Assignment: organization-defined processes — to be defined].

Implementation guidance:

System Owners must apply the minimization principle to every system that handles personally identifiable information (PII). They must do this through [SA-08(33) parameter 1 — to be defined]. Each system must collect, use, and keep only the PII that an approved business function needs. System Owners must repeat the review before they add a new data field or a new use of PII. When a Super Intelligence (SI) system will handle PII, the Senior Agency Official for Privacy (SAOP) must take part in the review from the start, per OMB M-25-22.

SA-09 — External System Services #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management), ID.AM (Asset Management)

Requirement:

1. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: Appropriate FedRAMP Security Controls Baseline (s) if Federal information is processed or stored within the external system;
2. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and
3. Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored.

Implementation guidance:

External system services take one of two paths. A service that collects or keeps Organization information for the Organization must hold a FedRAMP authorization when it is a cloud service, and the Authorizing Official must authorize its use. An external service that OMB M-24-15 places outside FedRAMP scope may keep no Organization information. It may briefly process non-sensitive information only as an information provider with a no-retention setting, and the section “Reviewing External Services” sets its review. Providers of authorized services must comply with the Organization’s security and privacy requirements and implement the controls that the CISO and the System Owner select. The Contracting Officer puts those controls in the contract. Continuously, the ISSO reviews each authorized provider’s independent assessment, such as its FedRAMP, FISMA, or Statement on Standards for Attestation Engagements (SSAE) 18 report. At the same interval, the System Owner must confirm in writing that the service is still in use, its data types have not changed, and the provider’s assessment is current. The AO keeps accountability for the risk of every external system service. The Organization must stop using a provider that cannot show its controls through independent reporting.

SA-11 — Developer Testing and Evaluation #

Baselines: Moderate / High / Privacy CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)

Requirement:

Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to: a. Develop and implement a plan for ongoing security and privacy control assessments; b. Perform [Selection (one or more): unit; integration; system; regression — to be defined] testing/evaluation [Assignment: organization-defined frequency to conduct — to be defined] at [Assignment: organization-defined depth and coverage — to be defined]; c. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during testing and evaluation.

Implementation guidance:

The Contracting Officer must require, in each contract, that developers develop and follow a security and privacy assessment plan at every stage after design. The developer must test and evaluate the system at installation and at least twice a month after that. The testing must include vulnerability scanning and security configuration benchmark scanning. The developer must deliver evidence that it carried out the plan and what the testing found. The developer must run a verifiable flaw remediation process that corrects what the testing finds. The System Owner must not accept a deliverable until the ISSO has reviewed its assessment plan and results. A flaw that the developer finds and fixes shows the process working. A flaw that the developer finds and ships without fixing is a contract violation. The Contracting Officer’s Representative must report it to the Contracting Officer, who must use the contract’s remedies.

SA-22 — Unsupported System Components #

Baselines: Low / Moderate / High CSF 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)

Requirement:

1. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
2. Provide the following options for alternative sources for continued support for unsupported components [Selection (one or more): in-house support; [organization-defined] — to be defined].

Implementation guidance:

When developer, vendor, or manufacturer support for a system component ends, the System Owner must replace the component. If the Organization cannot replace it at once, the System Owner must arrange continued support. That support is either in-house, by developing customized patches for critical software, or through an external provider under contract to sustain the designated components. The CISO must approve the arrangement and must document the residual risk. The System Owner must remove from service any unsupported component that has no approved support arrangement. The System Owner must track end-of-support dates in advance, so that the Organization plans each replacement, funds it through the ordinary acquisition process, and completes it before support ends.

Reviewing External Services #

An external service is an internet-based service that staff use with no FedRAMP authorization and no Organization authorization to operate. OMB M-24-15 says FedRAMP does not apply to every use of an internet-based service, and lists the services outside its scope. FedRAMP’s 2026 scope guidance explains each category with examples, and says only the agency can decide whether its use of a service is within scope. Organization information means any information the Organization creates, collects, or holds that is not approved for public release, including what users type, upload, or search for in a service.

• No external service may store or maintain Organization information. It may process or transmit Organization information only as an information provider allows, in the rule that follows.
• An information provider, such as a business and risk intelligence service, may briefly process non-sensitive Organization information, such as a name or address, to answer a request. It keeps none of that information after the request, and the Organization does not rely on it to keep any.
• Before staff send a request to an information provider, the System Owner must turn on the provider’s no-retention setting, which some providers call zero footprint, and get the provider’s written confirmation that it keeps no request data. Staff must never send Controlled Unclassified Information (CUI) or sensitive personally identifiable information.
• A provider’s cloud service that would collect or keep Organization information for the Organization is within FedRAMP scope. It must hold a FedRAMP authorization, and the Authorizing Official must authorize its use under “Using FedRAMP and FedRAMP 20x Authorized Cloud Services” in the Assessment, Authorization, and Monitoring Policy.
• Without a FedRAMP authorization, staff may use only a service that OMB M-24-15 places outside FedRAMP scope. The four kinds are social media and communications platforms used under the social media policy, search engines, widely available services that supply commercially available information and collect no federal information, and ancillary services whose compromise poses negligible risk.
• The CISO must answer FedRAMP’s four use case indicators for each request and record the answers. First, does the use fall under the agency’s information resource duties in 44 U.S.C. 3506? Second, does it need an agency tenant or central administration? Third, does it connect to enterprise security services such as single sign-on or the security information and event management (SIEM) system? Fourth, is it offered to several agencies or others? All yes means FedRAMP scope. All no means this review. A mix means the CISO decides from FedRAMP’s category guidance and records the reasons. Signing in through the single sign-on (SSO) service answers the third indicator yes, so the CISO weighs it with the other three.
• An official account on a social media or communications platform may publish only content approved for public release under the social media policy.
• A system the Organization builds on cloud infrastructure or a cloud platform only for its own operations, not offered as a shared service or run under a shared responsibility model, is outside FedRAMP scope. It is an Organization information system and needs its own authorization to operate.
• Software a provider delivers for installation on Organization systems, such as agents, clients, and mobile apps, is not a cloud service. It goes through software approval, not this review.
• The CISO must review, and the Privacy Officer must screen, each use case at each office before anyone uses an external service. An approval for one office or purpose does not cover another.
• Staff must sign in to each external service through the SSO service when the service supports it. Where it does not, the CISO may approve a separate account with a unique password, and with multi-factor authentication where the service offers it.
• Being outside FedRAMP scope does not remove privacy, records management, or accessibility requirements.
• The System Owner must record each approved external service in the System Security and Privacy Plan (SSPP) of the system whose work it supports. The ISSO must record the approval and its conditions in the governance, risk, and compliance (GRC) system.
• A user who finds that Organization information reached an external service beyond what its approved use case allows must report it at once as a suspected incident. The CISO must stop the service’s use until a new review is complete.

Source: OMB M-24-15, Modernizing the Federal Risk and Authorization Management Program (July 25, 2024), section III and footnote 7; FedRAMP Authorization Act, 44 U.S.C. 3614(1)(A); FedRAMP Consolidated Rules for 2026, version 2026.10.13.01: MAS-CSO-IIR notes, MKT-IIP-AGU, and MKT-FRP-SOF, with FedRAMP’s guidance “Scope of FedRAMP” in the same rules (agency use case indicators and the information provider category); NIST SP 800-145; OMB M-10-23; NIST SP 800-53 SA-09, AC-20, CM-10, CM-11, PL-04(01).

Security and Privacy Contract Terms #

FISMA covers systems that contractors operate for an agency (44 U.S.C. 3554(a)(1)(A)(ii)). Each contract where a contractor operates a system or handles federal information must carry the terms in this section. The terms come from the IT intake review and from the clauses the contract writing system adds.

• Each new IT purchase, renewal, cloud service, or contract that includes IT must start as a request in the IT intake system.
• The IT Intake Team must review each request before a solicitation goes out. The reviewers are the CISO’s office, the Privacy Officer, the Section 508 Program Manager, IT Operations, and the Application Development Team. Each sets the requirements its area needs.
• The program office must write the requirements from that review into the statement of work.
• No contractor may operate a system for the Organization before the Authorizing Official authorizes it.
• The Contracting Officer must build each solicitation and contract in the contract writing system, which adds the required clauses from the FAR and the acquisition regulation supplement automatically.
• The Contracting Officer must confirm that the clauses that depend on the facts of the purchase are present. These include FAR 52.224-1, 52.224-2, and 52.224-3 for a system of records or PII, and FAR 52.239-1 for information technology.
• The Contracting Officer must also confirm FAR 52.204-9 when contractor staff need routine access to a federal facility or system.
• The Organization must not buy an Internet of Things device that fails NIST SP 800-213 unless the CIO grants a waiver under the IoT Cybersecurity Improvement Act.
• Each solicitation for information and communication technology must require the Revised 508 Standards and an Accessibility Conformance Report. The Section 508 Program Manager sets the accessibility requirements during the intake review.
• Each solicitation must require products that conform to the USGv6 profile when they use Internet Protocol, unless the CIO waives it (FAR 11.002(g), OMB M-21-07).

Source: 44 U.S.C. 3554(a)(1)(A)(ii); OMB M-17-12; FAR 52.204-9, 52.224-1, 52.224-2, 52.224-3, and 52.239-1; FAR 11.002(g); 36 CFR 1222.32; NIST SP 800-88; IoT Cybersecurity Improvement Act of 2020 (15 U.S.C. 278g-3a to 278g-3e); NIST SP 800-213; Section 508 of the Rehabilitation Act (29 U.S.C. 794d) and 36 CFR Part 1194; OMB M-21-07.

Contractor Systems That Handle CUI #

This section covers contractors that process, store, or transmit the Organization’s CUI on systems the contractor owns or runs. Under 32 CFR 2002.14(h)(2), such a system is a non-federal information system. Contractors often keep CUI in a separate part of their network or cloud, called an enclave. The enclave is the set of people, assets, and services that hold, process, send, or protect the CUI. The steps are in the System and Services Acquisition procedure.

• The Program Office must identify and mark the CUI a contractor will handle before the Organization shares it or awards the contract.
• The Contracting Officer must include CUI terms in each contract or agreement that lets a contractor handle CUI on the contractor’s own systems.
• Under those terms, the contractor must handle CUI under Executive Order 13556, 32 CFR Part 2002, and the CUI Registry. The contractor must also report any failure to handle CUI as required (32 CFR 2002.16(a)(6)).
• Under those terms, the contractor must protect the CUI with the security requirements of NIST SP 800-171, in the revision the contract names (32 CFR 2002.14(h)(2)).
• The CISO must name NIST SP 800-171 Revision 3 unless the CISO records a reason to name Revision 2. One such reason is accepting a Cybersecurity Maturity Model Certification (CMMC) Level 2 assessment, which uses Revision 2 (32 CFR 170.14).
• The CISO may add NIST SP 800-172 requirements only when the CUI supports a critical program or a High Value Asset.
• The contractor must document the enclave boundary in its system security plan, with a network diagram and an asset inventory. The contractor must also list each external service provider that handles the CUI.
• The contractor may use a cloud service provider for the CUI only if the provider holds a FedRAMP Moderate or higher authorization, or meets equivalent security requirements.
• The Organization must not treat a contractor’s own system as an agency system. The CISO may assess only the contractor systems that store, process, or transmit the CUI, and only against the contract (CUI Notice 2020-04).
• The contractor must report a CUI incident to the Contracting Officer and the Security Operations Center within 8 hours of discovery, as the contract requires.
• When the CUI includes PII, the Contracting Officer must also include the breach reporting terms from the Breach Response Plan.
• The contractor must put the same CUI terms in each subcontract that gives a subcontractor access to the CUI.
• At the end of the contract, the contractor must return or destroy all CUI and give the Contracting Officer’s Representative a signed certificate. The contractor must destroy CUI under 32 CFR 2002.14(f) and NIST SP 800-88.
• The System Owner and the ISSO must set up an interconnection security agreement (ISA) before a contractor enclave connects to an Organization system. The Authorizing Official must approve the connection.
• The CMMC Program in 32 CFR Part 170 applies only to Department of Defense contracts. For the Organization’s contracts, the Contracting Officer may accept a CMMC certificate as evidence.
• The Contracting Officer must not require a CMMC certificate unless a final FAR rule allows it or the Office of the General Counsel confirms the Organization’s authority in writing.

Before the solicitation, the CISO must decide which of these kinds of evidence each contract requires, based on the kind and amount of CUI involved:

• the contractor’s own assessment under NIST SP 800-171A, with its system security plan and its plan of action and milestones (POA&M);
• an assessment under NIST SP 800-171A by an independent assessor the contractor hires;
• a current CMMC Level 2 certificate from a Certified Third-Party Assessment Organization (C3PAO), where the contractor has one. Because CMMC uses Revision 2, the contractor adds its own assessment of any Revision 3 requirements the certificate does not cover;
• for each cloud service provider in the enclave, its FedRAMP Marketplace listing at Moderate or higher, or the provider’s evidence of equivalent security requirements.

These roles carry out this section:

• CUI Senior Agency Official: approves the CUI terms the Organization uses with contractors and the way contractors report a failure to handle CUI as required.
• CUI Program Manager: helps the Program Office identify and mark CUI, and keeps the list of contracts that involve CUI.
• CISO: sets the security requirement and the evidence for each contract, reviews the evidence, and advises the Contracting Officer before award.
• SAOP: decides whether the CUI includes PII and sets the privacy and breach terms.
• Contracting Officer: puts the terms in the solicitation and the contract, and decides whether an offeror meets them.
• Contracting Officer’s Representative: checks the contractor against the requirements checklist during the contract and at close-out.
• Program Office: identifies the CUI the work needs and shares only that CUI.
• System Owner and ISSO: handle any connection between the enclave and an Organization system, and any contractor accounts on Organization systems.
• Office of the General Counsel: advises on the Organization’s authority to require a particular assessment or certificate.

Source: 32 CFR Part 2002, Controlled Unclassified Information (2002.14(h)(2), 2002.14(f), 2002.16(a)(5) and (a)(6)); CUI Notice 2020-04, Assessing Security Requirements for CUI in Non-Federal Information Systems (June 16, 2020); NIST SP 800-171 Rev. 3 and SP 800-171A Rev. 3 (May 2024); NIST SP 800-172 Rev. 3 (May 2026); NIST SP 800-88 Rev. 2; FAR overhaul proposed rule for FAR 52.240-6 and 52.240-7 (91 FR 37550, June 23, 2026; not final as of October 2026); 32 CFR Part 170, CMMC Program, and the DFARS CMMC rule, DFARS Case 2019-D041 (Department of Defense contracts only).

Related Required Processes #

• Each contract for a system or service that handles the Organization’s information requires the contractor to report incidents to the Security Operations Center. Cloud service providers report under the FedRAMP incident rules. The steps are in the Incident Response procedure.
• Each purchase of a system or service that will handle PII starts with a privacy threshold analysis at intake. The steps are in the Personally Identifiable Information Processing and Transparency procedure.
• Each IT purchase, including a purchase-card buy, gets a supply chain review by the CISO before award. The review tiers are in the Supply Chain Risk Management procedure.
• The Contracting Officer and the Contracting Officer’s Representative follow the cloud service steps under Using FedRAMP and FedRAMP 20x Authorized Cloud Services in the Assessment, Authorization, and Monitoring procedure.

4. Roles and Responsibilities #

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

5. Performance Measurement #

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

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

6. Compliance and Enforcement #

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

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

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

7. Continuous Improvement #

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

1. Review the performance measures in this document at least annually; where a measure has met its target for four consecutive periods, tighten the target or replace the measure with a more demanding indicator.
2. Conduct an annual effectiveness review of this policy area using IG FISMA audit results, assessment findings, incident data, and metric trends; document resulting changes in the revision history.
3. Feed lessons learned from incidents, assessments, and exercises into updates of this document and its procedures within 90 days of the triggering event.
4. Benchmark against the IG FISMA maturity model annually and maintain a documented plan to reach and sustain Level 4 (Managed and Measurable), with a roadmap toward Level 5 (Optimized).
5. Verify vendor assurance evidence and SBOMs automatically at intake, rejecting deliveries that fail minimum-element validation.

8. Exceptions and Waivers #

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

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

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

9. References #

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

• 32 CFR Part 170: Cybersecurity Maturity Model Certification (CMMC) Program, December 16, 2024.
• 32 CFR Part 2002: Controlled Unclassified Information, September 14, 2016.
• 36 CFR Part 1222: Creation and Maintenance of Federal Records, current text.
• 2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA/NSA/FBI joint guidance: CISA/NSA/FBI joint guidance, July 29, 2026.
• CUI Notice 2020-04: Assessing Security Requirements for CUI in Non-Federal Information Systems, June 16, 2020.
• CUI Registry.
• Executive Order 13556: Controlled Unclassified Information, November 4, 2010.
• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Executive Order 14319: Preventing Woke AI in the Federal Government, July 23, 2025.
• FAR 52.204-9: Personal Identity Verification of Contractor Personnel, January 2011.
• FAR 52.204-21: Basic Safeguarding of Covered Contractor Information Systems, June 15, 2016.
• FAR 52.204-25: Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment (Section 889; with FAR 52.204-24 and 52.204-26 representations), August 13, 2020.
• FAR 52.204-30: Federal Acquisition Supply Chain Security Act Orders — Prohibition (with FAR 52.204-29 representation and disclosures), December 4, 2023.
• FAR 52.224-1: Privacy Act Notification, April 1984.
• FAR 52.224-2: Privacy Act, April 1984.
• FAR 52.224-3: Privacy Training, January 2017.
• FAR 52.239-1: Privacy or Security Safeguards, August 1996.
• FAR Part 40: Information Security and Supply Chain Security, April 1, 2024.
• FAR: Revolutionary Federal Acquisition Regulation Overhaul — Parts 1, 2, 4, 33, 39, 40, and 53 (proposed rule), June 23, 2026.
• Federal Acquisition Regulation (FAR), current text.
• Federal agency responsibilities (Paperwork Reduction Act) (44 U.S.C. § 3506).
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FedRAMP Authorization Act (44 U.S.C. §§ 3607-3616 (FY2023 NDAA, Pub. L. 117-263, § 5921)), December 23, 2022.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• FIPS 199: Standards for Security Categorization, February 2004.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• Information and Communication Technology Standards and Guidelines (Revised 508 Standards, 36 CFR Part 1194): Information and Communication Technology Standards and Guidelines, January 18, 2017.
• Internet of Things Cybersecurity Improvement Act of 2020 (Pub. L. 116-207; 15 U.S.C. §§ 278g-3a to 278g-3e), December 4, 2020.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 500-267B Rev. 1: USGv6 Profile, November 12, 2020.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization, September 2025.
• NIST SP 800-145: The NIST Definition of Cloud Computing, September 2011.
• NIST SP 800-160 Rev. 1: Engineering Trustworthy Secure Systems, November 2022.
• NIST SP 800-171 Rev. 3: Protecting Controlled Unclassified Information in Nonfederal Systems, May 14, 2024.
• NIST SP 800-171A Rev. 3: Assessing Security Requirements for Controlled Unclassified Information.
• NIST SP 800-172 Rev. 3: Enhanced Security Requirements for Protecting Controlled Unclassified Information, May 13, 2026.
• NIST SP 800-213: IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements, November 2021.
• NIST SP 800-218: Secure Software Development Framework (SSDF), February 2022.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• OMB M-07-18: Ensuring New Acquisitions Include Common Security Configurations, June 1, 2007.
• OMB M-10-23: Guidance for Agency Use of Third-Party Websites and Applications, June 25, 2010.
• OMB M-17-12: Preparing for and Responding to a Breach of Personally Identifiable Information, May 22, 2017.
• OMB M-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management (ICAM), May 21, 2019.
• OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6), November 19, 2020.
• Superseded source, kept for its history: OMB M-22-18: Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, September 14, 2022. Replaced by OMB M-26-05.
• Superseded source, kept for its history: OMB M-23-16: Update to M-22-18: Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, June 27, 2023. Replaced by OMB M-26-05.
• OMB M-24-15: Modernizing the Federal Risk and Authorization Management Program (FedRAMP), July 25, 2024.
• OMB M-25-22: Driving Efficient Acquisition of Artificial Intelligence in Government, April 3, 2025.
• OMB M-26-02: Ensuring Government Use of Secure Unmanned Aircraft Systems and Supporting United States Producers, November 21, 2025.
• OMB M-26-04: Increasing Public Trust in Artificial Intelligence Through Unbiased AI Principles, December 11, 2025.
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026.
• OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
• Privacy Act of 1974 (5 U.S.C. § 552a), December 31, 1974.
• Scope of FedRAMP (FedRAMP Consolidated Rules for 2026), June 24, 2026.
• Section 508 of the Rehabilitation Act of 1973 (Electronic and Information Technology) (29 U.S.C. § 794d), August 7, 1998.
• Strengthening and Enhancing Cyber-capabilities by Utilizing Risk Exposure Technology Act (SECURE Technology Act) — Federal Acquisition Security Council (Pub. L. 115-390, Title II; 41 U.S.C. §§ 1321–1328; 41 U.S.C. § 4713), December 21, 2018.