Trackr.Live The landing site for Trackr Services
§ Trackr.Live

SA — System and Services Acquisition

System and Services Acquisition is the family that governs how a system gets built, bought, and contracted for before it is ever a system you operate. SA reaches the parts of the lifecycle most of the other families assume already happened: the SDLC the engineering ran inside, the language in the contract that bound the vendor, the developer-side testing and configuration management you will never see directly, the external services you pulled in instead of building. It is also the family most mangled by stale documentation, because Rev 5 tore the supply-chain story out of SA entirely and a lot of SSPs never noticed.

Schematic of an acquisition-to-build pipeline: a contract document feeding requirements into a development line that produces a system, with an inspection gate checking each stage against the contract.

SA is a control catalog family from SP 800-53, not a stage of the RMF. The RMF is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. SA controls get pulled in at Select off the 800-53B baseline, get implemented and documented at Implement, and graded at Assess. The awkward thing about SA is that a chunk of its evidence lives outside your organization. SA-10, SA-11, SA-15, SA-16, SA-17, and SA-21 are developer controls. The artifact that satisfies them was produced by whoever wrote the code, which means the real work of SA-4 is making sure your contract obligated that developer to produce and hand over the evidence in the first place. Miss that at acquisition and you spend the assessment trying to manufacture it after the fact.

The Rev 5 shift you have to internalize first

If you are reading SA against a Rev 4 mental model, throw it out. Several controls people still cite by number are withdrawn. SA-6 (Software Usage Restrictions) is gone, folded into CM-10 and SI-7. SA-7 (User-Installed Software) is gone, folded into CM-11 and SI-7. And the big one: SA-12, SA-13, and SA-14, the old supply-chain-protection, trustworthiness, and criticality-of-components controls, are all withdrawn. The entire supply chain risk management story was lifted out of SA in Rev 5 and made its own family, SR. SA-18 (tamper resistance) and SA-19 (component authenticity) went out the same door, landing as SR-9 and SR-11. SA-20 (Customized Development of Critical Components) is a different story: it survived and is still live in Rev 5, so do not write it off with the rest.

So if you go looking for supply chain protection under SA, you will not find it, and any SSP that cites SA-12 as a live control is quoting a catalog that’s two major revisions stale. SCRM lives in SR now (SR-3 controls, SR-5 acquisition strategies, SR-11 component authenticity). The SA/SR line trips people up because the families touch the same procurement, so it is worth nailing down before going further.

Where SA stops and SR starts

The cleanest way to hold the boundary: SA-4 puts requirements into the contract; SR owns the provenance story; SA-9 governs external services already running.

SA-4 (Acquisition Process) is the control that makes the contract carry security weight. It is where you obligate the vendor to deliver an SBOM, to provide assessment evidence, to hold a FedRAMP authorization, to ship in an approved secure configuration as a delivery condition (SA-4(5)). If the requirement is not in the acquisition, you have no leverage to demand the artifact later. SR-5 (acquisition strategies, tools, and methods) overlaps here, and honestly the two read like cousins in a procurement package. The distinction the assessor wants: SA-4 is the security and functional requirements on the deliverable; SR-5 is the strategy for sourcing that reduces supply-chain exposure (diversified suppliers, tamper-evident delivery, restrictions on where components originate).

SA-9 (External System Services) is a different animal from both. It is not about buying a thing. It is about the security of a third-party service you are consuming and the agreements wrapped around it. The CSP hosting your workload, the SaaS your application calls, the managed service that processes your data. SA-9(2) makes you identify the functions, ports, protocols, and services those external systems use. Location is a separate enhancement: SA-9(5) (Processing, Storage, and Service Location) is where the GovCloud-versus-commercial question gets real and where data residency stops being abstract, with SA-9(8) pinning processing and storage to U.S. jurisdiction. SA-9 overlaps with AC-20 (use of external systems) from the access-control side; AC-20 draws the user-and-connection boundary, SA-9 governs the service relationship and the contract behind it.

Counterfeit parts, tamper, and component authenticity are not SA anymore. SR-11 owns that. Draw the line in the SSP and stop sending assessors hunting for it under SA.

The controls that carry the weight

Every family has a -1. SA-1 (Policy and Procedures) is the org-level policy that everything else inherits its existence from, and SA-2 (Allocation of Resources) is the easy-to-forget one that says you actually budgeted for security in the acquisition, which sounds like paperwork until an assessor asks to see it.

SA-3 (System Development Life Cycle) is the spine. It says you run a defined SDLC with security and privacy built into each phase, with roles and responsibilities assigned. SA-5 (System Documentation) is the admin/user/security docs for the system, and it goes brittle fast because vendor documentation drifts from the shipped version and nobody refreshes the SSP reference.

