164.400 Applicability draft
Subpart D applies to covered entities, business associates, subcontractors
and affiliated entities with respect to unsecured protected health
information.
Pryv platform facilitated
Subpart D applies only
to "unsecured" PHI, PHI that has not been rendered unusable
through encryption or destruction per HHS guidance (NIST SP
800-111 / SP 800-88). Pryv's posture (TLS in transit by default,
operator-side encryption-at-rest, per-user backup files
transportable as encrypted bundles) lets you put PHI inside the
safe-harbor where you choose to, narrowing what §400 actually
reaches in your deployment.
HDS facilitated USCH
Subpart D only reaches PHI that is "unsecured" — PHI not rendered unusable
per HHS guidance. HDS narrows that surface on both halves of the data
path: TLS is enforced in transit, and ePHI is encrypted at rest in both
regions by hosting-layer volume encryption (verified 2026-06-26). The
unsecured-PHI boundary that remains is the in-use one: a running system,
account or token compromise reaches decrypted content.
detail
As a business associate, HDS is squarely within Subpart D's reach. The
practical effect of this row is to set the boundary that the encryption
and risk-assessment rows below refine: what counts as unsecured PHI in an
HDS deployment is governed by the transit/at-rest/in-use posture described
under 164.402(2) — media exposures of at-rest content fall inside the
safe harbor; live-system compromises do not.
- 🔒 hipaa/risk/at-rest-encryption available on request
- 🔒 hipaa/evidence/at-rest-encryption-verification available on request
Implementer
covered-entity documented
Determine which of your data flows on HDS fall inside the unsecured-PHI
scope and document that determination in your breach-readiness records.
business-associate documented
📄 baa
Confirm with HDS, in your BAA, which protections apply to your data and
which obligations flow down to your own subcontractors.
individual out-of-scope
164.402 Definitions — breach and unsecured PHI draft
Defines "breach" (an impermissible acquisition, access, use or disclosure of
PHI under Subpart E, assessed against four risk factors) and "unsecured PHI"
(PHI not rendered unusable per HHS guidance).
Pryv platform facilitated
Two Pryv contributions to
applying the §164.402 definitions: (1) the audit log is the data
source for the §402 risk-assessment factors, nature of PHI
involved, unauthorized person, whether PHI was actually acquired,
mitigation extent; and (2) Pryv's access + permission model
makes "acquisition / access / use / disclosure not permitted
under Subpart E" a queryable property (was the access within its
granted scope?) rather than an after-the-fact narrative.
HDS facilitated USCH
HDS supplies the technical substrate that lets an implementer apply the
§164.402 definitions to a concrete incident: the per-user audit log shows
what was accessed, and the access-scoping model shows what a given token
could reach. Whether an access was "permitted under Subpart E" becomes a
property that can be checked against recorded scope rather than narrated
after the fact.
detail
The two limbs of §164.402 are refined in the dedicated rows below:
164.402(1) covers the four-factor risk assessment, for which the audit log
and access-version chain are the structured inputs, and 164.402(2) covers
the unsecured-PHI safe harbor — available for at-rest media exposures
since the 2026-06-26 at-rest encryption rollout, not for live-system
compromises. The definitional analysis itself — deciding whether a given
event meets the breach definition — remains the implementer's, supported
by HDS evidence.
- 🔒 hipaa/procedures/breach-risk-assessment available on request
- 🔒 hipaa/risk/at-rest-encryption available on request
Implementer
covered-entity documented
Apply the breach and unsecured-PHI definitions to each incident and
record the determination, drawing on HDS-supplied audit evidence.
business-associate documented
Run the same definitional analysis for incidents in your custody and
preserve the supporting evidence.
individual out-of-scope
164.402(1) Definition of "breach" — four-factor risk assessment draft
An impermissible use or disclosure of PHI is presumed to be a breach unless
a low probability of compromise is shown via a four-factor risk assessment:
(i) the nature and extent of the PHI involved, (ii) the unauthorized person
involved, (iii) whether the PHI was actually acquired or viewed, and (iv) the
extent to which the risk has been mitigated.
Pryv platform facilitated
The four risk-assessment
factors all draw on Pryv data:
(i) nature + extent: audit-row method + key request fields +
derived event-type set from the touched streams.
(ii) unauthorized person: audit-row accessId → access holder
with clientData.role + clientData.purpose.
(iii) actually acquired vs merely accessed: method-level
distinction in audit (events.get vs attachments.get,
success vs unauthorized error).
(iv) mitigation extent: access-version chain showing
revoke / scope-down timestamps relative to the incident.
The risk-assessment write-up is the operator's analytical
artefact; Pryv supplies the structured inputs.
HDS facilitated USCH
Each of the four risk-assessment factors maps onto data HDS already
retains. The per-user audit log and the access-version chain answer "what
PHI, by which credential, actually acquired or merely accessed, and was the
access revoked or scoped down" — the structured inputs to the assessment.
detail
Factor mapping: (i) nature and extent of PHI — audit records identify the
API methods and the streams/event types touched; (ii) unauthorized person
— each audit record carries the access identity behind the call; (iii)
acquired vs. merely viewed — the method-level distinction (read vs.
attachment download, success vs. denied) is recorded; (iv) mitigation
extent — the access-version history shows revocation and scope-down
timestamps relative to the incident. The analytical write-up that weighs
these factors and reaches the low-probability conclusion is the
implementer's artefact; HDS supplies and preserves the inputs.
- 🔒 hipaa/procedures/breach-risk-assessment available on request
Implementer
covered-entity documented
Perform and document the four-factor risk assessment for each
impermissible use or disclosure, using the HDS-supplied audit inputs.
business-associate documented
Conduct the same assessment for incidents you discover and share the
result with the covered entity.
individual out-of-scope
164.402(2) Definition of "unsecured PHI" — encryption safe harbor draft
"Unsecured PHI" is PHI not rendered unusable, unreadable or indecipherable to
unauthorized persons through a technology or methodology specified in HHS
guidance (NIST SP 800-111 for at-rest encryption, the FIPS-validated
in-transit standards, and NIST SP 800-88 for destruction).
The safe-harbor
narrows what triggers Subpart D notification: PHI that's
actually secured per HHS guidance is outside §164.402's
"unsecured PHI" definition and a leak of it doesn't compel
notification. Pryv's default posture (TLS 1.3 in transit via
built-in ACME, AES-256-GCM for platform secrets at rest) puts
the in-transit half firmly inside the safe-harbor; the at-rest
half for ePHI content itself depends on the operator's chosen
at-rest encryption (operator-side LUKS / PG TDE / dm-crypt).
HDS facilitated USCH
The safe harbor exempts properly secured PHI from breach notification. HDS
enforces TLS in transit (the FIPS-validated in-transit standards), and
ePHI is encrypted at rest in both regions by hosting-layer volume
encryption meeting NIST SP 800-111 full-volume encryption (verified
2026-06-26). The safe harbor is therefore available for lost, stolen or
decommissioned media — the volume keys are not stored with the media. It
is NOT available where a running system, account or access token is
compromised, since the volume is decrypted in use.
detail
In-transit protection (TLS) aligns with the FIPS-validated standards
referenced by HHS guidance, so leaked data in flight is generally outside
the unsecured-PHI definition. At rest, hosting-layer full-volume
encryption (Exoscale hypervisor-layer on ch1; AWS EBS/KMS on us1) renders
stored ePHI "secured" for media exposures. Keys are provider-managed —
the cited risk record analyses that accepted residual, and the evidence
record holds the vendor statements plus the Security Official's
attestation. A compromise of a live system, account or token reaches
decrypted content and must still be assessed under 164.402(1).
- 🔒 hipaa/risk/at-rest-encryption available on request
- 🔒 hipaa/evidence/at-rest-encryption-verification available on request
Implementer
covered-entity documented
Rely on the at-rest safe harbor for media exposures; assess
running-system, account or token compromises separately, where it does
not apply.
business-associate documented
Reflect the media-vs-live-system safe-harbor boundary in your own risk
posture and in assurances you give upstream.
individual out-of-scope
164.404 Notification to individuals draft
Following discovery of a breach of unsecured PHI, the covered entity must
notify each affected individual without unreasonable delay and no later than
60 calendar days after discovery.
Pryv platform facilitated
The notification process splits into **identification**
(Pryv-shipped, audit-log-driven per-subject roster, packaged
into the one-command `bin/breach-scope.js` report) and **delivery**
(voluntarily missing + operator-owned, Pryv's transactional
mail surface isn't bulk-send; operators compose with their
existing CRM / mail / SMS pipeline). The per-recipient
audit-trace bridge uses operator-authored
`compliance/breach-notification/sent-cmc` events on a
compliance system stream, satisfying the §164.414 burden-
of-proof obligation. Full delivery-side treatment in
`context/breach-notification-delivery-operator-owned.md`.
HDS documented USCH
Individual notification is owned by the covered entity, not by HDS. HDS
supports it by supplying audit evidence to identify the affected
individuals, but composing and delivering the notices is the covered
entity's operational responsibility.
detail
HDS is not a bulk-notification system. The contribution is identification:
filtering the audit log by the implicated credential and time window yields
the distinct set of affected subjects, with evidence. Producing the roster
and the per-recipient delivery sit with the covered entity, who carries
this duty.
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
Notify each affected individual within the 60-day window and retain proof
of the notifications.
business-associate documented
📄 baa
If your BAA delegates individual notification to you, perform it;
otherwise provide the covered entity the information it needs to notify.
individual out-of-scope
164.404(b) Timeliness of notification draft
The required individual notification must be provided without unreasonable
delay and in no case later than 60 calendar days after discovery of a breach.
Pryv platform facilitated
The 60-day clock is procedural,
the covered entity owns the incident-response cadence. The
shipped `bin/breach-scope.js` compresses the "discovery" +
"scoping" steps that dominate the timeline: one command on the
subject's home core answers "what was accessed, by whom, when,
how many records", so the clock is dominated by editorial work,
not data-gathering. The discipline of acting on that data
within the 60-day window is the operator's process.
HDS facilitated USCH
The 60-day clock is an operational cadence owned by the covered entity. HDS
shortens the data-gathering portion of that window: the audit log and
access-version chain answer "what was accessed, by whom, when" quickly, so
the timeline is dominated by editorial and decision work rather than
investigation.
detail
Discovery and scoping are typically the slowest steps before notices can be
drafted. By making the access history queryable, HDS compresses scoping so
that meeting the 60-day deadline becomes a matter of process discipline.
Acting on the evidence within the window — and recording when discovery
occurred — remains the implementer's responsibility.
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
Track the discovery date and complete notification within 60 days,
documenting the timeline.
business-associate documented
Surface discovery to the covered entity promptly so its 60-day clock is
not eroded by your delay.
individual out-of-scope
164.404(c) Content of notification draft
The individual notification must describe what happened (including the dates
of breach and discovery), the types of PHI involved, steps individuals should
take, what the entity is doing in response, and contact procedures.
Pryv platform facilitated
Content of the notification is the covered entity's editorial
artefact; Pryv has no opinion on the wording. The shipped
`bin/breach-scope.js` report machine-derives inputs to two of
the five §404(c) content elements: the what-happened
description (time window, methods invoked, record counts) and
raw material for the PHI-involved description (streams in the
compromised access's query scope). The stream list is an upper
bound on exposure, mapping streams to "types of PHI" is
editorial, and the remaining elements (steps individuals
should take, what the entity is doing, contact procedures)
stay operator-side.
HDS facilitated USCH
The wording of a notice is the covered entity's editorial artefact. HDS
contributes to one content element — the description of the PHI involved —
which is derivable from the audit-log scoping performed for the risk
assessment. The remaining elements are operational and authored by the
covered entity.
detail
The "types of PHI involved" element can be derived from the streams and
event types touched, as recorded in the audit data used under 164.402(1).
The dates-of-breach-and-discovery, the steps individuals should take, the
entity's response, and the contact procedures are not data HDS holds; they
are composed by the covered entity. HDS therefore facilitates the
evidence-derivable element and documents the rest.
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
Author each notice with all required content elements; use HDS audit
output to populate the PHI-involved description.
business-associate documented
Provide the covered entity the factual elements (PHI involved, dates) it
needs to compose the notice.
individual out-of-scope
164.404(d) Methods of individual notification draft
Notice must be by first-class mail (or email where the individual has agreed),
with telephone or other urgent contact where imminent misuse is possible, and
substitute notice (web posting or media) where contact information is
insufficient or out of date.
Pryv platform out-of-scope
Notification method choice is operational. Pryv has no software
role in actually delivering the notice (Pryv is not a mailer).
When the entity uses Pryv events to record the notice-delivery
attempt (e.g., a `breach-notice/sent` event per affected
individual), the audit chain proves the delivery attempt.
HDS out-of-scope USCH
Choosing and executing the notification method is operational; HDS is not a
mailer and plays no role in delivering notices. Where the implementer
records each delivery attempt as an event, the HDS audit chain can evidence
that the attempt occurred, but the delivery itself is out of scope for HDS.
detail
First-class mail, email, telephone, and substitute notice are all
organizational channels the covered entity operates with its own
communications stack. HDS neither selects nor sends. Its only adjacent
contribution is preserving an audit record if the implementer chooses to
log delivery attempts as events.
Implementer
covered-entity documented
Select compliant notification methods, deliver the notices, and retain
delivery records including any substitute-notice steps.
individual out-of-scope
164.406 Notification to media draft
A breach affecting more than 500 residents of a State or jurisdiction
requires notification to prominent media outlets serving that area.
Pryv platform out-of-scope
Media notification is an organizational / communications
procedure. No software contribution; the threshold determination
(500 residents) is derivable from the §164.404 per-subject list,
but the notification itself is operational.
HDS documented USCH
Media notification is an organizational and communications procedure owned
by the covered entity. HDS provides no software contribution; the
500-resident threshold can be derived from the affected-subject list
produced under 164.404, but the notification itself is operational.
detail
Determining whether the 500-resident threshold is met for a given State or
jurisdiction draws on the per-subject roster that HDS audit evidence helps
assemble. Identifying and notifying prominent media outlets is entirely the
covered entity's process.
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
Where the threshold is met, notify prominent media in the affected
jurisdiction and retain the records.
individual out-of-scope
164.408 Notification to the Secretary draft
The covered entity must notify the Secretary of HHS following discovery of a
breach of unsecured PHI; timing and method depend on whether 500 or more
individuals are affected.
Pryv platform out-of-scope
HHS notification (via the OCR online portal) is procedural and
organizational. Pryv's audit + access-version data inform the
content (subjects affected, dates, root cause) but the
submission itself is operator-side.
HDS documented USCH
Submission to the Secretary via the HHS portal is procedural and owned by
the covered entity. HDS audit and access-version data inform the content
(subjects affected, dates, contributing cause), but the submission itself
is operational.
detail
For breaches of 500 or more individuals the notice is contemporaneous with
individual notification; smaller breaches are logged and submitted
annually. In both cases the factual inputs can be drawn from HDS evidence,
while the act of submitting and tracking the report sits with the covered
entity.
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
File the required HHS notification on the applicable schedule and keep the
submission records.
individual out-of-scope
164.410 Notification by a business associate draft
A business associate must notify the covered entity of a breach of unsecured
PHI without unreasonable delay and no later than 60 days after discovery,
including the identities of affected individuals where known.
Pryv platform facilitated
When you (the implementer)
act as a business associate to a covered entity and store their
PHI on your Pryv deployment, your BA-to-CE notification chain
is operational. The CMC plugin's cross-platform consent +
revocation flow gives you the technical substrate for
inter-organization handshakes; audit data lets you meet the
"without unreasonable delay" element on the data-gathering side.
HDS facilitated USCH
This is HDS's core breach duty. As a business associate, HDS notifies the
covered entity without unreasonable delay (and within 60 days) on discovery
of a breach, following a documented procedure. The audit log lets HDS
gather the required content — affected subjects and timing — quickly.
detail
HDS maintains an internal breach-notification procedure that defines
discovery, escalation, content assembly and the upstream notification to
affected covered entities, with the 60-day ceiling. The per-user audit log
is the data source for the "identities of affected individuals" element and
for the timing evidence backing "without unreasonable delay". When an
implementer is itself a business associate to a covered entity and stores
PHI on HDS, the same procedure and evidence support its own upstream
notification chain.
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
On receipt of an HDS breach notice, run your own §164.404/406/408
notification obligations.
business-associate documented
📄 baa
Notify the covered entity (or upstream BA) you serve within the 60-day
window, using the BAA terms and your own breach procedure.
individual out-of-scope
164.412 Law enforcement delay draft
Notification may be delayed when a law-enforcement official states that it
would impede a criminal investigation or cause damage to national security,
for the period specified (with a 30-day cap for oral statements).
Pryv platform out-of-scope
Procedural, depends on receipt of the law-enforcement
statement (oral with 30-day cap, or written with the official's
time-limit). No software role beyond preserving the audit log
across the delay period (which happens by default).
HDS documented USCH
Invoking a law-enforcement delay is procedural and depends on receipt of an
official statement. HDS has no software role beyond preserving the audit log
across the delay period, which happens by default; the decision and its
documentation are the implementer's.
detail
Whether the statement is oral (subject to a 30-day cap) or written (bounded
by the official's stated period), the implementer must record it and pause
the affected notifications accordingly. HDS retention keeps the underlying
evidence intact for the duration so notification can proceed once the delay
lapses.
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
Document any law-enforcement delay request and the resumption of
notification once the stated period ends.
business-associate documented
Honor and record any law-enforcement delay communicated to you and inform
the covered entity.
individual out-of-scope
164.414 Administrative requirements and burden of proof draft
The covered entity or business associate must maintain documentation
sufficient to demonstrate that all required notifications were made, or that
an impermissible use or disclosure did not constitute a reportable breach.
"Burden of proof" is met
with evidence; Pryv's audit + access-version chain is the
technical evidence layer ("we know exactly what was accessed by
which credential at what time"), and the shipped
`bin/breach-scope.js` bundles the audit walk + integrity hashes
for the affected window into one artefact. The organizational
documentation (incident response records, notification records,
decisions to not notify with rationale) sits on top of that
data.
HDS facilitated USCH
The burden of proof is met with evidence. HDS's per-user audit log and
access-version chain are the technical evidence layer — a precise record of
what was accessed, by which credential, and when — that backs both "we
notified" and "this was not a reportable breach" determinations.
detail
The audit and access history give an implementer the factual spine for the
§164.414 demonstration: it can show the scope of any incident and the basis
for a no-breach conclusion. The organizational records that sit on top of
that data — incident-response files, notification records, and the
documented rationale for any decision not to notify — are the implementer's
to maintain. HDS also retains its own breach-procedure execution records as
evidence of its §164.410 performance.
- 🔒 hipaa/registers/breach-log available on request
- 🔒 hipaa/procedures/breach-notification available on request
Implementer
covered-entity documented
Maintain the documentation that demonstrates notification or a justified
no-breach determination, retaining it for the required period.
business-associate documented
Keep records demonstrating your own notifications and risk assessments to
meet the burden of proof.
individual out-of-scope