Custom MFA broker for EHR
Organization builds a broker tying badges to EHR. SA-20 elevates design review, testing, and dual maintenance ownership.
Customized Development of Critical Components
Medium Risk
Very Complex
High Cost
SA-20 requires re-implementing or custom developing critical system components with specific controls when organizational risk warrants not trusting commodity components. Rare but relevant when a hospital builds a critical identity bridge, crypto module wrapper, or safety-critical interface that processes ePHI and cannot accept opaque vendor internals.
Control Objective
Apply heightened development, review, and assurance when the organization custom-builds critical components that can critically affect ePHI confidentiality, integrity, or availability.
Implementation Guidance
- Define what components are critical enough to warrant SA-20 treatment.
- Prefer trusted vendors when possible; use SA-20 only with clear risk rationale.
- Apply rigorous SA-3/SA-11/SA-17 practices plus independent review for custom criticals.
- Minimize ePHI handling in custom critical components.
- Subject code to enhanced testing and integrity controls (SA-10/SI-7).
- Document decision not to use commodity alternatives.
- Ensure maintainers are screened (SA-21) and knowledge is not single-person.
- Plan sustainment and succession for custom criticals.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
Homegrown crypto wrapper
Team wraps encryption for a legacy DB. SA-20 demands independent crypto review and key-management alignment to SC-12.
Critical HL7 filter
Custom filter blocks malware-laden messages. Treated as critical component with enhanced CM and monitoring.
Best Practices
- Explicit criticality criteria.
- Enhanced SDLC for SA-20 components.
- Independent review.
- Minimize ePHI in custom criticals.
- Dual maintenance ownership.
- Document why commodity was rejected.
Common Gaps & Violations
- Critical homegrown tools with no extra assurance.
- Single volunteer maintainer.
- No threat model.
- Custom crypto without review.
- Shadow critical scripts unknown to security.
Required Documentation
- SA-20 decision criteria and register of critical custom components
- Enhanced development/testing evidence
- Independent review records
- Sustainment/ownership plans
- Rationale vs commodity alternatives
How to Test & Validate
- Identify any custom components labeled critical; review SA-20 evidence.
- Verify independent review occurred.
- Confirm dual ownership/succession.
- Check enhanced testing artifacts.
- Validate register completeness vs tribal knowledge.
Audit Considerations
Most healthcare orgs use SA-20 rarely. If you custom-build critical ePHI components, expect assessors to demand higher assurance evidence.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.308(a)(1) Risk Management — critical custom components need stronger risk treatment.
- 164.312(c) Integrity — custom critical code can undermine integrity if weak.
- 164.312(a) Access Control — identity/crypto customizations affect access control assurance.
- 164.306 Reasonable safeguards — higher impact warrants stronger measures.
Compliance Tips
- Keep the SA-20 register short and honest.
- Prefer configuring hardened vendor components over custom criticals when possible.
- Fund independent review in the SA-2 budget for these items.
Frequently Asked Questions
Do all custom HL7 maps need SA-20?
No — only components your organization designates as critical with heightened assurance needs.
Is forking open source SA-20?
It can be if the fork becomes a critical component; apply commensurate controls.
How related to SA-3?
SA-3 always applies; SA-20 adds assurance intensity for designated critical custom components.
References & Resources
- NIST SP 800-53 Rev. 5 — SA-20
- Related controls: SA-3, SA-11, SA-17, SC-12, SI-7
Related Guidelines
Related controls that commonly accompany SA-20.
Need Help Implementing SA-20?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.