HDS compliance-matrix

Where Health Data Safe stands

HDS runs a documented compliance programme across four frameworks. This page is about HDS itself: the role it holds under each one, what its position rests on, and what it is still working on. For what HDS carries on your behalf, see the implementer view.

144 of 229 requirements across 4 frameworks are answered from approved HDS documentation, released on request under NDA, signed BAA or audit engagement.

General Data Protection Regulation

EU + EEA (extraterritorial via Art. 3) CHUS ยท 47 requirements

3 of 47

requirements answered from approved HDS documentation ยท 38 more evidenced, documentation still in review

Individual holds the account Controller

The individual's vault. HDS determines the purposes and means of operating it, so HDS is the Art.4(7) controller. Data enters only with the individual's explicit consent, and the individual decides who may access it afterwards.

HDS operates a GDPR programme rather than holding a GDPR credential. A Data Protection Officer was designated on 2026-07-17, a controller-side record of processing activities under Art.30(1) is maintained with eight live activities, and the platform supplies the technical measures the articles require. The Art.30(2) processor record is deliberately empty: HDS processes on no controller's instructions, so there is nothing true to record there. This is the least settled of the four frameworks on paper: three requirements rest on fully approved documentation and thirty-eight more are evidenced by documents still in review. The two material open items are the transfer stack for the US hosting layer, where the AWS DPA, the EU and Swiss standard contractual clauses and the transfer impact assessment are not yet executed, and HDS's own DPIA process, which is drafted but not yet operating.

What building on HDS does not create. HDS is not an Art.28 processor for this product, and the matrix does not offer that arrangement. Art.28(3) requires processing on the controller's documented instructions, assistance with data subject rights, and deletion or return of the data at the controller's choice. HDS acts on the individual's permissions, the individual exercises their rights directly from their own dashboard, and HDS cannot delete an individual's vault at a third party's direction. An organisation that receives data an individual chose to share with it is an independent controller of what it holds, not a controller instructing HDS. Any future engagement in which HDS genuinely does process on instructions falls outside this matrix and carries its own documentation.

Read the requirement rows โ†’
self-assessed
6 open items HDS is tracking
  • high Nothing is on file evidencing the Swiss hosting region's physical and environmental controls. The safeguards HDS inherits there are asserted by the provider rather than evidenced by a third-party audit, and the provider's public encryption statement is a product claim, not an attestation. ๐Ÿ”’ hipaa/registers/hosting-provider-attestations
  • high Art.46 transfer stack for the US hosting layer is not executed: the AWS GDPR DPA, EU and Swiss SCCs and the transfer impact assessment are all outstanding. Art.46
  • medium The Art.30 register carries no retention period on the recruitment, CRM and contact-mailbox rows, and its Art.30(2) half stays empty until the first partner DPA is signed. Art.30
  • medium Art.32 encryption rests on provider-managed keys. End-to-end or operator-held-key encryption, where the server never holds plaintext, is queued upstream and not shipped. Art.32
  • medium The audit.onUserDelete pseudonymise mode is refused at boot upstream, so the Art.17 erasure story is complete only in its erase and keep modes. Art.17
  • low HDS's own DPIA process is drafted internally but is not yet a running procedure with a first executed assessment. Art.35
Certificates HDS relies on but does not hold
  • AWS ISO/IEC 27001, 27017 and 27018 (us region hosting layer, obtained 2026-07-28)

These belong to the hosting providers and cover their infrastructure, not HDS's own practices.

HIPAA 3 rules

US US ยท 91 requirements

85 of 91

requirements answered from approved HDS documentation ยท 3 more evidenced, documentation still in review

Individual holds the account Does not apply

Every vault. The individual holds the account and decides who may see the data, so HDS holds it for them and never on a covered entity's behalf, whoever put it there and wherever it physically sits. A business associate is defined by acting on a covered entity's behalf, so HDS is not one here and HIPAA does not reach it.

