System and Services Acquisition Procedure

Approval #

Revision History #

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

1. Purpose #

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

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

2. Scope #

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

2.1 CSF 2.0 Alignment #

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

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

3. Controls Covered #

This procedure covers the following 22 controls in the SA family:

3.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 that the Procedure section carries out.

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)

4. Procedure #

4.1 General Implementation Approach #

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

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

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

4.2 Control-Specific Procedures #

SA-01 — Policy and Procedures #

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

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

Procedure:

The CISO’s office keeps the master copies of POL-SA and PROC-SA. Every 3 years the CISO’s office opens the review in the policy library in the document management system. The policy team collects input from the Authorizing Official (AO), System Owners, Information System Security Officers (ISSOs), and acquisition officials. The policy team adds any newly identified supply chain risks and any federal acquisition changes to the draft and sends the revision to the CISO for approval. A new supply chain risk, or a federal change in how the Organization buys services or material, starts the same review immediately.

The CISO’s office sends each approved version to the AO, System Owners, ISSOs, and key stakeholders and records the distribution on the review record. The CISO’s office withdraws each superseded version so that no one works from outdated requirements.

Evidence: the two-year and out-of-cycle review records, the approved revision history with the CISO’s sign-off, and the recorded distribution for each version.

SA-02 — Allocation of Resources #

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

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.

Procedure:

Security and privacy resourcing starts with the first planning document for an investment. System Owners record the high-level security and privacy requirements for a proposed system or service, and the resources needed to meet them, at the time they document the mission or business need. The Chief Information Officer (CIO)’s capital planning staff check that the request carries a separate security and privacy line item. They return a request without one to the System Owner and record the return.

The CISO reviews the allocation against the documented requirements before the investment is approved. The CISO reports any shortfall to the CIO and states the risk it creates. After funding, the System Owner tracks security and privacy spending against the line item through the year and records any material deviation in the ticketing system record for the investment.

Evidence: the planning documents with the recorded requirements, the budget documents that show the separate line item, the CISO’s review notes, and the investment tickets that record returns and deviations.

SA-03 — System Development Life Cycle #

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

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.

Procedure:

At project initiation, the System Owner registers the effort under the Organization system development life cycle (SDLC) standard operating procedure (SOP) and opens the ticketing system record that tracks it through the life cycle. The System Owner documents the security and privacy roles for each phase and names the person assigned to each. The ISSO confirms the assignments before design work begins.

Each phase gate includes a security and privacy checkpoint. The ISSO verifies that the risk management activities the SDLC SOP requires for that phase are complete, from requirement definition through design review, test evidence, and residual risk documentation. The ISSO records the verification on the gate approval. A gap holds the gate until the System Owner resolves it or obtains a documented risk decision.

The CISO’s staff sample life cycle records to confirm that teams follow the SDLC SOP and that role assignments stay current when personnel change.

Evidence: the SDLC registration and gate approvals in the ticketing system, the documented role assignments with named individuals, and the checkpoint records for each phase.

SA-04 — Acquisition Process #

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

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.

Procedure:

An acquisition starts as a request in the IT intake system. The IT Intake Team reviews it with the CISO’s office, the Privacy Officer, the Section 508 Program Manager, IT Operations, and the Application Development Team. The CISO’s staff set the security and privacy requirements, the documentation and configuration expectations, and the acceptance criteria for the item. The program office writes them into the statement of work. The Contracting Officer builds the solicitation in the contract writing system, which adds the required clauses automatically.

The intake reviewers set the terms that apply to the purchase. A cloud service within FedRAMP scope must hold a FedRAMP authorization. An Internet of Things device must meet NIST SP 800-213, or the CIO must sign a waiver under the statute before award. Information and communication technology must meet the Revised Section 508 Standards. Networked products must meet the USGv6 profile, as Federal Acquisition Regulation (FAR) 11.002(g) requires. When the contract involves a system of records or personal information, the Contracting Officer confirms that FAR 52.224-1, 52.224-2, 52.224-3, and 52.239-1 are present.

