SA-4: Acquisition Process

SA-4: Acquisition Process requires you to put specific security and assurance requirements into every acquisition contract for a system, system component, or system service, either explicitly or by referencing them in the contract. Operationally, you must standardize contract language, route purchases through security review, and retain evidence that requirements were included and accepted before onboarding or renewal. ¹

Key takeaways:

• SA-4 is a contracting control: your biggest risk is buying a system or service without enforceable security requirements baked into the agreement.
• “By reference” still needs traceability; auditors will ask where the referenced requirements live and how they are incorporated into the contract.
• Evidence matters as much as process: keep the executed contract, the referenced security exhibit, and the approval trail. ¹

SA-4: Acquisition Process is easy to misunderstand because it looks like procurement paperwork, but assessors treat it as a security control that determines whether your security requirements are enforceable against third parties and internal builders. The control’s intent is straightforward: you should not acquire a system, component, or service unless the acquisition contract includes the security requirements, descriptions, and criteria you need to manage the risk of that acquisition. ¹

For a CCO, GRC lead, or security compliance owner, the operational challenge is consistency. Teams buy SaaS, APIs, hosting, managed services, and hardware through many paths: procurement, IT, business units, engineering, even corporate cards. SA-4 is the mechanism that forces all of those paths through the same gate: contract terms that bind the supplier (or internal provider) to security expectations, deliverables, and acceptance criteria.

This page gives requirement-level implementation guidance you can put into a procurement workflow immediately: who owns it, what contract artifacts you need, how to handle “click-through” SaaS terms, what evidence auditors request, and how to avoid common gaps that cause control failures.

What SA-4 requires (plain-English interpretation)

SA-4: acquisition process requirement means: every time you acquire a system, system component, or system service, you must ensure the acquisition contract includes the required security requirements, descriptions, and criteria—either written directly into the contract or incorporated by reference to an attached or linked security exhibit. ¹

Three operator-grade implications follow:

1. No contract, no onboarding. If you cannot show the requirements were included “in the acquisition contract,” you should treat the acquisition as noncompliant.
2. Your requirements must be named and retrievable. “By reference” only works if the referenced document is version-controlled and clearly incorporated into the executed agreement.
3. This applies to components and services, not just “big systems.” A managed database, endpoint agent, SIEM, identity provider, and outsourced support function can all fall in scope depending on your authorization boundary and system categorization.

Regulatory text

Regulatory excerpt (verbatim):
“Include the following requirements, descriptions, and criteria, explicitly or by reference, using {{ insert: param, sa-04_odp.01 }} in the acquisition contract for the system, system component, or system service:” ¹

What you must do as an operator:

• Define what “the following requirements, descriptions, and criteria” are in your environment (for example, a Security Requirements Exhibit for suppliers, a System Security Requirements baseline for internal development, or both).
• Ensure the contract incorporates them (a signed exhibit, an MSA addendum, a SOW clause set, or a contract section that references a controlled document).
• Make incorporation auditable by retaining the executed agreement, the incorporated text/exhibit, and approval evidence that it happened before purchase or renewal. ¹

Who SA-4 applies to (entity and operational context)

Entity types: Federal information systems and contractor systems handling federal data. ¹

Operationally, this lands on:

• Procurement / sourcing (they own contracting mechanics, templates, and signature workflow)
• Information security / GRC (they own security requirements content and approval gates)
• Legal (they negotiate and ensure incorporation language is enforceable)
• System owners / product owners (they define scope, data types, and service criticality)
• Third-party risk management (TPRM) (they validate the third party can meet requirements and track exceptions)

In-scope acquisition events typically include:

• New SaaS, PaaS, IaaS subscriptions
• Managed services (MSSP, managed detection, managed hosting, call center)
• Software licenses with support and data processing
• Hardware/firmware components that become part of the system boundary
• Material renewals, scope expansions, or migrations to a new environment

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

Step 1: Establish the “security requirements package” that must be included

Create a controlled package that procurement can attach or reference. Keep it short enough to negotiate, but concrete enough to test. Minimum contents usually include:

• Security control expectations (aligned to your NIST 800-53 control baseline where relevant)
• Data handling restrictions (access, storage, location, retention, deletion)
• Incident reporting and cooperation obligations
• Subcontractor/flow-down expectations for downstream third parties
• Right to assess / provide evidence (reports, attestations, questionnaires)
• Secure development and change management expectations for software suppliers

If you use Daydream, map SA-4 to a single control owner and link it to the exact contract artifacts you expect to see every time (e.g., “Security Exhibit vX,” “DPA,” “SOW security schedule”). That mapping becomes your operator runbook and your audit index.

Step 2: Build “incorporation by reference” language that legal will accept

Standardize a clause that states:

• The exhibit/document is incorporated by reference
• The version/date of the exhibit
• Order of precedence (what wins if the MSA conflicts with the exhibit)
• Survival (which obligations survive termination)

Avoid vague references like “supplier will follow industry standards.” SA-4 is about enforceable requirements and criteria in the contract. ¹

Step 3: Put a procurement gate in front of spend

You need an intake path that catches:

• Purchase requests (including renewals)
• Nonstandard agreements
• Click-through SaaS

Practical gating pattern:

• Procurement cannot issue a PO, sign, or approve expense reimbursement unless the request has a “SA-4 satisfied” status from Security/GRC.
• The “SA-4 satisfied” status means the final contract packet includes the required security requirements/exhibit, or an approved exception exists with compensating controls.

Step 4: Tie SA-4 to third-party due diligence and risk decisions

SA-4 is not only “attach a doc.” It’s where you align:

• What you require (contract terms)
• What the third party can do (due diligence results)
• What you will accept (risk acceptance and exceptions)

