HIPAA Security Rule scope follows the ePHI path—not a vendor tier
HHS ties the HIPAA Security Rule to electronic protected health information created, received, used, or maintained by a covered entity or business associate. A third-party-risk tier can set review depth, but the defensible scope record must follow the actual ePHI path, regulated role, safeguard responsibility, and retained evidence.
Third Party Current editorial graphic. Source material: HHS HIPAA Security Rule; analysis and presentation by Third Party Current.
Map the information path before assigning the tier
The direct answer is to begin with the electronic protected health information path, not with a generic label such as critical, high risk, or software-as-a-service. HHS defines the Security Rule boundary through ePHI created, received, used, or maintained by a covered entity or business associate. The relationship record should therefore identify the covered entity or business associate roles, the exact data classes, the purpose of the exchange, every system and subprocessor that creates or handles the information, storage and transmission locations, and the point at which the data is returned, deleted, or retained. [1]
A tier remains useful for scheduling diligence and monitoring, but it cannot substitute for the scope analysis. Two engagements with the same company may have different data paths, legal roles, environments, integrations, and safeguard allocations. Preserve a separate engagement identifier, approved use, system owner, data owner, privacy and security reviewers, business-associate-agreement status where applicable, exceptions, effective dates, and reassessment triggers. A vendor-level approval should not silently authorize a new product, population, interface, or purpose.
Allocate safeguards to the party that performs the work
HHS groups the required protection objective around administrative, physical, and technical safeguards and the confidentiality, integrity, and availability of ePHI. A responsibility matrix should translate that boundary into the actual service: identity and access administration, authentication, logging, change control, encryption decisions, backup and recovery, facilities, workforce access, incident handling, deletion, and evidence production. Record whether the customer, provider, subprocessor, or a shared process performs each control and which artifact demonstrates it for the named environment. [1]
Do not mark a responsibility complete because a questionnaire answer, contract clause, certification, or platform description mentions the topic. Link the asserted control to its owner, applicable system and data, frequency, test or operating evidence, review result, exception, remediation, and acceptance authority. Shared responsibility deserves two connected records when one party configures a control and another operates infrastructure. Unknown allocation should stay visible rather than being converted into a low residual-risk score.
Test change against the approved ePHI path
Use a representative change test: add a new interface, enable a support feature, move processing to another environment, introduce a subprocessor, expand the patient population, or retain a new log field. The review should compare the proposed path with the approved path and identify changed roles, data classes, systems, locations, safeguard owners, contracts, notices, evidence, and incident or deletion procedures. The decision record should show what stayed in scope, what entered scope, what left scope, who approved the change, and when the new state became effective.
Monitoring should use the same map. A corporate event, vulnerability, outage, audit finding, missed evidence delivery, or changed service boundary matters only after the team connects it to the affected engagement and ePHI path. Preserve the source event, affected component, exposure window, provider response, compensating control, customer decision, due date, closure evidence, and next review. Avoid inferring patient impact, reportability, or legal compliance from a vendor alert alone.
Keep the authority and evidence limits explicit
The reviewed HHS page establishes the Security Rule's high-level ePHI and safeguard boundary and links the controlling regulatory text. It does not determine whether a named organization is a covered entity or business associate, whether specific information is ePHI, which implementation specification applies, whether a contract is sufficient, or whether a control operates effectively. Those conclusions require the controlling rule, facts, contracts, system design, evidence, and qualified privacy, security, compliance, and legal judgment. [1]
A defensible third-party record therefore ends with a scoped decision rather than a universal vendor status. State the relationship and environment approved, the data path reviewed, the safeguard evidence accepted, remaining unknowns and exceptions, decision owner, effective date, and next trigger. If the team cannot reconstruct that chain after the vendor tier or questionnaire changes, the portfolio has a score but not a durable HIPAA scope record.
What we will watch next
Third Party Current will watch for later primary-source evidence that changes the maintained company, capability, or standards record. The next useful evidence may include implementation documentation, release details, regulator findings, corrected methods, product packaging, customer-observable workflow, or a subsequent company statement. Until then, the dated source and its stated boundary remain attached to this analysis.