14.4 Vulnerabilities, Roles, Data Controls, and Ongoing Validation

Key Takeaways

  • Task E.2 is assess and mitigate: a current risk analysis, scans and walkthroughs, then patch, compensate, or document a residual-risk acceptance—not a binder that says “we are aware.”
  • Task E.5 separates roles: information security owns cyber and technical control design; physical security owns facilities and badges; compliance/privacy owns Privacy Rule, BAAs, and OCR-facing process. One person may wear two hats in a small clinic; the functions still differ.
  • Task E.6 controls the data themselves: ownership, criticality, classification/security level, protection, retention, destruction, and access. IT is often custodian, not the owner of clinical meaning.
  • Retention is not the same as backup, and destruction yields to a legal hold. Media leaving the organization need sanitization or destruction, not a trip to the dumpster.
  • Task E.7 is ongoing validation of security features after go-live: access recertification, restore tests, patch evidence, control monitoring, and a periodic Security Rule evaluation—not last year’s scan printout.
Last updated: August 2026

14.4 Vulnerabilities, Roles, Data Controls, and Ongoing Validation

Quick Answer: E.2 find and fix (or formally accept) vulnerabilities. E.5 name who owns cyber, physical, and compliance work. E.6 control the data—owner, criticality, classification, protection, retention, destruction, access. E.7 re-validate security features on a schedule. Last year’s binder is not a control.

Section 14.3 wrote the policy and placed the safeguards. This section is the loop that keeps those safeguards true in a living EHR, a growing device fleet, and a vendor cloud that patches on its own calendar. Domain 3 remains 30% of CPHIMS; these four tasks are how you refuse the sentence “we were secure at go-live.”

CPHIMS practice questionsPractice questions with detailed explanations

Assess and mitigate vulnerabilities (E.2)

A vulnerability is a weakness that a threat could use to harm confidentiality, integrity, availability, or privacy. In healthcare it is not only a CVE on a Windows box. It is also an unpatched pump, an open forwarding rule, a contractor VPN that never died, a mis-set break-the-glass role, a photocopier hard drive, or a business associate with no BAA.

Assess with more than one lens:

  • A Security Rule risk analysis (required administrative safeguard) that is current, scoped to ePHI, and owned—not a vendor brochure pasted into a binder.
  • Technical vulnerability scans and, where risk supports it, authenticated scans or penetration tests in a controlled window.
  • Vendor and HHS/OCR advisories, medical-device manufacturer notices, and interface-engine CVEs.
  • Walkthroughs: unlocked closets, unattended workstations, visitor tailgating, discarded labels with MRNs.
  • Process reviews: joiner-mover-leaver samples, BAA inventory, backup restore tests, log-review evidence.

Mitigate in a recorded risk-management plan. Typical treatments:

TreatmentWhen it is honestWhen it is theater
Remediate (patch, remove, rebuild, revoke)You can change the asset on a date“We will patch someday” with no owner
Compensate (segment, monitor, virtual patch, disable function)The device cannot take the vendor patchGuest Wi-Fi as the only control on a pump
Accept residual riskLeadership signs, time-bounded, re-reviewedAn analyst accepts ransomware risk in a ticket
Transfer (insurance, contract)Residual financial risk after safeguardsInsurance instead of MFA and backups

Prioritize by exploitability × impact on care and ePHI, not by which vendor shouted. A critical remote-code bug on an internet-facing VPN outranks a low finding on an isolated report server. An unencrypted backup of the entire EHR outranks a missing banner text.

Do not run a hostile penetration test against production life-safety systems without a window, a rollback, and clinical notice. Do not publish identifiable screenshots from a “test” in a slide deck. Assessment itself is a CIA event.

Who owns which vulnerability (E.5)

HIMSS names three role examples. Keep the functions distinct even when one human in a small clinic wears two hats.

Information security (often the CISO or security officer) owns cyber risk, technical and many administrative safeguard designs, identity standards, vulnerability management for systems, security architecture, and security-incident command. They decide whether a CVE is mitigated and whether MFA is mandatory on the VPN. They do not usually badge the loading dock or interpret a state privacy authorization form.

Physical security (often facilities, protective services, or a designated officer) owns badges, cameras, visitor control, locks, after-hours access, and the server-room and IDF door. An unlocked closet is their finding even if IT owns the rack. They escalate cyber-adjacent physical events (tailgating into the data center, stolen laptop from a car) into the incident process.

Compliance / privacy owns the Privacy Rule interpretation, notice of privacy practices, authorization language, minimum-necessary program design, BAA completeness, sanction consistency, and OCR- or state-facing investigations. They do not patch servers. They do decide whether a research extract is a permitted use and whether a “quality review” is actually workforce snooping.

Related seats you should be able to place without merging them: HIM (legal record, retention schedule, release), clinical engineering (device firmware), internal audit (independent testing of the control), and the security official required by the Security Rule (may be the CISO). Chapter 2.4 placed the CISO in the organization; here the exam asks which function remediates this finding.

Trap: sending a missing BAA to the network team, or sending a failed door contact to the privacy officer, or asking compliance to approve a residual ransomware risk without information security in the room.

Data management controls (E.6)

Chapter 12.4 taught ownership versus stewardship versus custodianship for design. E.6 is the control list HIMSS wants on the data themselves.

