HIPAA

HDS inherits the platform substrate (per-user audit log, system-level observability) that several specifications draw on, and wraps it in a written, maintained programme that is reviewed periodically. The programme rests on a risk analysis that has been conducted, rated, reviewed and approved, with a treatment register keyed to its findings, and on an approved sanction policy; the analysis and register are held internally and released on request. Three of the four specifications carry their own row here: risk analysis (ii)(A), risk management (ii)(B) and information-system activity review (ii)(D). Only the sanction policy (ii)(C) has none, being wholly organizational and evidenced by the internal documents cited on this row. This umbrella row does not assert that any specification is fully operational: that status is held once, in the treatment register, and reading it alongside the programme gives the honest current position. For a partner acting as Covered Entity or upstream BA, this is a programme they must run themselves; HDS supplies the technical raw material and its own programme as evidence of operator diligence.

This specification is wholly organizational: no platform feature discharges it. What HDS contributes to a partner's own analysis is the control inventory in this matrix and the technology-stack register, which shorten the asset-identification step considerably; the assessment itself, its ratings and its conclusions remain the partner's. HDS's own analysis, its ratings and the specific weaknesses it names are confidential and released only on request under NDA, signed BAA or audit engagement, as is normal for a document whose contents are an inventory of what could go wrong.

Risk management is the disposition half of the risk-analysis cycle, and is as organizational as the analysis itself. The measures HDS selects are largely the controls documented across this matrix, which is why the matrix doubles as HDS's own control inventory. The register is complete against the analysis rather than a standing wish list: every identified risk carries a decision, including the decisions to accept. The register's contents, like the analysis, are confidential and released on request.

Per-API-call audit records (platform layer) plus infrastructure telemetry (HDS layer) together give both subject-level and system-level activity review. HDS operates the alerting chain end to end as a matter of policy before any component is treated as in production, so silent failures are caught. Operator activity is reviewed at an operator population of one, which makes that half inherent rather than scheduled; the scheduled cycle becomes substantive when a second operator holds credentials. The per-user half carries no such assurance and is the part still to be established in practice. The documented review procedure is available on request, and the implementer runs its own review over its own workload.

This is an organisational designation, not a software control. The designation is made and recorded as an operator artefact; the assigned official draws on the audit log, monitoring and this matrix as operational substrate. A distinct Privacy Official is designated separately (see hipaa-privacy §164.530(a)). A partner running ePHI on HDS names their own security official.

HDS runs the revocation as a tracked procedure: the Security Official opens a dated termination ticket, revokes credentials and closes any break-glass grant (whose closure is recorded in the per-user audit log), disables accounts on each host and service, rotates shared secrets the person knew, confirms no active token or session remains, and closes the ticket the same business day, or immediately for involuntary or suspected-compromise cases. Partners apply their own termination procedure to their own staff; the platform's per-stream access model is what makes narrowing an access an alternative to revoking it.

Access grants carry the streams and levels the grantee may exercise, plus free-form metadata such as workforce role, granting administrator and business reason. On the platform path there is no trust-based bypass: no HDS role can grant itself an access into a user account. That is a statement about the authorisation mechanism and not about what infrastructure access can technically reach. An identity holding host or database access can read or alter stored ePHI without presenting a user token, because someone has to operate the database that holds the data; what bounds it is least-privilege authorisation, time-boxed and logged break-glass, and periodic access review, and HDS records it as an accepted residual rather than engineering it away. HDS documents its own authorization policy and partners apply the same primitives.

HDS operates establishment, review and modification of access rights as audited operations: grants can be enumerated with their full version chain, narrowed or revoked, with each step timestamped and attributed to the acting administrator. HDS's own periodic operator access review is defined on a stated cadence and has been executed, so the cadence is exercised rather than merely written; the execution record is filed internally and is in review, not yet signed off. Partners apply the same primitives to their own populations. The review covers the operator accounts HDS administers, not the accesses that individual account holders grant over their own data: those are the account holder's to review and revoke, and HDS does not act on them.

HDS treats security reminders as part of its workforce-awareness programme, an operator artefact rather than a platform feature. The written programme is cited as an internal document and runs as a continuous process against a completion register, with residual gaps documented and addressed as they arise rather than blocking the programme. Each partner runs its own reminder programme for its own workforce.

