SA-1: Policy and Procedures

SA-1 sits at the front of the NIST SP 800-53 System and Services Acquisition (SA) control family. It’s the control that makes the rest of the SA family executable because it forces you to write down what “good” looks like in your environment and communicate it to the people who actually buy, build, integrate, and operate systems and services.

For a Compliance Officer, CCO, or GRC lead, the trap is treating SA-1 as a generic “security policy” checkbox. Assessors rarely fail you for having a policy document; they fail you for having a policy that doesn’t match how procurement and engineering actually work, or for lacking proof it was distributed, reviewed, and used. SA-1 is where you connect governance to operational reality: acquisition planning, third-party onboarding, contract requirements, security reviews, and acceptance into production.

This page gives requirement-level guidance you can execute quickly: what to write, who must approve it, where to publish it, how to prove it’s implemented, and what auditors typically challenge.

Regulatory text

Control requirement (excerpt): “Develop, document, and disseminate to {{ insert: param, sa-1_prm_1 }}:” ¹

Operator interpretation: NIST is requiring you to (1) create written SA policy and procedures, (2) keep them documented in an official place, and (3) distribute them to the defined audience (“organization-defined personnel or roles”). The parameterized audience is intentionally flexible; you must define it and make it defensible for your environment. ²

Plain-English interpretation (what SA-1 demands)

SA-1 requires two layers of instruction:

• Policy: your formal management intent for how system and services acquisition is governed (scope, objectives, roles, compliance expectations).
• Procedures: the step-by-step “how” your teams follow to implement acquisition-related security and compliance requirements in practice.

Then you must disseminate both to the right groups (procurement, legal, engineering, vendor management/TPRM, security, product owners, program managers), and run a maintenance loop so the content stays accurate as your processes change.

Who it applies to

Entities

SA-1 commonly applies when you operate under NIST SP 800-53 expectations, including:

• Federal information systems
• Contractor systems handling federal data ²

Operational context (where SA-1 shows up)

SA-1 becomes “real” anywhere your organization acquires or integrates:

• Third-party software/SaaS, hosting, MSP/MSSP services, consultants, data providers, and other third parties.
• Internally developed systems that rely on external components (libraries, APIs, platforms).
• Cloud services and managed platforms where shared responsibility needs to be made explicit.

If you have any formal procurement, vendor onboarding, security review gates, contract templates, or production release approvals, SA-1 must align to those motions.

What you actually need to do (step-by-step)

Step 1: Define the SA-1 scope and audience (make the parameter real)

Create a short “SA-1 applicability statement” that answers:

• Which business units and system types are in scope?
• Which acquisition pathways are in scope (purchase, renewal, build vs. buy, open source intake, cloud subscriptions)?
• Who must receive the policy/procedures (your filled-in audience for the parameter)?

Practical tip: define the audience by role, not name. Example: “Procurement, Legal, Information Security, Engineering leaders, Product owners, TPRM, and any requestor who initiates third-party purchases.”

Step 2: Assign ownership and governance

For SA-1 to pass an exam, it needs clear accountability.

• Control owner: usually Head of TPRM, CISO delegate, or GRC lead with procurement alignment.
• Document owner: person responsible for drafting, updates, and publication logistics.
• Approvers: security leadership + procurement leadership + legal (as needed), based on your internal governance.

Capture this in a RACI that you can show an assessor.

Step 3: Draft the SA policy (what management expects)

Your SA policy should be short and enforceable. Minimum sections that tend to satisfy assessors:

• Purpose and scope (systems, third parties, acquisitions)
• Roles and responsibilities (requestor, procurement, security, legal, vendor owner, system owner)
• Required acquisition security activities (risk tiering, security review, contract/security terms, acceptance criteria)
• Minimum documentation expectations (what must be recorded for each acquisition)
• Exceptions process (who can approve, how it’s documented, expiry/compensating controls)
• Review and update cadence (state your approach; keep it realistic)

Keep the policy high-level. Put the operational steps in procedures.

Step 4: Write procedures that mirror the real workflow

Procedures should be executable by the teams doing the work. Build them around your lifecycle:

1. Intake and triage: how a third-party or system acquisition request is submitted; required fields.
2. Risk classification: criteria to determine review depth (data types, connectivity, criticality).
3. Due diligence activities: security questionnaire, evidence review, architecture/security review, privacy review, etc. (tie to your TPRM program if you have one).
4. Contracting and security requirements: how security requirements get into contracts/SOWs/order forms; who approves deviations.
5. Approval and go-live: what “approval to onboard” means; required sign-offs; recording approvals.
6. Ongoing obligations: renewal reviews, reassessments, monitoring triggers (breach, service changes).
7. Records retention: where artifacts live, naming conventions, how long retained (state internal retention rule if you have one).

Make it auditable: every procedure step should produce an artifact (ticket, approval, signed addendum, risk rating record).

Step 5: Disseminate (and prove it)

“Disseminate” is a common failure point because teams publish a doc but can’t show distribution.

