System and Services Acquisition (SA)

What is System and Services Acquisition (SA) 

The Centers for Medicare and Medicaid Services (CMS) uses SA to ensure that information security and privacy requirements are integrated into every stage of acquiring, developing, and maintaining information systems and services. Early allocation of resources incorporates security and privacy controls throughout the system development life cycle and can also reduce costly risks and rework, as well as accelerate project delivery for stakeholders. This approach mandates early allocation of resources for security, incorporates security and privacy controls throughout the system development life cycle, establishes strict requirements for third-party providers, and enforces documentation, configuration management, and supply chain protection. This guide discusses how the organization must: 

• Allocate sufficient resources to protect organizational information systems
• Employ system development life cycle processes that incorporate information security and privacy assurance considerations
• Restrict software usage and installation to minimize security vulnerabilities.
• Ensure that third- party providers employ adequate security measures to protect information, applications, and/or services outsourced from the organization 

Allocation of Resources 

Identifying and funding information security and privacy requirements early in mission and business planning supports effective system lifecycle management. At CMS, this is accomplished by documenting these needs in capital planning documents—specifically the Major IT Business Case (MITBC) and establishing a discrete line item for security and privacy in the program or project budget. This early budgeting helps secure management support and ensures security and privacy are integrated into system development, acquisition, and ongoing operations. Guidance on submitting budget requests is available through the Division of IT Investment Management. Key takeaways: 

• During the CMS-System Development Life Cycle (SDLC) Initiation phase you identify
  security and privacy requirements early by following using the Target Life Cycle model
• As the Information System Security Officer (ISSO) or Business Owner (BO), you define and document all resource needs including assessments, training, testing, and documentation in the OMB form 300 
• You create discrete line items for security and privacy, then submit them for review by the Business Architecture and Technology Solutions (BATS) Board and approval by the IT Investment Review Board (ITIRB) 
• Once items are approved, you record them in the IT Portfolio Summary (ITPS) as part of the Capital Planning and Investment Control (CPIC) process 

System Development Life Cycle (SDLC) 

The SDLC ensures that security and privacy requirements are integrated from the start of system development. CMS enforces this through the Target Life Cycle (TLC), which developers must follow to remain compliant. Roles and responsibilities for security and privacy are clearly defined, and systems handling Personally Identifiable Information (PII) must support automated privacy controls. Embedding these requirements early reduces costs, improves compliance, and produces artifacts that support audits and accountability. 

SDLC Best Practices:

• Developers must refer to the current CMS-SDLC guidance available on the official CMS-SDLC webpage
• The BO or designee ensures security and privacy tasks and artifacts are included in the system’s project plan
• The CMS-SDLC can be updated through a Process Change Request submitted to the IT Governance team if it does not meet project needs
• System Developers and Maintainers (SDMs) must follow the Technical Reference Architecture (TRA) during system development
• Use of live (production) data in development or test environments is prohibited unless explicitly approved by the Authorizing Official (AO) and documented in SDLC artifacts. Such use must also be coordinated with the CMS Privacy Office and protected in accordance with NIST SP 800-122 using production-level security and privacy controls. 

Acquisition Process 

When acquiring IT hardware, software, and services, CMS ensures information security and privacy requirements are built into every stage of the process. Contracting Officers must include specific language addressing security and privacy expectations to extend CMS protections to vendor-supported systems. 

This is especially critical for systems handling PII. To guide this work, CMS and HHS provide standard contract templates and maintain the Security & Privacy Language for IT Procurements repository, which offers pre-approved language for Statements of Work (SOWs) and contracts. 

Contracting Officers must include the following CMS information security requirements in acquisition contracts: 

• Security functional requirements 
• Security strength requirements 
• Security assurance requirements 
• Security-related documentation requirements and protections 
• Description of the information system development environment and operating system 
• Acceptance criteria 

Program offices assess each SOW and insert the appropriate standard security language based on: 

• The type of service being procured (e.g., cloud, software development, IT support) 
• The sensitivity of data involved, especially if PII or protected health information is processed or stored 
• Whether vendor personnel will have access to CMS systems or data 
• Risk assessments or known vulnerabilities associated with the solution or provider 

