Offshore EHR customization team
BA proposes unnamed developers with prod VPN. SA-21 contract clause requires named, screened individuals and JIT access.
Developer Screening
High Risk
Moderate
Medium Cost
SA-21 requires requiring that the developer of the system have appropriate security and privacy screening as defined by the organization. Offshore or contractor developers with EHR codebase or production debug access without screening create insider risk to ePHI.
Control Objective
Ensure people and supplier staff who develop, customize, or maintain ePHI systems are screened to a level matching their access to code, configs, and environments.
Implementation Guidance
- Define screening requirements for internal developers and vendor developers with ePHI system access.
- Align depth to PS-2/PS-3 style risk tiers (production access vs lower environments with synthetic data).
- Flow screening requirements into BA/contracts for custom development.
- Reassess when developers gain production break-glass.
- Protect screening results; share only clearance status with project managers.
- Deny or gate repo/prod access until clearance complete.
- Include privileged CI/CD admins as developers under this control.
- Coordinate with MA-5 for maintainer screening overlaps.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
Intern with production debug
Internship expands to live ePHI troubleshooting. Screening upgrade required before rights expand.
CI admin role
Pipeline admin can inject code into billing APIs. Treated as high-risk developer screening tier.
Best Practices
- Screening tiers by access level.
- Contractual vendor developer screening.
- Gate repo/prod access on clearance.
- Named individuals, not anonymous teams.
- Reassess on privilege growth.
- Include CI/CD admins.
Common Gaps & Violations
- Anonymous vendor developer pools with shared VPN.
- Screening only for employees, not BA coders.
- Production access before checks complete.
- No re-screen on privilege increase.
- Treating all developers as low risk.
Required Documentation
- Developer screening standard (SA-21)
- Tier matrix linked to access types
- Contract clauses for BA developers
- Clearance gating evidence for access provisioning
- Rescreen triggers documentation
How to Test & Validate
- Sample internal developers with prod access for screening evidence.
- Review BA SOW for screening requirements.
- Confirm access provisioning checks clearance flag.
- Trace a privilege increase to rescreen.
- Verify CI admins included in high tier.
Audit Considerations
Insider and vendor-insider risk is material for ePHI. SA-21 should show developers are trusted commensurate with their reach into clinical systems.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.308(a)(3) Workforce Security — authorization and clearance for workforce including those building systems.
- 164.308(a)(3)(ii)(B) Workforce Clearance Procedures — determine access appropriateness.
- 164.308(b) Business Associate Contracts — BA workforce handling ePHI need equivalent assurances.
- 164.308(a)(1) Risk Management — insider development risk requires treatment.
Compliance Tips
- Add clearance status to the identity workflow for developer roles.
- Prohibit shared vendor logins regardless of screening.
- Align SA-21 tiers with PS-2 position risk designations.
Frequently Asked Questions
Does SA-21 apply to low-code citizen developers?
Yes when they build apps touching ePHI — screen and train commensurate with access.
How does SA-21 differ from PS-3?
PS-3 is general personnel screening; SA-21 focuses on developers of the system, including supplier developers.
Are screened developers allowed unlimited prod access?
No — screening complements least privilege (AC-6) and JIT access, it does not replace them.
References & Resources
- NIST SP 800-53 Rev. 5 — SA-21
- Related controls: PS-2, PS-3, SA-3, AC-6, MA-5
Related Guidelines
Related controls that commonly accompany SA-21.
Need Help Implementing SA-21?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.