• Publish policy/procedures in an authoritative repository (GRC tool, controlled intranet, document management system).
• Send a formal distribution notice to the defined audience (email, LMS assignment, policy portal attestation).
• Require an acknowledgement for key roles (procurement, security reviewers, vendor owners).

Evidence design rule: if you cannot prove distribution within minutes during an audit, dissemination is not complete.

Step 6: Operationalize with a control map and recurring evidence

Turn SA-1 into a small operating system:

• Map SA-1 to a named owner, the procedure documents, and the recurring evidence artifacts you will collect each period ¹.

A lightweight way to do this is to maintain a “SA-1 control card”:

• Owner
• In-scope orgs/systems
• Policy link + procedure link
• Where evidence lives
• What events trigger updates (new procurement system, new contract template, cloud migration)

Tools like Daydream can help you maintain this mapping so SA-1 stays connected to real workflows and evidence, rather than becoming a static document that drifts from operations.

Required evidence and artifacts to retain

Keep evidence that proves creation, approval, dissemination, and use:

Policy/procedure governance artifacts

• Approved SA policy (version-controlled)
• Approved SA procedures (version-controlled)
• Approval record (meeting minutes, workflow approval, e-signature trail)
• Document owner and control owner assignment (RACI or control register entry)

Dissemination artifacts

• Distribution email(s) or policy portal publication record
• Training or attestation completion records for the defined audience
• Screenshot/export showing document location and access controls (read access to intended roles)

Operational “proof it’s used” artifacts

• Acquisition intake tickets with required fields completed
• Third-party risk ratings and review checklists
• Contract/security addenda or clause library reference used in contracting
• Exception requests and approvals (with expiry and compensating controls)
• Renewal review records (if applicable to your process)

Common exam/audit questions and hangups

Auditors and assessors tend to press on:

• “Who exactly is the dissemination audience?” If you can’t define it, you can’t prove dissemination.
• “Show me the procedure that procurement follows, not a security policy.” SA-1 expects procedures that match real buying motions.
• “How do you keep this current?” Expect questions about ownership, update triggers, and version history.
• “Prove people follow it.” They will sample acquisitions and trace artifacts back to your procedures.

Frequent implementation mistakes (and how to avoid them)

1. Generic policy that doesn’t match operations. Fix: write procedures around your actual intake-to-contract-to-go-live workflow.
2. No evidence of dissemination. Fix: use attestations or an LMS assignment for key roles; retain exports.
3. Undefined or overbroad scope. Fix: define which acquisitions are covered and which process is authoritative.
4. Procedures with no artifacts. Fix: each step produces a record; build naming conventions and storage locations into the procedure.
5. No exception process. Fix: document how exceptions are requested, approved, time-bounded, and reviewed.

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement, so this page does not list case examples. Practically, SA-1 failures increase operational risk: inconsistent third-party onboarding, missing contractual security requirements, and inability to prove governance during assessments against NIST SP 800-53 expectations. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and publish)

• Name SA-1 control owner and document owner.
• Define scope and dissemination audience (roles).
• Draft SA policy and baseline procedures aligned to your current acquisition workflow.
• Publish in a controlled repository with versioning.
• Send formal dissemination notice; capture acknowledgements for key roles.

Days 31–60 (connect to workflows and evidence)

• Add required fields and checkpoints to the intake/ticketing process.
• Align procurement and legal: contract templates or clause library references in the procedures.
• Build an evidence checklist and a sampling approach (what you will show an auditor).
• Pilot on real acquisitions; fix friction points.

Days 61–90 (make it repeatable)

• Run an internal mini-audit: sample a set of recent acquisitions and trace artifacts to procedures.
• Tune the exception process and add expiry reviews.
• Establish a standing review trigger list (org changes, tooling changes, major incidents, template updates).
• Put SA-1 on a recurring review agenda with procurement/security stakeholders.

Frequently Asked Questions

What counts as “disseminate” for SA-1?

Disseminate means you can show the policy and procedures were formally distributed to your defined roles, not just posted somewhere. Keep a distribution record and acknowledgements or training completion tied to the audience you defined. ¹

Can SA-1 be satisfied with a single document?

You can combine policy and procedures in one controlled document if the policy intent and step-by-step procedures are both present and clearly separated. Assessors mainly care that both layers exist and are distributed to the defined audience. ²

How specific do procedures need to be?

Procedures should be specific enough that a procurement partner or vendor owner can execute them and produce predictable artifacts (tickets, approvals, contract language references). If a step cannot be evidenced, it usually needs to be rewritten.

Who should own SA-1: security, procurement, or GRC?

Put ownership where day-to-day accountability lives, then document shared responsibilities in a RACI. In many orgs, security or GRC owns the control, while procurement owns parts of execution; your documents should reflect that split.

How do we handle third parties already in place before SA-1 was written?

Treat them as a remediation population: define a catch-up review approach (for example, at renewal or on a risk trigger) and document it in procedures. Keep a tracker showing status and any granted exceptions.

What evidence is fastest to produce in an audit?

A version-controlled policy/procedure with approvals, a dissemination/attestation report, and a short sample set of acquisition tickets showing risk rating, review steps, and contracting/security requirements applied.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5