Policy and Procedures

To meet the FedRAMP Moderate “Policy and Procedures” requirement (NIST SP 800-53 Rev 5 SA-1), you must create and publish a system and services acquisition policy plus supporting procedures that clearly define purpose, scope, roles, responsibilities, leadership commitment, coordination points, and compliance expectations. Then you must prove the policy is adopted, communicated, and used in acquisition decisions. ¹

Key takeaways:

• Your SA-1 deliverable is a written acquisition policy plus actionable procedures, not a generic security policy. ¹
• Examiners look for management commitment, named roles, and evidence of dissemination and use in procurement workflows. ¹
• Operationalize SA-1 by tying procedures to intake, third-party due diligence, contract clauses, and acceptance gates for systems and services. ¹

SA-1 is the requirement that forces acquisition discipline: you cannot buy, subscribe to, or build systems and services in an ad hoc way and still pass a FedRAMP assessment. The control is deceptively simple (“write a policy and procedures”), but assessors typically fail teams on execution details: unclear ownership, no proof people follow the process, or procedures that do not map to how procurement actually works.

For a Compliance Officer, CCO, or GRC lead, the goal is to produce two things: (1) an acquisition policy that leadership signs and that sets non-negotiable rules for acquiring systems and services, and (2) procedures that translate those rules into steps your teams follow during intake, evaluation, contracting, and go-live. SA-1 also needs dissemination: you must show the policy and procedures are communicated to the people who buy and approve services, including Engineering, Procurement, Security, Legal, and Finance. ¹

If you are using a workflow tool such as Daydream to manage third-party onboarding and due diligence, SA-1 becomes easier to evidence because requests, approvals, and artifacts are captured by default. The requirement still expects you to define the “rules of the road” first.

Regulatory text

Requirement (excerpt): “Develop, document, and disseminate a system and services acquisition policy and procedures that address purpose, scope, roles, responsibilities, management commitment, coordination, and compliance.” ¹

What the operator must do

You must:

1. Develop the policy and procedures (create them, don’t borrow boilerplate that doesn’t match your process). ¹
2. Document them (versioned, approved, and accessible). ¹
3. Disseminate them (publish and communicate to the teams who acquire and approve systems/services). ¹
4. Ensure the documents explicitly cover:
   • Purpose (why the acquisition policy exists)
   • Scope (what systems/services and which business units it applies to)
   • Roles and responsibilities (who does what, including approvals)
   • Management commitment (executive sponsorship and enforcement)
   • Coordination (required handoffs across Security, Procurement, Legal, etc.)
   • Compliance (what must be met and how exceptions are handled) ¹

Plain-English interpretation (what SA-1 really means)

SA-1 means your organization must run acquisitions like a controlled process, not a set of one-off purchases. For FedRAMP, “acquisition” includes more than signing a contract. It includes evaluating third parties, selecting cloud services, purchasing software, outsourcing functions, and acquiring internally built components or external services that affect the system boundary.

A usable SA-1 implementation answers:

• Who can initiate a purchase or onboarding of a third party?
• What risk checks are required before selection?
• What contract terms are mandatory before production use?
• Who can accept residual risk, and how is that decision recorded?
• How do you prove the policy is known and followed? ¹

Who it applies to

Entity types

• Cloud Service Providers (CSPs) pursuing or maintaining FedRAMP Moderate authorization.
• Federal Agencies applying NIST SP 800-53 controls to systems and service acquisitions. ¹

Operational context (where SA-1 shows up)

SA-1 touches any workflow where your organization acquires or integrates systems and services, including:

• Procurement of SaaS/PaaS/IaaS used in the authorized environment
• Contracting with managed service providers, consultants, and other third parties
• Software/tooling purchases by Engineering or Security
• Renewals, expansions, and material scope changes (new data types, new integrations, new regions)

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

Step 1: Define the acquisition “system and services” scope

Write down what counts as:

• In-scope systems/services for the FedRAMP boundary
• In-scope third parties (including subcontractors when they support the boundary)
• In-scope acquisition events (new, renewal, change in use, emergency purchase)

Deliverable: a one-page scope statement inside the policy. ¹

Step 2: Draft the acquisition policy (the rules)

Your SA-1 policy should read like enforceable rules. Include:

• Purpose: drive secure, compliant acquisition outcomes. ¹
• Management commitment: name the executive owner (often the CIO/CISO or equivalent) and state enforcement expectations (e.g., “no production use without required approvals”). ¹
• Roles/responsibilities: RACI-level clarity for Requestor, Procurement, Security, Legal, Privacy (if applicable), and the risk acceptance authority. ¹
• Compliance: map to required risk checks (security review, third-party due diligence, contract clauses) and define exception handling. ¹
• Coordination: specify mandatory handoffs, such as “Security must review before contract signature” and “Legal must approve data processing terms.” ¹

Practical tip: if people can bypass Procurement by buying on a card, the policy must address that channel explicitly (block it, require retroactive intake, or define approved low-risk categories).

Step 3: Write procedures that match how work really happens

Procedures are the “how,” and they should be executable by the teams doing the work. At minimum, document:

• Intake procedure: how to submit a request, required fields (service description, data types, integrations, hosting model), and initial triage.
• Due diligence procedure: what reviews occur (security questionnaire, evidence collection, architecture review) and decision points.
• Contracting procedure: required security/privacy terms, who negotiates, and what must be in place before signature.
• Go-live procedure: acceptance criteria, approvals, and what artifacts must be stored.
• Renewal/change procedure: what triggers re-review (material changes), and how renewals are re-approved.
• Exception procedure: who can approve, time-bounded exceptions, and compensating controls. ¹