For software and hardware, the CISO’s staff record the risk-based assurance determination that Office of Management and Budget (OMB) M-26-05 requires. They record any shortfall as a plan of action and milestones (POA&M) item in the governance, risk, and compliance (GRC) system. The delivered SBOMs stay with the acquisition record. At delivery, the System Owner and the ISSO test the deliverable against the acceptance criteria and record acceptance or rejection.

Evidence: the intake records with each reviewer’s requirements, the statements of work, the awarded contracts with their clauses, any CIO waivers, the assurance determinations, the delivered SBOMs, and the acceptance test records.

SA-04(1) — Functional Properties of Controls #

Baselines: Moderate / High

Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.

Procedure:

The requirement enters each contract through the standardized security language at award. When the developer delivers the descriptions, the ISSO reviews them against the control set the contract requires. The ISSO confirms that each description explains the control’s externally visible behavior well enough to test and records the review in the ticketing system. The Contracting Officer returns deficient descriptions to the developer with a due date, and the deficiency stays open on the ticket until the developer corrects it. The ISSO files accepted descriptions with the system’s authorization records and uses them to plan assessments. Evidence: the contract language, the delivered descriptions, the review records, and the deficiency correspondence.

SA-04(2) — Design and Implementation Information for Controls #

Baselines: Moderate / High

Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: at a minimum to include security-relevant external system interfaces; high-level design; low-level design; source code or network and data flow diagram; at [Assignment: organization-defined level of detail — to be defined].

Procedure:

The contract line items name the design and implementation deliverables at award. On delivery, the ISSO checks the package for each required element: interface documentation, high-level and low-level design, source code, and hardware schematics where hardware is in scope. The ISSO confirms that the package lists configurable settings and processed data types in enough depth to support analysis and functional testing. The ISSO records the review in the ticketing system, and the Contracting Officer returns any shortfall to the developer. The ISSO protects accepted material according to its sensitivity and keeps it with the system’s authorization records. Evidence: the contract deliverable list, the delivery review record, the deficiency correspondence, and the retained design package.

SA-04(9) — Functions, Ports, Protocols, and Services in Use #

Baselines: Moderate / High

Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.

Procedure:

The developer delivers its declaration of functions, ports, protocols, and services during design, before delivery. The ISSO and the System/Application Administrator review the declaration against mission need and question any item that has no operational justification. The Contracting Officer sends requested removals back to the developer while the design can still change at low cost. The ISSO records the accepted declaration in the ticketing system. It becomes the reference for boundary rules, hardening, and later configuration baselines. The ISSO handles any deviation found after delivery as a deficiency. Evidence: the delivered declaration, the recorded review with the challenged items, and the accepted baseline reference.

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

Baselines: Low / Moderate / High

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

Procedure:

The ISSO checks each purchase request for a product with PIV capability against the Federal Information Processing Standards (FIPS) 201-approved products list before the Contracting Officer places the order. The ISSO records the verification, including the product, the list entry, and the date, on the intake record in the IT intake system. At deployment, the ISSO confirms that the installed product and version match the approved entry and records the confirmation. The ISSO opens a replacement ticket for any product found in service without a matching list entry. Evidence: the acquisition tickets with the recorded list verification, the deployment confirmations, and the replacement tickets for nonconforming products.

SA-05 — System Documentation #

Baselines: Low / Moderate / High

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

Procedure:

Each acquisition names documentation as a deliverable, and the System Owner verifies receipt before acceptance. The System Owner confirms that the administrator material covers secure installation and operation, maintenance of security functions, and the known weaknesses of privileged functions. The System Owner also confirms that the user material tells users what protections exist and what the Organization expects of them. The ISSO reviews the security content as a second reviewer.

If a vendor cannot or will not supply documentation, the ISSO records each attempt in the ticketing system, including who was contacted, when, and the result. The System Owner then has the material written in-house or contracts a third party to produce it. The gap stays open on the ticket until the documentation exists.

The System Owner distributes accepted documentation at minimum to the AO, the System Owner, the ISSO, and the System/Application Administrator, and records the distribution. The System Owner stores the documentation with access limited according to its sensitivity.