SA-8 (Security and Privacy Engineering Principles) is the engineering-principles control. This is the one the stale pages mislabel as SA-6. It is least privilege, defense in depth, minimized attack surface, applied as design discipline rather than bolted-on controls. SA-10 (Developer Configuration Management) requires the developer to run CM on the code and track flaws through the build. SA-11 (Developer Testing and Evaluation) is where static analysis, dynamic analysis, and vulnerability scanning during development get demanded. SA-15 (Development Process, Standards, and Tools) covers the developer’s defined process, including threat modeling and SA-15(3) criticality analysis (note: criticality analysis is SA-15(3) and RA-9, not a standalone SA-11 the way old pages claimed).

The high-water marks: SA-16 (Developer-Provided Training), SA-17 (Developer Security and Privacy Architecture and Design), and SA-21 (Developer Screening) typically enter at High, and they are the controls where the gap between contract language and actual artifacts is widest. The contract says the developer applies a security architecture; the question at assessment is whether anyone can produce the document.

Baselines and where SA goes brittle

The baselines are in SP 800-53B, not in the catalog. FIPS 199 sets categorization, FIPS 200 sets the floor, 800-53B turns the impact level into a starting control set, and FedRAMP or DoD (DoDI 8510.01, CNSSI 1253 for national-security systems) overlay on top.

Control Typical first live at What an assessor actually checks
SA-3 Low A real SDLC with security gates, not a one-page diagram that names phases and nothing else.
SA-4 Low The actual contract or task order language: are security requirements, an SBOM, and config requirements obligated, or assumed?
SA-5 Low System docs exist, match the deployed version, and are reachable to operators.
SA-9 Low Each external service is enumerated with an agreement; SA-9(5) service location and data residency is documented.
SA-8 Low Engineering principles applied in design evidence, not asserted in a sentence.
SA-10 / SA-11 Moderate Developer CM and test evidence (static/dynamic scan output, flaw tracking) actually delivered, not just promised in the SOW.
SA-15 Moderate Developer process artifacts including threat models; SA-15(3) criticality analysis present.
SA-22 Low Component inventory cross-referenced against vendor end-of-support dates.

Treat the “first live at” column as directional. Your overlay moves things, and a FedRAMP Moderate package pulls SA enhancements above the bare 800-53B set.

Where SA goes brittle is the gap between the contract and the artifact. SA-11 is the sharpest example. The SOW says the developer performs static and dynamic analysis. At assessment, the assessor asks for the scan reports, the tool names, the finding counts, the remediation evidence. If the program office bought the system without writing delivery of that evidence into SA-4, there is nothing to hand over, and the control comes back Other Than Satisfied no matter how diligent the developer actually was. The control failed at acquisition, not at engineering.

Deeper: developer controls are inheritance you have to police.
SA-10, SA-11, SA-15, SA-16, SA-17, and SA-21 describe work someone else did. On a system built around a COTS or GOTS product, you are not the developer, so you are inheriting these controls from a vendor whose internal process you cannot directly observe. That is fine, RMF allows it, but the inheritance only holds if you can point to evidence the vendor produced and an agreement that obligated them to produce it. “The vendor follows a secure SDLC” with no artifact behind it is the SA equivalent of a copy-paste AC narrative: it restates the control text and proves nothing. FedRAMP packages and a vendor’s own third-party assessment can supply that evidence, but you have to actually attach it and map it, control by control, the same way you would defend any inherited control in the SSP.

SA-22 and the EOL problem

SA-22 (Unsupported System Components) is the control that quietly generates more POA&M entries than any other in the family. It says you do not run components past end-of-support, or if you must, you have documented compensating controls and an in-house or contracted source of continued support.

In practice this means an inventory that tracks vendor EOL dates and flags anything past them. Windows Server builds that aged out. A database engine the vendor stopped patching. Network gear running firmware with no further releases. The reason SA-22 keeps showing up on POA&Ms is that the inventory and the EOL calendar are maintained by different people, or not maintained at all, and a component slides past end-of-support without anyone flagging it until the assessment.

SA-22 does not sit alone. It cascades. An unsupported component cannot receive flaw remediation, so it lights up SI-2 the moment a relevant CVE drops with no vendor patch coming. And SA-22 is only as good as the inventory under it, which is CM-8. If CM-8 is incomplete, SA-22 is fiction, because you cannot certify that nothing is unsupported when you cannot enumerate what you run. I will plant a flag here: SA-22 should be assessed against CM-8 every time, not as a standalone attestation. An SA-22 narrative that says “no unsupported components are in use” without a CM-8 inventory and a dated EOL cross-check is an assertion, not a control, and an assessor who samples three components against vendor lifecycle pages will catch the gap fast.

The fastest way to fail an SA assessment is the same failure mode that sinks AC: an SSP that paraphrases the catalog back at the assessor instead of describing what this acquisition actually required and what this developer actually delivered. They have read 800-53. They want the contract clause and the scan report.

Sources

Adjacent material on this site