Internet-facing components receive priority patching for known CVEs, application dependencies are monitored for advisories and triaged, only required services are exposed, and the container model limits the blast radius of a compromised component. Anomalies that may indicate malware, such as unexpected processes or crash loops, are investigated under the incident process. The patch cadence and the dependency-triage service level are not yet defined, so currency rests on practice rather than on a control that can be evidenced; HDS records that as an open risk-analysis item. Partners must protect their own workstations and any infrastructure they operate outside HDS.

Logs are shipped to HDS-operated collectors and stay on HDS infrastructure, with only aggregate metrics reaching the monitoring service. On the quarterly cycle the Security Official reviews failed-login spikes, off-hours operator access and token-use anomalies; a suspected compromise is escalated to incident response within one business day and the affected user is contacted. While the Security Official is the only operator able to log in, every operator authentication is his own, so that surface carries assurance the user-side surface does not, and the user side is reviewed on the cadence regardless. Multi-factor authentication is mandated separately on the surfaces from which production can be reached. Partners tune their own discrepancy thresholds.

Credentials live apart from ordinary content data; password complexity and rotation rules are operator-configured and multi-factor authentication strengthens the login beyond a password alone (see the person-or-entity-authentication standard). HDS documents the configuration it runs; partners may layer their own additional rules.

Detection draws on per-user audit records (who accessed what) and system-level anomaly signals; containment uses immediate token revocation or scope reduction. HDS documents its incident-handling and notification flow, which feeds the breach-reporting obligations a partner carries under their BAA. Partners run their own incident programme for their workload. For vulnerabilities in the platform substrate itself, the upstream open-pryv.io project publishes a coordinated vulnerability disclosure program (private GitHub Security Advisories plus a security mailbox, with GHSA/CVE issuance); a published advisory affecting the deployed release enters HDS's incident procedure as a provider notification.

HDS runs the backup primitive on a schedule and documents the plan (frequency, location, encryption-at-rest applied at the storage boundary). The scheduled cycle produces encrypted, off-host, in-region copies on every regional core, and an archive has been retrieved and decrypted with the off-host key to demonstrate that the copies are usable rather than merely produced. What is not yet demonstrated is restore at production scale per region; that drill is the remaining gap. Partners operating their own deployments define their own schedule.

Recovery rests on two layers: restore from backup as the canonical path, and live replication across cores so a single-region failure does not lose live data. HDS documents the recovery objectives and the runbook it operates, and states their standing plainly: the per-region production drill has not been run, so the recovery-time and recovery-point objectives are targets rather than demonstrated capability, and the runbook is documented but unproven at production scale. Contingency-plan testing is tracked under the testing-and-revision specification. Partners running their own deployments document their own plan.

Emergency mode is a documented runbook layered on the platform's HA topology and the backup-restore path, distinct from the disaster-recovery plan that covers full loss. On declaration the on-call operator confirms that per-user isolation, consent and access-token checks, TLS and per-user audit logging are all still enforced, sheds non-critical load to preserve the critical path, and keeps the unaffected region serving its own users. Every control degraded or suspended is recorded at closure and carries a follow-up. The definition of critical business processes and the procedure itself are operator artefacts, cited internally. Partners define their own emergency-mode plan for their workload.

The testing programme itself is an operator activity rather than a platform feature, though restore drills run against the platform's backup primitive. HDS documents the cadence and revision process, and testing has begun: a first restore rehearsal was performed on 2026-07-29 and recorded. It covered a single account rather than a full per-region restore, so this specification is partly evidenced rather than satisfied, and HDS says so instead of reading a rehearsal as a drill. Partners run and document their own contingency-plan tests.