Evidence: the deliverable acceptance records, the review notes, the attempt logs for unavailable documentation, the commissioning decisions, and the distribution records.

SA-08 — Security and Privacy Engineering Principles #

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

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

Procedure:

The System Owner’s engineers document how they applied the principles at each design activity under the Organization SDLC SOP. This applies to new development, upgrades, and modifications. The engineers record how zero-trust assumptions shape the architecture. They record how they designed in continuous monitoring and its metrics. They also record how security testing and evaluation will run across the life cycle. The ISSO takes part in the design reviews. The ISSO records the security and privacy engineering rationale with the design record in the ticketing system.

Where an existing system cannot fully apply a principle, the engineers document the constraint and the compensating approach. The CISO approves the deviation. The ISSO reviews the deviation register each time the system changes, so that a temporary limit does not become permanent without a decision.

Evidence: the design review records that show the applied principles, the recorded rationales, the CISO-approved deviations, and the register that tracks each deviation to closure.

SA-08(33) — Minimization #

Baselines: Privacy

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

Procedure:

During system design, the System Owner and the Privacy Officer review each proposed personally identifiable information (PII) data field with the Mission/Business Owner. For each field, they record the business function that needs it. They remove any field that no approved function needs. The developers then design the data workflows to collect and keep only the approved fields. The ISSO records the approved field list and the review results in the GRC system with the System Security and Privacy Plan (SSPP). Before a release adds a field or a new use, the System Owner repeats the review.

Evidence: the field-by-field review record, the approved field list in the GRC system, and the SSPP that describes the data workflows.

SA-09 — External System Services #

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

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.

Procedure:

A request to use an internet-based service starts with the section “Reviewing External Services”. That review decides whether the service is outside FedRAMP scope and may be used without keeping Organization information, or whether it needs a FedRAMP authorization and an authorization to use. For an authorized service, the CISO and the System Owner select the controls the provider must implement, and the contract carries them with the duty to supply independent assessment reports. The System Owner documents the oversight arrangement in the SSPP.

Continuously the ISSO obtains each authorized provider’s current independent assessment report, such as a FedRAMP, FISMA, or Statement on Standards for Attestation Engagements (SSAE) 18 report. The ISSO reviews the findings against the contracted controls and records the review in the GRC system. At the same time, the System Owner attests that the service is still in use, that its data types have not changed, and that the provider’s assessment is current, and reviews user access.

The System Owner escalates a provider that fails to supply its report, or that leaves findings unremediated, to the AO for a continued-use decision. The CISO asks the CIO to retire a service whose owner does not attest.

Evidence: the scope decisions, the SSPP records of each service, the recorded control selections, the contracts, the continuous review records and owner attestations, and the escalation decisions.

SA-09(1) — Risk Assessments and Organizational Approvals #

Baselines: Moderate / High

1. Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and
2. Verify that the acquisition or outsourcing of dedicated information security services is approved by [Assignment: organization-defined personnel or roles — to be defined].

Procedure:

A request to acquire or outsource an information security service opens in the ticketing system and names the sponsoring System Owner. The CISO’s staff assess the risk: what the service touches, what a failure or compromise would cost, and how the provider arrangement changes that exposure. They record the assessment in the GRC system and note the record on the request ticket. The CISO and the Contracting Officer record their approval or denial before any award. The Contracting Officer engages an approved service through the standard acquisition workflow. Evidence: the request ticket, the recorded risk assessment, and the approvals recorded before award.

SA-09(2) — Identification of Functions, Ports, Protocols, and Services #

Baselines: Moderate / High

Require providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: all external systems where Federal information is processed or stored.

Procedure:

The agreement for each in-scope external service requires the provider to declare the functions, ports, protocols, and services it needs before activation. The ISSO reviews the declaration, confirms that each item has an operational justification, and configures boundary protections to allow only the declared items. The ISSO records the declaration and the review in the ticketing system. A change to the service requires an updated declaration and a new ISSO review before the ISSO admits the change. Evidence: the agreements that carry the requirement, the recorded declarations and reviews, and the change records tied to updated declarations.

SA-09(5) — Processing, Storage, and Service Location #

