HIPAA Security Rule HIPAA-Security

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 four child specifications each carry their own row where the contribution is more concrete. 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.

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. The documented review procedure HDS runs as operator is available on request.

This is an organisational designation, not a software control. HDS holds the designation as an operator artefact; the assigned official draws on the audit log, monitoring and this matrix as operational substrate. A partner running ePHI on HDS names their own security official.

HDS operates the access-token model so that ending or changing a workforce member's access is an immediate, audited operation rather than a manual clean-up across systems. Full revocation removes the token; narrowing reduces permissions while preserving the access identity and its history. HDS documents the termination procedure it follows for its own workforce; partners apply the same primitives to their own staff.

Access grants carry the streams and levels the grantee may exercise, plus free-form metadata such as workforce role, granting administrator and business reason. HDS operates this as the authoritative authorization mechanism for ePHI; there is no trust-based bypass path. HDS documents its own authorization policy and partners apply the same primitive.

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 documents its own establishment-and-review cadence; partners apply the same primitives.

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. Formal, verified security-awareness training is a known gap being matured; each partner runs its own reminder programme for its own workforce.

HDS's hosting environment carries malware-protection controls as part of operator-side infrastructure hardening, described privately and cited as an internal document. The platform software itself includes no antivirus. Partners must protect their own workstations and any infrastructure they operate outside HDS.

HDS surfaces login and authentication-failure events through the audit log and layers monitoring on top to detect anomalous rates. The platform does not by itself lock accounts after N failures; HDS operates additional rate-limiting and alerting at the infrastructure boundary, documented privately. 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.

HDS runs the backup primitive on a schedule and documents the plan (frequency, location, encryption-at-rest applied at the storage boundary). Verified, automatically tested backups are a known gap being matured; the backup plan as it stands is cited as an internal document. 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 runbook it operates; contingency-plan testing is tracked separately (see the testing-and- revision specification, a known gap). Partners running their own deployments document their own plan.

HDS treats emergency-mode operation as a documented runbook layered on the platform's HA topology and backup-restore path. The definition of critical business processes and the emergency procedures 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 intended cadence and revision process and is maturing verified, scheduled execution. 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, and the platform's automated test suite as ongoing effectiveness evidence. HDS documents the cadence and findings; 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.

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. 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. 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. Note: platform at-rest encryption of bulk event data is not yet shipped, so media leaving the production environment must be encrypted by the implementer's own at-rest layer before transport — 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.

Emergency access is supported by an operator-held privileged access capability treated as a custody-controlled credential. Because every call made under it is audited like any other, post-emergency review is concrete and the break-glass event is reconstructable. HDS configures and safeguards the mechanism; the implementer authors the emergency-access procedure (triggers, authorisers, mandatory after-action review) on top of it.

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. HDS documents the configured defaults; the implementer tunes them and documents the rationale for the chosen inactivity window (the "Addressable" path).

This is a known gap and is stated plainly: the platform does not yet encrypt event content with a platform-managed key. HDS covers at-rest protection at the infrastructure layer using the hosting provider's storage/volume encryption in each region, and TLS covers the transmission half (see §164.312(e)). HDS documents the at-rest posture and the boundary it does not yet cover so implementers can assess residual risk and apply additional at-rest controls where their risk analysis requires.

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. 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. Improper destruction is mitigated by per-user export/backup as a recovery path. The audit log ties every change to an authenticated access identity. 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 must present a valid access token, so the platform verifies the requester before any access is granted. HDS operates this stack and can require multi-factor authentication where the implementer's risk profile calls for it; the achievable assurance level depends on which factor method is configured. HDS documents the authentication policy in effect; the implementer decides whether to require MFA universally or per-role.

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), where the platform gap is noted.

When a partner acting as a Covered Entity or upstream Business Associate processes ePHI on HDS, HDS is their Business Associate. HDS offers the BAA template (templates/baa), supplies the technical-safeguards evidence the contract relies on, and flows obligations down to its own subcontractors via back-to-back agreements tracked in the BAA register.

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.