Acquisition Process SA-4

System and Services Acquisition · Low baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds SA-4 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, System and Services Acquisition family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SA-4 (Acquisition Process) is about spelling out your security and privacy expectations before you buy or bring in a system, component, or service — and getting them written into the agreement. That means stating the security requirements, the assurance you need, what documentation the supplier must hand over, and the criteria you will use to accept the delivery. It is a Low-baseline control.

What good looks like

State the security requirements in the contract or agreement — the functional needs, the strength of the mechanisms, and the assurance you expect.
List the controls the supplier must provide to meet those security and privacy requirements.
Demand documentation. Require the security and privacy documentation you need, plus rules for protecting it.
Fix responsibility. Say who is accountable for security, privacy, and supply-chain risk — and describe the environment the system will run in.
Set acceptance criteria so you can check what you received against what you asked for before you rely on it.

Framework mapping

NIST CSF 2.0 — GV.SC-05 — Cybersecurity requirements are established and integrated into supplier contracts and agreements
CIS Controls v8 — Control 15 — Service Provider Management

How to move it toward Implemented

For each major package or image on the server, record its source and how you trust it — the repository, the vendor, and whether it is signature-verified.
Verify supplier integrity in practice: confirm your package manager checks signatures (signed repositories for apt, or gpgcheck=1 in /etc/yum.repos.d/*.repo) so you only accept signed software.
Write a short acceptance checklist you run on anything new — source verified, signature good, documentation on hand — and save it as a dated file.
Attach that source-and-acceptance record as hardening evidence on the asset, naming SA-4 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.