Baselines: Moderate / High

Restrict the location of information processing, information or data, AND system services to [Assignment: organization-defined locations — to be defined] based on [Assignment: organization-defined requirements — to be defined].

Procedure:

During acquisition, the System Owner records the location requirements for the service. The Contracting Officer writes the permitted processing, storage, and service locations into the agreement. The Contracting Officer’s Representative files the provider’s declaration of its actual locations with the contract record in the ticketing system. During the annual provider review, the ISSO verifies that the declared locations still apply. A provider-initiated location change requires approval before it takes effect. Evidence: the agreements with location clauses, the provider declarations, the review records, and the approved change requests.

SA-10 — Developer Configuration Management #

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

Require the developer of the system, system component, or system service to: a. Perform configuration management during system, component, or service development, implementation, AND operation; b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items — to be defined]; c. Implement only organization-approved changes to the system, component, or service; d. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel — to be defined].

Procedure:

The contract fixes the developer’s configuration management duties at award, including the configuration items under management and the reporting path for security flaws. The developer keeps change control across design, development, implementation, and operation. The developer submits each proposed change for approval before implementing it. The System Owner or a designee approves the change and records the approval.

Each delivered release arrives with its change documentation and the security and privacy impact noted for each approved change. The ISSO spot-checks releases against the documented baseline, comparing versions, components, and configuration, and records the check in the ticketing system.

The developer sends flaw reports to the System Owner, the ISSO, and the System/Application Administrator as the contract requires. The ISSO tracks each report to resolution on its ticket. The System Owner escalates through the Contracting Officer any developer whose changes appear without approval or whose flaws go unreported.

Evidence: the contracted configuration management requirements, the change approvals, the release documentation with impact notes, the spot-check records, and the flaw tickets with their resolutions.

SA-11 — Developer Testing and Evaluation #

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

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.

Procedure:

The developer’s security and privacy assessment plan is a contract deliverable. The ISSO reviews it before testing begins and confirms it states what the developer will test, how, how often, and what artifacts each cycle produces. The developer then tests and evaluates the system at installation and at least twice a month after that. Vulnerability scanning and security configuration benchmark scanning set the required depth and coverage.

The developer sends each cycle’s results to the ISSO. The ISSO verifies that the scans ran on schedule, reviews the findings, and confirms that the developer’s flaw remediation process corrected each flaw, with evidence of the fix. The ISSO records the results and the reviews in the GRC system against the contract.

The ISSO documents any shortfall, such as a missed cycle, an unremediated flaw, or reduced coverage. The Contracting Officer’s Representative reports it to the Contracting Officer, who uses the contract’s remedies with the developer. The System Owner weighs the testing record in each acceptance decision.

Evidence: the reviewed assessment plan, the scan results for each cycle, the remediation evidence, the ISSO’s review records, and the deficiency correspondence.

SA-11(1) — Static Code Analysis #

Baselines: Moderate / High

Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.

Procedure:

The developer runs static analysis inside its own process, early enough to check each code change. With each delivery, the developer provides the analysis output: the tool, the scope, the findings, and the disposition of every finding as fixed, mitigated, or justified as a false positive. The ISSO reviews the package before acceptance, questions any set of dispositions that looks like a bulk dismissal, and records the review in the GRC system. The Contracting Officer returns unresolved defects to the developer with a due date. Evidence: the delivered analysis reports with dispositions, the acceptance review record, and the correspondence for returned findings.

SA-11(2) — Threat Modeling and Vulnerability Analyses #

Baselines: Moderate / High

Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service that: (a) Uses the following contextual information: [Assignment: organization-defined information — to be defined]; (b) Employs the following tools and methods: [Assignment: organization-defined tools and methods — to be defined]; (c) Conducts the modeling and analyses at the following level of rigor: [Assignment: organization-defined breadth and depth of modeling and analyses — to be defined]; and (d) Produces evidence that meets the following acceptance criteria: [Assignment: organization-defined acceptance criteria — to be defined].

Procedure:

