Re-evaluate when a change alters what touches electronic protected health information or how it is protected: a new data handling library, a new hosted service, a major version jump in a core framework, a change in crypto or authentication components, or an advisory on something you rely on. Routine patch bumps usually do not need a full review.
What the rule says about evaluation
45 CFR 164.308(a)(8) asks for a periodic technical and nontechnical evaluation, based initially on the standards and afterward in response to environmental or operational changes affecting the security of electronic protected health information. Section 164.306(e) separately says security measures must be reviewed and modified as needed. The text does not list triggers, so you define them in policy and apply them consistently.
Trigger list
| Change | Re-evaluate? | Why |
|---|---|---|
| New library that parses or stores patient data | Yes | New code on the data path |
| New hosted service that can receive ePHI | Yes | New party, new agreement question |
| Major version of web framework, ORM or auth library | Yes | Behavior and defaults change |
| Swap of crypto, TLS or token library | Yes | Core protection changes |
| Advisory rated critical or listed as exploited in the wild | Yes, fast track | Active risk |
| Minor or patch update with no advisory | No, log only | Covered by routine process |
| Dev only tooling update | Usually no | No runtime exposure |
CISA maintains the Known Exploited Vulnerabilities catalog and says organizations should use it as an input to vulnerability prioritization, which makes it a sensible trigger source for the fast track row.
How to wire triggers into daily work
- Add a pull request check that flags a new dependency or a major version bump.
- Label those changes "security re-evaluation needed" and route them to a named reviewer.
- Give the reviewer a short form: what changed, does it touch ePHI, what risks changed, what controls changed.
- Store the completed form with the release record.
- Once a quarter, sample five forms and confirm they were completed on time.
What a good record looks like
Four lines are enough: the change, the question asked, the decision, and the date with an owner. The rule asks for documentation to be kept in written form, which may be electronic (164.316(b)(1)), so a stored pull request template qualifies as a practical way to meet it. Check your own retention policy for how long to keep it.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a change to a released component raises a new finding long after the build, which is the kind of event your trigger list should catch.
Safeguard's policies, gates and guardrails can flag new or upgraded components automatically, and its evidence automation can store the result. The evaluation decision stays with your reviewer.
Quick check
Do we need a full risk analysis after every new library?
No. A short, recorded review is proportionate for most additions. Reserve a full update for changes that alter exposure of ePHI in a meaningful way.
Who should own the trigger list?
Usually the security or compliance lead, with engineering input. Name one person so it does not drift.
Sources
- 45 CFR 164.308 Administrative safeguards, eCFR
- 45 CFR 164.306 Security standards: General rules, eCFR
- 45 CFR 164.316 Policies and procedures and documentation, eCFR
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
