What SA-4 requires in acquisition contracts
SA-4 requires security and privacy requirements, assurance evidence and responsibility splits to be written into the contract before a system, component or service is bought. Your procurement team or auditor will usually ask for this control when you buy software, a managed platform or a hosted service that handles regulated data. The question they are testing is whether the agreement itself tells the supplier what to build, what to prove and who is accountable for what, rather than whether the product happens to be secure when it arrives. The control covers functional requirements, the strength of the mechanisms that enforce them, assurance and documentation requirements, the description of the development and operating environments, the allocation of security, privacy and supply chain responsibilities, and the acceptance criteria that decide whether delivery is complete.
The risk behind SA-4 is that a buyer inherits the weaknesses of a supplier's development process, its subcontractors and its update practices without any ability to see them. Technical testing can find some of these problems after purchase, but many of them can only be fixed by a contract term: a right to design documentation, a notice period before a material change, a named owner for vulnerability remediation, or a clear line between what the supplier patches and what you configure. That is why drafting usually decides whether SA-4 is met. Procurement, legal, security and the system owner have to agree on the requirements before the request for proposal goes out, and the answers belong in the statement of work. Ask whether the supplier will commit to those terms in writing and which of them it already meets.
SP 800-53B assigns SA-4 to the low, moderate and high security baselines and to the privacy baseline, so the control applies at every impact level. The baseline sets which enhancements are required: the low baseline selects SA-4(10), the moderate baseline adds SA-4(1), (2), (9) and (10), and the high baseline adds SA-4(5). Confirm the exact selections against the current SP 800-53B baseline profiles, because your system's impact level and any overlay determine which set applies. Release 5.2.0 updated the SA-4 discussion to address customer agreements and notification and coordination of updates, without changing the requirement itself. In practice, ask suppliers how they notify customers of material changes, how far in advance, and who approves the change before it reaches your environment.
Which acquisitions and third parties SA-4 reaches
SA-4 applies to every acquisition of a system, component or service, but the work differs widely by what is bought and how much impact the system carries. The cards below cover the decisions that change the contract workload: what falls in scope, who signs, and how the baseline changes the enhancements that apply.
Systems, components and services in scope
SA-4 reaches acquisitions of systems, system components and system services. Build an inventory of purchases that touch a system boundary, including hardware, licensed software, managed services and professional services. Confirm with procurement which purchases route through a standard purchase order and which skip contract review, since those are the ones most likely to miss SA-4 language. Record the scope decision in your system security plan so an assessor can trace it.
Cloud and SaaS contracts
Cloud and SaaS agreements are usually standard click-through or master terms that the buyer cannot negotiate line by line. Check whether the provider documents its development and operating environments, supports security requirements in the agreement, and gives notice of updates. Where the terms are fixed, record what you accepted and where the provider's own assurance documents fill the gap, because SA-4 expects a documented allocation of responsibilities.
Open-source support agreements
Self-hosted open-source platforms often come with a paid support or subscription contract rather than a license fee. The contract may not mention security requirements at all. Ask the support provider for written commitments on patch timing, vulnerability disclosure, access to design documentation and acceptance criteria. Where the project itself has no contract, document who in your organization owns those responsibilities, since SA-4 still requires that allocation.
Hardware and appliance purchases
Hardware purchases carry supply chain questions that software purchases do not, such as component origin, firmware sources and end-of-life dates. Include purchase terms that request configuration baselines, firmware provenance and support timelines. Confirm with the vendor which firmware and software versions ship with the product and how updates are delivered, since these details feed acceptance criteria and later SA-22 decisions.
Teams that sign and review contracts
Contract signature usually sits with procurement or legal, but SA-4 requirements must be written by security, privacy and system owners. Name who drafts the security requirements, who reviews the vendor response, and who accepts the component into production. A single accountable owner for each acquisition makes the responsibility allocation traceable during assessment.
Baseline and impact level changes
The baseline selected for a system changes which SA-4 enhancements apply. In SP 800-53B, the low baseline selects SA-4(10), the moderate baseline selects SA-4(1), (2), (9) and (10), and the high baseline adds SA-4(5). Confirm the impact level with your authorizing official before drafting contracts, because a system moved to a higher baseline may need contract amendments for enhancements it did not previously carry.
How an assessor tests SA-4
This table compares how an assessor approaches SA-4 under the SP 800-53A examine, interview and test methods, which evidence each method draws on, and where findings usually arise. Read it as a checklist of what to prepare before an assessment, not as a list of pass or fail thresholds.
| Assessment element | What the assessor looks at | Where findings usually arise |
|---|---|---|
| Examine: acquisition contracts | Contracts or statements of work for the system, components and services, checked for security and privacy functional and assurance requirements | Contracts that omit security terms, or that list requirements with no assurance or documentation obligations attached |
| Examine: design documentation | System design documentation showing the development and operating environments and how acquired components fit the architecture | Design documents that are out of date with the deployed system or that do not describe the operating environment |
| Examine: responsibility allocation | Evidence that security, privacy and supply chain responsibilities are split between the organization and the provider | Responsibilities assumed by both sides, or assigned to no one, so gaps surface only during an incident |
| Examine: acceptance criteria | Defined acceptance criteria tied to the contracted requirements and records of acceptance decisions | Acceptance based on feature delivery alone, with no security or privacy test results recorded |
| Interview: procurement and contracting staff | How requirements enter the acquisition, who reviews them and how exceptions are approved | Security reviewers engaged after the contract is signed, leaving no room to change terms |
| Interview: system owners and engineers | How the description of the development and operating environments is kept current and how updates from the provider are coordinated | Owners who cannot name the provider's notification obligations or where updates are tracked |
| Test: delivered artifacts | Whether delivered components match the contracted requirements through sample checks or functional verification | No test evidence tying delivered behavior back to the contract clauses |
| Test: sample contract walkthrough | Tracing one or more acquisitions from requirement to contract clause, acceptance record and design document | Traces that break at the acceptance step because the contract and the acceptance record use different terms |
Sequence for putting SA-4 into contracts
This sequence turns SA-4 from a clause someone remembers to add into a repeatable part of procurement, with every acquisition carrying the same security requirements, documentation duties, responsibility split and acceptance tests. Each step produces a record that the organization, its legal and procurement teams and an independent assessor can check.
Inventory current and upcoming acquisitions
The organization, usually through procurement with the system owners, lists every acquisition that brings in a system, component or service in scope for the SA-4 review, including renewals and changes to existing contracts. Each entry records the system it supports, the impact level or baseline that applies, the vendor, and whether the vendor hosts or operates any part of the system. The output is an acquisition register that is reviewed whenever a new purchase request arrives. The step is done when every in-scope contract has an owner and a baseline assigned, and the team can explain why any excluded purchase is out of scope.
Define functional and assurance requirements per system
Security architects and system owners translate the baseline for each system into written functional requirements (what the security and privacy functions must do) and assurance requirements (how much confidence the organization needs that they work). They use the SP 800-53B baseline selection and the SA-4 enhancements that apply to the baseline, and they record which enhancements are required and why. The output is a requirements register, with one row per requirement, a link to the control it supports and an assigned owner. The step is complete when a reviewer can trace each contract requirement back to a baseline control and to a named system.
Specify documentation and descriptions of environments
Next, the team lists the documentation the vendor must deliver, such as security design information, the development and operating environment descriptions, and the list of ports and services in use where the enhancements require them. It also defines what must be supplied before go-live and what must be kept current afterward. Procurement and the system owner agree the format and delivery points. The output is a documentation schedule attached to each requirements register entry. The step is done when every documentation item names a responsible party, a due point in the contract lifecycle and a reviewer inside the organization.
Allocate security, privacy and supply chain responsibilities
The contract must state which party performs each security, privacy and supply chain task. The organization, the vendor and any subcontractor are each assigned responsibilities for controls such as configuration, vulnerability handling, incident notification and update coordination. Supply chain responsibilities, including how the vendor reports its own suppliers, are written down separately so they are not left implicit. Security and legal staff review the split together. The output is a responsibility matrix that is attached to the contract and cross-referenced to the requirements register. The step is done when no requirement in the register lacks a responsible party.
Set acceptance criteria and test evidence
For each requirement, the team defines how acceptance is decided: the evidence the vendor must provide, the test or review that checks it, and who signs off. Acceptance criteria should reflect the assessment procedures in SP 800-53A for the related controls so that what the organization accepts is what an assessor will later examine. The output is an acceptance criteria table linked to the requirements register. The step is complete when each criterion can be checked by someone who did not write it and when the criteria state what happens if the vendor does not meet them.
Build the standard clause set and contract templates
Using the completed registers, the legal and procurement teams draft a standard clause set that covers the requirements, documentation duties, responsibility matrix and acceptance criteria. Clauses are grouped by baseline so a low-impact purchase does not carry high-baseline obligations by default, and optional enhancements are included as selectable clauses. The output is a versioned clause library and one or more contract templates that reference it. The step is done when each template maps to a baseline and to the register entries it covers.
Review templates with legal, procurement and security
Legal counsel, procurement and the security team review the templates together, checking that the clauses are enforceable, that the responsibility split matches operational reality, and that exceptions have a documented approval path. Where a vendor pushes back, the team records the requested change and the risk decision rather than dropping the requirement silently. The output is an approved template set, a log of negotiated deviations and a review record with names and dates. The step is complete when the approved templates are in use for new acquisitions and existing contracts have a documented plan for renewal or amendment. Your assessor will expect to see this review record, so confirm with your auditor which level of sign-off they will accept.
How the SA-4 enhancements change what the contract must say
The SA-4 enhancements turn a general acquisition clause into specific contract terms, and the ones that apply depend on the baseline the system is authorized under. In SP 800-53B, the low baseline selects only SA-4(10). The moderate baseline adds SA-4(1), SA-4(2) and SA-4(9), and the high baseline keeps those four and adds SA-4(5). Confirm these selections against the SP 800-53B profile for your impact level before drafting, because a contract written for moderate will be short of requirements at high.
SA-4(1) concerns the functional properties of the security controls, so the contract should require the supplier to describe what each control does and how it behaves under normal operation. SA-4(2) concerns design and implementation information for those controls, at a level of detail your assessors can use to test them. The contract should name the documents expected, such as design specifications and source references, along with the format and the delivery point. Ask the supplier to commit to these deliverables before award, since the information is far harder to obtain after the product is in production.
SA-4(9) asks for the ports, protocols and services the product uses in operation, which your network team can check against firewall rules and boundary policy. SA-4(10) concerns approved PIV products, so the contract should name the approved product list the program references and require the supplier to use only products on it. SA-4(5), which applies only at high, concerns configuration at delivery, so the contract should require security settings in the most restrictive mode operations allow. FedRAMP's Consolidated Rules for 2026 require SA-4 at Classes B, C and D, with 1 enhancement at Class B, 4 at Class C and 5 at Class D. Confirm which enhancements those counts refer to against the catalog before you write the clause list.
Evidence that passes an SA-4 review
An assessor testing SA-4 looks for signed acquisition contracts and the security requirements inside them, then checks that those requirements were carried into design, testing and acceptance. The cards below cover the artifacts that usually satisfy that trail and the routines that keep them current between assessments.
Executed contracts and clause templates
Keep the signed contract, order form or customer agreement for each system, component and service in scope, along with the clause template it was drawn from. An assessor will look for security and privacy functional and assurance requirements, documentation obligations, and the allocation of security, privacy and supply chain responsibilities written into the contract text, not only in a procurement checklist. Confirm the template version matches the contract date, and note which clauses were negotiated away.
Security requirements specification
Maintain a written specification that turns each contract requirement into a testable statement, with the controls it needs and the strength-of-mechanism expected for each. Map every requirement to an owner and an acceptance method. A specification that exists only as a sales slide will not show that the organization defined what it bought, so store it under version control with dated approvals.
Vendor design documentation
Collect the design documents the supplier delivers for the system or component, including architecture diagrams, data flows and descriptions of the development and operating environments. Assessors use these to test whether the design matches the contract. Record the document version, the date received and any gaps the supplier has not closed, and confirm the documents describe the version actually deployed.
Ports and services inventory
Obtain a list of the ports, protocols and services the product requires and actually runs, and reconcile it against the approved configuration. Where the vendor's list and your scan results differ, record the difference and the decision taken. This item is an SA-4 enhancement in the 800-53B baselines, so confirm which enhancements your baseline selects before collecting it.
PIV product confirmations
Where the acquisition involves personal identity verification, keep the vendor's written confirmation that the products are on the approved PIV list and the version tested. Store the confirmation with the contract and check it again at renewal, because product versions change. If the product is not confirmed, record the exception and the compensating approach.
Acceptance test and supply chain records
Retain acceptance test plans, executed results, sign-off records and the supply chain responsibility matrix that shows who owns each supplier duty. Record failed tests, retests and waivers with approver names and dates. Together these show that acceptance criteria from the contract were applied before the system went live.
Renewal and update tracking
Keep a register of contract renewal dates, customer agreement updates and supplier notices of product changes. The SA-4 discussion in Release 5.2.0 addresses customer agreements and notification and coordination of updates, so review each supplier notice against the agreement and record whether the change was accepted, tested or escalated. Review the register at least once between assessments and before each renewal.
What meeting SA-4 costs in money and effort
Most of the cost of SA-4 at the contract stage is paid in review hours. Counsel and procurement staff write or redline the security and privacy clauses, check that the functional, assurance and documentation requirements are enforceable, and agree how responsibilities for supply chain risk are split between the buyer and the supplier. This work is largely one-time for each contract, but it recurs whenever a contract is renewed, amended or replaced. NIST does not publish a figure for these hours, so ask your own counsel and procurement team to estimate them.
- Clause drafting: Time to write security requirements, assurance requirements and documentation obligations into each contract.
- Redlining: Negotiation rounds with suppliers who push back on audit rights, notification duties or acceptance criteria.
- Responsibility matrices: Agreeing who owns each security, privacy and supply chain task, which is a core SA-4 expectation.
- Renewal and amendment: Repeated review when contracts renew or change scope, which is recurring.
- Template reuse: Standard clause libraries reduce the per-contract cost but still need legal sign-off.
Before accepting a quote from any firm, confirm with your counsel how many contracts are in scope and which clauses are standard across them.
Security engineering staff translate SA-4 into concrete requirements for each acquisition. This includes choosing which SP 800-53 controls and enhancements apply, based on the system's impact level and your baseline. The effort rises with the number of enhancements selected, because each one adds a requirement the supplier must meet and you must later verify. Much of this work is one-time per system type, then reused, but it recurs when baselines or NIST releases change, such as the Release 5.2.0 update that revised the SA-4 discussion.
- Baseline selection: The SP 800-53B baseline sets the starting list. The low baseline selects SA-4(10), the moderate baseline selects SA-4(1), (2), (9) and (10), and the high baseline adds SA-4(5).
- Enhancement choice: Each added enhancement increases drafting and verification work.
- Requirement reuse: A reusable requirements library cuts effort for later acquisitions.
- Release updates: Rework when NIST or a sponsoring program revises the control.
- Design information requests: Specifying what design documentation the supplier must provide.
Ask the implementation partner to state in the quote how many requirement sets are included and whether reusable templates are part of the scope.
Once a supplier is under contract, you need evidence that it meets the requirements. This is collected from suppliers in the form of documentation, attestations and test results, then checked against your acceptance criteria before the system or service goes live. Evidence collection recurs for each supplier and each major change, and it often grows with the number of vendors. Acceptance testing is usually one-time per deployment but repeats after significant updates. These costs are mostly internal staff time and supplier effort, and they are often underestimated.
- Evidence requests: Chasing design documents, configuration guides and assurance artifacts from each supplier.
- Review effort: Checking whether supplied evidence matches the contract requirements.
- Acceptance testing: Verifying functions, configurations and ports before acceptance, which can use internal or contracted testers.
- Supplier cost pass-through: Some suppliers charge for additional documentation or testing support, so confirm this in the contract.
- Tooling: Self-hosted tools that track evidence can reduce repeat collection work, but they carry setup and upkeep costs.
When reviewing a quote, ask how the partner will handle supplier evidence that is missing or incomplete, and whether acceptance testing is included or billed separately.
An independent assessor tests SA-4 by examining acquisition contracts and system design documentation, and by interviewing staff. Assessor effort is driven by the number of contracts and systems sampled, which your assessor decides. Your organization pays for preparing samples, answering questions and fixing findings. The assessor's own fees are set by the assessor, and only the assessor can issue an assessment report. Assessment cost recurs on each assessment cycle, which varies by program and authorizing body. Confirm your cycle with the program owner.
- Sample preparation: Assembling contracts, design documents and acceptance records for sampled acquisitions.
- Interview time: Procurement, engineering and security staff answering assessor questions.
- Remediation: Fixing gaps, such as contracts missing required clauses, which can require reopening agreements.
- Assessor fees: Set by the independent assessor, so request a written scope and fee from each candidate.
- Ongoing upkeep: Keeping contract files current, which recurs for the life of each supplier relationship.
Before engaging an assessor, confirm with your authorizing body which evidence is expected, how many samples are taken, and how often the assessment repeats.
Where SA-4 usually fails and how to close it
SA-4 failures tend to start at the contract table, not in the security team. The cards below cover the gaps assessors meet most often, and each one ends with a closing action that can be written into the next contract, renewal or procurement checklist.
Contracts signed before security terms existed
Many agreements for systems and services predate the organization's security requirements, so they contain no functional, assurance or documentation requirements at all. Assessors look for those requirements in the contract text itself, not in a policy that says they should exist. Close it by inventorying every active contract for systems, components and services, then amending or re-papering the ones that carry no SA-4 terms at renewal. Ask counsel and procurement to confirm which amendment route each contract allows.
No defined acceptance criteria
SA-4 expects acceptance criteria to be part of the acquisition, yet many purchases close on delivery and invoice alone. Without measurable security tests, an assessor cannot tell whether the product met the requirements the organization wrote down. Close it by writing acceptance tests into the statement of work, such as configuration checks, vulnerability scan results and a documented sign-off by the security owner before payment.
Unclear supply chain responsibilities
Responsibility for patching, key management, logging and incident notification often falls between the buyer and the supplier, and each side assumes the other owns it. SA-4 requires the allocation of security, privacy and supply chain responsibilities to be written down. Close it by building a responsibility matrix for each contract that names an owner for every control area, including who holds the component inventory and who approves subcontractors.
Vendors refusing design documentation
Suppliers often resist sharing architecture diagrams, data flow maps and secure configuration guides, citing confidentiality. Without that design information, the organization cannot test the system or explain its boundary, and the SA-4 design documentation objective goes unmet. Close it by making design documentation a contract deliverable under a non-disclosure agreement, and by setting a delivery date before the contract is signed. Ask the vendor to confirm the format it will provide.
No tracking of update notifications
Release 5.2.0 updated the SA-4 discussion to cover customer agreements, notification and coordination of updates. Many organizations learn about vendor patches or changes from the news rather than from a notice they are entitled to receive. Close it by recording in the contract who notifies whom about updates, and by logging each notice in a register with the date received, the assessment owner and the decision taken.
Questions buyers ask about SA-4
How much effort does SA-4 add to a procurement?
SA-4 adds work mainly at the contract drafting and supplier review stages, not in day-to-day operations. The organization must write security, privacy and supply chain requirements into each acquisition for systems, components and services, describe the development and operating environments, assign responsibilities and define acceptance criteria. Effort rises with the number of contracts, the diversity of suppliers and how many requirements are new to the procurement team. Ask any partner for a quote built from a written list of contract types in scope, the number of templates to revise and the review steps each acquisition must pass.
How long does a contract template update take?
No researched figure supports a fixed duration, so confirm the timeline with your legal, procurement and security owners before committing to one. The duration depends on how many templates exist, how many approval layers apply, whether master agreements are renegotiated or only new purchase orders are affected, and how much supplier negotiation is expected. Ask for the scope of templates covered, the review cycle and the acceptance criteria before work starts, since these determine the schedule more than the drafting itself.
Can our team carry out SA-4 in-house?
Yes, many organizations draft their own acquisition requirements, provided the right people are involved. SA-4 touches procurement, legal, security, privacy, architecture and the business owner of each system. In-house teams usually need a clear requirements catalog drawn from SP 800-53, a documented owner for each clause and a repeatable review step. An outside partner can help by preparing templates, mapping requirements to existing contracts and documenting evidence, but the organization keeps ownership of its contracts and its risk decisions.
What does a partner need from us to start?
A partner needs access to the people and documents that define your acquisitions. Typical inputs include current contract templates, a list of systems, components and services in scope, existing security and privacy requirements, architecture and design documentation, and the names of the approvers for each contract type. Expect to provide the operating environment descriptions that SA-4 asks for, and to confirm which requirements are binding under your own policies. Scope and deliverables are agreed in writing before work begins, so gather these inputs early to keep the quote accurate.
Is a self-hosted repository enough evidence for SA-4?
A self-hosted repository can hold strong evidence, but it does not prove compliance on its own. Assessors look for executed acquisition contracts, the requirements inside them, design documentation and records showing acceptance decisions. A wiki with version history, such as XWiki, can show what changed, when and by whom, and BookStack permissions can restrict who edits templates. The repository should store the contracts and approval records themselves, and an independent assessor determines whether the evidence satisfies the control. Confirm retention and access requirements with your assessor before choosing the platform.
How does SA-4 relate to SA-9 and the SR controls?
SA-4 governs what goes into the acquisition contract, SA-9 governs the ongoing security oversight of external system services, and the SR family covers supply chain risk management across the wider supplier base. SA-4 is the contractual starting point: it defines the requirements a supplier must meet. SA-9 then sets expectations for monitoring those services after purchase, and SR controls such as the supply chain risk management plan and supplier assessments determine how supplier risk is governed. Cross-reference them in your templates so one requirement is not written three different ways. Check the related-control list in the official catalog before assuming a specific mapping.
What drives the cost of SA-4 compliance up or down?
Cost depends on scope, the number of acquisition types, the maturity of existing templates and how much supplier negotiation follows. Recurring costs include reviewing new contracts, updating requirements when SP 800-53 changes and rechecking suppliers. One-time costs include the initial requirements catalog, template redesign and staff training. When requesting a quote, ask what is included in the fixed scope, which deliverables are one-time, which are retained support, and what the partner needs from your procurement and legal teams. Ask for the assumptions behind any effort estimate.
How DeployOpen prepares SA-4 contracts and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the acquisition evidence for SA-4 reflects how the systems are actually built and run. We prepare the requirements, documentation and acceptance material that your contracts and assessors will examine, while your organization keeps ownership of its controls and contract decisions.
How we scope
- Engagements are fixed-scope, with the SA-4 deliverables, systems and boundaries agreed in writing before work starts.
- We review which acquisitions, components and services fall under your SA-4 contract requirements and list them in the written scope.
- The scope names who owns each responsibility: your organization, the supplier, or DeployOpen for the platform work we perform.
How we build
- We draft security, privacy and assurance requirement sets for each acquisition, mapped to the SA-4 requirement and enhancements your baseline selects.
- We prepare design and development environment descriptions and collect system design documentation that assessors will examine.
- We test acceptance criteria against the delivered platform and record results so acceptance decisions can be traced to evidence.
How we hand over
- You receive the requirement templates, acceptance criteria, responsibility matrix and documentation set, in formats your team can maintain.
- Each deliverable is stored with version history so you can show what changed, when and by whom during an assessment.
- We walk your contract, security and procurement staff through the evidence so they can answer assessor questions. Independent auditors issue any reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.
- Retainer work can keep acceptance criteria and supplier requirements current when contracts, components or NIST releases change.
- Confirm with DeployOpen during scoping which support terms, response expectations and review cadence apply to your SA-4 evidence.