The developer produces threat models and vulnerability analyses during design and updates them as the build departs from the design. The developer must update them again before delivery, because late changes receive the least review. The ISSO reviews each version. The ISSO checks whether the model reflects the current design and whether the developer mitigated each identified weakness or accepted it with a rationale. The ISSO also checks whether the test results exercise the threats the model names. The ISSO records each review in the GRC system, and the Contracting Officer returns any gap to the developer. Evidence: the delivered models and analyses, the review records, and the mitigation disposition for each finding.

SA-15 — Development Process, Standards, and Tools #

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

1. Require the developer of the system, system component, or system service to follow a documented development process that:

1. Explicitly addresses security and privacy requirements;
2. Identifies the standards and tools used in the development process;
3. Documents the specific tool options and tool configurations used in the development process; and
4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and

2. Review the development process, standards, tools, tool options, and tool configurations frequency at least annually to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: [Assignment: organization-defined security and privacy requirements — to be defined].

Procedure:

At award, the developer delivers its documented development process: the security and privacy requirements it addresses, the standards it follows, the tools it uses, and the specific options and configurations of those tools. The developer discloses any change to the process or toolchain during performance and controls the change under its own change control.

At least every year, the CISO’s staff review the current process documentation and tool configurations against the Organization’s requirements. They confirm that the toolchain has no covert data paths, keeps no data or PII in tool memory or media, and carries no malware exposure. They record the review and its findings in the GRC system. The ISSO adds the results to the system’s assessment record.

The Contracting Officer sends shortfalls to the developer with remediation dates. Repeated failures inform continued-use and future-award decisions.

Evidence: the delivered process documentation, the disclosed toolchain changes, the yearly review records, and the remediation correspondence.

SA-15(3) — Criticality Analysis #

Baselines: Moderate / High

Require the developer of the system, system component, or system service to perform a criticality analysis: (a) At the following decision points in the system development life cycle: [Assignment: organization-defined decision points — to be defined]; and (b) At the following level of rigor: [Assignment: organization-defined breadth and depth of criticality analysis — to be defined].

Procedure:

At each contracted decision point, from initial design through design implementation review, integration testing, and acceptance testing, the developer delivers its criticality analysis. In the analysis, the developer traces which components and functions the mission depends on and tests them formally, with attention to the data flows across interconnections. The ISSO reviews each delivery, confirms that the analysis reflects the current design, and records the review in the ticketing system. The System Owner uses the results in the Organization’s criticality determinations and protection priorities. Evidence: the analyses delivered at each decision point, the review records, and the determinations they informed.

SA-22 — Unsupported System Components #

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

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

Procedure:

Administrators and the ISSO track vendor support timelines for the components in their systems. They open a ticketing system ticket when an end-of-support date approaches. The System Owner decides on the ticket which path to take: replacement through the standard acquisition process, or continued support while replacement waits.

For continued support, the System Owner documents the arrangement, either customized in-house patching for critical software or an external provider under contract. The CISO approves the arrangement and records the residual risk with the approval. The component stays on the ticket until replacement closes it, and the System Owner reviews the arrangement at each renewal.

If an administrator or the ISSO finds a component in service after its support has ended and with no approved arrangement, they open a ticket at once. They escalate it to the System Owner and the CISO for removal or emergency cover.

Evidence: the end-of-support tickets, the replacement acquisitions, the documented support arrangements with CISO approvals, and the closure records for completed replacements.

4.3 Reviewing External Services #

These steps start when an office asks to use an internet-based service that has no FedRAMP authorization. They decide which path the request takes, using the scope in OMB M-24-15 section III and the FedRAMP Consolidated Rules for 2026.

Step 1: Request the service #

Describe the use case before anyone signs up.

Step 2: Decide the path #

Send the request to the right review.

Step 3: Screen for privacy #

Meet the privacy requirements that apply outside FedRAMP.

Step 4: Approve with conditions #

Set the limits each use must stay within.

Step 5: Record the service #

Keep every approved service visible to its system’s owner and assessor.

Step 6: Review each year #

Confirm the use has not grown into something that needs FedRAMP.

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

4.4 Security and Privacy Contract Terms #

These steps run from the IT request to contract close-out. The IT Intake Team review sets the requirements, and the contract writing system adds the required clauses.