Inputs to the evaluation include audit-log samples, operational-stability data, this layered matrix as the inventory of controls to assess against, the platform's automated test suite as ongoing effectiveness evidence, and the upstream project's published security-advisory history (open-pryv.io's coordinated vulnerability disclosure program with GHSA/CVE issuance), checked against the release HDS deploys. The procedure also requires re-verifying that controls previously evidenced are still in force, since a rebuild or provider change can silently regress one. HDS documents the cadence and the inputs; the first evaluation report is still to be produced. A partner runs its own periodic evaluation for its own programme.

For each specification under §164.310 (facility access controls, workstation use, workstation security, device and media controls), the underlying controls are physical and operational. HDS's position: HDS chooses and documents the hosting environment per region, binds a deployment to that region's data residency, and holds the provider attestations on file. The facility-control hardware itself remains the certified provider's; HDS's contribution is selection, documentation and the residency guarantee. Evidence grades differ by region: the US region (AWS, us-east-1) is evidenced by independent third-party attestations obtained 2026-07-28 and on file (SOC 2 Type II with a continued-operations letter, ISO/IEC 27001 with us-east-1 named in the certified locations, 27017 and 27018). The Swiss region is contractually assured but not yet evidenced: nothing is on file for it, and the provider's audit clause is the route to closing that.

HDS does not operate its own data centres; it deploys open-pryv.io onto certified infrastructure in the EU/Switzerland and US regions. The facility-access-control specification is satisfied at the server tier by the provider's attested controls, which HDS records in its hosting-provider register. Evidence grades differ by region: the US region's facility controls rest on third-party attestations on file since 2026-07-28; the Swiss region's rest on contract alone, with no attestation yet obtained. The implementer's own facilities (offices where workforce members access ePHI) remain their responsibility.

open-pryv.io enforces that every workstation reaching ePHI does so through an authenticated session carrying a scoped access token, so a workstation can only exercise the permissions its token grants. The physical-surroundings and proper-function obligations of the workstation-use standard remain organizational. HDS records this boundary so implementers can scope their own workstation-use policy to the residual physical/operational concerns.

The physical safeguards the standard calls for — restricting who can be at a workstation that reaches ePHI — are facility and endpoint controls outside the HDS platform. HDS's compensating contribution is that workforce access is mediated by revocable, per-stream access tokens with session/token expiry, so the blast radius of a compromised workstation is bounded and recoverable. HDS documents this so implementers can right-size their physical workstation controls.

The server-tier device-and-media-controls obligation (secure disposal, media re-use, sanitisation) is satisfied by the hosting provider's attested controls, recorded in the HDS hosting-provider register, where the US region is evidenced by attestations on file and the Swiss region rests on contract alone. At the application tier, open-pryv.io's per-user data model means an individual subject's ePHI can be exported and moved as a discrete unit. Production volumes are encrypted at rest (hosting-layer full-volume encryption, every region, since 2026-06-26), so decommissioned server media are protected by construction; a per-subject export leaving the platform is a fresh plaintext artefact, and encrypting it in transport/storage remains the mover's responsibility — HDS documents this boundary explicitly.

Each subject's data is isolated per user, and access by any person or program is mediated by an access token carrying explicit per-stream, per-level permissions. Enforcement happens at the API boundary on every request, and privileged namespaces (account, credentials) are separately controlled. HDS operates this stack and documents its access-control policy; the implementer configures which grants their application mints.

Unique identification is intrinsic to the platform: accounts and the access tokens minted from them each carry unique identifiers, and the audit record for every API call references the acting access identity. This gives the requirement's "identify and track" obligation a technical anchor that HDS operates by default. The implementer maps their workforce/role model onto these identities.

Routine access to a user's ePHI is by the user and their granted tokens; this procedure covers the exceptional operator-level case, such as assisting an individual locked out during an outage or validating a disaster-recovery restore. Temporary credentials are revoked on completion and the time box confirmed closed. One grant is standing rather than per-incident: HDS Leadership holds administrative access to the provider consoles and does not use it, as the means by which HDS can revoke the Security Official's own access, so that no single individual can lock the organisation out of its infrastructure. That grant carries the mandated multi-factor authentication, is reviewed on the quarterly access-review cadence (first cycle 2026-07-30, confirmed still unused), and rests on attestation by signature rather than a captured configuration record, a residual HDS has accepted.

HIPAA's automatic-logoff specification is workstation-centric in origin; in an HDS-mediated workflow the analogous control is the validity window of the session and access token. The platform supports a bounded interactive session lifetime for workforce sessions and a per-grant token expiry for app-driven processes, covering both shapes. On the vault these values sit with the account holder: the approved policy places session lifetime and per-grant token expiry under the end user's control and approval, which is a consequence of the data being theirs. An implementer tunes what it can set for its own workforce and documents the rationale for the chosen inactivity window, which is the Addressable path.

Both production cores store ePHI on encrypted volumes. ch1 (Exoscale, ch-dk-2) runs on an Exoscale-encrypted root volume by default — "Compute root volumes … encrypted at rest transparently at the hypervisor layer," AES-256 in XTS mode, Exoscale-managed keys. us1 (AWS us-east-1) stores ePHI on an encrypted EBS volume (AES-256, aws/ebs KMS key). Encryption/decryption is transparent to the guest; it protects stolen/decommissioned disks, off-host snapshots and backups, and grounds the breach safe-harbor (NIST SP 800-111 recognises full-volume encryption). TLS covers the transmission half (§164.312(e)). Residual: keys are provider-managed, so a running host or a compelled provider could read plaintext — operator-held-key encryption (the container-encrypted-volume facility, CEV_ENABLED, shipped in the open-pryv.io rc.5 encrypted image and LUKS-verified on HDS hosts) or end-to-end encryption remain optional strengthenings, not required for this addressable spec. Source for ch1's default-on encryption: Exoscale's compliance statement (exoscale.com/compliance/encryption), covering Compute root volumes, Block Storage and Object Storage alike (AES-256-XTS, unique key per volume), so the claim does not depend on which storage type holds the ePHI. Evidence grades differ by region: ch1 rests on this vendor default-on statement; us1 on the Security Official's attestation, since AWS EBS encryption is opt-in per volume and vendor documentation cannot establish it is in force.

Audit controls are a native, always-on property of the platform: each API invocation against a subject's data produces an audit record scoped to that subject. The log captures who did what, when, and via which access, and is retrievable for routine review and incident investigation. One dependency is worth naming: the record has to survive recovery. A restore that returns the data without its audit trail is not a successful restore for this control, because the four-factor breach assessment rests on being able to say whether PHI was acquired or viewed for the period before the restore. HDS records that dependency as an open risk-analysis item. HDS operates and retains this substrate; the implementer defines the written review cadence (see §164.308(a)(1)(ii)(D)) and who performs it.

Improper alteration is constrained because only tokens with write permission on a stream can modify it, and modifications are versioned so the prior state is retained. The audit log ties every change to an authenticated access identity, on the platform path; privileged infrastructure access is a separate path covered under §164.308(a)(4)(ii)(B). Improper destruction is mitigated by per-user export and backup as a recovery path, with one dependency worth naming: the audit history has to return with the data, since a restore that brings back the records but not who touched them leaves improper alteration undetectable afterwards. How far that recovery capability is demonstrated is tracked as an open risk-analysis item rather than asserted here. HDS operates these primitives and documents its integrity policy; the implementer owns the surrounding procedural obligation.

The platform corroborates that ePHI has not been altered improperly through two evidence sources HDS operates: the version history of each record, and the audit attribution of every change to an authenticated actor. This satisfies the addressable specification's evidentiary intent for most deployments. HDS documents the boundary; where an implementer's risk analysis demands stronger tamper-proofing, they layer in content-integrity verification themselves.

Every request reaching ePHI through the API must present a valid access token, so the platform verifies the requester before any access is granted; credentials are stored one-way hashed in a separately access-controlled namespace. The MFA mandate covers the provider consoles, the code-hosting organisation carrying deploy rights, and administrative access to the platform hosts, because those are the surfaces from which production can be reached. It is attested by the Security Official rather than demonstrated by a captured configuration record, and HDS records that evidence gap as an accepted residual. This control governs the platform path; privileged infrastructure access is a separate path covered under access authorization. An implementer decides the MFA position for its own workforce and its own users.

ePHI in transit between clients and the platform is protected by TLS, which provides confidentiality and integrity over the connection. HDS operates the certificate lifecycle and serves only encrypted endpoints. The implementer's obligation is to ensure that its own onward transmission paths (any proxy or integration hop it controls) preserve the same protection.

The transmission-integrity specification is met on the platform connection by the authenticated-encryption guarantees of TLS: in-transit tampering breaks the connection's integrity check. HDS operates this for all served endpoints. Where an implementer routes ePHI through intermediate hops it controls, it must ensure those hops do not terminate and re-emit traffic in a way that loses the integrity guarantee.

For ePHI in transit, HDS's default is to encrypt every connection via TLS, satisfying the addressable transmission-encryption specification without requiring an implementer decision to enable it. HDS operates the certificate lifecycle. The implementer documents that transmission encryption is in force and, separately, assesses at-rest encryption under §164.312(a)(2)(iv), which is implemented in every region (no platform gap).

The vault creates no business associate relationship, because access flows from the individual's consent rather than from a covered entity's delegation. The arrangement in which an organisation places protected health information with HDS on its own behalf would create one, and that is where the template applies; no such agreement has been signed to date. What is executed today is the downstream half: back-to-back subcontractor agreements with the hosting providers, tracked in the BAA register. HDS offers the BAA template (templates/baa) and supplies the technical-safeguards evidence such a contract would rely on.

Rather than restating safeguards in prose, HDS's BAA points to the implemented and configurable controls already documented in this matrix — access control, audit logging, encryption, monitoring and regional residency. This gives the contractual "reasonable and appropriate safeguards" clause a concrete, auditable backing.

Detection rests on the audit log (Pryv layer) plus HDS's infrastructure monitoring with end-to-end alert wiring. When an incident is detected, the BAA's notification clause defines the channel and timing for reporting to the implementer; HDS's incident-response procedure governs how that report is produced and what evidence it carries.

HDS maintains a current list of its ePHI-relevant subprocessors and holds a written contract with each that flows down the applicable Security Rule obligations. The subprocessor list is made available to implementers so they can satisfy their own §164.314(a)(2)(ii)(B) due diligence.

HDS's security policies and procedures are owned by its security function and reviewed on a defined cadence. They are referenced throughout this matrix as the administrative backing for the technical controls. The implementer cannot inherit these policies for its own organisation, but can cite HDS's programme where HDS operates the underlying system.

HDS's documentation-and-retention policy defines what is documented, where it is held, and how versions are preserved. Operational records (activity reviews, assessments, incident reports) are retained as written artefacts; the per-user audit log (Pryv layer) supplies the automatic operational record. The implementer keeps the equivalent documentation for its own programme.

The six-year minimum applies to HDS's own policies, procedures and assessment records for the systems it operates. Retention beyond the minimum, and any pruning, follow HDS's documented retention schedule. For subject-level data and audit records, retention is configured per the implementer's lawful basis and contractual instructions; the implementer retains its own documentation independently.

HDS's documentation-and-retention policy sets the review cadence and the triggers (infrastructure change, new threat, incident, regulatory change) that prompt an out-of-cycle update. Each policy and register carries its review history. The implementer runs its own review cycle for the documentation it owns.

Every workforce, app, and counterparty action on PHI is mediated by an access whose permissions bound the streams and levels reachable. HDS configures no use or disclosure of customer PHI for its own purposes, and the audit log makes each use attributable to a specific access at a specific time.

A common pattern separates accesses by purpose — one per treatment, billing and operations workflow — so the TPO classification becomes a durable artefact rather than a verbal claim. HDS stores the purpose tag and preserves it across the access version chain.

The §164.508(c) elements map onto access and client-data fields: the information disclosed onto permissions, the recipient onto the access counterparty, the signature equivalent onto the auditable grant act, the expiration onto the access expiry, and the right to revoke onto access deletion. HDS ships the primitives; presenting the §508(c) elements at the grant moment is the covered entity's UX responsibility.

The opportunity-to-agree-or-object construct is operational and circumstance-driven. HDS stores the offered choice and the recorded response so the §164.510 determination is reconstructable later.

The recommended pattern mints a purpose-specific access per §512 invocation, records the disclosure category and statutory basis, executes the disclosure, then revokes the access. The audit trail shows the full lifecycle attached to the legal-basis claim.

A typical layout keeps identified events on a restricted clinical stream tree and de-identified projections on a parallel tree accessible to a broader analyst group. The de-identification logic is the covered entity's application code; HDS stores its output.

HDS facilitates a stream topology where distinct purposes live on distinct subtrees and per-purpose accesses point at the smallest necessary subtree, avoiding blanket permissions except for stated unrestricted roles. The same discipline is applied to HDS's own operational telemetry, whose contents are evidenced as carrying no PHI and no individually identifiable health information: the operator channel is a place minimum-necessary can quietly fail, so it is evidenced rather than assumed.

The customer-facing authentication surface is where the notice typically appears at grant time, and HDS stores the presented notice as a durable artefact bound to the individual's session. A template and process for ingesting and displaying a covered entity's own notice through HDS software are not yet formalised; HDS records that as pending remediation, activated when a covered-entity engagement requires it. Separately, HDS plans to publish a notice-style privacy statement of its own, as good practice and because equivalent transparency is required under other regimes it operates within. That is a voluntary undertaking, not a §164.520 duty.

HDS applies directly only those restrictions sitting in platform configuration it controls, and routes to the responsible covered entity any request belonging to a covered-entity relationship, since that decision is theirs. Stated response times are 30 days where HDS does not control the outcome and 60 days where it applies a restriction it does, each with one 30-day extension. The how-to guide and a formal intake for requests reaching HDS directly are not yet formalised, which HDS records as pending remediation. Post-HITECH §522(a)(1)(vi) makes a restriction on disclosure to a health plan for out-of-pocket-paid services mandatory on request; the configuration pattern is identical, but a covered entity must apply it without discretion when that condition is met.

Events return as canonical JSON validated against the data-type schemas — structured, machine-readable and consumer-friendly — and attachments download in their stored MIME type. The 30-day response timeline is the covered entity's process target, not a software latency, and any non-native export format is produced by the implementer's portal.

For denied amendments where the individual files a statement of disagreement, the statement can be stored as a separate event on the designated-record-set stream linked back to the original, so the disagreement travels with the data on subsequent disclosures.

Each accounting field has an audit-log source: date from the row timestamp, recipient from the access holder or counterparty, description from the recorded API method and path, and purpose from the access purpose tag. The audit log does not capture request bodies, so the description is at the API-shape level — sufficient under §164.528 and favourable for data minimisation.

HDS names a responsible official and a contact point as a matter of its own programme. The covered entity's privacy-official designation is a programme element outside HDS's scope.

Audit and observability data can make training effectiveness measurable by revealing whether access patterns match policy after training, but the training content and record-keeping belong to the implementer.

See the HIPAA-Security rows for the technical safeguards HDS operates and the physical-safeguard coverage of the hosting environment. Together they constitute the §530(c) technical and physical answer; the administrative safeguards remain the covered entity's.

HDS exposes access deletion to revoke an offending counterparty and operates the backup-restore capability across every region; the mitigation decision and any breach notification follow the covered entity's process.

Where an exception applies, the implementer leaves the access scoped per that exception's permission; HDS records the broader access so it remains accountable. The substantive minimum-necessary policy is the covered entity's. On HDS's own side, the operational telemetry it collects as operator is evidenced as carrying no PHI and no individually identifiable health information.

Cross-platform business-associate arrangements inherit the cross-account capability pattern. The access carries its business-associate role and contract reference so disclosures are attributable to the BAA, while the contract itself is signed between the parties.

Storing complaints and dispositions as data makes the §530(d)(2) documentation requirement a byproduct of normal record-keeping. The intake workflow and response are the implementer's.

The policy's enforceability rests on the workforce having acknowledged the policy set, which is tracked separately rather than asserted here: sanctioning someone against a policy they never acknowledged is the weak point that tracking exists to close. The covered entity's sanction programme is outside HDS's scope.

HDS provides no technical control bearing on this requirement; it is a conduct obligation of the covered entity.

Policies-as-data on a dedicated compliance stream inherit versioning, retention and audit. The covered entity's policy programme is its own; HDS documents the policies governing its operations.

The access records the relationship, the involved person's role, and the individual's opportunity-to-object record. HDS stores and enforces the narrowed scope; the disclosure decision is the implementer's.

A per-instance access carries the public-health-authority recipient and the statutory basis; the audit trail preserves the disclosure. HDS makes no public-health disclosure of customer PHI on its own initiative.

The access carries the specific §512(f) basis vocabulary; HDS stores and audits the disclosure but makes no law-enforcement disclosure of customer PHI on its own initiative outside legal process served on it.

The request-intake artefact records receipt time and the resulting due date. The substantive response is delivered through the §164.524 access capability described in the parent row. Self-service via app-portability eliminates the need for a §524(b)(2) timely-response procedure on the individual-direct path, which is the vault's own case. The timeline obligation remains operative on the partner-mediated path, where a covered entity takes the request in and HDS fulfils it under whatever agreement is in force between them.

HDS operates the standard read path that returns structured, machine-readable PHI. The app-portability tool (portability.hds.ngo) packages it into ZIPs the individual can keep or forward to another covered entity. Non-native formats and summaries are built by the implementer's portal from the same source events.

The exception pattern narrows or deletes the representative's access. HDS stores the representative relationship and legal basis; the determination of whether an exception applies is the implementer's. Where a covered entity is party to the relationship it verifies the representative's legal authority before instructing HDS, and HDS does not independently adjudicate that status. On the direct-to-individual path, which is the vault's own case, HDS has no written intake or verification procedure for representative status yet, and no evidence template; it records that as pending remediation rather than implying the check exists.

The access carries the statute reference; the audit trail preserves the disclosure. HDS responds to legal process served on it under applicable law, and under the terms of a BAA wherever one is in force.

HDS documents that de-identification is the covered entity's responsibility; the platform simply persists whatever events the implementer's de-identification process produces.

With the alias path, the aliased access exposes only the alias and the covered entity re-identifies by resolving it through the platform — the code is used for no other purpose. With an explicit map, the mapping lives on a dedicated subtree with access permitted only to the re-identification role; HDS enforces the scope and stores the mapping, and ensuring the code is random or derived from non-PHI is the implementer's.

Pre-computing per-subject accounting reports and storing them on a dedicated stream keeps the §528 response window tractable. Compiling and delivering the accounting is the covered entity's process. The app-portability tool ships the unfiltered audit-event stream (with timestamps, requesting access tokens, methods invoked) — sufficient source material for the covered entity to assemble the formal §528(b) accounting.

HDS is not a business associate in the vault, so no BAA governs that arrangement. It does execute BAAs for the separate arrangement in which an organisation places protected health information with it on its own behalf, and flows the obligations down to its own subcontractors. The access tags and audit log support enforcement and evidence of the §164.504(e) terms.

The plan-document amendment and certification are entirely the covered entity's contractual obligations.

HDS neither enables nor restricts good-faith whistleblower disclosures beyond ordinary access controls. What it holds is the organizational half: a written non-retaliation position inside the sanctions policy, so a workforce member making a §502(j) disclosure is not exposed to the graduated-sanctions process for having made it. The audit trail of a disclosing person's access remains available as evidence in subsequent proceedings. The implementer still states the protection in their own policies; HDS's control binds HDS's own workforce.

Subpart D binds covered entities and business associates. HDS holds neither role in the vault, where every access flows from the individual's own consent, so this row is the map for an implementer that does hold one rather than a statement of an HDS duty. Its practical effect is to set the boundary the encryption and risk-assessment rows below refine: what counts as unsecured PHI in an HDS deployment is governed by the transit, at-rest and in-use posture described under 164.402(2), where media exposures of at-rest content fall inside the safe harbor and live-system compromises do not.

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.

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.

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).

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. Where no covered entity is party to the relationship, which is the vault's own case, HIPAA does not reach the event at all and any duty to notify individuals arises under the FTC Health Breach Notification Rule, which sets its own delivery requirements. This matrix has no scope for that rule yet.

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.

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.

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.

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.

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.

The approved procedure defines discovery, escalation, content assembly and upstream notification with the 60-day ceiling. It governs that out-of-matrix arrangement, and is available on request as a model an implementer can adopt. The per-user audit log is the data source for the identities-of-affected-individuals element and for the timing evidence behind "without unreasonable delay". An implementer that is itself a business associate to a covered entity and stores protected health information on HDS uses the same evidence for its own upstream notification chain.

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.

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.