CA-6 Security Assessment

Security Authorization

High Risk Moderate Low Cost

CA-6 requires assigning a senior official as the authorizing official for the system, ensuring the official authorizes the system for operation before commencement, and updating the authorization when required. In healthcare terms, someone accountable must accept residual risk for EHR, imaging, patient portals, and BA platforms — go-live is not only a project decision, it is a security authorization decision.

Control Objective

Ensure a designated authorizing official formally accepts residual risk and authorizes operation of ePHI systems before production use and when significant changes occur.

Implementation Guidance

  1. Name authorizing officials (AO) by system tier — e.g., CIO/CISO for enterprise EHR; delegated AO for lower-impact tools.
  2. Require a security authorization package: system description, risk assessment, control status, POA&M, and residual risk statement.
  3. Block production go-live until AO sign-off is recorded.
  4. Define events that trigger re-authorization: major architecture change, new data flows, ownership change, severe incident.
  5. Time-box authorizations (e.g., annual re-attest) even without change.
  6. Align with change advisory and privacy reviews for ePHI scope.
  7. Document conditional authorizations with explicit POA&M conditions.
  8. Include cloud SaaS ePHI systems — authorize the use of the service in your environment, not only on-prem boxes.

Real-World Use Cases

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

New telehealth platform go-live

Project wants weekend cutover. CA-6 gate holds until AO reviews BAA, encryption, and residual risk; conditional ATO issued with 60-day MFA milestone.

Imaging archive migration to cloud

Re-authorization is triggered by architecture change; AO accepts residual risk only after SC-8/SC-28 evidence and updated diagrams.

Clinic adds a shadow transcription SaaS

Security finds it in use without CA-6; access is suspended until authorization package and BAA are completed.

Best Practices

  • Named AO with authority and accountability.
  • Package-driven authorization before prod.
  • Conditional ATOs tied to POA&M.
  • Re-auth on significant change.
  • Cover SaaS ePHI tools.
  • Record decisions with dates and scope.

Common Gaps & Violations

  • Systems live for months with no AO sign-off.
  • 'IT approved the ticket' treated as authorization.
  • No re-auth after major cloud migration.
  • Residual risk never stated in writing.
  • Shadow IT ePHI tools never authorized.

Required Documentation

  • Security authorization policy
  • AO designation letters / RACI
  • Authorization package template
  • Signed ATO / residual risk acceptance records
  • Re-authorization triggers and schedule

How to Test & Validate

  1. Pick a production ePHI system; locate AO authorization evidence.
  2. Verify go-live date is after authorization date.
  3. Sample a major change for re-authorization.
  4. Confirm conditional ATO items appear in CA-5.
  5. Check SaaS ePHI inventory for authorization coverage.

Audit Considerations

Lack of formal risk acceptance for systems holding ePHI undermines the risk-management story. Assessors expect named accountability, not informal go-lives.

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.308(a)(1)(ii)(B) Risk Management — decide and document security measures; authorization records that decision for a system.
  • 164.308(a)(2) Assigned Security Responsibility — official responsible for security aligns with AO accountability.
  • 164.316 Policies and procedures — document authorization decisions and retain them.
  • 164.308(a)(8) Evaluation — periodic evaluation supports ongoing authorization decisions.

Compliance Tips

  • Add 'AO security authorization complete' as a hard gate on the EHR change checklist.
  • Use one authorization register listing system, AO, date, expiry, and conditions.
  • Train project managers that 'privacy signed the BAA' is not a substitute for CA-6.

Frequently Asked Questions

Is CA-6 only for federal systems?

The control language comes from RMF, but the practice — formal residual risk acceptance before operating ePHI systems — is valuable and mappable for healthcare.

Who can be the AO?

A senior official with authority to accept risk for the organization; often CIO/CISO or a documented delegate — not the project manager alone.

How does CA-6 relate to CA-5?

CA-6 may authorize with conditions; those conditions become POA&M items under CA-5.

References & Resources

  • NIST SP 800-53 Rev. 5 — CA-6
  • NIST SP 800-37 Risk Management Framework
  • Related controls: CA-2, CA-5, CA-7, RA-3, PM-9

Need Help Implementing CA-6?

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