Data ownership is accountability for purpose, quality bar, access policy, and retention. Clinical meaning still belongs to a clinical or HIM executive, not to the analyst who can truncate a table.

Criticality is what happens to care and operations if the data are wrong or gone: allergy lists and active medications are life-critical; a marketing campaign list is not. Criticality drives backup RPO/RTO (Chapter 12.3), monitoring, and who is paged. Label it; do not discover it during an outage.

Security levels / classification (public, internal, confidential, ePHI / restricted) drive protection: encryption, DLP, who may export, whether a vendor cloud is allowed. A “de-identified” file that still has dates of service, zip, and rare diagnosis may still be identifiable; classification is a decision, not a file extension.

Protection controls are the safeguards from 14.3 applied to the class: encryption, access, audit, segmentation, masking in lower environments (14.1).

Retention and destruction follow the record retention schedule, statute, payer rules, and legal hold—not the backup tape’s free space. Backup is a recovery control, not an archive, and not a retention strategy. Destruction of ePHI and of devices that stored it must make the data unreadable (media sanitization, certified shredding, crypto-erase with key destruction). A dumpster of printed MAR sheets or a surplus PC sold with a disk is a disclosure. Legal hold suspends destruction for named matters; HIM and counsel own the hold list.

Access controls on data close the loop with E.3: role, purpose, minimum necessary extracts, and expiration on vendor and researcher access.

Write these as a table you can audit: system or data set, owner, steward, custodian, class, criticality, retention trigger, destruction method, who may grant access.

Ongoing validation of security features (E.7)

The Security Rule’s evaluation standard and activity review are not a go-live checkbox. E.7 asks you to validate on an ongoing basis that existing systems still have the features you claimed.

A practical calendar (scale it to size; do not skip the categories):

  • Access recertification — managers attest that each high-risk and privileged role is still needed; disable what they cannot defend.
  • Control monitoring — MFA coverage, encryption inventory, backup success, patch age, failed-login spikes, break-the-glass outliers.
  • Restore and contingency tests — actually restore a file and a system; walk the downtime procedure (availability is a security feature).
  • Vulnerability cadence — scan, ticket, verify the fix, and re-scan. A finding that is “closed” without a verifying scan is not validated.
  • Vendor and BA re-validation — SOC reports, penetration-test summaries, BAA still matches the services, unused connections revoked.
  • Periodic risk analysis / Security Rule evaluation — when technology, operations, or threats change materially, and on a planned cycle, not only after a breach.
  • Tabletops — ransomware, lost laptop, insider snooping, failed restore. Update the playbook when the tabletop fails.

Evidence is the point: tickets, attestations, restore screenshots, scan diffs, minutes. A policy that says “we review annually” with a 2019 date stamp fails E.7. So does a single penetration test performed to impress a board and never repeated after a major EHR upgrade.

Loading diagram...
Vulnerabilities move through owners into data controls and a repeating validation loop
Study heuristic: E.7 evidence strength (illustrative emphasis, not an audit score)

Scenarios and exam traps

Scenario. A scan finds a critical VPN flaw. Facilities is copied because “security is everyone’s job.” E.5: information security owns mitigation and the change window; physical security is involved only if a related door or closet is part of the path. Compliance is informed if ePHI exposure is plausible. Do not page the privacy officer to patch the concentrator.

Scenario. Research wants a “de-identified” extract that includes dates, full zip, and rare diagnoses. E.6: the data owner and privacy/compliance classify it; it may still be identifiable. Do not let the analyst who can run the query also be the owner who approves it.

Scenario. HIM’s retention schedule says destroy certain films at year ten. Counsel has a legal hold on a subset. Destruction stops for the hold set. Backup tapes that contain the hold set are not casually overwritten “because the backup job rotated.”

Scenario. The board is shown a two-year-old penetration-test slide after a major EHR version upgrade and a new remote-ICU program. E.7 fails. Re-validate the new remote path (MFA, logging, break-glass) and the upgraded surfaces; do not recycle the old badge.

Watch these traps:

  1. Assessment without mitigation, or mitigation without a verifying re-test.
  2. Collapsing CISO, facilities, and privacy into one nameless “compliance.”
  3. Letting IT “own” clinical meaning or letting a vendor “own” the data.
  4. Using backup as retention, or destroying media under legal hold.
  5. Treating a go-live hardening or a single old scan as ongoing validation.
  6. Inventing unpublished HHS dollar penalties instead of naming the risk-analysis and evaluation duties.

Domain 3 testing and security now form a chain: controlled tests (14.1), contract and benefit evidence (14.2), policies and safeguards (14.3), and a living vulnerability, role, data, and re-validation program (14.4). Leadership and strategy in Chapter 15 assume this chain exists.

Test Your Knowledge

A walkthrough finds an unlocked IDF closet, a missing BAA for a transcription vendor, and an unpatched internet-facing VPN. Who should own each finding under task E.5?

A
B
C
D
Test Your Knowledge

HIM’s schedule says destroy a set of electronic fetal-monitor archives at year ten. Counsel issues a legal hold on a subset the same week. Facilities wants the disk array back. What is the E.6-correct data-control move?

A
B
C
D
Test Your Knowledge

Two years after go-live the organization completes a major EHR upgrade and adds remote ICU coverage. The security committee recycles a pre-go-live penetration-test slide as proof that “security features are validated.” What does task E.7 require instead?

A
B
C
D