If a procurement involves higher-risk systems, additional security language and requirements may be triggered—for example, mandates for enhanced encryption, multi-factor authentication, or detailed incident reporting protocols. 

Functional Properties of Security Controls 

CMS documents how systems implement security capabilities and mechanisms by recording security controls in the System Security and Privacy Plan (SSPP) during the SDLC Planning phase. The ISSO enters these details into the CMS FISMA Continuous Tracking System (CFACTS) in accordance with the CMS Information Security & Privacy Policy (IS2P2). 

To maintain consistency with broader CMS security requirements, all SA control implementations are explicitly mapped to the CMS Acceptable Risk Safeguards (ARS) baseline. This alignment ensures that acquisition activities, control documentation, and related artifacts reflect the appropriate baseline of security and privacy requirements. 

Incorporating ARS tailoring at this stage strengthens transparency, developer accountability, and downstream security reviews. This approach also provides clarity on how system interfaces are secured.  

Design/Implementation Information for Security Controls 

Security controls are safeguards or measures such as policies, technical protections, and procedures that organizations use to reduce risks and protect information systems from threats. These controls help prevent unauthorized access, ensure data integrity, and support compliance with federal requirements. 

This security requirement ensures that CMS system developers document high-level system designs and security-relevant external interfaces. The documentation must clearly explain what interfaces exist, their purpose, and how they meet security control requirements. This supports system maintainability, secure design, and knowledge transfer for ongoing security and operational needs. The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: 

• Security-relevant external system interfaces with sufficient detail to explain their existence, purpose, and use
• Source code and hardware schematics
• High-level design documentation that demonstrates how security controls are implemented 

Functions/Ports/Protocols/Services in Use 

This enhancement requires developers to identify and document all functions, ports, protocols, and services used by a system early in the system development life cycle. This allows the ISSO to help shape secure design decisions and ensure proper security controls are implemented. This control: 

• Supports risk management and selection of secure configurations
• Helps avoid the use of high-risk or unnecessary services
• Reduces the need for costly post-implementation fixes
• Ensures compliance with the TRA Volume II 

Use of Approved PIV Products 

This enhancement ensures that CMS uses only IT products from the Federal Information Processing Standard (FIPS) Publication 201-8-approved products list for Personal Identity Verification (PIV) within organizational information systems, in accordance with Homeland Security Presidential Directive 12. CMS fulfills this directive by adopting FIPS 201 as its official standard for personal identification and access control. 

Information System Documentation 

This security requirement ensures CMS systems are supported by appropriate administrator and user documentation to enable secure configuration, operation, and maintenance. Documentation is to be distributed only to authorized personnel, as defined in each system's System Security and Privacy Plan (SSPP), to prevent unauthorized access to sensitive operational details that could lead to security vulnerabilities. Documentation includes the following: 

• Administrator documentation:
  • Secure configuration, installation, and operation details
  • Maintenance of security functions
  • Known vulnerabilities for administrative functions
• User documentation:
  • Security features accessible to users and how to use them
  • Secure interaction methods
  • User responsibilities for maintaining system security
• Additional Notes:
  • The BO or ISSO must assess the need for any extra documentation
  • CMS logs failed attempts to access missing documentation and determines whether it should be created
  • Documentation distribution must be restricted to defined roles per the SSPP
  • Sensitive admin documentation must be protected to maintain confidentiality. 

Security Engineering Principles 

Security Engineering Principles ensures that security and privacy principles are integrated throughout the SDLC. CMS developers are required to follow the CMS-SDLC, which embeds these principles into both new system development and system modifications as follows: 

• Security and privacy are built in from the start, reducing long-term costs and risks
• Developers generate required artifacts and evidence such as system security plans, threat models, security test results, code review reports, and architecture diagrams to demonstrate these principles are applied. 
• The CMS-SDLC serves as the framework for applying security engineering practices across all development phases
• Adding security after development is less efficient and more costly, reinforcing the need for early integration 

External Information System Services 

