Patient bill-pay portal design
Developer architecture misses account linking risks. SA-17 review forces stronger identity proofing before coding.
Developer Security Architecture and Design
High Risk
Complex
Medium Cost
SA-17 requires requiring the developer to produce a design specification and security/privacy architecture consistent with organizational architecture, and to demonstrate concept of use for security functions. Custom patient apps and interfaces designed without threat models become breach headlines.
Control Objective
Require developers of ePHI systems to deliver security/privacy architectures and designs aligned to enterprise architecture, with demonstrated secure concepts of use before build-out.
Implementation Guidance
- Mandate design specifications covering authN/Z, data protection, logging, and privacy for ePHI projects.
- Require alignment to PL-8/PL-13 enterprise architectures.
- Conduct threat modeling for high-risk interfaces and portals.
- Review developer architecture artifacts at design gates.
- Demand concept-of-use demos for break-glass, encryption, and audit features.
- Apply to BA-developed customizations via contract.
- Reject designs that require standing shared clinical accounts.
- Retain design evidence with SA-5 documentation.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
RPA bot for prior auth
Design shows bot using a physician's password. Redesign under SA-17 uses service identity and audited API scopes.
Vendor abstraction layer
BA proposes a bus that decrypts all HL7 to cleartext centrally. Architecture challenge requires encryption and minimization patterns.
Best Practices
- Design specs before major coding.
- Threat models for high risk.
- Align to enterprise architecture.
- Demo security functions early.
- Contractual design deliverables for BAs.
- Gate shared-account designs.
Common Gaps & Violations
- Code-first with design later.
- Architecture diagrams without trust boundaries.
- No privacy design content.
- Security features undemoable until production.
- Copying consumer-app patterns for clinical data.
Required Documentation
- Developer security architecture requirements (SA-17)
- Design review checklist
- Threat model samples
- Concept-of-use demonstration records
- BA design deliverable clauses
How to Test & Validate
- Sample a project for SA-17 design artifacts.
- Verify design review occurred before build.
- Check alignment notes to PL-8.
- Review a threat model for a portal/API.
- Confirm BA SOW includes design deliverables.
Audit Considerations
Design flaws are expensive to fix post-go-live. Assessors look for design discipline on systems that create new ePHI exposure.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.308(a)(1) Risk Analysis — design should address identified risks to ePHI.
- 164.312 Access Control / Audit / Integrity / Transmission — design allocates these technical safeguards.
- 164.530(c) Safeguards — privacy by design supports reasonable safeguards.
- 164.316 Documentation — retain design documentation of how safeguards work.
Compliance Tips
- Put SA-17 artifacts on the same gate as funding approval for ePHI apps.
- Reuse pattern catalogs (authZ, logging) to speed reviews.
- Invite privacy to design reviews involving new disclosures.
Frequently Asked Questions
How does SA-17 relate to PL-8?
PL-8 is organizational security architecture; SA-17 requires developers to produce system designs consistent with it.
Do configuration-only projects need SA-17?
Scale formality to risk — significant EHR security configuration still needs design/spec of how controls will be set.
Is a threat model mandatory?
Strongly recommended for high-risk ePHI apps; document alternative design analysis if a formal TM is deferred.
References & Resources
- NIST SP 800-53 Rev. 5 — SA-17
- Related controls: PL-8, PL-13, SA-3, SA-8, SA-4
Related Guidelines
Related controls that commonly accompany SA-17.
Need Help Implementing SA-17?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.