Container image for patient API
CI records signed provenance attestations for images deployed to the ePHI API cluster.
Provenance
High Risk
Complex
Medium Cost
SR-4 requires documenting, retaining, and auditing the provenance of systems and components. Knowing where EHR appliances, containers, and device firmware came from enables authenticity checks, vulnerability response, and investigation when ePHI environments are compromised.
Control Objective
Capture and retain provenance information for critical ePHI system components — including origin, modifiers, and supply path — so integrity and authenticity can be verified over time.
Implementation Guidance
- Define provenance data required for critical hardware/software (supplier, lot/serial, build IDs, SBOM).
- Collect provenance at acquisition and build time.
- Store provenance records with asset inventory (CM-8).
- Prefer vendors who provide SBOMs or signed build attestations.
- Use provenance during incident response to find affected components.
- Audit completeness for tier-1 components periodically.
- Protect provenance stores from unauthorized alteration.
- Align with SR-11 authenticity verification.
Real-World Use Cases
How this control shows up in healthcare and HIPAA-covered environments.
Network appliance incident
Provenance records identify which clinics received a suspect firmware batch for rapid isolation.
Missing SBOM for billing RPA
Procurement holds go-live until vendor provides component inventory for the bot runtime.
Best Practices
- Provenance requirements by criticality.
- SBOM/attestation preference.
- Link to CM-8 assets.
- Use in IR.
- Periodic completeness audits.
- Integrity-protect provenance data.
Common Gaps & Violations
- No idea which firmware versions are where.
- Unsigned containers in production.
- Provenance only in email threads.
- No SBOM asks of critical vendors.
- Inventory without supplier origin fields.
Required Documentation
- Provenance procedure (SR-4)
- Required provenance data elements
- SBOM/attestation repository evidence
- Audit samples of tier-1 components
- IR use-case references
How to Test & Validate
- Sample critical assets for provenance fields populated.
- Review SBOM or attestation for a production app.
- Confirm storage integrity controls.
- Trace how IR would use provenance.
- Check vendor contract language for provenance deliverables.
Audit Considerations
Provenance is foundational to authenticity and vulnerability response. Assessors ask whether you can identify affected components quickly after a supplier advisory.
HIPAA Mapping
How this NIST control supports HIPAA Security Rule expectations.
- 164.312(c) Integrity — provenance supports detection of unauthorized components.
- 164.308(a)(1) Risk Management — knowing supply origin informs risk treatment.
- 164.308(a)(6) Incident Procedures — provenance accelerates scoping.
- 164.312(b) Audit Controls — provenance records are auditable artifacts.
Compliance Tips
- Start SR-4 with boundary appliances, EHR-related servers, and custom apps.
- Require SBOM language in new critical software contracts.
- Store provenance in the same CMDB as assets.
Frequently Asked Questions
Is an SBOM mandatory for SR-4?
Not always available, but document provenance to the extent obtainable and prioritize vendors who provide it for critical ePHI software.
Does SR-4 apply to SaaS?
Capture what you can (provider, region, major version, subprocessors) as provenance of the service components you rely on.
How long retain provenance?
Align to asset life plus investigation/HIPAA documentation needs.
References & Resources
- NIST SP 800-53 Rev. 5 — SR-4
- Related controls: SR-11, CM-8, SI-7, RA-5, SA-10
Related Guidelines
Related controls that commonly accompany SR-4.
Need Help Implementing SR-4?
Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.