Step 1: Review the IT request #

Set the requirements before anyone writes a solicitation.

Step 2: Write the solicitation and the contract #

Put the requirements and the required clauses in the contract.

Step 3: Buy Internet of Things devices #

The Internet of Things (IoT) Cybersecurity Improvement Act of 2020 limits these purchases.

Step 4: Oversee the contract #

Check that the contractor meets the terms until close-out.

Evidence: the intake record with each reviewer’s requirements, the statement of work, the contract with its clauses, the authorization letter, the monitoring deliverables, the sanitization certificate, the Accessibility Conformance Report, and any waiver.

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.

4.5 Contractor Systems That Handle CUI (Enclaves and CMMC) #

These steps apply to each contract or agreement under which a contractor processes, stores, or transmits the Organization’s Controlled Unclassified Information (CUI) on the contractor’s own systems. The Contracting Officer keeps the contract records in the contract file. The CISO records security decisions in the GRC system.

Step 1: Identify the CUI and set the requirement #

These tasks happen before the solicitation is issued.

Evidence: the CUI list with its categories, the marking guidance, the SAOP’s privacy decision, the CISO’s security requirement in the GRC system, and the solicitation.

Step 2: Check the offeror’s evidence before award #

The CISO checks that the offeror’s enclave can protect the CUI before the Contracting Officer awards.

Evidence: the offeror’s system security plan and POA&M, the assessment evidence or certificate, the FedRAMP Marketplace check, the CISO’s written advice in the GRC system, and the Contracting Officer’s decision.

Step 3: Award the contract and start the work #

These tasks happen at award and before the contractor receives any CUI.

Evidence: the signed contract with its CUI terms, the signed ISA, the account requests, the training records, and a record of each CUI transfer.

Step 4: Oversee the contractor during the contract #

The Contracting Officer’s Representative and the CISO keep the evidence current until the contract ends.

Evidence: each yearly statement and assessment, the POA&M tracking record, each change notice and the CISO’s decision, and any assessment plan and results.

Step 5: Handle a CUI incident at the contractor #

These tasks start when the contractor finds an incident that involves the Organization’s CUI.

Evidence: the contractor’s report with its time of discovery, the incident ticket with the CISA incident ID, the breach record when PII is involved, and the CISO’s decision on new evidence.

Step 6: Close out the contract #

These tasks happen when the contract or agreement ends.

Evidence: the signed return-or-destroy certificate, the account removal tickets, the closed ISA, and the updated list of contracts that involve CUI.

Step 7: Use the requirements checklist #

The Contracting Officer’s Representative completes this checklist at award, every 12 months, and at close-out.

Evidence: the completed checklist for each contract, signed by the Contracting Officer’s Representative and kept in the contract file, with the records each row names.

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

5. Parameters (ODP Values) #

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

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Procedure execution records for SA
• Configuration documentation
• Periodic review records
• Evidence for IG FISMA metric C-SCRM.01
• Evidence for IG FISMA metric C-SCRM.06

7. Performance Measurement #

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

8. Training Requirements #

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

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

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

9. Governance References #

• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• 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-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 Part 40: Information Security and Supply Chain Security, April 1, 2024.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-07-18: Ensuring New Acquisitions Include Common Security Configurations, June 1, 2007.
• OMB M-17-12: Preparing for and Responding to a Breach of Personally Identifiable Information, May 22, 2017.
• 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.
• NIST SP 800-218: Secure Software Development Framework (SSDF), February 2022.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• 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.
• CISA Incident Reporting System: Incident Reporting Form (CISA Services Portal): Incident Reporting Form (CISA Services Portal), August 29, 2024.
• 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.
• FAR 52.204-9: Personal Identity Verification of Contractor Personnel, January 2011.
• 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: Revolutionary Federal Acquisition Regulation Overhaul — Parts 1, 2, 4, 33, 39, 40, and 53 (proposed rule), June 23, 2026.
• 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.
• 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-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.
• OMB M-10-23: Guidance for Agency Use of Third-Party Websites and Applications, June 25, 2010.
• 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-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.