This security requirement ensures that CMS maintains oversight and accountability when using external services to process or manage CMS information systems. These services must comply with CMS security and privacy requirements, including ARS and HIPAA (if PHI is involved), even though some system responsibilities are delegated to third parties. Key takeaways: 

• CMS requires external service providers to follow federal security and privacy laws and CMS-specific controls
• Roles and responsibilities for overseeing security and privacy must be clearly assigned within CMS
• External systems must be continuously monitored using methods defined in the system’s SSPP
• The goal is to minimize risk to PII and PHI that may leave CMS boundaries, while benefiting from cost efficiencies 

Identification of Functions/Ports/Protocols/Services 

This security enhancement ensures CMS documents and reviews the functions, ports, protocols, and services needed to use external information system services, such as cloud providers. This information often gathered from vendor documentation is entered into the system's Security Plan by the developer or maintainer. Implementation of this control includes: 

• Developers performing configuration management during system development, implementation, and operation phases
• Only implementing CMS-approved changes; documenting all changes with their security impact
• The ISSO managing flaw tracking, analysis, and reporting to key stakeholders (e.g., CMS TRB, ITIRB, and BO)
• Including configuration items like design documents, source code, hardware schematics, and implementation artifacts
• Following the formal change control process for all changes, such as submitting a CMS-SDLC Process Change Request
• Ensuring configuration and change management are integrated to prevent unintended impacts on security, users, or operations 

​​​​​​​Developer Configuration Management 

This security requirement ensures that CMS developers apply effective configuration management practices throughout the system development, implementation, and operation phases to protect against unauthorized changes and maintain system integrity. Key takeaways: 

• Developers must track, document, and control changes to hardware, software, and documentation to preserve security safeguards
• Only CMS-approved changes are permitted, and all updates must include security impact documentation
• Security flaws and resolutions must be tracked and reported to designated personnel listed in the SSPP
• Configuration management includes design documents, source code, hardware schematics, and tools to compare system changes
• Configuration and change management are integrated to manage dependencies and prevent disruptions to system operations 

​​​​​​​Developer Security Testing and Evaluation 

This security requirement ensures that security and privacy controls are thoroughly tested by developers and independently evaluated before CMS systems move to production. Testing is embedded in the CMS-SDLC Testing phase and is supported by formal test plans and documentation. Key takeaways: 

• Cybersecurity and Risk Assessment Program (CSRAP) is conducted by an independent third-party Evaluator using a Security Assessment Plan
• If the system contains PII, privacy controls must also be included in the assessment
• Testing includes unit, integration, system, and regression testing following CMS and ARS procedures
• Results are documented in the CMS Assessment/Audit Tracking (CAAT) file
• Flaws discovered are tracked using POA&Ms. Unresolved risks may require a Risk Acceptance form approved by the AO 

Supply Chain Protection 

In the CMS context, the supply chain refers to all external vendors, manufacturers, and service providers that deliver hardware, software, and support services used by CMS information systems. Protecting the supply chain means rigorously managing the risks presented by these third-party suppliers, from initial procurement through installation and ongoing maintenance. 

Supply chain protection safeguards CMS information systems by applying due diligence and security best practices throughout the acquisition process. CMS emphasizes selective supplier procurement using established methodologies and prefers government-reviewed components. 

Key Takeaways: 

• CMS uses best practices and contract language to safeguard against supply chain threats
• Suppliers are vetted to ensure they meet CMS security standards; those that don’t are rejected
• CMS aims to prevent threats introduced by third-party suppliers of system components
• The Division of Physical Security and Strategic Information (DPSSI) leads CMS’s Supply Chain Risk Management (SCRM) efforts
• Components already reviewed by entities like NIAP are preferred in acquisitions
• Inquiries related to supply chain security can be directed to CounterIntelligence@cms.hhs.gov. 

​​​​​​​Development Process, Standards, and Tools 

This security requirement ensures CMS developers use documented, secure, and repeatable development processes that incorporate security requirements and are regularly reviewed for effectiveness. This includes managing development tools, standards, and configurations to protect system integrity throughout the lifecycle. 