What building on HDS does not create. Consent is not delegation. When an individual grants a clinician or an application access to their own vault, that access flows from their consent, not from anyone instructing HDS, so it creates no business associate relationship: not with the clinician, not with the application, and not with HDS. The data sitting on HDS infrastructure does not change on whose behalf it is held. Where an organisation would place protected health information with HDS on its OWN behalf, a BAA would be required; that arrangement is documented separately and is outside this matrix. The requirements below remain the map for an implementer that holds a HIPAA role of its own, and the FTC Health Breach Notification Rule and state consumer-health-data law are what reach the user-sovereign case instead.

HIPAA-Security

HIPAA does not reach HDS in the vault, so what follows is not a claim that HDS meets the Security Rule: it is what the platform supplies to an implementer that does hold a role. All forty-three requirements are answered from HDS documentation, and forty of them rest entirely on documents that have completed approval; the other three cite a procedure-execution record still in review, which is the evidence that the control actually ran on the date claimed. The safeguards behind those answers are live rather than paper: a risk analysis and risk-management plan are approved, workforce training runs continuously against a completion register, and backups run on a daily timer on both regional cores, first verified live on 2026-07-30, with a first restore rehearsal executed on 2026-07-29. Recovery at production scale is not yet demonstrated, nine requirements carry remediation HDS has committed to and not delivered, and encryption at rest uses provider-managed keys.

HIPAA-Privacy

HIPAA does not reach HDS in the vault. Thirty-three of the thirty-five requirements are answered from approved HDS documentation, which is what an implementer holding a covered-entity or business-associate role inherits when it builds here. Most of this rule is the covered entity's to discharge in any case. What the platform supplies directly is the individual-rights machinery, access, amendment, accounting of disclosures and restriction, each an approved procedure, exercised in rehearsal rather than against production volume.

HIPAA-Breach

HIPAA does not reach HDS in the vault, but the question this rule turns on is one the platform can answer: who was affected and what did they hold. The breach-scope primitive is deployed to every core with the access index backfilled, so the blast radius of a compromised token is enumerated rather than estimated, and twelve of the thirteen requirements are answered from approved documentation. The notification procedure is approved and rehearsed; no real reportable breach has exercised it.

Read the requirement rows โ†’
self-assessed
5 open items HDS is tracking
  • high Addressable encryption at rest rests on provider-managed keys. Neither customer-managed keys nor end-to-end encryption is available, so a compromise of the hosting layer is not cryptographically contained. 164.312(a)(2)(iv)
  • medium Platform telemetry is mid-migration from a removed vendor agent to a self-hosted collector; the information-system activity review depends on that pipeline landing. 164.308(a)(1)(ii)(D)
  • high Nothing is on file evidencing the Swiss hosting region's physical and environmental controls, which is where the primary store sits. The safeguards inherited there are asserted by the provider, not evidenced by a third-party audit. 164.310(d)(1) ๐Ÿ”’ hipaa/registers/hosting-provider-attestations
  • medium Thirty-two of thirty-five rows are unreviewed drafts. The positions are stated but not second-read. ๐Ÿ”’ hipaa/policies/privacy-practices
  • medium No row in this scope has completed review, and the notification procedure has never run against a real incident. ๐Ÿ”’ procedures/security-incident-and-breach
Certificates HDS relies on but does not hold
  • AWS ISO/IEC 27001 (us-east-1 named in the certified locations), 27017, 27018 โ€” obtained 2026-07-28

These belong to the hosting providers and cover their infrastructure, not HDS's own practices.

SOC 2 โ€” AICPA Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy)

United States (AICPA) USCH ยท 61 requirements

45 of 61

requirements answered from approved HDS documentation ยท 16 more evidenced, documentation still in review

Individual holds the account Service organisation

HDS is the service organisation operating the vault; an organisation building on it is a user entity. The hosting providers are subservice organisations, carved in or out depending on the criterion.