If you run this in Daydream, align each procedure step to a workflow stage (Intake → Security Review → Legal → Approval → Evidence Archive). That makes “dissemination” and “compliance” easier to prove because the process is the system of record.

Step 4: Publish and disseminate (prove it was communicated)

Dissemination is not “it exists in a folder.” Do both:

• Publish in a controlled repository (GRC tool, policy portal, or document system with versioning).
• Communicate to stakeholders: Procurement, Engineering, Security, Legal, Finance, Product owners, and anyone with purchasing authority. ¹

Evidence to create: an announcement message, training snippet, meeting notes, or attestation tied to the policy version.

Step 5: Embed the policy into acquisition gates

Make the policy real by hardwiring it into:

• Purchase request forms (required security intake questions)
• Approval routing (Security/Legal signoff for defined risk categories)
• Contracting checklists (required clauses)
• Technical onboarding (SSO, logging, data handling prerequisites)

Assessors want alignment between “procedure says” and “teams do.”

Step 6: Set ownership and review mechanics

SA-1 does not prescribe a review cadence, but you still need controlled updates. Assign:

• Document owner
• Approver
• Change control method (ticketing, change log, version history)

Required evidence and artifacts to retain

Keep artifacts that show you developed, documented, and disseminated the policy and procedures, and that they are in use:

Core documents

• System and services acquisition policy (approved, versioned) ¹
• System and services acquisition procedures (approved, versioned) ¹

Governance proof

• Approval record (signature page, GRC approval workflow, or minutes)
• Roles/responsibilities mapping (RACI or org chart excerpt tied to process)
• Exception log and risk acceptance records (if exceptions are allowed)

Dissemination proof

• Training/awareness records or attestations
• Distribution list, policy portal publication record, or announcement post

Operational proof (sampling-ready)

• Completed third-party intake tickets
• Due diligence packages (questionnaires, security reviews, evidence requests)
• Contract review checklist and final executed agreement references
• Go-live approvals or change tickets that show gates were met

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the acquisition policy and the procedures, and point to where purpose/scope/roles/management commitment/coordination/compliance are addressed.” ¹
• “Who can approve exceptions, and show an example.”
• “Prove the policy was disseminated to Procurement and Engineering.”
• “Pick a recently onboarded third party and walk me through the procedure evidence from intake to approval.”
• “How do renewals and expansions trigger re-review?”

Hangup to watch: procedures that describe an idealized process, while real purchases happen through email threads or shadow IT.

Frequent implementation mistakes (and how to avoid them)

1. Publishing a policy without procedures. Fix: write step-by-step procedures with owners and outputs per step. ¹
2. Roles are vague (“Security reviews”). Fix: name accountable roles/titles and decision authorities. ¹
3. No management commitment evidence. Fix: require an executive approver and keep approval records. ¹
4. Dissemination is assumed, not proven. Fix: keep training/attestation or targeted comms artifacts tied to the policy version. ¹
5. No coordination points with Legal/Procurement. Fix: add explicit handoffs and contracting gates, then show tickets where those gates occurred. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this control in the source catalog. Practically, SA-1 gaps create assessable risk: inconsistent third-party onboarding, missing security terms, and undocumented risk acceptance. For FedRAMP work, that typically turns into audit findings, delayed authorization, or conditions that must be remediated before proceeding.

A practical 30/60/90-day execution plan

First 30 days: establish the documents and ownership

• Identify acquisition channels (Procurement, card spend, direct cloud signups).
• Draft SA-1 policy with required elements (purpose, scope, roles, responsibilities, management commitment, coordination, compliance). ¹
• Draft procedures for intake, due diligence, contracting, go-live, renewal/change, exceptions. ¹
• Assign document owner and approver; collect approval evidence.

By 60 days: operationalize in workflows

• Embed required intake questions and approvals into your request process (ticketing/GRC/workflow tool).
• Align Security, Legal, and Procurement checklists to the procedures.
• Stand up an evidence repository structure (by third party, by request, or by system).
• Run a pilot on a small set of new/renewal requests; fix friction points.

By 90 days: prove dissemination and consistent execution

• Conduct targeted training/briefings for requestors and approvers; collect attestations or attendance records.
• Perform an internal mini-audit: sample completed acquisitions and verify every required artifact is present.
• Tune exception handling: ensure exceptions are explicit, approved by the right authority, time-bounded, and tracked.
• If using Daydream, configure reporting to produce an assessor-ready package per acquisition (intake → reviews → approvals → artifacts).

Frequently Asked Questions

Do we need both a policy and procedures for SA-1?

Yes. SA-1 explicitly requires a system and services acquisition policy and procedures, and both must be developed, documented, and disseminated. ¹

What counts as “system and services acquisition” in practice?

Treat it as any purchase, subscription, outsourcing arrangement, or integration that introduces a system/service or third party into the authorized environment. Define the scope in your policy so requestors know what triggers the process. ¹

How do we prove “dissemination” to an assessor?

Keep objective records: policy portal publication logs, email or chat announcements, training attendance, or attestations tied to the policy version. “It’s available if people look for it” rarely holds up. ¹

Can Procurement own SA-1, or should Security/GRC own it?

Either can own it, but roles must be explicit and coordination points must be documented. Most teams split ownership: Procurement runs the purchasing mechanics while Security/GRC defines required risk checks and approval gates. ¹

What should an exception look like under SA-1?

Document who can approve exceptions, what conditions apply (compensating controls), and how the exception is tracked to closure. Keep the decision record so you can show why you accepted risk and who approved it. ¹

We already have a vendor management policy. Can we reuse it for SA-1?

You can extend it, but SA-1 is broader than “vendor management” and needs to cover system and services acquisition across the environment, including internal acquisition paths and service subscriptions. Make sure the required elements are explicitly addressed. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5