NIST SP 800-53 SA System and Services Acquisition: Key Controls, Enhancements and How to Evidence Them

The System and Services Acquisition (SA) family decides what you can demand from developers, vendors and service providers before a system is built or bought, and most of its findings trace back to contracts that never asked for the evidence. This guide works through the SA family of NIST SP 800-53 Rev. 5 control by control: what each key control and enhancement requires, which baselines select it, which organisation-defined parameters you must set, and what evidence an assessor will ask for under SP 800-53A. It includes the Release 5.2.0 additions SA-15(13) Logging Syntax and SA-24 Design for Cyber Resiliency. It is written for control owners, procurement and vendor risk teams, development leads, system security plan authors and assessors. For the catalogue as a whole, see the NIST SP 800-53 Guide; this page goes one level deeper on SA only.

Key takeaways

• SA-4 is a contract clause list. It requires functional, strength, assurance, documentation, environment, responsibility and acceptance requirements in the acquisition contract, explicitly or by reference. If the requirement is not in the contract, the evidence for later SA controls is hard to get.
• Developer controls start at Moderate. SA-10 developer configuration management, SA-11 developer testing and SA-15 development process are Moderate and High controls, and they apply to in-house developers as well as suppliers.
• SA-9 covers every external service. Cloud, SaaS and managed services must meet your requirements, with defined oversight roles and ongoing monitoring. SA-9(2) at Moderate asks providers to identify the functions, ports, protocols and services you need to use them.
• SA-22 applies at Low. Unsupported components must be replaced or given alternative support. End-of-life software in a Low system is a finding.
• Release 5.2.0 added two controls. SA-15(13) asks developers to log security events in a defined secure format, and SA-24 asks for design for cyber resiliency. Neither is in a baseline yet, so tailor them in where they fit.

The SA family at a glance

The table lists the current SA base controls with baseline allocations, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (L = Low, M = Moderate, H = High). SA-6, SA-7, SA-12, SA-13, SA-14, SA-18 and SA-19 are withdrawn; supply chain content formerly in SA-12 now sits in the SR family.

For baseline selection and tailoring, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

SA-2, SA-3 and SA-8: planning and engineering

• SA-2 Allocation of Resources: determine security and privacy requirements in mission and business planning, allocate the resources to protect the system in capital planning, and keep a discrete budget line for security and privacy. Evidence is a budget document, not a statement of intent.
• SA-3 System Development Life Cycle: acquire, develop and manage the system using an SDLC you name that includes security and privacy, with defined roles, named individuals and integrated risk management. See the Secure Software Development Lifecycle (SSDLC) Guide.
• SA-8 Security and Privacy Engineering Principles: apply the principles you define in specification, design, development, implementation and modification. The 33 enhancements (SA-8(1) to SA-8(33)) are a menu of named principles, from least privilege and secure defaults to secure failure and recovery. Pick the ones you will apply and show where. Release 5.2.0 also revised the SA-4 and SA-5 text and added a reference to SA-8.

SA-8(14) Least Privilege and SA-8(23) Secure Defaults are the principles most relevant to service accounts and workload identities: a system designed so that each component runs with only the permissions it needs, and ships with secure settings, avoids most later remediation. See the Least Privilege Techniques Guide.

SA-4 and SA-5: acquisition and documentation

SA-4 requires the acquisition contract to include, explicitly or by reference, using standardised contract language or another method you define: (a) security and privacy functional requirements, (b) strength of mechanism requirements, (c) assurance requirements, (d) controls needed, (e) documentation requirements, (f) protection of that documentation, (g) the development and operating environment, (h) allocation of responsibility for security, privacy and supply chain risk management, and (i) acceptance criteria.

NHI Mgmt Group recommends adding one more item to every SA-4 contract: a list of the service accounts, API keys, certificates and integration credentials the product creates or needs, with how each is rotated and revoked. This feeds IA-5 and AC-2 from day one. SA-5 then requires administrator and user documentation covering secure configuration, effective use of security functions and known vulnerabilities in administrative functions, documented attempts to obtain missing documentation, and distribution to defined roles. For buyer questions, see the Third-Party Risk Management Guide.

SA-9: external system services

SA-9 requires providers of external system services to comply with your security and privacy requirements and employ the controls you define, defined oversight and user roles, and ongoing monitoring of provider compliance using methods you name. SA-9(2) at Moderate and High requires providers to identify the functions, ports, protocols and services required to use them.

Enhancements outside the baselines are often the most useful for cloud and SaaS: SA-9(1) risk assessment and approval before acquiring a service, SA-9(3) trust relationships with providers, SA-9(5) processing, storage and service location, SA-9(6) organisation-controlled cryptographic keys and SA-9(7) organisation-controlled integrity checking. For federal cloud use, FedRAMP authorisation is the usual route to SA-9 evidence; see the FedRAMP Guide.

Ongoing monitoring under SA-9c should include the integrations you grant to a provider: OAuth applications, API tokens and service principals that let the provider act in your environment. These are external access paths that a questionnaire rarely surfaces.

SA-10, SA-11 and SA-15: developer controls

