The System and Services Acquisition (SA) domain is the blueprint for security programs. This domain requires you to plan for security before you even buy or build it. NIST SP 800-171 Rev 2 assumes nonfederal organizations already meet these controls. A single control from the SA domain wound up in the SC domain. Revision 3 of NIST SP 800-171 makes the assumed controls explicit requirements.
For this reason, we opted to include a policy for this domain. SA controls focus on resource allocation, system development, and external services. This domain builds proactive security by choosing secure vendors. The SA domain is about "buying and building" with your eyes wide open. Every new tool or service you add to your business makes your security stronger, not weaker.
Domain level policies address the controls implemented within systems and organizations. Policies are the perfect home to define control parameters, such as frequencies. Procedures describe the implementation of policies or controls. Organizations may document procedures within the system security plan or within separate documents.
Here are some of the principles that guided this system and services acquisition policy:
A cover page tracks specific details regarding the policy, including:
NIST SP 800-53 defines specific objectives for domain-level policies. From this guidance we incorporate the following major sections into our policy:
The purpose statement should identify why the policy exists and what it aims to achieve.
The scope should identify who it applies to and under what circumstances.
The policy governance section covers most of the organization defined parameters. These subsections cover the following details:
The fourth section includes our policy statements. Subsection headings group related Policy statements together. Each policy statement has a unique number for traceability to other documents. A policy statement number consists of the section, subsection, and policy statement order.
The fifth section identifies the relevant roles and responsibilities identified in the policy. A single, short paragraph describes the responsibilities for each role. The sixth section identifies the supporting procedures. We opted to align our subsection headings with the names of supporting procedures. The seventh section identifies related documents, to include relevant policies. The eighth section documents a revision history. This table captures policy changes, including: version, effective date, approver(s), change summaries. The ninth section captures a formal authorization of the policy by the policy owner.
NIST identified a named set of procedures for each practice within NIST SP 800-171. The assessment guide (SP 800-171A) contains the original mappings. The CMMC assessment guides include this mapping as well. NIST derived these assessment objects from SP 800-53A. Table E maps the tailoring actions of controls from SP 800-53. For this domain, we followed the original procedures defined for the underlying controls.
Before purchasing or building a new system, an assessment identifies the needed protections. The organization budgets the necessary people, money, and technology to install these protections. The CFO maintains a specific line item in the budget for security and privacy. This ensures money needed for updates, maintenance, and compliance is always available.
No CMMC Objectives Covered in This Section
The organization uses a System Development Life Cycle (SDLC) for new technology. This process incorporates security into every step. The organization assigns people to key roles, with each briefed on their duties. At major milestones, the team performs a "health check" to see how new threats might affect the project. The organization also uses strict, standardized language in all vendor contracts. These include requirements for specific capabilities and proof of their implementation.
The organization requires developers to map how the system works. This includes diagrams of how sensitive data moves and a list of every digital door or port the system uses. The organization disables any feature or connection not on the approved list. This "deny-by-default" approach ensures the system only performs its intended tasks. Before finishing a project, dedicated personnel perform a final review. This step verifies and tests security rules in the contract. This ensures the organization does not take ownership of a system that could put it at risk.
No CMMC Objectives Covered in This Section
The organization must get or create security manuals for every system. These documents must explain how to install, configure, and maintain security features. They also outline the security responsibilities for both administrators and regular users. If a vendor does not provide these guides, dedicated personnel must write them. The team distributes these manuals to personnel with security responsibilities for the system.
No CMMC Objectives Covered in This Section
The organization uses a Security and Privacy Architecture to defend its data. This includes detailed maps and designs that show a "defense-in-depth" approach. The team follows a "less is more" rule by only collecting the data they need. They isolate sensitive parts of the system from the rest of the network to limit risk. The organization updates security plans whenever the system architecture changes. The team follows government-standard principles to build and buy software or cloud services.
CMMC Objectives Covered in This Section:
The organization holds all outside partners to the same security standards used in-house. Any company handling CUI must prove they meet CMMC Level 2 requirements. Cloud services storing CUI must provide a FedRAMP Moderate or equivalent authorization. To keep roles clear, the organization uses a "Shared Responsibility Matrix." This document shows which security tasks the provider and organization manage. Dedicated personnel ensure these partners stay compliant every year. This includes reviewing audit reports and checking for any new security warnings.
CMMC Objectives Covered in This Section:
Outside services must provide a list of all digital doors and connections. The provider must document every port and protocol needed. Dedicated personnel review this list to ensure the system enables only required connections.
No CMMC Objectives Covered in This Section
Developers must follow a change control process during every phase of a system's life. Developers must track and protect changes made to source code or security settings. Developers must provide digital signatures or hashes for every file they deliver.
Dedicated personnel check digital signatures before allowing new updates on the network. The change control board must review how changes might affect the system's security. Developers must keep a formal log of any software bugs or security flaws they find. They report these findings to the organization every month. They report critical flaws immediately.
No CMMC Objectives Covered in This Section
Developers follow a plan to test that security guard and privacy lock works as intended. Developers must test the code every time they make a major update or at least once every three months. They use tools to scan for weaknesses and review the most important parts of the software. This deep dive ensures that the security features are solid before the software is ever used.
Developers must document evidence showing which tests passed. If they find any bugs, they must track them in a central system and fix them based on a risk categorization. Developers must verify fixes actually worked and didn't break something else.
No CMMC Objectives Covered in This Section
FedRAMP guidance on how to write a control implementation statement states the following:
Write your policies before you start drafting your security plan. K2 GRC shows you exactly how each part of your policy connects to your security goals. This starts with selecting an objective to document.
After selecting a criteria, K2 GRC shows policy statements relevant to that criteria. The input screen shows the specific policy name and the statement’s number. This enables users to cite relevant policy sections within the control narratives. The system aggregates these control narratives to populate the system security plan (SSP).
The System and Services Acquisition domain is your secret weapon for stress-free growth. By addressing security requirements early, you lead with a proactive defense. This includes making your budget, vendors, and developers care about security. When you build security from the start, compliance becomes a natural result of your work. Don't let a bad procurement decision today become a failed audit tomorrow. Our SA Policy template incorporates security into vendors, budgets, and product development. It turns "buying technology" from a risk into a strategic advantage. Download the policy template now and grow your business without sacrificing security.
