SA-1 System Acquisition

System Acquisition Policy and Procedures

High Risk Moderate Low Cost

SA-1 requires system and services acquisition policy and procedures addressing purpose, scope, roles, management commitment, coordination, and compliance, plus procedures to implement the SA family. Healthcare SA-1 ensures security, privacy, and HIPAA BA obligations are built into RFPs, contracts, and development for systems that will touch ePHI — not bolted on after purchase.

Control Objective

Govern acquisition and development of systems and services so security and privacy requirements for ePHI are defined, contracted, implemented, and maintained across the lifecycle.

Implementation Guidance

  1. Publish SA-1 policy covering purchased software, SaaS, custom development, medical devices, and managed services.
  2. Require security/privacy requirements in RFPs and contracts for ePHI-impacting acquisitions.
  3. Mandate BAA / BA due diligence when ePHI may be created, received, maintained, or transmitted.
  4. Define SDLC security expectations for internal builds and interfaces.
  5. Assign procurement, legal, security, and clinical IT gate roles.
  6. Require documentation (architecture, admin guides) from vendors (link SA-5).
  7. Review policy annually and after major sourcing model changes (e.g., cloud-first).
  8. Align with SA-4 acquisition process, SA-9 external services, and SR supply chain.

Real-World Use Cases

How this control shows up in healthcare and HIPAA-covered environments.

Selecting a new RCM cloud suite

SA-1 procedures block contract signature until encryption, audit export, MFA support, and BAA terms clear security/legal gates.

Custom HL7 interface build

Internal development follows SA-1 SDLC security checks before production ePHI messages flow.

Department buys a scheduling SaaS

Procurement gate under SA-1 catches the purchase and routes for privacy review before patient demographics are uploaded.

Best Practices

  • Security requirements catalog for ePHI vendors.
  • No PO without security/privacy sign-off when ePHI possible.
  • BAA tracking tied to acquisition.
  • Secure SDLC for in-house clinical apps.
  • Lifecycle support and EOL planning.
  • Flow-down to subcontractors.

Common Gaps & Violations

  • Clinical departments purchase apps with ePHI off-contract.
  • Security review after go-live.
  • BAAs missing for clear BA services.
  • No security requirements in RFPs.
  • Custom scripts in production without review.

Required Documentation

  • System and services acquisition policy (SA-1)
  • Procurement security checklist
  • SDLC security procedures
  • Roles for acquisition gates
  • Policy review records

How to Test & Validate

  1. Confirm SA-1 policy covers SaaS and devices.
  2. Sample a recent ePHI vendor purchase for checklist completion.
  3. Verify BAA executed when required.
  4. Review an internal development project for SDLC security steps.
  5. Interview procurement on gate enforcement.

Audit Considerations

Third-party and acquisition failures drive many healthcare breaches. SA-1 evidence shows security is a purchase requirement, not optional advice.

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.308(b) Business Associate Contracts — obtain satisfactory assurances before BA access to ePHI.
  • 164.314 Organizational Requirements — contract provisions for BA safeguard obligations.
  • 164.308(a)(1) Risk Management — acquisition decisions must reduce risk to reasonable levels.
  • 164.316 Policies and procedures — document acquisition-related security policy.

Compliance Tips

  • Embed the ePHI intake question on every IT/clinical purchase request form.
  • Maintain a standard security exhibit for vendor contracts.
  • Train department admins that “free clinical apps” still need SA-1 gates.

Frequently Asked Questions

Does SA-1 apply to open-source components?

Yes — policy should require review of components included in apps that process ePHI.

How does SA-1 relate to SA-4?

SA-1 is the policy; SA-4 defines acquisition process requirements applied to each purchase/build.

What if an executive already signed a vendor?

Policy should still require security onboarding and residual risk acceptance before ePHI connection — document the exception.

References & Resources

  • NIST SP 800-53 Rev. 5 — SA-1
  • Related controls: SA-3, SA-4, SA-5, SA-9, SR-3

Need Help Implementing SA-1?

Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.