• SA-10 Developer Configuration Management (M, H): the developer performs configuration management during selected life cycle stages, controls the integrity of changes to defined configuration items, implements only approved changes, documents changes and their impacts, and tracks flaws and their resolution. Signed commits, protected branches and build provenance are typical evidence. SA-10(1) software and firmware integrity verification is a useful tailoring addition.
• SA-11 Developer Testing and Evaluation (M, H): at all post-design stages, the developer implements an assessment plan, performs unit, integration, system or regression testing at a defined frequency, depth and coverage, produces evidence, runs a verifiable flaw remediation process and corrects flaws. Enhancements outside the baselines include SA-11(1) static code analysis, SA-11(2) threat modelling and vulnerability analysis, SA-11(5) penetration testing and SA-11(8) dynamic code analysis.
• SA-15 Development Process, Standards, and Tools (M, H): a documented development process that addresses security and privacy, identifies standards and tools, records tool options and configurations, and controls changes to the process and tools, reviewed at a defined frequency. SA-15(3) criticality analysis at Moderate and High requires analysis at defined decision points and rigour.
• SA-15(13) Logging Syntax (new in 5.2.0): the developer uses defined secure logging formats to log defined event types at a defined level of detail. NIST describes it as supporting incident response by making events easier to reconstruct. It pairs with AU-3 in the AU family.

NIST's Secure Software Development Framework (SP 800-218, version 1.1, February 2022) is a practical way to evidence SA-11 and SA-15 together. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.

High baseline additions: SA-16, SA-17 and SA-21

• SA-16 Developer-provided Training: developers provide defined training on correct use and operation of the security and privacy functions.
• SA-17 Developer Security and Privacy Architecture and Design: a design specification and security architecture consistent with your enterprise architecture, describing required functionality, allocation of controls and how mechanisms work together.
• SA-21 Developer Screening: developers of defined systems have appropriate access authorisations and meet additional screening criteria you define.

SA-22 and SA-24: unsupported components and cyber resiliency

SA-22 requires you to replace components when the developer, vendor or manufacturer no longer supports them, or to provide alternative support such as in-house support. It is in the Low baseline. Evidence is an inventory with support end dates and a replacement or support plan for each item past its date. See the Operating System End of Life and Extended Support Guide and the Technology End of Life Policy Template.

SA-24, added in Release 5.2.0, asks you to design systems for cyber resiliency by defining goals, objectives, techniques, implementation approaches and design principles, then implementing them through risk management or systems security engineering. Those five constructs come from NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems (December 2021). See the Cyber Resilience Guide.

How to evidence SA controls

SP 800-53A uses examine, interview and test for SA. Many SA controls are tested by examining contracts and developer artefacts rather than by testing the system.

For assessment depth, see the NIST SP 800-53A Guide.

Implementing the SA family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a Moderate system.

1. Fix the contract template. Add SA-4 items (a) to (i), SA-4(1), (2) and (9), and the credentials list, to standard contract language or a security schedule.
2. Inventory external services. List every SA-9 provider with the integrations and credentials each holds.
3. Request missing evidence. Ask existing providers for ports, protocols, services and documentation; record attempts under SA-5c.
4. Write the developer process. Document SA-15 tools and settings and the SA-11 test plan for in-house teams first, then require the same from suppliers at renewal.
5. Find unsupported components. Add support end dates to the inventory and plan SA-22 replacements.
6. Tailor in 5.2.0 additions. Decide on SA-15(13) and SA-24 and record the rationale.
7. Review on renewal. Tie SA-9 monitoring to contract renewals and to the Audit Evidence and Continuous Controls Monitoring Guide.

Contract changes apply to new agreements first; existing ones change at renewal, so record a dated exception for each contract that cannot yet meet SA-4.

Decision guidance

• Low versus Moderate: Low covers planning, SDLC, acquisition basics, documentation, engineering principles, external services and unsupported components. Moderate adds developer configuration management, testing, development process and the SA-4 design and ports enhancements.
• Build or buy: for in-house development, SA-10, SA-11 and SA-15 are your own evidence. For commercial products, you rely on SA-4 contract terms and supplier attestations, so ask for them before signing.
• Small organisations: a short standard security schedule attached to every purchase, plus a provider inventory reviewed yearly, covers most of the SA intent at Low.

Detection and measurement

• Share of active contracts that include the SA-4 security schedule.
• Share of external services with a current assurance review under SA-9c.
• Number of unsupported components in production and median age past support end.
• Releases with SA-11 test evidence attached, against all releases.
• Provider-held integrations and credentials with a named internal owner.

Framework mapping

Mappings are "intersects with", not equivalence, and are our reading of the texts. Check them against NIST's published informative references before using them in an audit. See the Control Mapping Guide.

Common failure patterns

• Security schedule missing from older contracts: the template was updated, but most active agreements predate it.
• SA-9 as a one-off questionnaire: providers are assessed at onboarding and never again.
• Provider integrations invisible: OAuth grants and API tokens held by suppliers are not in the SA-9 inventory.
• Developer controls assumed for SaaS: SA-10 and SA-11 marked inherited with no attestation or report behind them.
• End-of-life components accepted indefinitely: SA-22 exceptions with no end date or compensating support.
• SA-8 principles listed but not applied: the plan names principles with no link to design decisions.

Practitioner checklist

• Add SA-4 items (a) to (i) and a credentials list to the standard contract schedule.
• Request ports, protocols, services and documentation from every provider.
• Keep an SA-9 inventory that includes provider-held integrations and credentials.
• Monitor provider compliance on a schedule, not only at onboarding.
• Document the development process, tools and settings for SA-15.
• Attach SA-11 test evidence to each release.
• Track support end dates and plan SA-22 replacements.
• Decide on SA-15(13) and SA-24 and record the rationale.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: Revises Security and Privacy Control Catalog to Improve Software Update and Patch Releases
• NIST: SP 800-218, Secure Software Development Framework Version 1.1
• NIST: SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems
• NIST: SP 800-171 Rev. 3
• CIS: Controls Assessment Specification, Control 16 Application Software Security
• CIS: Controls Assessment Specification, Control 15 Service Provider Management

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · Third-Party Risk Management Guide · Secure Software Development Lifecycle (SSDLC) Guide · NIST SP 800-53 IA Identification and Authentication