Forty-five of the sixty-one Trust Services Criteria are answered from approved HDS documentation, and the remaining sixteen are evidenced by documents still moving through review. This is a readiness map: it shows which criteria the existing control environment already meets, which is what a service organisation needs before engaging an auditor. It is not an audit and confers no opinion. Twelve criteria carry open remediation, including change management, vendor management and a tamper-evident audit log.

Read the requirement rows โ†’
self-assessed, no external audit
4 open items HDS is tracking
  • high No SOC 2 examination has been engaged, so there is no report to give a user entity that asks for one. ๐Ÿ”’ soc2/policies/system-description
  • medium A written change-management process with ticketed approvals, per-change test evidence and rollback is drafted but not operating. CC8.1
  • medium A formal vendor-management programme with scored risk tiers and scheduled re-assessment is drafted but not operating. CC9.2
  • medium The audit log is append-only by convention with no hash chain or signed checkpoint, so it is not tamper-evident against a host-level admin. PI1.5
Certificates HDS relies on but does not hold
  • AWS SOC 2 (hosting layer only, as a subservice organisation)

These belong to the hosting providers and cover their infrastructure, not HDS's own practices.

Swiss Federal Act on Data Protection (revised FADP / nLPD)

Switzerland (extraterritorial via Art. 3 for processing affecting CH) CH ยท 30 requirements

11 of 30

requirements answered from approved HDS documentation ยท 13 more evidenced, documentation still in review

Individual holds the account Controller

The individual's vault. HDS determines the purposes and means of operating it, so HDS is the controller under the Act. Data enters only with the individual's explicit consent, and the individual decides who may access it afterwards.

Swiss residency is the strongest part of this position: the ch region runs on Swiss infrastructure and the data does not leave it, which is what most of this Act's residency and transfer concern is about. Thirteen of the thirty requirements rest on approved documentation and eleven more are evidenced by documents in review, the same pipeline as the GDPR. Six articles are recorded as out of scope because they address federal bodies or obligations that attach only to the controller, marked on the rows themselves rather than omitted.

What building on HDS does not create. HDS is not an processor for this product, and the matrix does not offer that arrangement. Acting as a processor would require processing on a controller's instructions and returning or deleting the data at its choice. HDS acts on the individual's permissions, the individual exercises their rights directly from their own dashboard, and HDS cannot delete an individual's vault at a third party's direction. An organisation that receives data an individual chose to share with it is an independent controller of what it holds, not a controller instructing HDS. Any future engagement in which HDS genuinely does process on instructions falls outside this matrix and carries its own documentation.

Read the requirement rows โ†’
self-assessed
3 open items HDS is tracking
  • high Nothing is on file evidencing the Swiss hosting region's physical and environmental controls. The safeguards HDS inherits there are asserted by the provider rather than evidenced by a third-party audit, and the provider's public encryption statement is a product claim, not an attestation. ๐Ÿ”’ hipaa/registers/hosting-provider-attestations
  • medium The processor-side register lacks retention periods on the recruitment, CRM and contact-mailbox activities, the same gap as the GDPR Art.30 row. Art.12
  • medium Only one of the thirty rows has completed review. The rest are drafts that state HDS's position but have not been checked by a second reader. ๐Ÿ”’ gdpr/registers/records-of-processing

How to read this page

Each requirement is answered from HDS's own documentation, and the document behind it is named by code on the requirement row. A requirement counts above only when every document it cites has completed internal approval. Open items are listed on each framework rather than omitted, and every framework page carries the same detail at requirement level.

HDS's compliance programme is self-assessed: it has not been examined by an external auditor, and HDS holds no certification or attestation of its own. Where certificates appear, they belong to the hosting providers and cover their infrastructure. HDS is a non-profit foundation and states this plainly so you can weigh it yourself.

Not legal advice; confirm your obligations with qualified counsel.