SA-4, Acquisition Process, is a contract control. It asks the organization to include, explicitly or by reference, a set of requirements, descriptions and criteria in the acquisition contract for any system, component or service. The nine items are security and privacy functional requirements, strength of mechanism requirements, security and privacy assurance requirements, controls needed to meet those requirements, security and privacy documentation requirements, requirements for protecting that documentation, a description of the development environment and the environment where the system will run, allocation of responsibility among the parties for security, privacy and supply chain risk management, and acceptance criteria.
800-53 binds US federal systems, and others through contract. For a small or mid size company it is a reference, and a good checklist for the next vendor agreement you sign or the next customer agreement you receive.
What it means in practice
Each item answers a question you would rather ask before signing than after an incident.
Functional requirements say what the security features must do. The guidance says they come from the high level requirements you set under SA-2, and describe capabilities, functions and mechanisms.
Strength of mechanism covers correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. In plain terms: how hard is it to break the feature?
Assurance requirements cover the development process and the evidence from development and assessment that gives you grounds for confidence.
Documentation requirements span the whole life cycle and give users and administrators the guidance to operate controls. The level of detail depends on the system's categorization and how much you depend on it. The guidance says requirements can include mandated configuration settings that specify allowed functions, ports, protocols and services.
Responsibility allocation names who does what for security, privacy and supply chain risk. The guidance adds that you can set notification and timing requirements for support, maintenance and updates.
Acceptance criteria are defined like any procurement criteria: what must be true before you accept delivery.
The enhancements go deeper where needed: SA-4.1 Functional Properties of Controls, SA-4.2 Design and Implementation Information for Controls, SA-4.3 Development Methods, Techniques, and Practices, SA-4.4 Assignment of Components to Systems, SA-4.5 System, Component, and Service Configurations, SA-4.6 Use of Information Assurance Products, SA-4.7 NIAP-approved Protection Profiles and SA-4.8 Continuous Monitoring Plan for Controls.
Evidence to collect
- The executed contract or order form with the security terms, or an attached security schedule.
- A requirements document that traces each functional requirement to a business need.
- The vendor's documentation set and the date you received it.
- Your acceptance checklist and the signed result.
- A responsibility matrix showing who owns each control, you or the provider.
- Notification terms for incidents, vulnerabilities and end of support.
Common gaps
Buying on a standard form with no security terms, then discovering you cannot get a vulnerability notice or an audit report.
Requirements that stay vague: "industry standard security." An auditor cannot test that sentence.
No acceptance criteria. If nothing defines done, the first release is accepted by default.
A shared responsibility model that nobody wrote down. Teams assume the provider handles encryption keys or logging while the provider assumes the reverse.
How to implement it
- Create a security schedule template with the nine items as headings.
- Fill in requirements per purchase, scaled to risk. A design tool needs less than a payment processor.
- Ask vendors for documentation before you sign, and keep it.
- Write acceptance tests that check the main security requirements.
- Assign each control to you or the provider in a responsibility matrix.
- Add timing for security notices and support windows.
- Store the signed contract and the acceptance results together.
Quick check
Which SA-4 item do teams most often leave out?
Often the allocation of responsibility, or the acceptance criteria. Both need to be written down, and both are easy to test for in an audit.
Does SA-4 only apply to buying software?
No. It applies to systems, components and services, and the control mentions development contracts as well.