If a third party refuses a requirement, record:

• The rejected clause(s)
• The negotiated alternative
• The risk decision and approver
• Any compensating controls you will implement internally

Step 5: Confirm contract completeness before onboarding and again at renewal

Operational checks to perform:

• Pre-onboarding: executed agreement is fully signed; security exhibit is attached or referenced with version/date; security approvals are recorded.
• Renewal: verify the security exhibit remains incorporated; confirm no downgrade in obligations; confirm scope/data types did not change.

Step 6: Make evidence retrieval trivial

Your goal is to answer an auditor request in minutes:

• “Show me the contract terms that impose your security requirements on this supplier.”
• “Show me who approved proceeding if requirements were missing or modified.”
• “Show me the exact referenced document and the version in effect at signature.” ¹

Required evidence and artifacts to retain

Keep a standard “SA-4 contract packet” per acquisition:

• Executed master agreement (MSA) and/or order form
• SOW and any amendments
• Security requirements exhibit / security addendum (the referenced document itself)
• Incorporation-by-reference clause text (or the section where requirements are embedded)
• Contract redlines and negotiation notes for disputed security terms (retain final redline set)
• Approval workflow evidence (ticket, email, CLM approval log)
• Exception record (if applicable): rationale, approver, compensating controls, expiration/review date

Daydream can serve as the system of record that links each third party to the contract packet and the SA-4 control evidence set, so you can show operating effectiveness without rebuilding the story each audit.

Common exam/audit questions and hangups

Expect these questions:

• “Which acquisitions are in scope for SA-4, and how do you ensure you capture them?”
• “Show a sample of recent contracts and point to where the security requirements are included.”
• “You say you incorporate requirements by reference; where is the referenced document stored, and how do you prove it’s the same version that was incorporated?”
• “What happens if a business unit buys software without going through procurement?”
• “How do you handle click-through agreements where you cannot negotiate?”

Common hangups auditors focus on:

• Missing exhibits in the executed packet
• References to documents that are not versioned or are overwritten
• Security approvals that occur after signature
• Requirements existing in a policy, but not included in the contract as required by SA-4 ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SA-4 as a one-time template exercise.
   Fix: Build an intake gate and evidence checklist that runs on every purchase and renewal.

2. Mistake: “By reference” points to a living webpage or shared drive file.
   Fix: Reference a controlled document with a version/date; store an immutable copy in your contract repository.

3. Mistake: Security reviews draft terms, but the executed contract differs.
   Fix: Require a final pre-sign review or automated CLM control that blocks signature until security exhibits are attached.

4. Mistake: Only applying SA-4 to “critical vendors.”
   Fix: Define scope based on system boundary and data exposure. Apply at least baseline requirements to all in-scope acquisitions, then escalate for higher risk.

5. Mistake: No exception path, so teams bypass the process.
   Fix: Create a fast exception workflow with documented compensating controls and time-bound re-review.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SA-4 risk as assessment and authorization failure risk rather than tying it to specific penalties here. The practical risk is that, without contractual requirements, you may have no enforceable right to obtain security evidence, require incident notification, or compel remediation. That increases operational exposure and can result in audit findings or delays in system authorization activities. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Assign SA-4 control owner (Procurement + GRC joint ownership works well).
• Inventory active in-scope third parties and identify missing contract packets or missing security exhibits.
• Publish a minimum Security Requirements Exhibit and an incorporation-by-reference clause approved by Legal.
• Implement an interim gate: procurement requires GRC sign-off for new purchases and renewals.

Days 31–60 (operationalize and scale)

• Embed SA-4 checks into procurement intake and CLM workflow (required fields: exhibit version/date, security approval, exception ID).
• Define a standard exception process with required approvals and documentation.
• Train sourcing managers and IT procurement on when SA-4 applies (systems, components, services).
• Start sampling checks: pick a set of recent acquisitions and verify evidence completeness.

Days 61–90 (prove operating effectiveness)

• Run a formal internal control test: select acquisitions across business units and show the full SA-4 evidence chain.
• Close gaps for high-risk suppliers first by executing addenda to attach the security exhibit.
• Build metrics that matter for auditors: “contracts with exhibit attached,” “exceptions open,” “renewals reviewed before signature” (avoid publishing numbers externally unless you can defend them).
• In Daydream, link each third party record to the executed contract packet and map the evidence to SA-4 so audits become a retrieval exercise, not a scramble.

Frequently Asked Questions

Does SA-4 require us to paste security requirements into the contract body?

No. The text allows requirements to be included “explicitly or by reference,” as long as they are included in the acquisition contract package and are traceable to an incorporated exhibit or document. ¹

What counts as “acquisition contract” for SaaS with click-through terms?

Treat the order form, click-through terms, and any addenda as the contract packet. If you cannot incorporate your requirements, document an exception with compensating controls and an approver.

Do we need SA-4 for open-source components?

SA-4 is written for acquisition contracts, so it maps cleanly to third-party or commercial acquisition. If you rely on open source without a contract, manage the risk through your SDLC and supply chain controls, and document how you address the intent.

How do we prove “by reference” in an audit?

Produce the executed agreement showing incorporation language plus the exact referenced exhibit version/date, stored as an immutable artifact in your repository. Auditors will reject references that cannot be reconstructed.

Who should approve exceptions when a third party refuses key security terms?

Route exceptions to a defined risk owner with authority over the system (often the system owner) plus Security/GRC, with Legal confirming the contract outcome matches the recorded decision.

What is the fastest way to stand up SA-4 evidence collection?

Create a contract packet checklist and require it at intake, then store the executed packet and approvals in a single system of record (a CLM plus a GRC repository, or Daydream if you want evidence mapped directly to SA-4).

Footnotes

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