• Developers must document:
• Security requirements
• Standards and tools used in development
• Tool configurations and options
• Change management for tools and processes
• The CMS-SDLC is the approved development process framework.
• Development practices are:
• Reviewed annually by developers.
• Formally reviewed quarterly by the CMS-SDLC Steering Committee.
• Comprehensively reviewed every 3 years to ensure compliance with SA and CM security controls.
• Repeatable, documented processes support continuous improvement and supply chain risk mitigation. 

​​​​​​​​​​​​​​Developer Provided Training 

Developer provided training ensures that CMS receives appropriate training or training materials from developers to support the correct use of implemented security functions, controls, and mechanisms. This training helps CMS personnel understand how to operate and protect systems effectively. To ensure this objective is met, the following training requirements apply: 

• Training can include classroom, web-based, hands-on, or self-study formats
• Developers must provide training or materials before the CMS-SDLC Test phase for all relevant security features listed in the SSPP
• Training may vary based on specific security functions or roles
• Records of completed training must be maintained and submitted to the ISSO and CMS COR
• CMS uses this training to reduce risk and ensure proper system operation and protection 

​​​​​​​Developer Security Architecture and Design 

The purpose of this security requirement is to ensure that external developers create a System Design Document (SDD) based on a security architecture aligned with CMS’s enterprise and information security architecture. This requirement supports consistent implementation of security capabilities across systems and minimizes vulnerabilities from poor architectural design. Key takeaways: 

• The SDD must describe required security functions, control allocation, and how security components work together
• The design must align with CMS’s enterprise security architecture
• Helps prevent risks from improper security implementation during development
• Primarily applies to external developers, while PL-8 covers internal CMS development efforts
• Ensures outsourced systems meet CMS’s architectural and security standards 

Developer Screening 

Developer screening ensures that individuals responsible for developing or maintaining CMS information systems, components, or services meet appropriate authorization and personnel security requirements. This control reduces the risk of insider threats and ensures that sensitive CMS data and system designs are only accessible to trusted personnel. Screening activities include role-based access determinations as well as additional personnel background checks. 

• Developers must have access authorizations appropriate to their assigned duties, consistent with CMS role-based access controls
• Personnel involved in development must satisfy additional screening requirements, which may include background investigations, security clearances, citizenship or nationality restrictions, and other checks as directed by federal and CMS policy
• The BO and ISSO are responsible for ensuring that all personnel screening requirements are documented and verified before granting access to sensitive development environments or artifacts
• Screening helps prevent unauthorized access or influence during system development
• Documentation of screening outcomes must be retained as part of the system’s SSPP to demonstrate compliance 

Unsupported System Components 

This control ensures that CMS does not rely on system components (hardware, software, or services) that no longer receive vendor or developer support. Unsupported components present a significant security risk, as they no longer receive security patches or updates. CMS mitigates this risk by replacing unsupported components or implementing alternative support strategies. 

• System components must be replaced when vendor, developer, or manufacturer support is no longer available
• If immediate replacement is not feasible, the program office must provide alternative sources of continued support, such as CMS in-house support arrangements, until replacement is completed
• All instances of unsupported components must be documented in the System Secuirty and Privacy Plan (SSPP) and tracked in the Plan of Action and Milestones (POA&M) to ensure timely remediation
• The ISSO and system owner are responsible for verifying that unsupported components are identified, risk-assessed, and appropriately addressed
• Timely replacement is the preferred strategy, but documented in-house support may serve as an interim solution.
• Continuous monitoring processes must flag unsupported components for prompt action 

Conclusion 

SA security requirements outlined in this guide provide a structured and comprehensive approach to integrating security and privacy throughout the system lifecycle. By translating complex NIST requirements into practical, CMS-tailored processes, this guide ensures that all stakeholders from developers to program managers understand their roles in safeguarding CMS information systems. With clearly defined responsibilities, documentation requirements, and built-in review mechanisms, these control requirements support CMS’s mission to protect sensitive data, reduce risk, and maintain compliance with federal mandates. Use this guide as a reference to support a secure and efficient acquisition, development, and operation of CMS systems and services.